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
- [pntaw] TURN over websockets Sergio Garcia Murillo
- Re: [pntaw] TURN over websockets Lorenzo Miniero
- Re: [pntaw] TURN over websockets Sergio Garcia Murillo
- Re: [pntaw] TURN over websockets Simon Pietro Romano
- Re: [pntaw] TURN over websockets Stach, Thomas
- Re: [pntaw] TURN over websockets Markus.Isomaki
- Re: [pntaw] TURN over websockets Simon Perreault
- Re: [pntaw] TURN over websockets Sergio Garcia Murillo
- Re: [pntaw] TURN over websockets Markus.Isomaki
- Re: [pntaw] TURN over websockets Simon Perreault
- Re: [pntaw] TURN over websockets Sergio Garcia Murillo
- Re: [pntaw] TURN over websockets Stach, Thomas
- Re: [pntaw] TURN over websockets Tirumaleswar Reddy (tireddy)
- Re: [pntaw] TURN over websockets Marc Blanchet
- Re: [pntaw] TURN over websockets Hutton, Andrew
- Re: [pntaw] TURN over websockets Parthasarathi R
- Re: [pntaw] TURN over websockets Martin Thomson
- Re: [pntaw] TURN over websockets Melinda Shore
- Re: [pntaw] TURN over websockets Stephen Farrell
- Re: [pntaw] TURN over websockets Tirumaleswar Reddy (tireddy)
- Re: [pntaw] TURN over websockets Tirumaleswar Reddy (tireddy)
- Re: [pntaw] TURN over websockets Markus.Isomaki
- Re: [pntaw] TURN over websockets Simon Perreault