Subject: [pntaw] TURN over websockets or just TURN.

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 25 Sep 2013 09:59:09 +0000

Some thoughts on comparing the TURN over Websockets approach in draft-chenxin-behave-turn-websocket and the HTTP Connect (Without websocket) approach discussed in draft-hutton-rtcweb-nat-firewall-considerations.

Please note that my motivation is simply to find a good solution to deploying WebRTC in the presence of web proxies / firewalls and I am not tied to any particular solution.

In the presence of an explicit proxy the websockets approach is to use HTTP CONNECT to traverse the proxy (RFC 6455) so the question is whether there are any advantages or disadvantages to wrapping TURN with the websockets layer as this cannot be about the use of HTTP CONNECT which is used by in both solutions.

Websockets adds some overhead as there is an extra handshake that takes place with the server and there is some extra overhead in the data encapsulation.

The purpose of the extra HTTP handshake to upgrade to HTTP to a websockets connection is to allow an HTTP Server to use the same port for both HTTP and the websockets protocol.  However I don't think this is necessary for WebRTC media connections as it is very unlikely that a web server will want to handle WebRTC media/TURN at all never mind on the HTTP port as the media.

So does encapsulating the TURN data in websocket frames provide any benefit. I can imagine that there might be some scenarios in which using a websockets connection might work when TURN might not simply because the media is buried in further layers of encapsulation. However I don't know if this is really the case and also we are of course not trying to hide the fact that this is media. 

The extra websockets overhead for all the media packets is surely a drawback of this approach.

Not encapsulating the TURN in websockets would also probably provide better control for those wanting to assert policies on the handling of media.

Therefore as you can see I don't see the benefit of encapsulating TURN in websockets but I look forward to hearing other opinions and maybe I have missed something important.

Regards
Andy

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 25 Sep 2013 12:18:48 +0200

Hi Andy,

Some comments inline.

Best regards
Sergio

> Please note that my motivation is simply to find a good solution to deploying WebRTC in the presence of web proxies / firewalls and I am not tied to any particular solution.

So am I  :)

> In the presence of an explicit proxy the websockets approach is to use HTTP CONNECT to traverse the proxy (RFC 6455) so the question is whether there are any advantages or disadvantages to wrapping TURN with the websockets layer as this cannot be about the use of HTTP CONNECT which is used by in both solutions
 From my understanding if you use secure websockets it will use HTTP 
CONNECT as any other HTTPS connection, but if non-secure websockets are 
used over port 80, HTTP CONNECT won't be done. Before anyone jumps in 
regarding using a non-secure websockets, let's remind that this would  
be as secure as TURN over TCP and that data will be already secured by 
DTLS.

> Websockets adds some overhead as there is an extra handshake that takes place with the server and there is some extra overhead in the data encapsulation.
Yes it is just one HTTP request/response and a max of 8 byte headers. 
However if TURN over websockets is run un-secured, you will have less 
processing overhead due to the TLS encription.
> The purpose of the extra HTTP handshake to upgrade to HTTP to a websockets connection is to allow an HTTP Server to use the same port for both HTTP and the websockets protocol.  However I don't thi…
No, it isn't, the main purpose is to be able to traverse proxies with 
DPI that will drop the HTTP CONNECT with TURN over TLS. But, been an 
HTTP protocol, you would gain some extra functionalities for free.
> The extra websockets overhead for all the media packets is surely a drawback of this approach.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-------+-+-------------+-------------------------------+
      |F|R|R|R| opcode|M| Payload len |    Extended payload length    |
      |I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
      |N|V|V|V|       |S|             |   (if payload len==126/127)   |
      | |1|2|3|       |K|             |                               |
      +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
      |     Extended payload length continued, if payload len == 127  |
      + - - - - - - - - - - - - - - - +-------------------------------+
      |                               |Masking-key, if MASK set to 1  |
      +-------------------------------+-------------------------------+
      | Masking-key (continued)       |          Payload Data         |
      +-------------------------------- - - - - - - - - - - - - - - - +
      :                     Payload Data continued ...                :
      + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
      |                     Payload Data continued ...                |
      +---------------------------------------------------------------+

7 or 8 bytes from client to server (due to masking, which I think it could be avoided in this case) and 2 or 4bytes from server to client.

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

---

From: <[email-masked]>
Date: Wed, 25 Sep 2013 10:19:53 +0000

Hi,

I completely agree with Andy. The main point is this:

> In the presence of an explicit proxy the websockets approach is to use HTTP
> CONNECT to traverse the proxy (RFC 6455)

So, basically both approaches (to connect to a TURN server via a proxy), with or without WebSockets, use the same initial step. WS to my understanding would just introduce 1) an additional HTTP Upgrade handshake and 2) an additional encapsulation header. 

I don't think we need 1) because both ends already know that the protocol is TURN. 2) I think is just overhead.

Markus 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Hutton, Andrew
> Sent: 25 September, 2013 12:59
> To: [email-masked]
> Subject: [pntaw] TURN over websockets or just TURN.
> 
> Some thoughts on comparing the TURN over Websockets approach in draft-
> chenxin-behave-turn-websocket and the HTTP Connect (Without
> websocket) approach discussed in draft-hutton-rtcweb-nat-firewall-
> considerations.
> 
> Please note that my motivation is simply to find a good solution to deploying
> WebRTC in the presence of web proxies / firewalls and I am not tied to any
> particular solution.
> 
> In the presence of an explicit proxy the websockets approach is to use HTTP
> CONNECT to traverse the proxy (RFC 6455) so the question is whether there
> are any advantages or disadvantages to wrapping TURN with the websockets
> layer as this cannot be about the use of HTTP CONNECT which is used by in
> both solutions.
> 
> Websockets adds some overhead as there is an extra handshake that takes
> place with the server and there is some extra overhead in the data
> encapsulation.
> 
> The purpose of the extra HTTP handshake to upgrade to HTTP to a
> websockets connection is to allow an HTTP Server to use the same port for
> both HTTP and the websockets protocol.  However I don't think this is
> necessary for WebRTC media connections as it is very unlikely that a web
> server will want to handle WebRTC media/TURN at all never mind on the
> HTTP port as the media.
> 
> So does encapsulating the TURN data in websocket frames provide any
> benefit. I can imagine that there might be some scenarios in which using a
> websockets connection might work when TURN might not simply because
> the media is buried in further layers of encapsulation. However I don't know
> if this is really the case and also we are of course not trying to hide the fact
> that this is media.
> 
> Not encapsulating the TURN in websockets would also probably provide
> better control for those wanting to assert policies on the handling of media.
> 
> Therefore as you can see I don't see the benefit of encapsulating TURN in
> websockets but I look forward to hearing other opinions and maybe I have
> missed something important.
> 
> Regards
> Andy
>

---

From: <[email-masked]>
Date: Wed, 25 Sep 2013 10:33:23 +0000

Hi Sergio,

Sergio Garcia Murillo wrote:
> > In the presence of an explicit proxy the websockets approach is to use
> > HTTP CONNECT to traverse the proxy (RFC 6455) so the question is
> > whether there are any advantages or disadvantages to wrapping TURN
> > with the websockets layer as this cannot be about the use of HTTP
> > CONNECT which is used by in both solutions
> regarding using a non-secure websockets, let's remind that this would be as
> secure as TURN over TCP and that data will be already secured by DTLS.
> 

I believe this is the really crucial question. My recollection from test results posted to IETF HYBI WG mailing list is that these unsecure websockets connections actually fail quite regularly with proxies rendering them almost unusable. This is not about proxies deliberately blocking websockets, but deployed proxies that are totally unaware of websockets but expect only HTTP. 

Anyone has up-to-date data about this?

Markus

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 25 Sep 2013 11:00:08 +0000

At least according to RFC 6455 the use of HTTP CONNECT for websockets is independent of whether the connection is secure or not.

Andy

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 25 Sep 2013 15:25:01 +0200

Hi Andy,

Please correct me if I am wrong, but would browsers still do an HTTP 
connect for http 1.1 request? I thought it was only for HTTPS requests.

Anyway, the argument is still the same, turn over websockets will work 
on every scenario where turn over tls works, and in addition it may work 
in some others. Also, given that most people are using websockets for 
signaling anyway, we will ensure that in 100% of the cases if signaling 
over websockets works, media over websockets will work (except if 
explicitly forbidden by enterprises policies).

We can argue later if the percentage of cases additionally covered by 
turn over ws is significant enough so it is worthy to add a new protocol 
and change both clients and server (while I see that other initiatives 
are requiring it already). But I think that at least having an 
alternative proposal is a good thing.

Best regards
Sergio

---

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 25 Sep 2013 08:45:50 -0700

Hi Andy

please see below in the text:

On Wed, Sep 25, 2013 at 2:59 AM, Hutton, Andrew <
[email-masked]> wrote:

> HTTP CONNECT to traverse the proxy (RFC 6455) so the question is whether
> there are any advantages or disadvantages to wrapping TURN with the
> websockets layer as this cannot be about the use of HTTP CONNECT which is
> used by in both solutions.
>

HTTP CONNECT is used only when an explicit proxy is present. Websockets can
provide improved connectivity when NO explicit proxy is present

> place with the server and there is some extra overhead in the data

That overhead is relatively minor.

>
> The purpose of the extra HTTP handshake to upgrade to HTTP to a websockets
> connection is to allow an HTTP Server to use the same port for both HTTP
> and the websockets protocol.

No, in this particular case the purpose is to use HTTP protocol as a tunnel
for TURN protocol.

>  However I don't think this is necessary for WebRTC media connections as
> it is very unlikely that a web server will want to handle WebRTC media/TURN
> at all never mind on the HTTP port as the media.
>

I do not understand how a web server jumped into the picture. The proposal
has nothing to do with the web servers.

> benefit.

It provides a benefit of encapsulating TURN protocol into HTTP protocol
that is usually easily understandable and "parseable" by the firewalls. The
firewall can examine the subprotocol header and make a decision.

> I can imagine that there might be some scenarios in which using a
> websockets connection might work when TURN might not simply because the
> media is buried in further layers of encapsulation. However I don't know if
> this is really the case and also we are of course not trying to hide the
> fact that this is media.
>

There are scenarios when difference between HTTP and TURN is as simple as
"connectivity" vs "no connectivity". That's rather important.

> drawback of this approach.

When no packets can be passed through, then the network overhead is exactly
0 (zero) but we do not consider it as a great scenario.

> better control for those wanting to assert policies on the handling of

DPI of the TURN packets is a hard task, especially considering that the IP
addresses in the TURN packets are obfuscated. On the other hand, we may
require some headers in the websocket connection to contain information
about the protocol, so it may be more firewall-friendly and "examinable",
without serious investment into new DPI algorithms.

> missed something important.
I hope I provide an opinion.

Thanks
Oleg

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 25 Sep 2013 18:19:58 +0000

See below.

Andy

> From: Oleg Moskalenko [mailto:[email-masked]]
> Sent: 25 September 2013 16:46
> To: Hutton, Andrew
> Cc: [email-masked]
> Subject: Re: [pntaw] TURN over websockets or just TURN.
> 
> Hi Andy
> 
> On Wed, Sep 25, 2013 at 2:59 AM, Hutton, Andrew <andrew.hutton@siemens-
> enterprise.com> wrote:
> 
> whether there are any advantages or disadvantages to wrapping TURN with
> the websockets layer as this cannot be about the use of HTTP CONNECT
> which is used by in both solutions.
> 
> HTTP CONNECT is used only when an explicit proxy is present. Websockets
> can provide improved connectivity when NO explicit proxy is present
> 
> 

[AndyH] But it is still something that we would be better without unless it serves a good purpose.

> websockets connection is to allow an HTTP Server to use the same port
> for both HTTP and the websockets protocol.
> 
> No, in this particular case the purpose is to use HTTP protocol as a
> tunnel for TURN protocol.
>

[AndyH] Not really the proposal is to encapsulate TURN within a websockets connection not HTTP. 

> 
>  However I don't think this is necessary for WebRTC media connections
> as it is very unlikely that a web server will want to handle WebRTC
> media/TURN at all never mind on the HTTP port as the media.
> 
> I do not understand how a web server jumped into the picture. The
> proposal has nothing to do with the web servers.
> 

[AndyH] Exactly the media handling has nothing to do with the web server but websockets uses HTTP upgrade mechanism because it was designed to allow the web server to use the same port for HTTP and websockets (See http://tools.ietf.org/html/rfc6455#section-1.3). This mechanism is not needed in WebRTC because the web server and TURN server are not the same server.

> that is usually easily understandable and "parseable" by the firewalls.
> The firewall can examine the subprotocol header and make a decision.
> 

[AndyH] The subprotocol is nice but I assume the firewall only sees this if the websockets connection is not encrypted it seems to me that it might be better to have something like the subprotocol indicating TURN in the HTTP CONNECT making it clear to the proxy the purpose of the connection encrypted or not.

> media is buried in further layers of encapsulation. However I don't
> know if this is really the case and also we are of course not trying to
> hide the fact that this is media.
> 
> There are scenarios when difference between HTTP and TURN is as simple
> as "connectivity" vs "no connectivity". That's rather important.
> 

[AndyH] Can you explain in what scenarios TURN over Websockets would work and TURN/TCP with HTTP Connect would not?

> When no packets can be passed through, then the network overhead is
> exactly 0 (zero) but we do not consider it as a great scenario.
> 

[AndyH] I am not sure I understand your point here. If there are no significant advantage to using the websockets encapsulation and I have not heard one yet, then the overhead is again something we could do without.

> DPI of the TURN packets is a hard task, especially considering that the
> IP addresses in the TURN packets are obfuscated. On the other hand, we
> may require some headers in the websocket connection to contain
> information about the protocol, so it may be more firewall-friendly and
> "examinable", without serious investment into new DPI algorithms.
> 

[AndyH] I don't think we should discuss DPI it should simply be out of scope.

> 
> Therefore as you can see I don't see the benefit of encapsulating TURN
> in websockets but I look forward to hearing other opinions and maybe I
> have missed something important.
> 
> 

[AndyH] You have but I am not yet convinced of the benefit I think we need concrete examples of why a websockets approach would be more successful than just TURN/TCP using HTTP CONNECT.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 25 Sep 2013 18:32:06 +0000

> alternative proposal is a good thing.

This debate is definitely a good thing and we seem to be agreed that there is a problem to solve so we are making progress. I was trying to have the debate now on whether the websockets overhead is worthwhile or not I don't see any reason to delay that discussion.

I am still to see any concrete examples of scenarios where the websockets approach provides better connectivity which is what I think we need to see before we can say that it is worthwhile.

Regards
Andy

---

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 25 Sep 2013 11:40:00 -0700

Andy, you are not mentioning the case when no explicit web proxy is
configured. See below:

> it serves a good purpose.

it provides benefits when no explicit web proxy is configured in the
enterprise network.

> [AndyH] Not really the proposal is to encapsulate TURN within a websockets

I meant just that. From the firewall perspective it will be HTTP.

> [AndyH] Exactly the media handling has nothing to do with the web server
> but websockets uses HTTP upgrade mechanism because it was designed to allow
> the web server to use the same port for HTTP and websockets (See
> http://tools.ietf.org/html/rfc6455#section-1.3). This mechanism is not
> needed in WebRTC because the web server and TURN server are not the same
> server.
>

Web servers and TURN servers are not the same - a good observation. They
use different IP addresses. And both are allowed to use port 80, 443 or
8080 or whatever.

The analogy is media over TCP. TCP was not designed as a suitable for media
protocol. It is inferior to UDP and any media channel over TCP is
artificial and totally against the TCP original intentions and TCP design.

According to your logic, TCP has unnecessary (for media) overhead over UDP
So, if we are all technological purists here, we must immediately ban any
media over TCP and remove that from WebRTC specs. But we discovered that in
some cases TCP is necessary because there is no other way to deliver the
data. This is a compromise.

This is totally the same with websockets. It was designed for a different
purpose. But while technology progresses, it uses the available tools and
gadgets to move ahead. We found that websockets is helpful in extending
WebRTC connectivity. Pretty much the same as earlier it was found that
media over TCP is sometimes required (and accepted).

So, if we do not accept TURN inside Websockets then we must start an
immediate campaign against media inside TURN TCP connections and through it
out of WebRTC specs. These things are totally symmetrical in all senses,
and they serve the same purpose - the connectivity purpose, and they have
the same problems.

> [AndyH] The subprotocol is nice but I assume the firewall only sees this
> if the websockets connection is not encrypted it seems to me that it might
> be better to have something like the subprotocol indicating TURN in the
> HTTP CONNECT making it clear to the proxy the purpose of the connection
> encrypted or not.
>

Again, sometimes we have to HTTP CONNECT when explicit proxy is not present.

> [AndyH] Can you explain in what scenarios TURN over Websockets would work
> and TURN/TCP with HTTP Connect would not?
>

When explicit proxy is not configured.

> [AndyH] I am not sure I understand your point here. If there are no
> significant advantage to using the websockets encapsulation and I have not
> heard one yet, then the overhead is again something we could do without.
>
>
when explicit proxy is not configured

> [AndyH] I don't think we should discuss DPI it should simply be out of
OK

> [AndyH] You have but I am not yet convinced of the benefit I think we need
> concrete examples of why a websockets approach would be more successful
> than just TURN/TCP using HTTP CONNECT.
>
>
See above

Regards,
Oleg

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 25 Sep 2013 19:03:28 +0000

Below.

> Sent: 25 September 2013 19:40
> To: Hutton, Andrew
> Cc: [email-masked]

[AndyH] True I was considering that as the simple case and of course there is no HTTP CONNECT in that scenario. So are you saying that when there is no proxy then a websockets connection is more likely to work than a TURN/TCP or TURN/TLS connection. I would be interested in whether there is evidence of that I am not sure whether it is true or not certainly in the encrypted case I don't see how this can be but I am not an expert on this.  

> 
> On Wed, Sep 25, 2013 at 11:19 AM, Hutton, Andrew
> <[email-masked]> wrote:
> 
> >
> [AndyH] Exactly the media handling has nothing to do with the web
> server but websockets uses HTTP upgrade mechanism because it was
> designed to allow the web server to use the same port for HTTP and
> websockets (See http://tools.ietf.org/html/rfc6455#section-1.3). This
> mechanism is not needed in WebRTC because the web server and TURN
> server are not the same server.
> 
> Web servers and TURN servers are not the same - a good observation.
> They use different IP addresses. And both are allowed to use port 80,
> 443 or 8080 or whatever.
> The analogy is media over TCP. TCP was not designed as a suitable for
> media protocol. It is inferior to UDP and any media channel over TCP is
> According to your logic, TCP has unnecessary (for media) overhead over
> UDP So, if we are all technological purists here, we must immediately
> ban any media over TCP and remove that from WebRTC specs. But we
> discovered that in some cases TCP is necessary because there is no
> other way to deliver the data. This is a compromise.
> This is totally the same with websockets. It was designed for a
> different purpose. But while technology progresses, it uses the
> available tools and gadgets to move ahead. We found that websockets is
> helpful in extending WebRTC connectivity. Pretty much the same as
> earlier it was found that media over TCP is sometimes required (and
> accepted).
> 
> immediate campaign against media inside TURN TCP connections and
> through it out of WebRTC specs. These things are totally symmetrical in
> all senses, and they serve the same purpose - the connectivity purpose,
> and they have the same problems.
> 

[AndyH] Sorry I don't get this argument at all the question is simply whether the websockets overhead is worthwhile or not.

> [AndyH] The subprotocol is nice but I assume the firewall only sees
> this if the websockets connection is not encrypted it seems to me that
> it might be better to have something like the subprotocol indicating
> TURN in the HTTP CONNECT making it clear to the proxy the purpose of
> the connection encrypted or not.
> 
> the
> [AndyH] Can you explain in what scenarios TURN over Websockets would
> work and TURN/TCP with HTTP Connect would not?
> 
> significant advantage to using the websockets encapsulation and I have
> not heard one yet, then the overhead is again something we could do
> without.
> 
> 
> > better control for those wanting to assert policies on the handling
> of
> > media.
> >
> [AndyH] You have but I am not yet convinced of the benefit I think we
> need concrete examples of why a websockets approach would be more
> successful than just TURN/TCP using HTTP CONNECT.
> 
> See above
> 
> Regards,
> Oleg

---

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 25 Sep 2013 12:18:11 -0700

Andy, see below:

On Wed, Sep 25, 2013 at 12:03 PM, Hutton, Andrew <
[email-masked]> wrote:

>
> [AndyH] True I was considering that as the simple case and of course there
> is no HTTP CONNECT in that scenario. So are you saying that when there is
> no proxy then a websockets connection is more likely to work than a
> TURN/TCP or TURN/TLS connection. I would be interested in whether there is
> evidence of that I am not sure whether it is true or not certainly in the
> encrypted case I don't see how this can be but I am not an expert on this.
>

I cannot say that I am exactly an expert in IT firewall world, too. But I
personally observed a rather strict corporate environments where a strict
firewall is used without explicit HTTP proxy. Also, I heard from our TURN
server users the stories about similar cases. The usual story was that the
firewall blocks the outgoing TURN TCP connection unless it is destined to
80/443 port and it has an HTTP handshake.

> [AndyH] Sorry I don't get this argument at all the question is simply
> whether the websockets overhead is worthwhile or not.
>
>
Andy, I was trying to answer that exactly question. My point was that when
we use TCP to transmit the media, we have extra overhead over UDP (and
significantly more overhead than Websockets over "plain" TCP). Still, we
are OK with that overhead because we have no choice - we want extra
connectivity provided by TCP. I was just trying to make the Websockets vs
TCP story similar to TCP vs UDP story, in the particular media transmission
application. And in a similar way, I was making a conclusion that the
overhead is worthwhile.

Another point is that TCP adds so much overhead to the media transmission
(comparing to UDP) that an extra minor addition by Websockets is virtually
negligible - if we have a good reason for that (and I believe we do have).

But, of course, nobody likes the overhead.

Thanks
Oleg

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 25 Sep 2013 22:39:52 +0200

El 25/09/2013 21:18, Oleg Moskalenko escribió:
> Andy, see below:
>
> On Wed, Sep 25, 2013 at 12:03 PM, Hutton, Andrew 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     [AndyH] True I was considering that as the simple case and of
>     course there is no HTTP CONNECT in that scenario. So are you
>     saying that when there is no proxy then a websockets connection is
>     more likely to work than a TURN/TCP or TURN/TLS connection. I
>     would be interested in whether there is evidence of that I am not
>     sure whether it is true or not certainly in the encrypted case I
>     don't see how this can be but I am not an expert on this.
>
>
> I cannot say that I am exactly an expert in IT firewall world, too. 
> But I personally observed a rather strict corporate environments where 
> a strict firewall is used without explicit HTTP proxy. Also, I heard 
> from our TURN server users the stories about similar cases. The usual 
> story was that the firewall blocks the outgoing TURN TCP connection 
> unless it is destined to 80/443 port and it has an HTTP handshake.
>
Exactly the same case here. I have (had) a "potential" customer that is 
using a cloud based network filtering solution, and SIP over secure 
websockets works but TURN over TLS on port 443 doesn't. I yet have to 
double check my TURN TLS settings to see if everything is correctly 
configured and working correctly with chrome.

Best regards
Sergio

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 26 Sep 2013 03:26:43 +0000

Hi Oleg,

Please see inline [TR]

From: [email-masked] [mailto:[email-masked]] On Behalf Of Sergio Garcia Murillo
Sent: Thursday, September 26, 2013 2:10 AM
To: [email-masked]
Subject: Re: [pntaw] TURN over websockets or just TURN.

On Wed, Sep 25, 2013 at 12:03 PM, Hutton, Andrew <[email-masked]<mailto:[email-masked]>> wrote:

I cannot say that I am exactly an expert in IT firewall world, too. But I personally observed a rather strict corporate environments where a strict firewall is used without explicit HTTP proxy. Also, I heard from our TURN server users the stories about similar cases. The usual story was that the firewall blocks the outgoing TURN TCP connection unless it is destined to 80/443 port and it has an HTTP handshake.

Exactly the same case here. I have (had) a "potential" customer that is using a cloud based network filtering solution, and SIP over secure websockets works but TURN over TLS on port 443 doesn't. I yet have to double check my TURN TLS settings to see if everything is correctly configured and working correctly with chrome.

[TR] Various Enterprises in addition to firewalls are also using cloud connector which re-directs HTTP/HTTPS traffic to cloud based "Security As A Service" (SecaaS) for DPI, reputation based filtering etc http://www.gartner.com/technology/reprints.do?id=1-1FVA8PB&ct=130603&st=sb. SecaaS can also do HTTPS inspection by acting as HTTPS proxy.

-Tiru.

Best regards
Sergio

---

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 25 Sep 2013 23:41:08 -0700

Hi Tiru

thanks for the info !

What is your opinion, do we have to add something to the draft to improve
our interoperability with  Secaas systems ?

We are pretty much concentrating on two major aspects:

1) Connectivity
2) Ability for the network managers to set the access policies.

Regards,
Oleg

On Wed, Sep 25, 2013 at 8:26 PM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

>  Hi Oleg,****
>
> ** **
>
> Please see inline [TR]****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Sergio Garcia Murillo
> *Sent:* Thursday, September 26, 2013 2:10 AM
> *To:* [email-masked]
>
> *Subject:* Re: [pntaw] TURN over websockets or just TURN.****
>
>  ** **
>
> El 25/09/2013 21:18, Oleg Moskalenko escribió:****
>
>  Andy, see below:****
>
> ** **
>
> [email-masked]> wrote:****
>
>
> ****
> ** **
> 80/443 port and it has an HTTP handshake.****
>
> ** **
>
> configured and working correctly with chrome.****
>
> ** **
>
> [TR] Various Enterprises in addition to firewalls are also using cloud
> connector which re-directs HTTP/HTTPS traffic to cloud based "Security As A
> Service" (SecaaS) for DPI, reputation based filtering etc
> http://www.gartner.com/technology/reprints.do?id=1-1FVA8PB&ct=130603&st=sb.
> SecaaS can also do HTTPS inspection by acting as HTTPS proxy. ****
>
> ** **
>
> -Tiru.
>
> Best regards
> Sergio****
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 26 Sep 2013 10:49:17 +0000

Hi Oleg,

My opinion is that in such scenarios where Firewall + SecaaS is used, the Enterprise Security policies would like to do the following

1)Permit UDP pinholes through the firewalls only for WebRTC sessions originated by certain domains that Enterprise has business tie-up with.
2)Block UDP pinholes through the firewall for the rest of the domains.  In this case "TURN over web-sockets" would be of help since the traffic would go through SecaaS and it can make a decision whether to permit or block the traffic based on various information like Black-listed/White-listed TURN servers, TURN over web-sockets is permitted/denied etc. For example media session initiated using Skype (which has no business tie-up with the Enterprise) could be permitted over "TURN over web-sockets" because SecaaS can identify the traffic and also enforce granular policies for example

a)permit the "TURN over web-sockets" session only during non-business hours
b)permit the "TURN over web-sockets" session only for guests.

-Tiru.
From: Oleg Moskalenko [mailto:[email-masked]]
Sent: Thursday, September 26, 2013 12:11 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Sergio Garcia Murillo; [email-masked]
Subject: Re: [pntaw] TURN over websockets or just TURN.

Hi Tiru
thanks for the info !
What is your opinion, do we have to add something to the draft to improve our interoperability with  Secaas systems ?
We are pretty much concentrating on two major aspects:
1) Connectivity
2) Ability for the network managers to set the access policies.
Regards,
Oleg

On Wed, Sep 25, 2013 at 8:26 PM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Oleg,

Please see inline [TR]

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Sergio Garcia Murillo
Sent: Thursday, September 26, 2013 2:10 AM
To: [email-masked]<mailto:[email-masked]>

-Tiru.

Best regards
Sergio

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