IETF Logo Mail Archive

Re: [pntaw] New version of draft-hutton-rtcweb-nat-firewall-considerations

<Markus.Isomaki@nokia.com> Mon, 23 September 2013 09:57 UTC

Return-Path: <Markus.Isomaki@nokia.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 AE19021F84D0 for <pntaw@ietfa.amsl.com>; Mon, 23 Sep 2013 02:57:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.35
X-Spam-Level:
X-Spam-Status: No, score=-6.35 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156]
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 p5vpYzBySc0A for <pntaw@ietfa.amsl.com>; Mon, 23 Sep 2013 02:57:05 -0700 (PDT)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 526E021F9CB0 for <pntaw@ietf.org>; Mon, 23 Sep 2013 02:48:57 -0700 (PDT)
Received: from smtp.mgd.nokia.com ([65.54.30.50]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r8N9jl5d009377 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 23 Sep 2013 12:45:48 +0300
Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.213]) by 008-AM1MMR2-016.mgdnok.nokia.com ([65.54.30.50]) with mapi id 14.03.0136.001; Mon, 23 Sep 2013 09:45:47 +0000
From: Markus.Isomaki@nokia.com
To: sergio.garcia.murillo@gmail.com, andrew.hutton@siemens-enterprise.com
Thread-Topic: [pntaw] New version of draft-hutton-rtcweb-nat-firewall-considerations
Thread-Index: AQHOuDtYflHPznATyEWuFaO/MC8qupnTEJrA
Date: Mon, 23 Sep 2013 09:45:46 +0000
Message-ID: <E44893DD4E290745BB608EB23FDDB7620A0C0990@008-AM1MPN1-043.mgdnok.nokia.com>
References: <9F33F40F6F2CD847824537F3C4E37DDF17BCF3A5@MCHP04MSX.global-ad.net>, , <523CCD06.3030902@gmail.com>, <BLU169-W136A55AC013DA147313576D93220@phx.gbl>, <523CD42E.8070102@gmail.com> <BLU169-W82036280852F26ED26283C93230@phx.gbl>, <523D4F17.2040202@gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17BD01A8@MCHP04MSX.global-ad.net> <52400320.2070404@gmail.com>
In-Reply-To: <52400320.2070404@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tituslabs-classifications-30: TLPropertyRoot=Nokia; Confidentiality=Nokia Internal Use Only; Project=None;
x-titus-version: 3.5.9.3
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IgGGMI/hiHEM6lUUemiRPGnmf5wvrYCP1LsyqkjSWZ9xxO0drW75YWcMwNNdwy6lpEcleSIHCyvS9mqXZQEND8jb8etbOR6/AXGsnuxTxDGKAA2jIMPvViwlpc/YhWpb8iG0wxi47jl1y6cinTkqUTnt03aa7rVGuhuwoWk5/51lUcnrFoDTlw+rVoY22nyew7G24hxQCxfYqE4xMWlBDyZXFCKdsGs+3DkBa1c0fhKmL1P3OV+NQhFn+jHzxl+JMcnMNhiWTHCV8G00T2dOTsA=
x-originating-ip: [172.21.80.69]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Nokia-AV: Clean
Cc: bernard_aboba@hotmail.com, pntaw@ietf.org
Subject: Re: [pntaw] New version of draft-hutton-rtcweb-nat-firewall-considerations
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: Mon, 23 Sep 2013 09:57:38 -0000

Hi,

Sergio Carcia Murillo wrote:
> 
> El 22/09/2013 0:48, Hutton, Andrew escribió:
> > I just don't see any advantage in the TURN over Websockets approach over
> the HTTP Connect initiated tunnel which works without any new protocol and
> therefore works with existing TURN servers.
> 
> How about transparent proxying?
> 

Can you elaborate on this?

I think in either case the proxy sees possibly one transaction. In TURN over HTTP CONNECT established TLS connection, the proxy sees the HTTP CONNECT transaction and it's destination URI. If it's just "transparently" proxying, things will work, which is what we want. On the other hand, if there is some explicit policy, the proxy can also apply it - for instance if the destination domain is now allowed. I'm not sure if the TURN over WS has any advantages in this regard.

The disadvantage is that TURN over WS would require a change to TURN servers. I know you have argued that it is a very trivial change and I believe you, but nevertheless all existing servers would need to be upgraded and that's the problem. 

Markus

v2.23.0 | Report a Bug | By Email