Subject: [pntaw] TURN over websockets

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 30 Aug 2013 10:42:09 +0200

Hi all,

I will shoot first.

It is great to finally see some real interest in what I consider to be 
the blocking point for webrtc in order to run business on top of it, 
which is the ability to be able to connect through corporate firewalls.

I have seen some people arguing that with just TURN over TCP on port 443 
the problem will be solved, but I seriously doubt it. Neither TURN over 
SSL would do, as most web filters do DPI and will not enable the 
connection. Also, I have heard lots of voices that says we are trying to 
override network admin policies with dirty tricks. With whom, I could agree.

So, the only way I see to move forward and overcome this issues is by 
playing according to the WEB rules, and use HTTP standards to enable 
media connectivity in WebRTC that would play nicely with current 
corporate HTTP proxies and web filters.

And,  for me the most viable solution would be to enable TURN over 
websockets. As most WebRTC services relay on websockets in one way or 
another for signaling, we could assume that media would work on 100% of 
the cases where signaling is working today.
Also, as it is an http based solution, network administrators could 
apply corporate policies and block connections to not-trusted TURN servers.

Best regards
Sergio

---

From: Lorenzo Miniero <[email-masked]>
Date: Fri, 30 Aug 2013 13:45:31 +0200

On Fri, 30 Aug 2013 10:42:09 +0200

> override network admin policies with dirty tricks. With whom, I could agree.

That's the main objection I got when I published the (now expired) draft I published a year ago to throw the proverbial "stone in the lake" about an HTTP fallback solution. As I said at the time, I agree with you that the solution doesn't have to be sneaky, and that it could very well be conceived to be network admin-friendly/controllable.

> apply corporate policies and block connections to not-trusted TURN servers.

I'm not an expert in websockets, which is why in my rough proposal I described a way to do this using plain HTTP, but I guess they'd be good for the purpose as well. The only doubt I have is that, as far as I know, not always websockets are able to traverse some more restrictive components: the popular BitDefender firewall, for instance, apparently doesn't let it through.

Anyway, I'd personally support a work in that direction, and would be willing to help working on it too if needed.

Lorenzo

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

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 30 Aug 2013 13:55:34 +0200

El 30/08/2013 13:45, Lorenzo Miniero escribió:
> [..]

 From what I have seen, most people using webrtc are doing the signaling 
via websocket, either using SIP over websockets, or any other custom 
protocol. So, if websockets are not supported, you already have a 
problem as you will not be able to set up the SDP O/A negotiation in the 
first place.

> Anyway, I'd personally support a work in that direction, and would be willing to help working on it too if needed.

Thank you very much Lorenzo, anyone else on board?

Best regards
Sergio

---

From: Simon Pietro Romano <[email-masked]>
Date: Fri, 30 Aug 2013 13:58:50 +0200

+1 to the plain HTTP fallback solution proposed by Lorenzo a while ago.

Simon

Lorenzo Miniero <[email-masked]> ha scritto:
>That's the main objection I got when I published the (now expired)
>draft I published a year ago to throw the proverbial "stone in the
>lake" about an HTTP fallback solution. As I said at the time, I agree
>with you that the solution doesn't have to be sneaky, and that it could
>very well be conceived to be network admin-friendly/controllable.
>
>
>I'm not an expert in websockets, which is why in my rough proposal I
>described a way to do this using plain HTTP, but I guess they'd be good
>for the purpose as well. The only doubt I have is that, as far as I
>know, not always websockets are able to traverse some more restrictive
>components: the popular BitDefender firewall, for instance, apparently
>doesn't let it through.
>
>Anyway, I'd personally support a work in that direction, and would be
>willing to help working on it too if needed.
>
>Lorenzo
>

---

From: "Stach, Thomas" <[email-masked]>
Date: Fri, 30 Aug 2013 12:34:56 +0000

Sergio,

Some comments inline

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Sergio Garcia Murillo
> Sent: Freitag, 30. August 2013 10:42
> To: [email-masked]
> Subject: [pntaw] TURN over websockets
> 
> Hi all,
> 
> I will shoot first.
> 
[TS] I'm not sure if you are referencing draft-hutton-rtcweb-nat-firewall-considerations here.
Nevertheless the draft mentions TURN over TCP to port 443. 
The goal behind this is certainly not to sneak WEBRTC media streams through heavily fortified networks that have DPI deployed.
The goal rather to address a scenario e.g. at a small hotel with a not-so-skilled network admin, that opened his firewall on TCP port 80/443 to allow its guests to do some web browsing, but is afraid of opening its firewall for UDP traffic.
If we want to deploy WEBRTC in such an environment TURN over TLS to port 443 would do the job. 

> corporate HTTP proxies and web filters.
[TS] Playing nicely with HTTP proxies is also a use case draft-hutton-rtcweb-nat-firewall-considerations.
Usage of the HTTP CONNECT method is proposed here. The request URI would include the TURN server (preferably even to the well-known STUN port). If the network admin put the TURN server into its whitelist, that could hardly be considered as sneaking unwanted traffic through.
> websockets. 
[TS] This would require updates to the TURN protocol and the TURN software, whereas the proposals in draft-hutton-rtcweb-nat-firewall-considerations use the original transports.
As most WebRTC services relay on websockets in one way or
> apply corporate policies and block connections to not-trusted TURN
[TS] which could also be done by white-listing the TURN server address via TCP without any further intermediate HTTP/Websocket layers.

Regards 
Thomas

---

From: <[email-masked]>
Date: Fri, 30 Aug 2013 12:52:53 +0000

Hi Sergio, Thomas,

I also assume that we should run TURN over TLS directly, or by establishing that connection via a proxy using HTTP CONNECT. The first method would work in networks that allow outbound TLS/TCP connections, while the other would work even in networks that only allow outbound communication via a proxy.

As Thomas says, the benefit of TURN/TLS instead of TURN/WS/TLS is that no changes would need to be applied to existing TURN servers. Only the client side establishment (by the browser) would need to include the use of HTTP CONNECT. 

But is there some advantage why Websockets should be used? WS does have the explicit HTTP based handshake, which is supposed to make it somehow middlebox "friendlier". But I don't know how that is better than HTTP CONNECT in that sense.

Regards,
	Markus

> Of ext Stach, Thomas
> Sent: 30 August, 2013 15:35
> To: Sergio Garcia Murillo; [email-masked]
> Subject: Re: [pntaw] TURN over websockets
> 
> Sergio,
> 
> Some comments inline
> 
> > the problem will be solved, but I seriously doubt it. Neither TURN
> > over SSL would do, as most web filters do DPI and will not enable the
> > connection. Also, I have heard lots of voices that says we are trying
> > to override network admin policies with dirty tricks. With whom, I
> > could agree.
> The goal behind this is certainly not to sneak WEBRTC media streams through
> heavily fortified networks that have DPI deployed.
> The goal rather to address a scenario e.g. at a small hotel with a not-so-skilled
> network admin, that opened his firewall on TCP port 80/443 to allow its
> guests to do some web browsing, but is afraid of opening its firewall for UDP
> traffic.
> Usage of the HTTP CONNECT method is proposed here. The request URI
> would include the TURN server (preferably even to the well-known STUN
> port). If the network admin put the TURN server into its whitelist, that could
> hardly be considered as sneaking unwanted traffic through.
> >
> [TS] This would require updates to the TURN protocol and the TURN
> software, whereas the proposals in draft-hutton-rtcweb-nat-firewall-
> considerations use the original transports.
> > another for signaling, we could assume that media would work on 100%
> > of the cases where signaling is working today.
> [TS] which could also be done by white-listing the TURN server address via
> TCP without any further intermediate HTTP/Websocket layers.
> 
> Regards
> Thomas
> 
> >
> > Best regards
> > Sergio

---

From: Simon Perreault <[email-masked]>
Date: Fri, 30 Aug 2013 14:53:31 +0200

Le 2013-08-30 14:34, Stach, Thomas a écrit :
> The goal behind this is certainly not to sneak WEBRTC media streams
> through heavily fortified networks that have DPI deployed. The goal
> rather to address a scenario e.g. at a small hotel with a
> not-so-skilled network admin, that opened his firewall on TCP port
> 80/443 to allow its guests to do some web browsing, but is afraid of
> opening its firewall for UDP traffic. If we want to deploy WEBRTC in
> such an environment TURN over TLS to port 443 would do the job.

+1

I too am not convinced that we need anything more than TURN over TLS to
port 443.

Simon

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 30 Aug 2013 14:56:46 +0200

Hi Thomas,

Inline.

El 30/08/2013 14:34, Stach, Thomas escribió:
>> to
And also does mention TURN over websockets, while it consider it to be 
not necessary.
> If we want to deploy WEBRTC in such an environment TURN over TLS to port 443 would do the job.

Maybe that is your scenario, definitively not mine. Try doing some 
serious business with banking, insurance or such kind of sector and you 
won't find no-so-skilled admin but a full flavor DPI web filter in 
place. Then try to go to their admin it department and ask them to do 
some funny configuration on their firewalls.

I really doubt that TURN over TLS would work in 100% of this scenarios.

> [TS] This would require updates to the TURN protocol and the TURN software, whereas the proposals in draft-hutton-rtcweb-nat-firewall-considerations use the original transports.

Yes, it would require additions to the TURN protocol and new 
developments on TURN software.

> [TS] which could also be done by white-listing the TURN server address via TCP without any further intermediate HTTP/Websocket layers.

Try to open a firewall in a corporate location, good luck! White listing 
in the web filter would be much more doable.

Best regards
Sergio

---

From: <[email-masked]>
Date: Fri, 30 Aug 2013 12:57:54 +0000

Hi Simon,

> I too am not convinced that we need anything more than TURN over TLS to

I think we should also address networks that only allow outbound communication via an explicit HTTP/web proxy. I use one such network daily... So it should be possible to use HTTP CONNECT to establish the TURN over TLS connection via that proxy. 

Markus

---

From: Simon Perreault <[email-masked]>
Date: Fri, 30 Aug 2013 15:02:56 +0200

> I think we should also address networks that only allow outbound communication via an explicit HTTP/web proxy. I use one such network daily... So it should be possible to use HTTP CONNECT to establ…

Agreed. TURN/TLS over 443 through a proxy or not, up to the client.
Servers won't see the difference.

Simon

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 30 Aug 2013 15:04:42 +0200

Hi Markus,

I see some benefits for websockets over HTTP connect, but may be due to 
my own deployment choices, but I would be ok with it also.

One point that I see against http connect is that it is meant to be used 
as a fallback scenario, while with websockets you could use it always, 
regardless if there is any http proxy in place or not.

Best regards
Sergio

---

From: "Stach, Thomas" <[email-masked]>
Date: Fri, 30 Aug 2013 13:24:30 +0000

> From: Sergio Garcia Murillo [mailto:[email-masked]]
> Sent: Freitag, 30. August 2013 14:57
> To: Stach, Thomas
> Cc: [email-masked]
> over
> >> override network admin policies with dirty tricks. With whom, I
> could
> >> agree.
> through heavily fortified networks that have DPI deployed.
> > The goal rather to address a scenario e.g. at a small hotel with a
> opening its firewall for UDP traffic.
[TS] Certainly not, but it would already increase the number of working scenarios considerably.
I'd prefer to go on step by step and start with specifying the browser should use TURN over TLS (including the HTTP proxy case). The more sophisticated stuff could follow.

> > [TS] Playing nicely with HTTP proxies is also a use case draft-
> hutton-rtcweb-nat-firewall-considerations.
> port). If the network admin put the TURN server into its whitelist,
> that could hardly be considered as sneaking unwanted traffic through.
> of
> > [TS] which could also be done by white-listing the TURN server
> address via TCP without any further intermediate HTTP/Websocket layers.
> 
[TS] ... which is what I meant.

Regards
Thomas

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 30 Aug 2013 13:53:37 +0000

The other way to solve the Firewall problem is use PCP. For more details refer to sections 3.1, 3.2 of draft http://tools.ietf.org/html/draft-penno-rtcweb-pcp-00 which addresses the problem of Enterprise Firewalls permitting P2P media streams. 

-Tiru.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Sergio Garcia Murillo
> Sent: Friday, August 30, 2013 2:12 PM
> To: [email-masked]

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 30 Aug 2013 10:28:22 -0400

Le 2013-08-30 à 09:53, "Tirumaleswar Reddy (tireddy)" <[email-masked]> a écrit :

> The other way to solve the Firewall problem is use PCP.

don't agree.  it would be great, much better design, but all the install base of gateways in public wifi, coffee shop wifi, hotel networks, etc... are not going to do any PCP. 

Marc.

> For more details refer to sections 3.1, 3.2 of draft http://tools.ietf.org/html/draft-penno-rtcweb-pcp-00 which addresses the problem of Enterprise Firewalls permitting P2P media streams. 
> 
> -Tiru.
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 30 Aug 2013 15:07:15 +0000

P2P is something we can look at in the future but I don't see it as an option for enabling webrtc deployment in the near term.

We proposed the HTTP Connect mechanism in draft-hutton-rtcweb-nat-firewall-considerations because it would significantly improve the chances of enabling webrtc deployment today and requires no new implementation other than in the webrtc browser.

Regards
Andy

> Of Marc Blanchet
> Sent: 30 August 2013 15:28
> To: Tirumaleswar Reddy (tireddy)
> Cc: [email-masked]; Sergio Garcia Murillo
> don't agree.  it would be great, much better design, but all the
> install base of gateways in public wifi, coffee shop wifi, hotel
> networks, etc... are not going to do any PCP.
> 
> Marc.
> 
> > For more details refer to sections 3.1, 3.2 of draft
> http://tools.ietf.org/html/draft-penno-rtcweb-pcp-00 which addresses
> the problem of Enterprise Firewalls permitting P2P media streams.
> >
> > -Tiru.
> >

---

From: "Parthasarathi R" <[email-masked]>
Date: Sat, 31 Aug 2013 21:54:35 +0530

Hi all,

In case of (firewall) Policy vs protocol, the policy is the final decision
maker and not the protocol. In case TURN over WebSocket is chosen, it is a
matter of time for firewall policy enhancement to block these rat holes in
the network. 

Please try to understand from bank perspective that bank network security is
more important and end-user *MUST NOT* be allowed to use the traffic which
bank could not intercept.

Thanks
Partha

> Sent: Friday, August 30, 2013 6:27 PM
> To: Stach, Thomas
> Cc: [email-masked]

---

From: Martin Thomson <[email-masked]>
Date: Sat, 31 Aug 2013 10:33:46 -0700

> matter of time for firewall policy enhancement to block these rat holes in

I'm glad someone raised this point.  It's core to the discussion.
What, if any, visibility will a firewall or proxy be given into the
purpose of this exchange?   HTTP CONNECT followed by TLS doesn't give
the intermediary much of a chance to enforce policy.

---

From: Melinda Shore <[email-masked]>
Date: Sat, 31 Aug 2013 09:43:39 -0800

> the intermediary much of a chance to enforce policy.

Well, arguably NAT is not really a policy enforcement mechanism.
But yes, if you're using firewall/nat traversal technologies to
get around firewall policy enforcement, there's a huge problem.
For what it's worth we've been trying to have *that* discussion
for years.

One of the advantages of using a mechanism that signals the
firewall directly (say, midcom, pcp, etc.) is that it allows
the firewall to accept or deny the request based on policy.
However, it requires a forklift upgrade to pretty much everything
and is extremely difficult to deploy for that reason.  This
is the primary (but not the only) reason that midcom flopped, so
I was surprised to see pcp chartered since it's got the same
barriers to deployment.  But that is a different discussion.

Melinda

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 31 Aug 2013 19:53:07 +0100

> the intermediary much of a chance to enforce policy.

Just a note on this: Proposed solutions that require a man in the
middle attack on TLS are not likely to fare well. The security ADs
(incl me:-) are *very* strongly against messing about with TLS like
that. So I hope this design team effort (or whatever it is) don't
go down that road. And of course there's no need to go there either,
if you want to know what WebRTC stuff is going on, then there should
be fine WebRTC ways to do that that don't involve a TLS MITM attack.

Cheers,
S.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sun, 1 Sep 2013 03:53:05 +0000

> From: Hutton, Andrew [mailto:[email-masked]]
> Sent: Friday, August 30, 2013 8:37 PM
> To: Marc Blanchet; Tirumaleswar Reddy (tireddy)
> Subject: RE: [pntaw] TURN over websockets
> 
> P2P is something we can look at in the future but I don't see it as an option
> for enabling webrtc deployment in the near term.

I would suggest to evaluate both long term and short term needs. If Corporate, Banks, Insurance and other organizations want to deploy WebRTC then we may want to evaluate http://tools.ietf.org/html/draft-penno-rtcweb-pcp-00#section-3.2 which achieves similar results as existing Firewalls with SIP ALG but without the need for DPI of the signaling protocol used for WebRTC. 

-Tiru.

> 
> We proposed the HTTP Connect mechanism in draft-hutton-rtcweb-nat-firewall-
> considerations because it would significantly improve the chances of enabling
> webrtc deployment today and requires no new implementation other than in the
> webrtc browser.
> 
> Regards
> Andy
> 
> 
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sun, 1 Sep 2013 04:03:51 +0000

> Parthasarathi R
> Sent: Saturday, August 31, 2013 9:55 PM
> To: 'Sergio Garcia Murillo'; 'Stach, Thomas'
> Cc: [email-masked]

+1

-Tiru.