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

"Hutton, Andrew" <andrew.hutton@unify.com> Thu, 02 January 2014 14:56 UTC

Return-Path: <andrew.hutton@unify.com>
X-Original-To: pntaw@ietfa.amsl.com
Delivered-To: pntaw@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 203981AE0C4 for <pntaw@ietfa.amsl.com>; Thu, 2 Jan 2014 06:56:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.539
X-Spam-Level:
X-Spam-Status: No, score=-0.539 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dB5ssmnWyPUs for <pntaw@ietfa.amsl.com>; Thu, 2 Jan 2014 06:56:11 -0800 (PST)
Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 42B411AC440 for <pntaw@ietf.org>; Thu, 2 Jan 2014 06:56:11 -0800 (PST)
Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id C10E423F0413; Thu, 2 Jan 2014 15:56:02 +0100 (CET)
Received: from MCHP04MSX.global-ad.net ([169.254.1.126]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Thu, 2 Jan 2014 15:56:02 +0100
From: "Hutton, Andrew" <andrew.hutton@unify.com>
To: "sergio.garcia.murillo@gmail.com" <sergio.garcia.murillo@gmail.com>
Thread-Topic: [pntaw] New version of draft-hutton-rtcweb-nat-firewall-considerations
Thread-Index: AQHOuEI3WdWGgMZKyk6WRTa2tHhJqppyI70g
Date: Thu, 2 Jan 2014 14:56:01 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17C8FA6E@MCHP04MSX.global-ad.net>
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> <E44893DD4E290745BB608EB23FDDB7620A0C0990@008-AM1MPN1-043.mgdnok.nokia.com>
In-Reply-To: <E44893DD4E290745BB608EB23FDDB7620A0C0990@008-AM1MPN1-043.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.29.42.225]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "bernard_aboba@hotmail.com" <bernard_aboba@hotmail.com>, "pntaw@ietf.org" <pntaw@ietf.org>, "Markus.Isomaki@nokia.com" <Markus.Isomaki@nokia.com>
Subject: Re: [pntaw] New version of draft-hutton-rtcweb-nat-firewall-considerations
X-BeenThere: pntaw@ietf.org
X-Mailman-Version: 2.1.15
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, 02 Jan 2014 14:56:13 -0000

Hi Sergio,

Going back over some old mails with a view to restarting this discussion and updating my draft.

With regard to the transparent proxy could you explain why there is an advantage to using the RTP over websockets approach as compared to the HTTP CONNECT mechanism as currently described in draft-hutton-rtcweb-nat-firewall-considerations.

Regards
Andy





> -----Original Message-----
> From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]
> Sent: 23 September 2013 10:46
> To: sergio.garcia.murillo@gmail.com; Hutton, Andrew
> Cc: bernard_aboba@hotmail.com; pntaw@ietf.org
> Subject: RE: [pntaw] New version of draft-hutton-rtcweb-nat-firewall-
> considerations
> 
> 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