Re: [pntaw] TURN over websockets

"Parthasarathi R" <partha@parthasarathi.co.in> Sat, 31 August 2013 16:24 UTC

Return-Path: <partha@parthasarathi.co.in>
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 A4A5D11E8152 for <pntaw@ietfa.amsl.com>; Sat, 31 Aug 2013 09:24:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level:
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
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 AvGyl-hLm+d2 for <pntaw@ietfa.amsl.com>; Sat, 31 Aug 2013 09:24:50 -0700 (PDT)
Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.237]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF1E11E812D for <pntaw@ietf.org>; Sat, 31 Aug 2013 09:24:50 -0700 (PDT)
Received: from userPC (unknown [122.172.179.232]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id DE5FC638CDD; Sat, 31 Aug 2013 16:24:45 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1377966289; bh=NmUkhJ+OYKuK9am1/MLjtHwa9Rv/Ht2uZ++Wj0YsCL4=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=SUAqo6ilAJCaVzZ7ZmzzKY6vyeyH2M8RNA6Wj9W/u0OzcEYMoRWWwpi6axHOfcJIb ZL14LSkIcPpWZii8wVIq2AtELlX/y4Ksbo6FOn9wzXnXRfvXOsCNBMVzLEuC0nJ/6a a7cQ+BEFTmj+uVbpaUMC7stDhQkYJoZZuQcTKIpg=
From: Parthasarathi R <partha@parthasarathi.co.in>
To: 'Sergio Garcia Murillo' <sergio.garcia.murillo@gmail.com>, "'Stach, Thomas'" <thomas.stach@siemens-enterprise.com>
References: <52205AE1.9010807@gmail.com> <F81CEE99482EFE438DAE2A652361EE12179BF94B@MCHP04MSX.global-ad.net> <5220968E.2050708@gmail.com>
In-Reply-To: <5220968E.2050708@gmail.com>
Date: Sat, 31 Aug 2013 21:54:35 +0530
Message-ID: <004e01cea666$98e9b090$cabd11b0$@co.in>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac6lgGULYWCEuoOvRBOX3jgjCAJPWgA5BESg
Content-Language: en-us
X-CTCH-RefID: str=0001.0A0C0203.522218D1.00AC, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules:
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CTCH-SenderID: partha@parthasarathi.co.in
X-CTCH-SenderID-TotalMessages: 1
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalRecipients: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-BlueWhiteFlag: 0
X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142
Cc: 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: Sat, 31 Aug 2013 16:24:54 -0000

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.

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