Subject: Re: [tram] TURN over WebSocket

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 1 Dec 2014 17:06:00 +0000

I think HTTPbis WG is discussing that explicit proxy is preferred over transparent proxy.

-Tiru

From: Sergio Garcia Murillo [mailto:[email-masked]]
Sent: Monday, December 01, 2014 9:27 PM
To: Tirumaleswar Reddy (tireddy); Simon Perreault; Victor Pascual Avila
Cc: [email-masked]; [email-masked]
Subject: Re: [tram] TURN over WebSocket

Transparent proxying for example

Best regards
Sergio

On 01/12/2014 16:49, Tirumaleswar Reddy (tireddy) wrote:
https://tools.ietf.org/html/draft-ietf-httpbis-tunnel-protocol-00 already solves the problem with firewall only permitting HTTP(S) flows through a proxy. Please explain the firewall configuration in which the above technique will not work.

-Tiru

From: tram [mailto:[email-masked]] On Behalf Of Simon Perreault
Sent: Monday, December 01, 2014 8:45 PM
To: Victor Pascual Avila
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [tram] TURN over WebSocket

On Mon, Dec 1, 2014 at 4:10 AM, Victor Pascual Avila <[email-masked]<mailto:[email-masked]>> wrote:
Shall we create a new milestone for this?

All,

Note that this question from Victor is intended for the working group. The chairs are in listening mode! :)

Simon

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 1 Dec 2014 20:49:02 +0000

I prefer explicit proxies too.  Unfortunately, many networks where my customers are located deploy transparent proxies anyway.

On Dec 1, 2014, at 12:06 PM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:

-Tiru

Best regards
Sergio

-Tiru

All,

Simon

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

---

From: Oleg Moskalenko <[email-masked]>
Date: Mon, 1 Dec 2014 13:05:20 -0800

Yeah... That is the main problem.

Sent from my iPhone

> On Dec 1, 2014, at 12:49 PM, Jonathan Lennox <[email-masked]> wrote:
> 
>> On Dec 1, 2014, at 12:06 PM, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:
>> 
>> On Mon, Dec 1, 2014 at 4:10 AM, Victor Pascual Avila <[email-masked]> wrote:
>> [email-masked]
> [email-masked]

---

From: Brandon Williams <[email-masked]>
Date: Mon, 01 Dec 2014 17:51:00 -0500

Does this websockets approach actually work for those customers who are 
behind transparent proxies? And is it intentional that it works? Or will 
it be disabled once someone notices that their transparent proxy is 
being misused (in their opinion)? I'm just curious whether someone has 
seen this approach work reliably on the Internet. I'm always a bit 
dubious of methods that look like they're intended to circumvent 
someone's security architecture (whether or not that's the true intent).

--Brandon

On 12/01/2014 04:05 PM, Oleg Moskalenko wrote:
> On Dec 1, 2014, at 12:49 PM, Jonathan Lennox <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> I prefer explicit proxies too.  Unfortunately, many networks where my
>> customers are located deploy transparent proxies anyway.
>>
>> On Dec 1, 2014, at 12:06 PM, Tirumaleswar Reddy (tireddy)
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>> *From:*Sergio Garcia Murillo [mailto:[email-masked]]
>>> *Sent:*Monday, December 01, 2014 9:27 PM
>>> *To:*Tirumaleswar Reddy (tireddy); Simon Perreault; Victor Pascual Avila
>>> *Cc:[email-masked]
>>> <mailto:[email-masked]>;[email-masked]
>>> <mailto:[email-masked]>
>>> *Subject:*Re: [tram] TURN over WebSocket
>>>     https://tools.ietf.org/html/draft-ietf-httpbis-tunnel-protocol-00already
>>>     solves the problem with firewall only permitting HTTP(S) flows
>>>     through a proxy. Please explain the firewall configuration in
>>>     which the above technique will not work.
>>>     -Tiru
>>>     *From:*tram [mailto:[email-masked]]*On Behalf Of*Simon
>>>     Perreault
>>>     *Sent:*Monday, December 01, 2014 8:45 PM
>>>     *To:*Victor Pascual Avila
>>>     *Cc:[email-masked]
>>>     <mailto:[email-masked]>;[email-masked]
>>>     <mailto:[email-masked]>
>>>     *Subject:*Re: [tram] TURN over WebSocket
>>>     On Mon, Dec 1, 2014 at 4:10 AM, Victor Pascual Avila
>>>     <[email-masked]
>>>     <mailto:[email-masked]>> wrote:
>>>     Note that this question from Victor is intended for the working
>>>     group. The chairs are in listening mode! :)
>>>     Simon
>>>
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 2 Dec 2014 04:45:08 +0000

Yes, but the problem is transparent proxy acts as MIM (without the consent of the user). http://tools.ietf.org/html/draft-nottingham-http-proxy-problem-00#section-6.1 discusses this issue.

-Tiru

From: Jonathan Lennox [mailto:[email-masked]]
Sent: Tuesday, December 02, 2014 2:19 AM
To: Tirumaleswar Reddy (tireddy)
Cc: Sergio Garcia Murillo; Simon Perreault; Victor Pascual Avila; [email-masked]; [email-masked]
Subject: Re: [tram] TURN over WebSocket

-Tiru

Best regards
Sergio

-Tiru

All,

Simon

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 02 Dec 2014 10:36:13 +0100

More arguments in favor of adopting this draft.

If transparent proxies are considered MITM, then there should be no 
objections about bypassing any IT security mechanism. And we will allow 
webrtc to work on an scenario that currently doesn't work.

Best regards
Sergio

On 02/12/2014 5:45, Tirumaleswar Reddy (tireddy) wrote:
>
> Yes, but the problem is transparent proxy acts as MIM (without the 
> consent of the user). 
> http://tools.ietf.org/html/draft-nottingham-http-proxy-problem-00#section-6.1 
> discusses this issue.
>
> -Tiru
>
> *From:*Jonathan Lennox [mailto:[email-masked]]
> *Sent:* Tuesday, December 02, 2014 2:19 AM
> *To:* Tirumaleswar Reddy (tireddy)
> *Cc:* Sergio Garcia Murillo; Simon Perreault; Victor Pascual Avila; 
> [email-masked]; [email-masked]
> *Subject:* Re: [tram] TURN over WebSocket
>

---

From: Simon Perreault <[email-masked]>
Date: Tue, 2 Dec 2014 08:07:41 -0700

On Mon, Dec 1, 2014 at 9:45 PM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

> Yes, but the problem is transparent proxy acts as MIM (without the consent
> of the user).

IMHO arguing that "transparent proxies are wrong", or "transparent proxies
are not the IETF's preferred way of doing things" is irrelevant. The fact
is that they are extremely common today and in the foreseeable future.

In fact, if "X is wrong" was a good reason to not work around X, then
STUN/TURN/ICE would not exist (with X = NATs).

Simon

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 2 Dec 2014 16:34:00 +0000

Hi Simon,

Transparent proxies like firewalls keep getting upgraded frequently to handle new applications, threats etc. If firewall has a feature to block WebRTC traffic then by sending traffic over WebSocket will not solve the problem.

Cheers,
-Tiru

From: Simon Perreault [mailto:[email-masked]]
Sent: Tuesday, December 02, 2014 8:38 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Jonathan Lennox; Sergio Garcia Murillo; Victor Pascual Avila; [email-masked]; [email-masked]
Subject: Re: [tram] TURN over WebSocket

On Mon, Dec 1, 2014 at 9:45 PM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
Yes, but the problem is transparent proxy acts as MIM (without the consent of the user).

IMHO arguing that "transparent proxies are wrong", or "transparent proxies are not the IETF's preferred way of doing things" is irrelevant. The fact is that they are extremely common today and in the foreseeable future.

In fact, if "X is wrong" was a good reason to not work around X, then STUN/TURN/ICE would not exist (with X = NATs).

Simon

---

From: Simon Perreault <[email-masked]>
Date: Tue, 2 Dec 2014 09:49:12 -0700

On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

> Transparent proxies like firewalls keep getting upgraded frequently to
> handle new applications, threats etc. If firewall has a feature to block
> WebRTC traffic then by sending traffic over WebSocket will not solve the
> problem.

(As a participant...)

This has also been discussed before. TURN-over-WebSockets is not a way for
applications to circumvent policy.

The problem is there are networks that are set up so that "the web" is
open, through a transparent proxy. WebRTC is part of "the web". Making TURN
fit the mould of "the web" is is not circumventing policy, it's making
WebRTC work. You should not need to update your proxy/firewall config for
WebRTC to just work if "the web" already does work.

Simon

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 02 Dec 2014 17:50:46 +0100

Hi Tiru,

We don't want to bypass any FW, in fact the ws connection is tagged as 
TURN so the IT policies can be enforced if webrtc is explicitly disabled.

Could you try to sum up what are you concerns about this draft so we can 
address them? Would be easier to discuss and move things forward.

Best regards
Sergio
On 02/12/2014 17:34, Tirumaleswar Reddy (tireddy) wrote:
> handle new applications, threats etc. If firewall has a feature to 
> block WebRTC traffic then by sending traffic over WebSocket will not 
> solve the problem.
>
> Cheers,
>
> -Tiru
>
> *From:*Simon Perreault [mailto:[email-masked]]
> *Sent:* Tuesday, December 02, 2014 8:38 PM
> *Cc:* Jonathan Lennox; Sergio Garcia Murillo; Victor Pascual Avila; 
> On Mon, Dec 1, 2014 at 9:45 PM, Tirumaleswar Reddy (tireddy) 
> IMHO arguing that "transparent proxies are wrong", or "transparent 
> proxies are not the IETF's preferred way of doing things" is 
> irrelevant. The fact is that they are extremely common today and in 
> the foreseeable future.
>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 02 Dec 2014 10:53:36 -0700

On 12/02/2014 09:49 AM, Simon Perreault wrote:
> 
> On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar Reddy (tireddy) <[email-masked] <mailto:[email-masked]>> wrote:
> 
> This has also been discussed before. TURN-over-WebSockets is not a way for applications to circumvent policy.
> 
> The problem is there are networks that are set up so that "the web" is open, through a transparent proxy. WebRTC is part of "the web". Making TURN fit the mould of "the web" is is not circumventing policy, it's making WebRTC work. You should not need to update your proxy/firewall config for WebRTC to just work if "the web" already does work.
> 

Yes, that is a fundamental point, IMO.  If a webrtc app is successfully loaded, then the underlying network stuff MUST work, and TURN over WS is the ultimate way that we have to make this happen.  If on the other hand a network admin does not want this to happen, then s/he should prevent the app to load, not make it fail in mysterious ways.  By using TURN over WS we are in fact obeying the admin intent, not going around it.

So, +1 for TURN over WS.

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 2 Dec 2014 19:04:11 +0000

Sent: Tuesday, December 02, 2014 10:19 PM

On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
Transparent proxies like firewalls keep getting upgraded frequently to handle new applications, threats etc. If firewall has a feature to block WebRTC traffic then by sending traffic over WebSocket will not solve the problem.

(As a participant...)

[TR] Okay, so looks like the problem can also be solved by running TURN over 443 similar to proposals in DPRIVE WG to run DNS over 443.

-Tiru

Simon

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 2 Dec 2014 20:21:47 +0100

El 02/12/2014 20:04, "Tirumaleswar Reddy (tireddy)" <[email-masked]>
escribió:
> Cc: Jonathan Lennox; Sergio Garcia Murillo; Victor Pascual Avila;
>
>
>
> [TR] Okay, so looks like the problem can also be solved by running TURN
over 443 similar to proposals in DPRIVE WG to run DNS over 443.

Good try! Unlucky enough, doesn't work.

Best regards
Sergio

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 2 Dec 2014 19:44:13 +0000

why will it not work when ALPN is used ?

-Tiru

From: Sergio Garcia Murillo [mailto:[email-masked]]
Sent: Wednesday, December 03, 2014 12:52 AM
To: Tirumaleswar Reddy (tireddy)
Cc: Jonathan Lennox; [ACME] Victor Pascual Avila; Simon Perreault; [email-masked]; [email-masked]
Subject: RE: [tram] TURN over WebSocket

El 02/12/2014 20:04, "Tirumaleswar Reddy (tireddy)" <[email-masked]<mailto:[email-masked]>> escribió:
>
> From: Simon Perreault [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: Jonathan Lennox; Sergio Garcia Murillo; Victor Pascual Avila; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Best regards
Sergio

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 2 Dec 2014 19:53:33 +0000

On Dec 2, 2014, at 2:04 PM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:

Unfortunately, this forces you to get two IPv4 addresses — one for your https server, one for your TURN server — since they both have to listen on port 443.  Due to IPv4 address exhaustion, this can be a substantial expense for small providers.

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 02 Dec 2014 21:26:17 +0100

We control the client and the server, and you are asking me to wait 
until what is not in our control is changed. Obviously, not working for me

BTW, I am talking about real life experiences, when WSS works and TURNS 
over 443 doesn't.

Best regards
Sergio

On 02/12/2014 20:44, Tirumaleswar Reddy (tireddy) wrote:
> *From:*Sergio Garcia Murillo [mailto:[email-masked]] ?
>
> *Sent:* Wednesday, December 03, 2014 12:52 AM
> *Cc:* Jonathan Lennox; [ACME] Victor Pascual Avila; Simon Perreault; 
> [email-masked]; [email-masked]
> *Subject:* RE: [tram] TURN over WebSocket
>
>
> [email-masked] 
> <mailto:[email-masked]>; 
> > On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar Reddy (tireddy) 
> > Transparent proxies like firewalls keep getting upgraded frequently 
> to handle new applications, threats etc. If firewall has a feature to 
> > This has also been discussed before. TURN-over-WebSockets is not a 
> way for applications to circumvent policy.
> >
> >
> >
> > The problem is there are networks that are set up so that "the web" 
> is open, through a transparent proxy. WebRTC is part of "the web". 
> Making TURN fit the mould of "the web" is is not circumventing policy, 
> it's making WebRTC work. You should not need to update your 
> proxy/firewall config for WebRTC to just work if "the web" already 
> does work.
> >
> >
> >
> > [TR] Okay, so looks like the problem can also be solved by running 
> TURN over 443 similar to proposals in DPRIVE WG to run DNS over 443.
> >
> >
>

---

From: Brandon Williams <[email-masked]>
Date: Tue, 02 Dec 2014 19:58:10 -0500

What part of ALPN is not under your control? If you're doing WSS, then 
you've already got TLS in the picture, so ALPN and WSS seem to both 
solve the server-side multiplexing problem from the original problem 
statement. What part of the problem statement does WSS solve that ALPN 
does not?

If you're concerned about unencrypted TURN multiplexing with unencrypted 
HTTP on port 80, then I can see WS solving a problem that ALPN can't solve.

--Brandon

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 3 Dec 2014 03:45:05 +0000

Agreed it's a problem and but can be resolved using draft-ietf-tram-alpn.

-Tiru

From: Jonathan Lennox [mailto:[email-masked]]
Sent: Wednesday, December 03, 2014 1:24 AM
To: Tirumaleswar Reddy (tireddy)
Cc: Simon Perreault; Sergio Garcia Murillo; Victor Pascual Avila; [email-masked]; [email-masked]
Subject: Re: [tram] TURN over WebSocket

Unfortunately, this forces you to get two IPv4 addresses - one for your https server, one for your TURN server - since they both have to listen on port 443.  Due to IPv4 address exhaustion, this can be a substantial expense for small providers.

---

From: Victor Pascual <[email-masked]>
Date: Tue, 2 Dec 2014 22:55:24 +0100

Agree with Sergio. We're experiencing the same

-Victor

> On Dec 2, 2014, at 9:26 PM, Sergio Garcia Murillo <[email-masked]> wrote:
> 
> We control the client and the server,       and you are asking me to wait until what is not in our control is changed. Obviously, not working for me
> 
> BTW, I am talking about real life experiences, when WSS works and TURNS over 443 doesn't. 
> 
> Best regards
> Sergio
> 
>> From: Sergio Garcia Murillo [mailto:[email-masked]] ?
>> El 02/12/2014 20:04, "Tirumaleswar Reddy (tireddy)" <[email-masked]>             escribió:
>> >
>> > On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:
>> >

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 3 Dec 2014 09:00:22 +0000

I would be good to close as many holes as possible with regards to webrtc connectivity but we have to be clear on which particular hole we are trying to close.

If I read the thread correctly it looks like the case we don’t currently have a solution for is when using a transparent proxy with unencrypted TURN on port 80.  I would like to understand why in the scenario that Sergio mentioned that WSS works but not TURNS over 443 and whether support for ALPN would fix that.

This is all about webrtc so I think there is an issue also with increasing complexity in the browser which needs to implement all the different mechanisms and also probably a bigger issue is getting the rtcweb working group and the browser vendors to support this mechanism and refer to it in draft-ietf-rtcweb-transports.

So I would say I am sympathetic to this but not yet totally convinced it closes a big enough hole to make it compelling for the browser vendors to implement.

Regards
Andy

From: tram [mailto:[email-masked]] On Behalf Of Victor Pascual
Sent: 02 December 2014 21:55
To: Sergio Garcia Murillo
Cc: Jonathan Lennox; [email-masked]; [ACME] Victor Pascual Avila; Tirumaleswar Reddy (tireddy); [email-masked]; Simon Perreault
Subject: Re: [tram] TURN over WebSocket

-Victor

On Dec 2, 2014, at 9:26 PM, Sergio Garcia Murillo <[email-masked]<mailto:[email-masked]>> wrote:
We control the client and the server, and you are asking me to wait until what is not in our control is changed. Obviously, not working for me

Best regards
Sergio

-Tiru

Cc: Jonathan Lennox; [ACME] Victor Pascual Avila; Simon Perreault; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Best regards
Sergio

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 03 Dec 2014 10:13:53 +0100

Hi Andrew,

Completely agree with your statements, my concerns are about been able 
to have the same level of connectivity in webrtc than in other 
proprietary solutions (like Skype/Webex).

In my setup I have TURN over udp and  tcp and TURNS at port 443, and I 
still having issues in some scenarios when TURN is failing to connect. 
In those scenarios I have no problems at all with the signaling which 
goes over WSS.

I don't have anything personal in favor of turn over ws, but I (and 
propably any company trying to do any kind of busyness arround webrtc) 
need a solution that can be deployed in a "months" time frame and not a 
"years" one, and that don't have the prerequisite of been in control of 
the intermediary elements (FW,s proxies, etc). So if there is any other 
solution easier and better than the one we are proposing I will be more 
than willing to collaborate with it.

Best regards
Sergio

On 03/12/2014 10:00, Hutton, Andrew wrote:
>
> I would be good to close as many holes as possible with regards to 
> webrtc connectivity but we have to be clear on which particular hole 
> we are trying to close.
>
> If I read the thread correctly it looks like the case we don’t 
> currently have a solution for is when using a transparent proxy with 
> unencrypted TURN on port 80.  I would like to understand why in the 
> scenario that Sergio mentioned that WSS works but not TURNS over 443 
> and whether support for ALPN would fix that.
>
> This is all about webrtc so I think there is an issue also with 
> increasing complexity in the browser which needs to implement all the 
> different mechanisms and also probably a bigger issue is getting the 
> rtcweb working group and the browser vendors to support this mechanism 
> and refer to it in draft-ietf-rtcweb-transports.
>
> So I would say I am sympathetic to this but not yet totally convinced 
> it closes a big enough hole to make it compelling for the browser 
> vendors to implement.
>
> Regards
>
> Andy
>
> *From:*tram [mailto:[email-masked]] *On Behalf Of *Victor Pascual
> *Sent:* 02 December 2014 21:55
> *To:* Sergio Garcia Murillo
> *Cc:* Jonathan Lennox; [email-masked]; [ACME] Victor Pascual Avila; 
> Tirumaleswar Reddy (tireddy); 
> [email-masked]; Simon Perreault
> On Dec 2, 2014, at 9:26 PM, Sergio Garcia Murillo 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     We control the client and the server, and you are asking me to
>     wait until what is not in our control is changed. Obviously, not
>     working for me
>
>         *From:*Sergio Garcia Murillo
>         [mailto:[email-masked]] ?
>
>         *Sent:*Wednesday, December 03, 2014 12:52 AM
>         *Cc:* Jonathan Lennox; [ACME] Victor Pascual Avila; Simon
>         Perreault; [email-masked] <mailto:[email-masked]>;
>         <mailto:[email-masked]>
>         El 02/12/2014 20:04, "Tirumaleswar Reddy (tireddy)"
>         <[email-masked] <mailto:[email-masked]>> escribió:
>         >
>         > Cc: Jonathan Lennox; Sergio Garcia Murillo; Victor Pascual
>         Avila; [email-masked]
>         > Transparent proxies like firewalls keep getting upgraded
>         frequently to handle new applications, threats etc. If
>         firewall has a feature to block WebRTC traffic then by sending
>         traffic over WebSocket will not solve the problem.
>         >
>         >
>         >
>         > (As a participant...)
>         >
>         >
>         > This has also been discussed before. TURN-over-WebSockets is
>         not a way for applications to circumvent policy.
>         >
>         >
>         >
>         > The problem is there are networks that are set up so that
>         "the web" is open, through a transparent proxy. WebRTC is part
>         of "the web". Making TURN fit the mould of "the web" is is not
>         circumventing policy, it's making WebRTC work. You should not
>         need to update your proxy/firewall config for WebRTC to just
>         work if "the web" already does work.
>         >
>         >
>         >
>         > [TR] Okay, so looks like the problem can also be solved by
>         running TURN over 443 similar to proposals in DPRIVE WG to run
>         DNS over 443.
>         >
>         >
>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 03 Dec 2014 10:19:47 +0100

Am I supposed to change every hotel, cafe or airport wifi in the world 
in order to make it work? That's what I mean.

Don't take me wrong, ALPN seems a good solution, as good as ipv6 is for 
removing NAT, but it is something out my control to have it deployed 
worldwide, so I can't rely on it as a solution. From a webrtc point of 
view we only control the client and the turn server, everything in 
between should be considered hostile.

Best regards
Sergio

On 03/12/2014 1:58, Brandon Williams wrote:
> If you're concerned about unencrypted TURN multiplexing with 
> unencrypted HTTP on port 80, then I can see WS solving a problem that 
> ALPN can't solve.
>
> --Brandon
>

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 3 Dec 2014 10:19:41 +0100

+1, edge cases are not so rare anymore, and we really don't want people
saying that WebRTC doesn't work.

Besides, as Sergio pointed out, the solution can be controllable both
by network admins that want to filter most of the non-web traffic but
want to allow WebRTC, and those who *really* want to prevent WebRTC as
well.

Lorenzo

On Wed, 03 Dec 2014 10:13:53 +0100
Sergio Garcia Murillo <[email-masked]> wrote:

> Hi Andrew,
> 
> Completely agree with your statements, my concerns are about been
> able to have the same level of connectivity in webrtc than in other 
> In my setup I have TURN over udp and  tcp and TURNS at port 443, and
> I still having issues in some scenarios when TURN is failing to
> connect. In those scenarios I have no problems at all with the
> signaling which goes over WSS.
> 
> propably any company trying to do any kind of busyness arround
> webrtc) need a solution that can be deployed in a "months" time frame
> and not a "years" one, and that don't have the prerequisite of been
> in control of the intermediary elements (FW,s proxies, etc). So if
> there is any other solution easier and better than the one we are
> proposing I will be more than willing to collaborate with it.
> 
> Best regards
> Sergio
> 
> > webrtc connectivity but we have to be clear on which particular
> > hole we are trying to close.
> >
> > currently have a solution for is when using a transparent proxy
> > with unencrypted TURN on port 80.  I would like to understand why
> > in the scenario that Sergio mentioned that WSS works but not TURNS
> > over 443 and whether support for ALPN would fix that.
> >
> > increasing complexity in the browser which needs to implement all
> > the different mechanisms and also probably a bigger issue is
> > getting the rtcweb working group and the browser vendors to support
> > this mechanism and refer to it in draft-ietf-rtcweb-transports.
> >
> > So I would say I am sympathetic to this but not yet totally
> > convinced it closes a big enough hole to make it compelling for the
> > browser vendors to implement.
> >
> > Regards
> >
> > Andy
> >
> > *From:*tram [mailto:[email-masked]] *On Behalf Of *Victor
> > Pascual *Sent:* 02 December 2014 21:55
> >         firewall has a feature to block WebRTC traffic then by
> > sending traffic over WebSocket will not solve the problem.
> >         >
> >         >
> >         >
> >         > (As a participant...)
> >         >
> >         >
> >         "the web" is open, through a transparent proxy. WebRTC is
> > part of "the web". Making TURN fit the mould of "the web" is is not
> >         circumventing policy, it's making WebRTC work. You should
> > not need to update your proxy/firewall config for WebRTC to just
> >         running TURN over 443 similar to proposals in DPRIVE WG to
> > run DNS over 443.
> >         >
> >         >
> >

---

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 3 Dec 2014 01:24:15 -0800

That is a good point. A solution must not require changing every wifi
network in the world. A "pure" ALPN  solution is a great way to kill the
whole WebRTC idea.

On Wed, Dec 3, 2014 at 1:19 AM, Sergio Garcia Murillo <
[email-masked]> wrote:

> Am I supposed to change every hotel, cafe or airport wifi in the world in
> order to make it work? That's what I mean.
>
> worldwide, so I can't rely on it as a solution. From a webrtc point of view
> we only control the client and the turn server, everything in between
> should be considered hostile.
>
> Best regards
> Sergio
>
>
>> you've already got TLS in the picture, so ALPN and WSS seem to both solve
>> the server-side multiplexing problem from the original problem statement.
>> What part of the problem statement does WSS solve that ALPN does not?
>>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 3 Dec 2014 10:47:32 +0000

ALPN only requires changes to the client and server. With TLS 1.3 ALPN will be encrypted and may not be any use to intermediate devices for any policy enforcement. I don't understand why ALPN cannot be used to solve this problem ?

-Tiru 

> -----Original Message-----
> Sent: Wednesday, December 03, 2014 2:50 PM
> To: Brandon Williams; Tirumaleswar Reddy (tireddy)
> Cc: [email-masked]; Jonathan Lennox;
> [ACME] Victor Pascual Avila; [email-masked]; Simon Perreault
> worldwide, so I can't rely on it as a solution. From a webrtc point of view we
> only control the client and the turn server, everything in between should be
> considered hostile.
> 
> Best regards
> Sergio
> 
> >>> > frequently
> >>> to handle new applications, threats etc. If firewall has a feature
> >>> to block WebRTC traffic then by sending traffic over WebSocket will
> >>> not solve the problem.
> >>> >
> >>> >
> >>> >
> >>> > (As a participant...)
> >>> >
> >>> >
> >>> Making TURN fit the mould of "the web" is is not circumventing
> >>> policy, it's making WebRTC work. You should not need to update your

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 03 Dec 2014 12:22:08 +0100

I will ask it otherwise.

I am in a hotel that allows http/https/wss/wss but turns on 443 doesn't 
work. How is ALPN supposed to help in that scenario?

Best regards
Sergio

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 3 Dec 2014 11:46:54 +0000

> Sent: Wednesday, December 03, 2014 4:52 PM
> To: Tirumaleswar Reddy (tireddy); Brandon Williams
> work. How is ALPN supposed to help in that scenario ?

How will the hotel firewall identify that it's TURN traffic sent over 443 ?

-Tiru

> > ALPN only requires changes to the client and server. With TLS 1.3 ALPN will
> be encrypted and may not be any use to intermediate devices for any policy
> enforcement. I don't understand why ALPN cannot be used to solve this
> problem ?
> >
> > -Tiru
> >
> we

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 03 Dec 2014 12:56:10 +0100

> How will the hotel firewall identify that it's TURN traffic sent over 443 ?

Ask the hotel wifi administrators... ;)

I don't know how it works (DPI most probably) but the fact is that I 
have found this kind of scenarios in real life.

BR
Sergio

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 3 Dec 2014 13:58:57 +0000

On: 03 December 2014 11:56 Sergio Garcia Murillo Wrote:
> Cc: [email-masked]; Jonathan
> Lennox; [ACME] Victor Pascual Avila; [email-masked]; Simon Perreault

If it is DPI detecting that the traffic looks like media then who is to say that the DPI will not block the media when it is going over a websockets connection.

Again, I am not saying this is a bad idea I just think we have to understand the problem very clearly.

Andy

---

From: Brandon Williams <[email-masked]>
Date: Wed, 03 Dec 2014 09:25:35 -0500

+1

On 12/03/2014 08:58 AM, Hutton, Andrew wrote:
>> Lennox;

---

From: Brandon Williams <[email-masked]>
Date: Wed, 03 Dec 2014 09:27:03 -0500

I'm sorry Sergio, but I simply don't understand why WSS would work but 
ALPN would not. Why would ALPN require changing "every hotel, cafe or 
airport wifi"? Are you saying that they are transparently terminating 
TLS sessions (in which case it's not just a wifi), and that they aren't 
forwarding the ALPN designator downstream? In the absence of a middlebox 
that splits the TLS session, I don't see why ALPN support would need to 
be present anywhere other than the client that the TURN relay.

--Brandon

---

From: Brandon Williams <[email-masked]>
Date: Wed, 03 Dec 2014 09:27:42 -0500

What am I missing? Why would ALPN require changing the wifi network? I 
can accept that it may be necessary, but in the absence of someone 
explaining why the wifi network needs to care, it really doesn't make 
sense to me.

--Brandon

On 12/03/2014 04:24 AM, Oleg Moskalenko wrote:
> On Wed, Dec 3, 2014 at 1:19 AM, Sergio Garcia Murillo
>     Am I supposed to change every hotel, cafe or airport wifi in the
>     world in order to make it work? That's what I mean.
>
>     Don't take me wrong, ALPN seems a good solution, as good as ipv6 is
>     for removing NAT, but it is something out my control to have it
>     deployed worldwide, so I can't rely on it as a solution. From a
>     webrtc point of view we only control the client and the turn server,
>     everything in between should be considered hostile.
>
>     Best regards
>     Sergio
>
>
>         What part of ALPN is not under your control? If you're doing
>         WSS, then you've already got TLS in the picture, so ALPN and WSS
>         seem to both solve the server-side multiplexing problem from the
>         original problem statement. What part of the problem statement
>         does WSS solve that ALPN does not?
>
>         unencrypted HTTP on port 80, then I can see WS solving a problem
>         that ALPN can't solve.
>
>         --Brandon
>
>                 [mailto:[email-masked]
>                 <mailto:[email-masked]>] ?
>
>                 [email-masked] <mailto:[email-masked]>;
>                 [email-masked]
>                 <[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>>
>                 escribió:
>                  >
>                  > From: Simon Perreault [mailto:[email-masked]
>                 <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>]
>                 [email-masked]
>                 <mailto:[email-masked]
>                 <mailto:[email-masked]>>__;
>                 <mailto:[email-masked] <mailto:[email-masked]>>
>                 <[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>>
>                 wrote:
>                  >
>     _________________________________________________
>     tram mailing list
>     https://www.ietf.org/mailman/__listinfo/tram
>     <https://www.ietf.org/mailman/listinfo/tram>
>
>

---

From: Brandon Williams <[email-masked]>
Date: Wed, 03 Dec 2014 09:28:13 -0500

Please explain why TURNS on 443 doesn't work in this context. The only 
thing that makes sense is that there is a restrictive device 
transparently terminating the TLS session (how is it able to do that 
without you knowing?). How else would it tell the difference between 
TURNS and HTTPS if it can't see the data? This is not called out as part 
of the use case anywhere in your document or the e-mail thread up to 
this point.

--Brandon

On 12/03/2014 06:22 AM, Sergio Garcia Murillo wrote:
>>>>>> <mailto:[email-masked]>]

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 03 Dec 2014 15:39:10 +0100

Maybe then is me the one I am missing something, can you explain how is 
ALPN meant to solve the problem if TURNS over 443 is blocked by the proxy?

Best regards
Sergio

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 03 Dec 2014 15:46:09 +0100

> Again, I am not saying this is a bad idea I just think we have to understand the problem very clearly.

Completely fair. I would love to provide more info, but unfortunately 
this kind of stuff doesn't happen on a controlled environment. I have 
got reports which show no relay candidates/reflexive candidates gathered 
and WSS signaling happening without issues.

There have been quite a lot of similar reports going on the mailing 
lists for quite some time.

Best regards
Sergio

---

From: Brandon Williams <[email-masked]>
Date: Wed, 03 Dec 2014 10:57:23 -0500

The only thing that makes sense to me to explain the problem you 
describe is that the proxy is splitting the TLS session so that it can 
view the data flow. If such a proxy only supports HTTP (and by extension 
Websockets) for the data flow, then it would make sense that TURNS over 
443 does not work. The piece I'm missing though is how the proxy could 
be splitting the TLS session in this way without you knowing, unless the 
client is accepting a certificate signed by someone else's CA. 
Nevertheless, if TLS splitting is what's happening and the proxy is 
rejecting data flows that do not look like HTTP, I can understand how 
WSS might resolve the problem under conditions where TURNS with ALPN 
might not.

That having been said, if I'm correct about the source of the problem, 
I'm conflicted about taking up work intended to make a proxy like this 
function for WebRTC. If TLS is being used solely for the purpose of 
firewall traversal, then it's OK to split the session. But what if that 
isn't the case? There are significant security implications associated 
with helping such a system to function transparently. I personally would 
rather see my WebRTC sessions fail than accept decryption by an unknown 
MITM.

Of course, it might be the case that something else is happening here 
and there is no decryption happening on the proxy, which returns me to 
the point that Andrew made ... I think we need to better understand the 
nature of the problem in order to decide whether it makes sense to adopt 
the draft and add a milestone.

--Brandon

---

From: toadzky <[email-masked]>
Date: Wed, 3 Dec 2014 13:30:21 -0700

As a developer, I would much prefer to do this kind of thing over WSS.
Websockets allow the application to control processing on the packets,
rather than relying on a framework to do. As far as I can tell, nothing
really supports ALPN at all. If I wanted to write a proxy in Java that only
listened on 80 and 443, to do ALPN, Jersey (or whichever framework I
choose) would need to support ALPN and allow me to register different
handlers for different types. That would be fine if it was a network
library (like Netty), but it's an HTTP framework that would be dealing with
other TCP protocols. On top of that, the websocket solution can be
supported quickly and easily with existing frameworks and infrastructure -
no waiting for someone else to decide to finally support ALPN.

David

On Wed, Dec 3, 2014 at 8:57 AM, Brandon Williams <
[email-masked]> wrote:

> The only thing that makes sense to me to explain the problem you describe
> is that the proxy is splitting the TLS session so that it can view the data
> flow. If such a proxy only supports HTTP (and by extension Websockets) for
> the data flow, then it would make sense that TURNS over 443 does not work.
> The piece I'm missing though is how the proxy could be splitting the TLS
> session in this way without you knowing, unless the client is accepting a
> certificate signed by someone else's CA. Nevertheless, if TLS splitting is
> what's happening and the proxy is rejecting data flows that do not look
> like HTTP, I can understand how WSS might resolve the problem under
> conditions where TURNS with ALPN might not.
>
> That having been said, if I'm correct about the source of the problem, I'm
> conflicted about taking up work intended to make a proxy like this function
> for WebRTC. If TLS is being used solely for the purpose of firewall
> traversal, then it's OK to split the session. But what if that isn't the
> case? There are significant security implications associated with helping
> such a system to function transparently. I personally would rather see my
> WebRTC sessions fail than accept decryption by an unknown MITM.
>
> Of course, it might be the case that something else is happening here and
> there is no decryption happening on the proxy, which returns me to the
> point that Andrew made ... I think we need to better understand the nature
> of the problem in order to decide whether it makes sense to adopt the draft
> and add a milestone.
>
> --Brandon
>
>
>>>>                  to handle new applications, threats etc. If firewall
>>>> has
>>>>                  a feature to

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 3 Dec 2014 21:36:37 +0100

Not to mention the fact that even with plain WS instead of WSS you could
transport TURNS and keep it secure.

Lorenzo

On Wed, 3 Dec 2014 13:30:21 -0700
toadzky <[email-masked]> wrote:

> rather than relying on a framework to do. As far as I can tell,
> nothing really supports ALPN at all. If I wanted to write a proxy in
> Java that only listened on 80 and 443, to do ALPN, Jersey (or
> whichever framework I choose) would need to support ALPN and allow me
> to register different handlers for different types. That would be
> fine if it was a network library (like Netty), but it's an HTTP
> framework that would be dealing with other TCP protocols. On top of
> that, the websocket solution can be supported quickly and easily with
> existing frameworks and infrastructure - no waiting for someone else
> to decide to finally support ALPN.
> 
> David
> 
> > describe is that the proxy is splitting the TLS session so that it
> > can view the data flow. If such a proxy only supports HTTP (and by
> > extension Websockets) for the data flow, then it would make sense
> > that TURNS over 443 does not work. The piece I'm missing though is
> > how the proxy could be splitting the TLS session in this way
> > without you knowing, unless the client is accepting a certificate
> > signed by someone else's CA. Nevertheless, if TLS splitting is
> > what's happening and the proxy is rejecting data flows that do not
> > look like HTTP, I can understand how WSS might resolve the problem
> > under conditions where TURNS with ALPN might not.
> >
> > That having been said, if I'm correct about the source of the
> > problem, I'm conflicted about taking up work intended to make a
> > proxy like this function for WebRTC. If TLS is being used solely
> > for the purpose of firewall traversal, then it's OK to split the
> > session. But what if that isn't the case? There are significant
> > security implications associated with helping such a system to
> > function transparently. I personally would rather see my WebRTC
> > sessions fail than accept decryption by an unknown MITM.
> >
> > Of course, it might be the case that something else is happening
> > here and there is no decryption happening on the proxy, which
> > returns me to the point that Andrew made ... I think we need to
> > better understand the nature of the problem in order to decide
> > whether it makes sense to adopt the draft and add a milestone.
> >
> > --Brandon
> >
> >
> >> Maybe then is me the one I am missing something, can you explain
> >> how is ALPN meant to solve the problem if TURNS over 443 is
> >> blocked by the proxy?
> >>
> >> Best regards
> >> Sergio
> >>> What am I missing? Why would ALPN require changing the wifi
> >>> network? I can accept that it may be necessary, but in the
> >>> absence of someone explaining why the wifi network needs to care,
> >>> it really doesn't make sense to me.
> >>>
> >>> --Brandon
> >>>
> >>>> That is a good point. A solution must not require changing every
> >>>> wifi network in the world. A "pure" ALPN  solution is a great
> >>>> way to kill the whole WebRTC idea.
> >>>>
> >>>>      Am I supposed to change every hotel, cafe or airport wifi
> >>>> in the world in order to make it work? That's what I mean.
> >>>>
> >>>>      Don't take me wrong, ALPN seems a good solution, as good as
> >>>> ipv6 is for removing NAT, but it is something out my control to
> >>>> have it deployed worldwide, so I can't rely on it as a solution.
> >>>> From a webrtc point of view we only control the client and the
> >>>> turn server,
> >>>>          What part of ALPN is not under your control? If you're
> >>>> doing WSS, then you've already got TLS in the picture, so ALPN
> >>>> and WSS
> >>>>          original problem statement. What part of the problem
> >>>> statement does WSS solve that ALPN does not?
> >>>>
> >>>>          If you're concerned about unencrypted TURN multiplexing
> >>>> with unencrypted HTTP on port 80, then I can see WS solving a
> >>>> problem
> >>>>          that ALPN can't solve.
> >>>>
> >>>>          --Brandon
> >>>>
> >>>>                  El 02/12/2014 20:04, "Tirumaleswar Reddy
> >>>> (tireddy)" <[email-masked] <mailto:[email-masked]>
> >>>>                  <mailto:[email-masked]
> >>>> <mailto:[email-masked]>>> escribió:
> >>>>                   >
> >>>>                   > From: Simon Perreault
> >>>>                   > Cc: Jonathan Lennox; Sergio Garcia Murillo;
> >>>>                   > Victor
> >>>>                  Pascual Avila;
> >>>>                   > On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar
> >>>>                   > Reddy
> >>>>                  (tireddy)
> >>>>                  <mailto:[email-masked]
> >>>> <mailto:[email-masked]>>> wrote:
> >>>>                   >
> >>>>                   > Transparent proxies like firewalls keep
> >>>>                   > getting
> >>>>                  upgraded frequently
> >>>>                  to handle new applications, threats etc. If
> >>>> firewall has
> >>>>                  a feature to
> >>>>                   > The problem is there are networks that are
> >>>>                   > set up so
> >>>>                  that "the web"
> >>>>                   > [TR] Okay, so looks like the problem can
> >>>>                   > also be
> >>>>                  solved by running

---

From: Justin Uberti <[email-masked]>
Date: Thu, 11 Dec 2014 11:46:41 -0800

So I see 3 arguments being made here:
1) WSS allows the app and TURN server to be the same entity.
2) TURN/WSS works where TURN/TLS doesn't, because DPI.
3) TURN/WS works where TURN/TLS doesn't, because DPI.

#2 seems very hard to believe; both of these things will try to establish a
TLS connection and then run WS or TURN over top. It's not clear to me that
DPI will be able to reliably ID TURN packets versus TURN/WS packets when
they are encrypted. (Clearly if the DPI is able to intercept the TLS, it's
a different story.)
#3 implies that HTTPS and WSS doesn't work, so not sure how useful that is.

As Brandon says, I agree we need to understand the problem better before
deciding whether this has value.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 12 Dec 2014 16:42:07 +0200

Please, keep the cc: list short so that your messages are not held for
manual moderation.

Cheers,

Gonzalo

On 11/12/2014 9:46 PM, Justin Uberti wrote:
> #2 seems very hard to believe; both of these things will try to
> establish a TLS connection and then run WS or TURN over top. It's not
> clear to me that DPI will be able to reliably ID TURN packets versus
> TURN/WS packets when they are encrypted. (Clearly if the DPI is able to
> intercept the TLS, it's a different story.)
> On Wed, Dec 3, 2014 at 12:36 PM, Lorenzo Miniero <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     toadzky <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     > [email-masked] <mailto:[email-masked]>>
>     wrote:
>     >
>     <mailto:[email-masked]>
>     > >>>> <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>     > >>>>
>     > >>>>                  [mailto:sergio.garcia.murillo@
>     <mailto:sergio.garcia.murillo@>__gmail.com <http://gmail.com>
>     > >>>>                  <mailto:[email-masked]
>     <mailto:[email-masked]>>] ?
>     > >>>>
>     <mailto:[email-masked] <mailto:[email-masked]>>;
>     <mailto:[email-masked]>
>     > >>>> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked]>
>     > >>>> <mailto:[email-masked] <mailto:[email-masked]>>>> escribió:
>     > >>>>                   >
>     > >>>>                   > From: Simon Perreault
>     > >>>>                  <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     > >>>>                  <mailto:[email-masked]
>     > >>>> <mailto:[email-masked] <mailto:[email-masked]>>>]
>     <mailto:[email-masked]>
>     > >>>> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     <mailto:[email-masked]>
>     > >>>> <mailto:[email-masked]
>     <mailto:[email-masked]>>>__;
>     > >>>>                  <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     > >>>>                  <[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     <mailto:[email-masked]>
>     > >>>> <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>     > >>>>                   >

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 18 Dec 2014 11:23:38 +0100

Sorry for the late reply, busy week.. :)

Regarding #2 and #3, I agree that it needs to be look further.

Anyway, as I said in a previous email, it should not be a show stopper 
for working on the draft on the TRAM group, even if they are not 
clarified and we can state that TURN over WS provides same connectivity 
level than TURN over TLS + HTTP CONNECT.

Also, regarding 1, I have been thinking about it and it is not only 
about easing the deployment in some constrained scenarios. It would 
provide a much better integration with Web usage than normal TURN.

For example in our service, we have a couple balanced nginx servers 
acting ssl terminator ands reverse proxy for http and ws. So adding 
TURNS over WS to our deployment would be kind of trivial and would allow 
us to keep all our urls under the same domain. (I think that the extra 
delay of having a new intermediary proxy would be neglectable). So we 
could have:

https://www.xxxxx.xx/rest
https://www.xxxxx.xx/html
wss://www.xxxxx.xx/sip
wss://www.xxxxx.xx/turn

Theres huge is a side benefit for that, as all of them shares same 
domain, we can share cookies with authentication tokens and the other 
HTTP headers (like Origin) between the different websockets (sip/turn) 
and rest apis. Note that we had to add an HTTP REST API to the TURN 
server for short time credentials and load balancing and add origin 
header to STUN/TURN messages, to be able to do what is natively 
supported by websockets.

Best regards
Sergio
On 11/12/2014 20:46, Justin Uberti wrote:
> TURN/WS packets when they are encrypted. (Clearly if the DPI is able 
> to intercept the TLS, it's a different story.)
> As Brandon says, I agree we need to understand the problem better 
> before deciding whether this has value.
>
>
>     > [email-masked]
>     <mailto:[email-masked]>> wrote:
>     >
>     > >>>>          seem to both solve the server-side multiplexing
>     problem
>     > >>>> from the
>     > >>>>              BTW, I am talking about real life experiences,
>     when
>     > >>>> WSS works and TURNS
>     > >>>>              over 443 doesn't.
>     > >>>>
>     > >>>>              Best regards
>     > >>>>              Sergio
>     > >>>>
>     > >>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>;
>     > >>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     > >>>>                  <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>     > >>>>                  is open, through a transparent proxy.
>     WebRTC is
>     > >>>> part of "the web".
>     > >>>>                  Making TURN fit the mould of "the web" is
>     is not
>     > >>>>                  circumventing policy,
>     need to
>     > >>>> update your
>     > >>>>                  TURN over 443 similar to proposals in
>     DPRIVE WG
>     > >>>> to run DNS over 443.
>     > >>>>                   >
>     > >>>>                   >
>     > >>>>
>     > >>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>

---

From: Brandon Williams <[email-masked]>
Date: Thu, 18 Dec 2014 09:59:13 -0500

In my opinion, for the working group to adopt a draft that broadens the 
range of TURN transport options, there should be a solid justification 
for doing so based on a use case that cannot be satisfied with the 
transport options that are already defined.

I don't think that ease of implementation in a specific context provides 
a solid enough justification on its own. Although it might improve 
things for a closed system where both the client and the server are 
under common control, it potentially makes things harder for those of us 
who control only one side or the other, increasing the number of 
transports we must support in order to ensure compatibility.

Basically what I'm saying is that I do think a compelling use case that 
cannot be satisfied by existing RFCs and/or drafts is required in order 
for the draft to be adopted by the working group. At the moment, I think 
this should remain a discussion on the list, and I would also encourage 
you to ask for some presentation time at the in-person meeting in Dallas.

--Brandon