IETF Logo Mail Archive

Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt

"Hutton, Andrew" <andrew.hutton@unify.com> Fri, 06 February 2015 10:49 UTC

Return-Path: <andrew.hutton@unify.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9E81A01EC for <tram@ietfa.amsl.com>; Fri, 6 Feb 2015 02:49:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.609
X-Spam-Level:
X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 C-vFNLSorSlT for <tram@ietfa.amsl.com>; Fri, 6 Feb 2015 02:49:12 -0800 (PST)
Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id BE07E1A01CB for <tram@ietf.org>; Fri, 6 Feb 2015 02:49:11 -0800 (PST)
Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id EE42023F048E; Fri, 6 Feb 2015 11:49:09 +0100 (CET)
Received: from MCHP04MSX.global-ad.net ([169.254.1.206]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0224.002; Fri, 6 Feb 2015 11:49:09 +0100
From: "Hutton, Andrew" <andrew.hutton@unify.com>
To: Justin Uberti <juberti@google.com>, "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
Thread-Topic: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt
Thread-Index: AQHQQacTqq8Ul8nRs0eSp74XlWYQPpzjbsBA
Date: Fri, 06 Feb 2015 10:49:08 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E6AC8F3@MCHP04MSX.global-ad.net>
References: <20150204152347.30593.20532.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35538DB9@xmb-rcd-x10.cisco.com> <CANO7kWBebVBULHhiqUwXWZw0rCPFyKwEjB_KXrM3tBOMy8aFbQ@mail.gmail.com> <CAHbrMsCrw0m6AUbZaUHuOcj8+vw_b-Kmdcr+SH5+hA7sf-FUfw@mail.gmail.com> <913383AAA69FF945B8F946018B75898A35538E3D@xmb-rcd-x10.cisco.com> <CAHbrMsC=jjnG+XDApuOp6rhb-KnUqTiqo+S4mMN_zY_KGXvDXg@mail.gmail.com> <913383AAA69FF945B8F946018B75898A35538F91@xmb-rcd-x10.cisco.com> <CAHbrMsD470cNBPUXpdSXuNeJ5+sg22vvCuh2P9ZHMA_WdEAuTA@mail.gmail.com> <913383AAA69FF945B8F946018B75898A355390B9@xmb-rcd-x10.cisco.com> <CAOJ7v-253T3=4FfcgCreyAYgBpv3174kPW-GPYfsX6rG8nEGSg@mail.gmail.com>
In-Reply-To: <CAOJ7v-253T3=4FfcgCreyAYgBpv3174kPW-GPYfsX6rG8nEGSg@mail.gmail.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: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF1E6AC8F3MCHP04MSXglobal_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tram/9I9R7Sqnv50z3m9hOaZgTcgikt4>
Cc: Simon Perreault <sperreault@jive.com>, Benjamin Schwartz <bemasc@webrtc.org>, "tram@ietf.org" <tram@ietf.org>
Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2015 10:49:15 -0000

On a first read I am also rather skeptical about handing this privacy function over to the TURN server.

The draft introduces the first argument I have seen against using https://tools.ietf.org/html/draft-schwartz-rtcweb-return-03 in that it states:

“If the third party offered TURN server can provide IP address privacy then the application can avoid TURN-in-TURN mechanism discussed in[I-D.schwartz-rtcweb-return<http://tools.ietf.org/html/draft-reddy-tram-turn-ipaddress-privacy-00#ref-I-D.schwartz-rtcweb-return>] and thus avoid the overhead of using RETURN proxying”.

However it does not seem to me that the overhead of using a RETURN proxy is really that significant given that the RETURN proxy is likely to be close to the client in the enterprise proxy/firewall or in the access network.

Andy





From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: 06 February 2015 00:51
To: Tirumaleswar Reddy (tireddy)
Cc: Simon Perreault; Benjamin Schwartz; tram@ietf.org
Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt

I agree with Simon and Ben in being skeptical about this proposal.

The client is the only party which knows exactly what 'privacy' means, and there is no trivial way to serialize this into a single attribute for the TURN server.

As such, I think this decision should be left entirely to the client.

On Wed, Feb 4, 2015 at 10:50 AM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com<mailto:tireddy@cisco.com>> wrote:
I agree that the client can do equally well itself, by sending a STUN Binding Request and comparing the response to the TURN server's own IP address.

[TR3] The difference this draft brings in is that it helps the TURN server (offered by a global or cloud service) to determine that the client wants privacy and level of privacy required conveyed in the new STUN attribute, the TURN server determines suitable alternate TURN server that can offer the required level of privacy.

-Tiru

_______________________________________________
tram mailing list
tram@ietf.org<mailto:tram@ietf.org>
https://www.ietf.org/mailman/listinfo/tram

v2.23.0 | Report a Bug | By Email