Re: [pntaw] TURN over websockets

"Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com> Sun, 01 September 2013 04:03 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 0E4E311E8111 for <pntaw@ietfa.amsl.com>; Sat, 31 Aug 2013 21:03:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.51
X-Spam-Level:
X-Spam-Status: No, score=-10.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, 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 XC6IJ9RZsiLF for <pntaw@ietfa.amsl.com>; Sat, 31 Aug 2013 21:03:53 -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 10BF511E8107 for <pntaw@ietf.org>; Sat, 31 Aug 2013 21:03:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5576; q=dns/txt; s=iport; t=1378008233; x=1379217833; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Y3VQYQs/FSb2i8TW+DOHxYC+uplupH9Ruh19JJE72cM=; b=DFtyCABJx2una477KcUhU+vDndZeOcUUEvyQd/3ctMQkrC/Nt9SXgWIW zMBaNEy/K4QQIyPZDJYZjipMFmYX81MnO9A31CLEjl7v9wlMt1J+q3yt8 VfVWwHBgjzFQBiT266pmWmc7RaVRLMsGhARNy5hIr9R/g9P+HhpatM2ak I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFAM27IlKtJV2Z/2dsb2JhbABDFoMHNVHAa4EeFnSCJAEBAQMBAQEBawsMBAIBCBEEAQELCRQHJwsUCQgCBA4FCBOHYQYMuWIEji4BgR8xBwaDF4EAA4h9ix6VQIMggio
X-IronPort-AV: E=Sophos;i="4.89,1000,1367971200"; d="scan'208";a="254208302"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 01 Sep 2013 04:03:52 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8143qcZ004625 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 1 Sep 2013 04:03:52 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.8]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Sat, 31 Aug 2013 23:03:52 -0500
From: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
To: Parthasarathi R <partha@parthasarathi.co.in>, 'Sergio Garcia Murillo' <sergio.garcia.murillo@gmail.com>, "'Stach, Thomas'" <thomas.stach@siemens-enterprise.com>
Thread-Topic: [pntaw] TURN over websockets
Thread-Index: AQHOpVzYlJ1THI1FykWlGCDZp+nOV5muA8IAgAAGGgCAAcxlgIAAbzlg
Date: Sun, 01 Sep 2013 04:03:51 +0000
Message-ID: <913383AAA69FF945B8F946018B75898A1903D695@xmb-rcd-x10.cisco.com>
References: <52205AE1.9010807@gmail.com> <F81CEE99482EFE438DAE2A652361EE12179BF94B@MCHP04MSX.global-ad.net> <5220968E.2050708@gmail.com> <004e01cea666$98e9b090$cabd11b0$@co.in>
In-Reply-To: <004e01cea666$98e9b090$cabd11b0$@co.in>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.67.234]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "pntaw@ietf.org" <pntaw@ietf.org>
Subject: Re: [pntaw] TURN over websockets
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: Sun, 01 Sep 2013 04:03:58 -0000

> -----Original Message-----
> From: pntaw-bounces@ietf.org [mailto:pntaw-bounces@ietf.org] On Behalf Of
> Parthasarathi R
> Sent: Saturday, August 31, 2013 9:55 PM
> To: 'Sergio Garcia Murillo'; 'Stach, Thomas'
> Cc: pntaw@ietf.org
> Subject: Re: [pntaw] TURN over websockets
> 
> 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.

+1

-Tiru.

> 
> Thanks
> Partha
> 
> > -----Original Message-----
> > From: pntaw-bounces@ietf.org [mailto:pntaw-bounces@ietf.org] On Behalf
> > Of Sergio Garcia Murillo
> > Sent: Friday, August 30, 2013 6:27 PM
> > To: Stach, Thomas
> > Cc: pntaw@ietf.org
> > Subject: Re: [pntaw] TURN over websockets
> >
> > Hi Thomas,
> >
> > Inline.
> >
> > El 30/08/2013 14:34, Stach, Thomas escribió:
> > > Sergio,
> > >
> > > Some comments inline
> > >
> > >> -----Original Message-----
> > >> From: pntaw-bounces@ietf.org [mailto:pntaw-bounces@ietf.org] On
> > Behalf
> > >> Of Sergio Garcia Murillo
> > >> Sent: Freitag, 30. August 2013 10:42
> > >> To: pntaw@ietf.org
> > >> Subject: [pntaw] TURN over websockets
> > >>
> > >> 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.
> > > [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.
> > And also does mention TURN over websockets, while it consider it to be
> > not necessary.
> > > 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.
> >
> > 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.
> >
> >
> > >> 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.
> > > [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.
> > >> And,  for me the most viable solution would be to enable TURN over
> > >> 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.
> >
> > Yes, it would require additions to the TURN protocol and new
> > developments on TURN software.
> >
> > > 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.
> > > [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
> > _______________________________________________
> > pntaw mailing list
> > pntaw@ietf.org
> > https://www.ietf.org/mailman/listinfo/pntaw
> 
> _______________________________________________
> pntaw mailing list
> pntaw@ietf.org
> https://www.ietf.org/mailman/listinfo/pntaw