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

"Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com> Thu, 26 September 2013 10:49 UTC

Return-Path: <tireddy@cisco.com>
X-Original-To: pntaw@ietfa.amsl.com
Delivered-To: pntaw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8EF11E8189 for <pntaw@ietfa.amsl.com>; Thu, 26 Sep 2013 03:49:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.204
X-Spam-Level:
X-Spam-Status: No, score=-10.204 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftoRyELU3tkc for <pntaw@ietfa.amsl.com>; Thu, 26 Sep 2013 03:49:19 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id A326111E80AD for <pntaw@ietf.org>; Thu, 26 Sep 2013 03:49:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20418; q=dns/txt; s=iport; t=1380192559; x=1381402159; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7EWQq0wa8Cwwg5w3iXJluusZdxTsaCIXG+GSmaypGOM=; b=mH4sSmLl0EamI8VvyqRDc4iPksq2KiQlmMXH9PADPTh33waljvaneoRY c/fzzP5muJfIx2Ss/r9TKB7ye7MVB1T/Hs0txV6VREp4shinHrkOwF4G4 2Y/QktBHw9dJarw6sYpntW8P2ZRSZR7AOhTWr5BplHwP0fITONngJX4nv I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjMFALUQRFKtJXHA/2dsb2JhbABRCoJDRDhSwFSBIhZ0giUBAQEEAQEBKj4DCxACAQgOAwQBAQsdByEGCxQJCAIEDgUIE4dZAw8MsmANiWqMZoEogRItBAYBgx2BAQOJAY0Tji2FNIMkgio
X-IronPort-AV: E=Sophos; i="4.90,984,1371081600"; d="scan'208,217"; a="264728259"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 26 Sep 2013 10:49:18 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r8QAnItP023274 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Sep 2013 10:49:18 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Thu, 26 Sep 2013 05:49:18 -0500
From: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
To: Oleg Moskalenko <mom040267@gmail.com>
Thread-Topic: [pntaw] TURN over websockets or just TURN.
Thread-Index: Ac651aqKgci54WbeToGdcCETWYgQigAWo1kAAAViDwAAALMdAAAA0c8AAACDlIAAAtpOAAADozFAABFcjQAABRWeUA==
Date: Thu, 26 Sep 2013 10:49:17 +0000
Message-ID: <913383AAA69FF945B8F946018B75898A1907FACF@xmb-rcd-x10.cisco.com>
References: <9F33F40F6F2CD847824537F3C4E37DDF17BD44F6@MCHP04MSX.global-ad.net> <CALDtMrK9K-zSUd6-cLeRkkb0zixE=CDKKmOkfRCHNP-CZcriXg@mail.gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17BD53FD@MCHP04MSX.global-ad.net> <CALDtMrLfg3AJFOr=DYSGkhxrwuTA=LY3F6k9AJN7NCKCY+B0ZQ@mail.gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17BD5567@MCHP04MSX.global-ad.net> <CALDtMrL=CA8Y8urr+p2=AOFEWA-2Wn0BcoSc37foM1KOFinAmQ@mail.gmail.com> <52434A18.3080707@gmail.com> <913383AAA69FF945B8F946018B75898A1907F780@xmb-rcd-x10.cisco.com> <CALDtMrLy8O52k16zxtKiW6mUAC4XMEv87AxVQ7-afKELM-v7rA@mail.gmail.com>
In-Reply-To: <CALDtMrLy8O52k16zxtKiW6mUAC4XMEv87AxVQ7-afKELM-v7rA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [173.39.64.115]
Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A1907FACFxmbrcdx10ciscoc_"
MIME-Version: 1.0
Cc: "pntaw@ietf.org" <pntaw@ietf.org>, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Subject: Re: [pntaw] TURN over websockets or just TURN.
X-BeenThere: pntaw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for practices related to proxies, NATs, TURN, and WebRTC" <pntaw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pntaw>, <mailto:pntaw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pntaw>
List-Post: <mailto:pntaw@ietf.org>
List-Help: <mailto:pntaw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pntaw>, <mailto:pntaw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Sep 2013 10:49:24 -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:mom040267@gmail.com]
Sent: Thursday, September 26, 2013 12:11 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Sergio Garcia Murillo; pntaw@ietf.org
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) <tireddy@cisco.com<mailto:tireddy@cisco.com>> wrote:
Hi Oleg,

Please see inline [TR]

From: pntaw-bounces@ietf.org<mailto:pntaw-bounces@ietf.org> [mailto:pntaw-bounces@ietf.org<mailto:pntaw-bounces@ietf.org>] On Behalf Of Sergio Garcia Murillo
Sent: Thursday, September 26, 2013 2:10 AM
To: pntaw@ietf.org<mailto:pntaw@ietf.org>

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 <andrew.hutton@siemens-enterprise.com<mailto:andrew.hutton@siemens-enterprise.com>> 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=sbmp;st=sb. SecaaS can also do HTTPS inspection by acting as HTTPS proxy.

-Tiru.

Best regards
Sergio

_______________________________________________
pntaw mailing list
pntaw@ietf.org<mailto:pntaw@ietf.org>
https://www.ietf.org/mailman/listinfo/pntaw