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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

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:[e-mail]]
Sent: Thursday, September 26, 2013 12:11 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Sergio Garcia Murillo; [e-mail]
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) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Oleg,

Please see inline [TR]

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

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

El 25/09/2013 21:18, Oleg Moskalenko escribió:
Andy, see below:

On Wed, Sep 25, 2013 at 12:03 PM, Hutton, Andrew <[e-mail]<mailto:[e-mail]>> 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.

[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

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