From nobody Mon Feb 8 04:01:23 2016 Return-Path: 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 67E931AD49B for ; Mon, 8 Feb 2016 04:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] 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 KwY6oWsJDSW9 for ; Mon, 8 Feb 2016 04:01:21 -0800 (PST) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDA0A1AD47E for ; Mon, 8 Feb 2016 04:01:20 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id 39D151EB8458; Mon, 8 Feb 2016 13:01:19 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.37.243]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0279.002; Mon, 8 Feb 2016 13:01:19 +0100 From: "Hutton, Andrew" To: "Prashanth Patil (praspati)" , "tram@ietf.org" Thread-Topic: turn-server-discovery and return Thread-Index: AQHRYmhren0gOhTwNUCjuK8BThCSAQ== Date: Mon, 8 Feb 2016 12:01:17 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E99B5CF@MCHP04MSX.global-ad.net> References: <20160107000242.2632.86853.idtracker@ietfa.amsl.com> In-Reply-To: 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tram] turn-server-discovery and return 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 12:01:22 -0000 In the latest update of the discovery draft (https://tools.ietf.org/html/dr= aft-ietf-tram-turn-server-discovery-06#section-7.2) the following text was = added. >7.2. Recursively Encapsulated TURN > > A TURN client could attempt to discover multiple TURN servers so as > to use recursively encapsulated TURN, as described in > [I-D.ietf-rtcweb-return], to route traffic through multiple TURN > servers for privacy. I don't think this is correct as the discovery mechanisms described in the = draft will not be used to discover multiple TURN servers. In the -rtcweb-re= turn- case the discovery mechanisms is used to discover the return proxy an= d the application will provide the application specific TURN server.=20 I suggest the following text for this section: "The TURN server discovery may result in the discovery of an enterprise/loc= al TURN server being discovered and therefore in the case where a WebRTC ap= plication also provides a TURN server the use of Recursively Encapsulated T= URN, as described in [I-D.ietf-rtcweb-return]." =20 Regards Andy From nobody Mon Feb 8 08:09:55 2016 Return-Path: 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 B6D811B2E3B for ; Mon, 8 Feb 2016 08:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 DvG-Zh4GwpvR for ; Mon, 8 Feb 2016 08:09:52 -0800 (PST) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23FB41B2DFD for ; Mon, 8 Feb 2016 08:09:52 -0800 (PST) Received: by mail-vk0-x22a.google.com with SMTP id e185so98153793vkb.1 for ; Mon, 08 Feb 2016 08:09:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=webrtc-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=btOm4SrK2ovark8S2sqLdnx5aDgtx+H8ziV+tkzZnqQ=; b=BbLWloGiw8iDfE9GkCIZM4y4Fd4Geo2H393LdWca6/aU+kLZcV4TGu5ROzpzqwquGu m7jOvlSifTBQHeleXe5a2m2hpwSYv14BzmwMhrPFI8fBd9XoZWZc9n7hmemwrONbgPRH ozsobgH0jPPBLwSCKwE83gnODK5Z54nz5zwtJwrhJ4wfuft8tHLFxWoPiVW5G+/FQDYx z9+6aoleBa0z0UHTicANs96NRzYUHVx+uH5xGXlvUa59jf8m2eW89ZTFkKdWvJtdhQVR eQVNpVWR9krgdb7cTrvyxVijszFazuj0l5SshNt1VYPpE2hJbgvIdfOJG7IZSrVQ7CrI /I7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=btOm4SrK2ovark8S2sqLdnx5aDgtx+H8ziV+tkzZnqQ=; b=L5lsUwESRTmdSgI/MAiUxu9NG1PQzgTnLpM+9qJzSe2bD9iUo+hddURUOShV3tP1+o 59BiMEXt2FcGSY3EzZ7n8lkaAkQU2pZL2WHYUpyrV380rcJyS2BYZXtceFYbndcklu0s kIjtoNPOQfIn+iYkAq1tO9cuhrDA9WrYSJSTZckDNuFEoKprEUpWcdaW5L/wgPE30OCU ypO9qiZkm23kQQ+mYz8KGo9nXms195evJr22ng6tGDxC8/B9BF3oHnfJGm+dLmLel41+ tQxhU+Nnx9EU08Rj6Wf79c46+xEHDITqrVS1GoRhzqv4P12NBH//v0zB7Owm84VKOaLa pnZw== X-Gm-Message-State: AG10YOQ1z0S/t2NxI2oMnmB/OonrH4veW/2Krf80wl4/LJq2P52WTASGty4b2qro1fYpmA== X-Received: by 10.31.5.134 with SMTP id 128mr20558362vkf.29.1454947791037; Mon, 08 Feb 2016 08:09:51 -0800 (PST) Received: from mail-vk0-f43.google.com (mail-vk0-f43.google.com. [209.85.213.43]) by smtp.gmail.com with ESMTPSA id c190sm6641720vkc.16.2016.02.08.08.09.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Feb 2016 08:09:49 -0800 (PST) Received: by mail-vk0-f43.google.com with SMTP id e185so98153119vkb.1 for ; Mon, 08 Feb 2016 08:09:49 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.31.44.77 with SMTP id s74mr20572296vks.4.1454947789444; Mon, 08 Feb 2016 08:09:49 -0800 (PST) Received: by 10.31.153.138 with HTTP; Mon, 8 Feb 2016 08:09:49 -0800 (PST) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E99B5CF@MCHP04MSX.global-ad.net> References: <20160107000242.2632.86853.idtracker@ietfa.amsl.com> <9F33F40F6F2CD847824537F3C4E37DDF1E99B5CF@MCHP04MSX.global-ad.net> Date: Mon, 8 Feb 2016 11:09:49 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Benjamin Schwartz To: "Hutton, Andrew" Content-Type: multipart/alternative; boundary=001a11c075a2285fd1052b446e28 Archived-At: Cc: "Prashanth Patil \(praspati\)" , "tram@ietf.org" Subject: Re: [tram] turn-server-discovery and return 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 16:09:53 -0000 --001a11c075a2285fd1052b446e28 Content-Type: text/plain; charset=UTF-8 I think _all_ TURN servers identified by autodiscovery are enterprise/local, by definition. How about "WebRTC endpoints SHOULD treat any TURN server discovered through this process as an enterprise/gateway server, in accordance with Recursively Encapsulated TURN [I-D.ietf-rtcweb-return]." On Mon, Feb 8, 2016 at 7:01 AM, Hutton, Andrew wrote: > In the latest update of the discovery draft ( > https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-06#section-7.2) > the following text was added. > > > >7.2. Recursively Encapsulated TURN > > > > A TURN client could attempt to discover multiple TURN servers so as > > to use recursively encapsulated TURN, as described in > > [I-D.ietf-rtcweb-return], to route traffic through multiple TURN > > servers for privacy. > > > I don't think this is correct as the discovery mechanisms described in the > draft will not be used to discover multiple TURN servers. In the > -rtcweb-return- case the discovery mechanisms is used to discover the > return proxy and the application will provide the application specific TURN > server. > I suggest the following text for this section: > > > "The TURN server discovery may result in the discovery of an > enterprise/local TURN server being discovered and therefore in the case > where a WebRTC application also provides a TURN server the use of > Recursively Encapsulated TURN, as described in [I-D.ietf-rtcweb-return]." > > > Regards > Andy > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --001a11c075a2285fd1052b446e28 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think _all_ TURN servers identified by autodiscovery are= enterprise/local, by definition.

How about
"WebRTC endpoints SHOULD treat any TURN= server discovered through this process as an enterprise/gateway server, in= accordance with Recursively Encapsulated TURN [I-D.ietf-rtcweb-return].&qu= ot;

On Mon, Feb 8, 2016 at 7:01 AM, Hutton,= Andrew <andrew.hutton@unify.com> wrote:
In the latest update of the discovery draft (https://tools.ietf.org/html= /draft-ietf-tram-turn-server-discovery-06#section-7.2) the following te= xt was added.


>7.2.=C2=A0 Recursively Encapsulated TURN
>
>=C2=A0 =C2=A0A TURN client could attempt to discover multiple TURN serv= ers so as
>=C2=A0 =C2=A0to use recursively encapsulated TURN, as described in
>=C2=A0 =C2=A0[I-D.ietf-rtcweb-return], to route traffic through multipl= e TURN
>=C2=A0 =C2=A0servers for privacy.


I don't think this is correct as the discovery mechanisms described in = the draft will not be used to discover multiple TURN servers. In the -rtcwe= b-return- case the discovery mechanisms is used to discover the return prox= y and the application will provide the application specific TURN server. I suggest the following text for this section:


"The TURN server discovery may result in the discovery of an enterpris= e/local TURN server being discovered and therefore in the case where a WebR= TC application also provides a TURN server the use of Recursively Encapsula= ted TURN, as described in [I-D.ietf-rtcweb-return]."


Regards
Andy

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

--001a11c075a2285fd1052b446e28-- From nobody Mon Feb 8 08:32:53 2016 Return-Path: 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 494531B2EA0 for ; Mon, 8 Feb 2016 08:32:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] 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 yZhLTyapvqTt for ; Mon, 8 Feb 2016 08:32:50 -0800 (PST) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 525831B2E6E for ; Mon, 8 Feb 2016 08:32:50 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 8D3FE23F0457; Mon, 8 Feb 2016 17:32:48 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.37.243]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0279.002; Mon, 8 Feb 2016 17:32:48 +0100 From: "Hutton, Andrew" To: Benjamin Schwartz Thread-Topic: [tram] turn-server-discovery and return Thread-Index: AQHRYmhren0gOhTwNUCjuK8BThCSAZ8iQLCAgAAXJJA= Date: Mon, 8 Feb 2016 16:32:47 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E99BE7A@MCHP04MSX.global-ad.net> References: <20160107000242.2632.86853.idtracker@ietfa.amsl.com> <9F33F40F6F2CD847824537F3C4E37DDF1E99B5CF@MCHP04MSX.global-ad.net> In-Reply-To: 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_9F33F40F6F2CD847824537F3C4E37DDF1E99BE7AMCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: Cc: "Prashanth Patil \(praspati\)" , "tram@ietf.org" Subject: Re: [tram] turn-server-discovery and return 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 16:32:52 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF1E99BE7AMCHP04MSXglobal_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V29ya3MgZm9yIG1lLg0KDQpBbmR5DQoNCkZyb206IEJlbmphbWluIFNjaHdhcnR6IFttYWlsdG86 YmVtYXNjQHdlYnJ0Yy5vcmddDQpTZW50OiAwOCBGZWJydWFyeSAyMDE2IDE2OjEwDQpUbzogSHV0 dG9uLCBBbmRyZXcNCkNjOiBQcmFzaGFudGggUGF0aWwgKHByYXNwYXRpKTsgdHJhbUBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFt0cmFtXSB0dXJuLXNlcnZlci1kaXNjb3ZlcnkgYW5kIHJldHVybg0K DQpJIHRoaW5rIF9hbGxfIFRVUk4gc2VydmVycyBpZGVudGlmaWVkIGJ5IGF1dG9kaXNjb3Zlcnkg YXJlIGVudGVycHJpc2UvbG9jYWwsIGJ5IGRlZmluaXRpb24uDQoNCkhvdyBhYm91dA0KIldlYlJU QyBlbmRwb2ludHMgU0hPVUxEIHRyZWF0IGFueSBUVVJOIHNlcnZlciBkaXNjb3ZlcmVkIHRocm91 Z2ggdGhpcyBwcm9jZXNzIGFzIGFuIGVudGVycHJpc2UvZ2F0ZXdheSBzZXJ2ZXIsIGluIGFjY29y ZGFuY2Ugd2l0aCBSZWN1cnNpdmVseSBFbmNhcHN1bGF0ZWQgVFVSTiBbSS1ELmlldGYtcnRjd2Vi LXJldHVybl0uIg0KDQpPbiBNb24sIEZlYiA4LCAyMDE2IGF0IDc6MDEgQU0sIEh1dHRvbiwgQW5k cmV3IDxhbmRyZXcuaHV0dG9uQHVuaWZ5LmNvbTxtYWlsdG86YW5kcmV3Lmh1dHRvbkB1bmlmeS5j b20+PiB3cm90ZToNCkluIHRoZSBsYXRlc3QgdXBkYXRlIG9mIHRoZSBkaXNjb3ZlcnkgZHJhZnQg KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRyYW0tdHVybi1zZXJ2ZXIt ZGlzY292ZXJ5LTA2I3NlY3Rpb24tNy4yKSB0aGUgZm9sbG93aW5nIHRleHQgd2FzIGFkZGVkLg0K DQoNCj43LjIuICBSZWN1cnNpdmVseSBFbmNhcHN1bGF0ZWQgVFVSTg0KPg0KPiAgIEEgVFVSTiBj bGllbnQgY291bGQgYXR0ZW1wdCB0byBkaXNjb3ZlciBtdWx0aXBsZSBUVVJOIHNlcnZlcnMgc28g YXMNCj4gICB0byB1c2UgcmVjdXJzaXZlbHkgZW5jYXBzdWxhdGVkIFRVUk4sIGFzIGRlc2NyaWJl ZCBpbg0KPiAgIFtJLUQuaWV0Zi1ydGN3ZWItcmV0dXJuXSwgdG8gcm91dGUgdHJhZmZpYyB0aHJv dWdoIG11bHRpcGxlIFRVUk4NCj4gICBzZXJ2ZXJzIGZvciBwcml2YWN5Lg0KDQoNCkkgZG9uJ3Qg dGhpbmsgdGhpcyBpcyBjb3JyZWN0IGFzIHRoZSBkaXNjb3ZlcnkgbWVjaGFuaXNtcyBkZXNjcmli ZWQgaW4gdGhlIGRyYWZ0IHdpbGwgbm90IGJlIHVzZWQgdG8gZGlzY292ZXIgbXVsdGlwbGUgVFVS TiBzZXJ2ZXJzLiBJbiB0aGUgLXJ0Y3dlYi1yZXR1cm4tIGNhc2UgdGhlIGRpc2NvdmVyeSBtZWNo YW5pc21zIGlzIHVzZWQgdG8gZGlzY292ZXIgdGhlIHJldHVybiBwcm94eSBhbmQgdGhlIGFwcGxp Y2F0aW9uIHdpbGwgcHJvdmlkZSB0aGUgYXBwbGljYXRpb24gc3BlY2lmaWMgVFVSTiBzZXJ2ZXIu DQpJIHN1Z2dlc3QgdGhlIGZvbGxvd2luZyB0ZXh0IGZvciB0aGlzIHNlY3Rpb246DQoNCg0KIlRo ZSBUVVJOIHNlcnZlciBkaXNjb3ZlcnkgbWF5IHJlc3VsdCBpbiB0aGUgZGlzY292ZXJ5IG9mIGFu IGVudGVycHJpc2UvbG9jYWwgVFVSTiBzZXJ2ZXIgYmVpbmcgZGlzY292ZXJlZCBhbmQgdGhlcmVm b3JlIGluIHRoZSBjYXNlIHdoZXJlIGEgV2ViUlRDIGFwcGxpY2F0aW9uIGFsc28gcHJvdmlkZXMg YSBUVVJOIHNlcnZlciB0aGUgdXNlIG9mIFJlY3Vyc2l2ZWx5IEVuY2Fwc3VsYXRlZCBUVVJOLCBh cyBkZXNjcmliZWQgaW4gW0ktRC5pZXRmLXJ0Y3dlYi1yZXR1cm5dLiINCg0KDQpSZWdhcmRzDQpB bmR5DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp0 cmFtIG1haWxpbmcgbGlzdA0KdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0KDQo= --_000_9F33F40F6F2CD847824537F3C4E37DDF1E99BE7AMCHP04MSXglobal_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V29ya3MgZm9yIG1lLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QW5k eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBCZW5qYW1pbiBT Y2h3YXJ0eiBbbWFpbHRvOmJlbWFzY0B3ZWJydGMub3JnXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDA4 IEZlYnJ1YXJ5IDIwMTYgMTY6MTA8YnI+DQo8Yj5Ubzo8L2I+IEh1dHRvbiwgQW5kcmV3PGJyPg0K PGI+Q2M6PC9iPiBQcmFzaGFudGggUGF0aWwgKHByYXNwYXRpKTsgdHJhbUBpZXRmLm9yZzxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW3RyYW1dIHR1cm4tc2VydmVyLWRpc2NvdmVyeSBhbmQgcmV0 dXJuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgdGhpbmsgX2FsbF8gVFVSTiBzZXJ2ZXJzIGlkZW50aWZpZWQgYnkgYXV0b2Rpc2NvdmVyeSBh cmUgZW50ZXJwcmlzZS9sb2NhbCwgYnkgZGVmaW5pdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvdyBhYm91dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVw dCI+JnF1b3Q7V2ViUlRDIGVuZHBvaW50cyBTSE9VTEQgdHJlYXQgYW55IFRVUk4gc2VydmVyIGRp c2NvdmVyZWQgdGhyb3VnaCB0aGlzIHByb2Nlc3MgYXMgYW4gZW50ZXJwcmlzZS9nYXRld2F5IHNl cnZlciwgaW4gYWNjb3JkYW5jZSB3aXRoIFJlY3Vyc2l2ZWx5IEVuY2Fwc3VsYXRlZCBUVVJOIFtJ LUQuaWV0Zi1ydGN3ZWItcmV0dXJuXS4mcXVvdDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgRmViIDgsIDIwMTYgYXQg NzowMSBBTSwgSHV0dG9uLCBBbmRyZXcgJmx0OzxhIGhyZWY9Im1haWx0bzphbmRyZXcuaHV0dG9u QHVuaWZ5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFuZHJldy5odXR0b25AdW5pZnkuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGUgbGF0 ZXN0IHVwZGF0ZSBvZiB0aGUgZGlzY292ZXJ5IGRyYWZ0ICg8YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXR1cm4tc2VydmVyLWRpc2NvdmVyeS0wNiNz ZWN0aW9uLTcuMiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLXRyYW0tdHVybi1zZXJ2ZXItZGlzY292ZXJ5LTA2I3NlY3Rpb24tNy4yPC9hPikN CiB0aGUgZm9sbG93aW5nIHRleHQgd2FzIGFkZGVkLjxicj4NCjxicj4NCjxicj4NCiZndDs3LjIu Jm5ic3A7IFJlY3Vyc2l2ZWx5IEVuY2Fwc3VsYXRlZCBUVVJOPGJyPg0KJmd0Ozxicj4NCiZndDsm bmJzcDsgJm5ic3A7QSBUVVJOIGNsaWVudCBjb3VsZCBhdHRlbXB0IHRvIGRpc2NvdmVyIG11bHRp cGxlIFRVUk4gc2VydmVycyBzbyBhczxicj4NCiZndDsmbmJzcDsgJm5ic3A7dG8gdXNlIHJlY3Vy c2l2ZWx5IGVuY2Fwc3VsYXRlZCBUVVJOLCBhcyBkZXNjcmliZWQgaW48YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwO1tJLUQuaWV0Zi1ydGN3ZWItcmV0dXJuXSwgdG8gcm91dGUgdHJhZmZpYyB0aHJvdWdo IG11bHRpcGxlIFRVUk48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO3NlcnZlcnMgZm9yIHByaXZhY3ku PGJyPg0KPGJyPg0KPGJyPg0KSSBkb24ndCB0aGluayB0aGlzIGlzIGNvcnJlY3QgYXMgdGhlIGRp c2NvdmVyeSBtZWNoYW5pc21zIGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQgd2lsbCBub3QgYmUgdXNl ZCB0byBkaXNjb3ZlciBtdWx0aXBsZSBUVVJOIHNlcnZlcnMuIEluIHRoZSAtcnRjd2ViLXJldHVy bi0gY2FzZSB0aGUgZGlzY292ZXJ5IG1lY2hhbmlzbXMgaXMgdXNlZCB0byBkaXNjb3ZlciB0aGUg cmV0dXJuIHByb3h5IGFuZCB0aGUgYXBwbGljYXRpb24gd2lsbCBwcm92aWRlIHRoZQ0KIGFwcGxp Y2F0aW9uIHNwZWNpZmljIFRVUk4gc2VydmVyLjxicj4NCkkgc3VnZ2VzdCB0aGUgZm9sbG93aW5n IHRleHQgZm9yIHRoaXMgc2VjdGlvbjo8YnI+DQo8YnI+DQo8YnI+DQomcXVvdDtUaGUgVFVSTiBz ZXJ2ZXIgZGlzY292ZXJ5IG1heSByZXN1bHQgaW4gdGhlIGRpc2NvdmVyeSBvZiBhbiBlbnRlcnBy aXNlL2xvY2FsIFRVUk4gc2VydmVyIGJlaW5nIGRpc2NvdmVyZWQgYW5kIHRoZXJlZm9yZSBpbiB0 aGUgY2FzZSB3aGVyZSBhIFdlYlJUQyBhcHBsaWNhdGlvbiBhbHNvIHByb3ZpZGVzIGEgVFVSTiBz ZXJ2ZXIgdGhlIHVzZSBvZiBSZWN1cnNpdmVseSBFbmNhcHN1bGF0ZWQgVFVSTiwgYXMgZGVzY3Jp YmVkIGluIFtJLUQuaWV0Zi1ydGN3ZWItcmV0dXJuXS4mcXVvdDs8YnI+DQo8YnI+DQo8YnI+DQpS ZWdhcmRzPGJyPg0KQW5keTxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KdHJhbSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86dHJhbUBpZXRmLm9yZyI+dHJhbUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0iIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW08L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9F33F40F6F2CD847824537F3C4E37DDF1E99BE7AMCHP04MSXglobal_-- From nobody Mon Feb 8 08:50:01 2016 Return-Path: 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 64C6A1B2F35 for ; Mon, 8 Feb 2016 08:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 BcowrEeXdBKr for ; Mon, 8 Feb 2016 08:49:58 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A9991B2F2E for ; Mon, 8 Feb 2016 08:49:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12688; q=dns/txt; s=iport; t=1454950198; x=1456159798; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=SF21LA1aMxzVMjVKpbC1kelJVE+c7xy9wZ8YWnFkT0U=; b=gnNDs63yYaz2lu9HIJHKgfzDrX1235QD11e2QV0L1kUjk5ln64stgS3b nP6gTTlVhkQ0Z/5qRThCbOe8IMlweBNX0fFZgskxJEPKPorGDSWoFWJbF MmtjIhvZrV+3yoSSOdEdQNpurvenm2cijBiNW8CsPTDAs8bcLRaMiT/1Z E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgAbxrhW/40NJK1egm5MUm0GiFWxD?= =?us-ascii?q?AENgWYXAQuFagIcgRM4FAEBAQEBAQGBCoRBAQEBBAEBASAKQQsQAgEIEQQBASg?= =?us-ascii?q?DAgICJQsUCQgCBAENBQiIEw6uRo5TAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGE?= =?us-ascii?q?oQ3hBouFwmCSoE6BZJuhAcBhUuHfYFijRiFbohPAR4BAUKDZGoBh1Z8AQEB?= X-IronPort-AV: E=Sophos; i="5.22,417,1449532800"; d="scan'208,217"; a="69105139" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Feb 2016 16:49:57 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u18GnvxB009210 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 Feb 2016 16:49:57 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 8 Feb 2016 10:49:56 -0600 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1104.009; Mon, 8 Feb 2016 10:49:56 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "Hutton, Andrew" , Benjamin Schwartz Thread-Topic: [tram] turn-server-discovery and return Thread-Index: AQHRYmh2YFzwmP/IiU6G35xxS4HZOJ8itgmAgAAGa4D//6AewA== Date: Mon, 8 Feb 2016 16:49:56 +0000 Message-ID: References: <20160107000242.2632.86853.idtracker@ietfa.amsl.com> <9F33F40F6F2CD847824537F3C4E37DDF1E99B5CF@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1E99BE7A@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E99BE7A@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.69.70] Content-Type: multipart/alternative; boundary="_000_dfaa18bf236f43d08ef4b6bb1ca53356XCHRCD017ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Prashanth Patil \(praspati\)" , "tram@ietf.org" Subject: Re: [tram] turn-server-discovery and return 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 16:50:00 -0000 --_000_dfaa18bf236f43d08ef4b6bb1ca53356XCHRCD017ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WXVwLCB3aWxsIHVwZGF0ZSBkcmFmdC4NCg0KLVRpcnUNCg0KRnJvbTogdHJhbSBbbWFpbHRvOnRy YW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEh1dHRvbiwgQW5kcmV3DQpTZW50OiBN b25kYXksIEZlYnJ1YXJ5IDA4LCAyMDE2IDEwOjAzIFBNDQpUbzogQmVuamFtaW4gU2Nod2FydHoN CkNjOiBQcmFzaGFudGggUGF0aWwgKHByYXNwYXRpKTsgdHJhbUBpZXRmLm9yZw0KU3ViamVjdDog UmU6IFt0cmFtXSB0dXJuLXNlcnZlci1kaXNjb3ZlcnkgYW5kIHJldHVybg0KDQpXb3JrcyBmb3Ig bWUuDQoNCkFuZHkNCg0KRnJvbTogQmVuamFtaW4gU2Nod2FydHogW21haWx0bzpiZW1hc2NAd2Vi cnRjLm9yZ10NClNlbnQ6IDA4IEZlYnJ1YXJ5IDIwMTYgMTY6MTANClRvOiBIdXR0b24sIEFuZHJl dw0KQ2M6IFByYXNoYW50aCBQYXRpbCAocHJhc3BhdGkpOyB0cmFtQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW3RyYW1dIHR1cm4tc2VydmVyLWRpc2NvdmVyeSBhbmQgcmV0dXJuDQoNCkkgdGhpbmsg X2FsbF8gVFVSTiBzZXJ2ZXJzIGlkZW50aWZpZWQgYnkgYXV0b2Rpc2NvdmVyeSBhcmUgZW50ZXJw cmlzZS9sb2NhbCwgYnkgZGVmaW5pdGlvbi4NCg0KSG93IGFib3V0DQoiV2ViUlRDIGVuZHBvaW50 cyBTSE9VTEQgdHJlYXQgYW55IFRVUk4gc2VydmVyIGRpc2NvdmVyZWQgdGhyb3VnaCB0aGlzIHBy b2Nlc3MgYXMgYW4gZW50ZXJwcmlzZS9nYXRld2F5IHNlcnZlciwgaW4gYWNjb3JkYW5jZSB3aXRo IFJlY3Vyc2l2ZWx5IEVuY2Fwc3VsYXRlZCBUVVJOIFtJLUQuaWV0Zi1ydGN3ZWItcmV0dXJuXS4i DQoNCk9uIE1vbiwgRmViIDgsIDIwMTYgYXQgNzowMSBBTSwgSHV0dG9uLCBBbmRyZXcgPGFuZHJl dy5odXR0b25AdW5pZnkuY29tPG1haWx0bzphbmRyZXcuaHV0dG9uQHVuaWZ5LmNvbT4+IHdyb3Rl Og0KSW4gdGhlIGxhdGVzdCB1cGRhdGUgb2YgdGhlIGRpc2NvdmVyeSBkcmFmdCAoaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHJhbS10dXJuLXNlcnZlci1kaXNjb3Zlcnkt MDYjc2VjdGlvbi03LjIpIHRoZSBmb2xsb3dpbmcgdGV4dCB3YXMgYWRkZWQuDQoNCg0KPjcuMi4g IFJlY3Vyc2l2ZWx5IEVuY2Fwc3VsYXRlZCBUVVJODQo+DQo+ICAgQSBUVVJOIGNsaWVudCBjb3Vs ZCBhdHRlbXB0IHRvIGRpc2NvdmVyIG11bHRpcGxlIFRVUk4gc2VydmVycyBzbyBhcw0KPiAgIHRv IHVzZSByZWN1cnNpdmVseSBlbmNhcHN1bGF0ZWQgVFVSTiwgYXMgZGVzY3JpYmVkIGluDQo+ICAg W0ktRC5pZXRmLXJ0Y3dlYi1yZXR1cm5dLCB0byByb3V0ZSB0cmFmZmljIHRocm91Z2ggbXVsdGlw bGUgVFVSTg0KPiAgIHNlcnZlcnMgZm9yIHByaXZhY3kuDQoNCg0KSSBkb24ndCB0aGluayB0aGlz IGlzIGNvcnJlY3QgYXMgdGhlIGRpc2NvdmVyeSBtZWNoYW5pc21zIGRlc2NyaWJlZCBpbiB0aGUg ZHJhZnQgd2lsbCBub3QgYmUgdXNlZCB0byBkaXNjb3ZlciBtdWx0aXBsZSBUVVJOIHNlcnZlcnMu IEluIHRoZSAtcnRjd2ViLXJldHVybi0gY2FzZSB0aGUgZGlzY292ZXJ5IG1lY2hhbmlzbXMgaXMg dXNlZCB0byBkaXNjb3ZlciB0aGUgcmV0dXJuIHByb3h5IGFuZCB0aGUgYXBwbGljYXRpb24gd2ls bCBwcm92aWRlIHRoZSBhcHBsaWNhdGlvbiBzcGVjaWZpYyBUVVJOIHNlcnZlci4NCkkgc3VnZ2Vz dCB0aGUgZm9sbG93aW5nIHRleHQgZm9yIHRoaXMgc2VjdGlvbjoNCg0KDQoiVGhlIFRVUk4gc2Vy dmVyIGRpc2NvdmVyeSBtYXkgcmVzdWx0IGluIHRoZSBkaXNjb3Zlcnkgb2YgYW4gZW50ZXJwcmlz ZS9sb2NhbCBUVVJOIHNlcnZlciBiZWluZyBkaXNjb3ZlcmVkIGFuZCB0aGVyZWZvcmUgaW4gdGhl IGNhc2Ugd2hlcmUgYSBXZWJSVEMgYXBwbGljYXRpb24gYWxzbyBwcm92aWRlcyBhIFRVUk4gc2Vy dmVyIHRoZSB1c2Ugb2YgUmVjdXJzaXZlbHkgRW5jYXBzdWxhdGVkIFRVUk4sIGFzIGRlc2NyaWJl ZCBpbiBbSS1ELmlldGYtcnRjd2ViLXJldHVybl0uIg0KDQoNClJlZ2FyZHMNCkFuZHkNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnRyYW0gbWFpbGlu ZyBsaXN0DQp0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQoNCg== --_000_dfaa18bf236f43d08ef4b6bb1ca53356XCHRCD017ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPll1cCwgd2lsbCB1cGRhdGUgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tVGlydTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiB0cmFtIFttYWlsdG86dHJh bS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5IdXR0b24sIEFuZHJldzxi cj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEZlYnJ1YXJ5IDA4LCAyMDE2IDEwOjAzIFBNPGJyPg0K PGI+VG86PC9iPiBCZW5qYW1pbiBTY2h3YXJ0ejxicj4NCjxiPkNjOjwvYj4gUHJhc2hhbnRoIFBh dGlsIChwcmFzcGF0aSk7IHRyYW1AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0 cmFtXSB0dXJuLXNlcnZlci1kaXNjb3ZlcnkgYW5kIHJldHVybjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5Xb3JrcyBmb3IgbWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BbmR5PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEJlbmphbWluIFNjaHdhcnR6IFttYWlsdG86 YmVtYXNjQHdlYnJ0Yy5vcmddDQo8YnI+DQo8Yj5TZW50OjwvYj4gMDggRmVicnVhcnkgMjAxNiAx NjoxMDxicj4NCjxiPlRvOjwvYj4gSHV0dG9uLCBBbmRyZXc8YnI+DQo8Yj5DYzo8L2I+IFByYXNo YW50aCBQYXRpbCAocHJhc3BhdGkpOyB0cmFtQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbdHJhbV0gdHVybi1zZXJ2ZXItZGlzY292ZXJ5IGFuZCByZXR1cm48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayBfYWxsXyBU VVJOIHNlcnZlcnMgaWRlbnRpZmllZCBieSBhdXRvZGlzY292ZXJ5IGFyZSBlbnRlcnByaXNlL2xv Y2FsLCBieSBkZWZpbml0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SG93IGFib3V0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij4mcXVvdDtXZWJSVEMg ZW5kcG9pbnRzIFNIT1VMRCB0cmVhdCBhbnkgVFVSTiBzZXJ2ZXIgZGlzY292ZXJlZCB0aHJvdWdo IHRoaXMgcHJvY2VzcyBhcyBhbiBlbnRlcnByaXNlL2dhdGV3YXkgc2VydmVyLCBpbiBhY2NvcmRh bmNlIHdpdGggUmVjdXJzaXZlbHkgRW5jYXBzdWxhdGVkIFRVUk4gW0ktRC5pZXRmLXJ0Y3dlYi1y ZXR1cm5dLiZxdW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBGZWIgOCwgMjAxNiBhdCA3OjAxIEFNLCBIdXR0b24s IEFuZHJldyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFuZHJldy5odXR0b25AdW5pZnkuY29tIiB0YXJn ZXQ9Il9ibGFuayI+YW5kcmV3Lmh1dHRvbkB1bmlmeS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHRoZSBsYXRlc3QgdXBkYXRlIG9mIHRo ZSBkaXNjb3ZlcnkgZHJhZnQgKDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLXRyYW0tdHVybi1zZXJ2ZXItZGlzY292ZXJ5LTA2I3NlY3Rpb24tNy4yIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHJhbS10 dXJuLXNlcnZlci1kaXNjb3ZlcnktMDYjc2VjdGlvbi03LjI8L2E+KQ0KIHRoZSBmb2xsb3dpbmcg dGV4dCB3YXMgYWRkZWQuPGJyPg0KPGJyPg0KPGJyPg0KJmd0OzcuMi4mbmJzcDsgUmVjdXJzaXZl bHkgRW5jYXBzdWxhdGVkIFRVUk48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtBIFRV Uk4gY2xpZW50IGNvdWxkIGF0dGVtcHQgdG8gZGlzY292ZXIgbXVsdGlwbGUgVFVSTiBzZXJ2ZXJz IHNvIGFzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDt0byB1c2UgcmVjdXJzaXZlbHkgZW5jYXBzdWxh dGVkIFRVUk4sIGFzIGRlc2NyaWJlZCBpbjxicj4NCiZndDsmbmJzcDsgJm5ic3A7W0ktRC5pZXRm LXJ0Y3dlYi1yZXR1cm5dLCB0byByb3V0ZSB0cmFmZmljIHRocm91Z2ggbXVsdGlwbGUgVFVSTjxi cj4NCiZndDsmbmJzcDsgJm5ic3A7c2VydmVycyBmb3IgcHJpdmFjeS48YnI+DQo8YnI+DQo8YnI+ DQpJIGRvbid0IHRoaW5rIHRoaXMgaXMgY29ycmVjdCBhcyB0aGUgZGlzY292ZXJ5IG1lY2hhbmlz bXMgZGVzY3JpYmVkIGluIHRoZSBkcmFmdCB3aWxsIG5vdCBiZSB1c2VkIHRvIGRpc2NvdmVyIG11 bHRpcGxlIFRVUk4gc2VydmVycy4gSW4gdGhlIC1ydGN3ZWItcmV0dXJuLSBjYXNlIHRoZSBkaXNj b3ZlcnkgbWVjaGFuaXNtcyBpcyB1c2VkIHRvIGRpc2NvdmVyIHRoZSByZXR1cm4gcHJveHkgYW5k IHRoZSBhcHBsaWNhdGlvbiB3aWxsIHByb3ZpZGUgdGhlDQogYXBwbGljYXRpb24gc3BlY2lmaWMg VFVSTiBzZXJ2ZXIuPGJyPg0KSSBzdWdnZXN0IHRoZSBmb2xsb3dpbmcgdGV4dCBmb3IgdGhpcyBz ZWN0aW9uOjxicj4NCjxicj4NCjxicj4NCiZxdW90O1RoZSBUVVJOIHNlcnZlciBkaXNjb3Zlcnkg bWF5IHJlc3VsdCBpbiB0aGUgZGlzY292ZXJ5IG9mIGFuIGVudGVycHJpc2UvbG9jYWwgVFVSTiBz ZXJ2ZXIgYmVpbmcgZGlzY292ZXJlZCBhbmQgdGhlcmVmb3JlIGluIHRoZSBjYXNlIHdoZXJlIGEg V2ViUlRDIGFwcGxpY2F0aW9uIGFsc28gcHJvdmlkZXMgYSBUVVJOIHNlcnZlciB0aGUgdXNlIG9m IFJlY3Vyc2l2ZWx5IEVuY2Fwc3VsYXRlZCBUVVJOLCBhcyBkZXNjcmliZWQgaW4gW0ktRC5pZXRm LXJ0Y3dlYi1yZXR1cm5dLiZxdW90Ozxicj4NCjxicj4NCjxicj4NClJlZ2FyZHM8YnI+DQpBbmR5 PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQp0cmFtIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYu b3JnIj50cmFtQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdHJhbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdHJhbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_dfaa18bf236f43d08ef4b6bb1ca53356XCHRCD017ciscocom_-- From nobody Wed Feb 10 01:34:59 2016 Return-Path: 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 5401D1A03ED for ; Wed, 10 Feb 2016 01:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.102 X-Spam-Level: * X-Spam-Status: No, score=1.102 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_FAIL=0.001] autolearn=no 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 IY9rpFGF_Sx9 for ; Wed, 10 Feb 2016 01:34:54 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3045C1A0404 for ; Wed, 10 Feb 2016 01:34:52 -0800 (PST) Received: from Kallei7 ([90.227.80.227]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201602101034491295; Wed, 10 Feb 2016 10:34:49 +0100 From: "Karl Stahl" To: "'Tirumaleswar Reddy \(tireddy\)'" , "'Hutton, Andrew'" , "'Benjamin Schwartz'" References: <20160107000242.2632.86853.idtracker@ietfa.amsl.com> <9F33F40F6F2CD847824537F3C4E37DDF1E99B5CF@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1E99BE7A@MCHP04MSX.global-ad.net> In-Reply-To: Date: Wed, 10 Feb 2016 10:34:46 +0100 Message-ID: <0a1d01d163e6$47c31450$d7493cf0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A1E_01D163EE.A9877C50" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHRYmh2YFzwmP/IiU6G35xxS4HZOJ8itgmAgAAGa4D//6AewIAB7wkQ Content-Language: sv Archived-At: Cc: "'Prashanth Patil \(praspati\)'" , tram@ietf.org Subject: Re: [tram] turn-server-discovery and return 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 09:34:58 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0A1E_01D163EE.A9877C50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am also positive to the update below. =20 Further,=20 6. Discovery using Anycast needs improvement.=20 It has two flaws that easily can be remedied:=20 =20 Current method :=20 =E2=80=9CWhen a client requires TURN services, it sends a TURN allocate = request to the assigned anycast address. The TURN anycast server = responds with a 300 (Try Alternate) error as described in [RFC5766]; = The response contains the TURN unicast address in the ALTERNATE-SERVER = attribute. For subsequent communication with the TURN server, the = client uses the responding server's unicast address.=E2=80=9D =20 Flaw 1: Turn servers do not respond differently (Try alternate or OK) = dependent on how they are addressed (by an anycast address or by a = unicast address), do they? =20 Flaw 2: As already pointed out under 9. Security Considerations, 9.3. = Anycast =E2=80=9CIn a network without any TURN server that is aware of the TURN = anycast address, outgoing TURN requests could leak out onto the external = Internet, possibly revealing information. (I would also add that a far = away bad TURN server might be used)... Sensitive clients that do not = wish to leak information about their presence can set an IP TTL on their = TURN requests that limits how far they can travel into the public = Internet.=E2=80=9D It would be better, not to have to rely on the TTL limitation. =20 Considering that a TURN server also includes a STUN server (when using = the binding request) and that the STUN server also can respond with 300 = Try alternate, I suggest the following modified method: =E2=80=9CWhen a client requires TURN services, it sends a STUN binding = request to the assigned anycast address. The STUN server responds with = a 300 (Try Alternate) error as described in [RFC5389]; The response = contains a unicast address in the ALTERNATE-SERVER attribute, which the = client compares with the source address of the response and if the = addresses are the same, it is an indication to use the TURN server at = that address. For subsequent communication with the TURN server, the = client uses that responding server's unicast address.=E2=80=9D =20 Or simply, a STUN server pointing out it=E2=80=99s own IP address as the = alternate server, means that server it is a network provided TURN server = that should be used. =20 Flaw 1 does not occur. =20 Flaw 2 is completely avoided if the client only tries this method when = the enterprise/ISP enforces a sealed configuration (according to = [I-D.ietf-rtcweb-return]) by stopping STUN packets in the = router/firewall/default gateway by detecting the STUN cookie. =20 In [I-D.ietf-rtcweb-return], the WebRTC endpoint could then maintain its = default leaky behavior, but be signaled by the local TURN server = deployment (stopping STUN packets) to behave sealed, and only in such = case try the (modified) anycast method for TURN discovery. Thus, TURN = requests will never leak out of the local network. =20 We have verified that common rule based firewalls (at least Linux = netfilter/IPtables based) can be configured to route the anycast STUN = packet, while still stopping other packets containing the STUN cookie.=20 =20 Considering that the anycast method works on all network types, and it = allows the TURN server network deployment to automatically signal sealed = behavior to a leaky WebRTC endpoint (by stopping STUN packets), this = should be the preferred discovery method for WebRTC endpoints. A web = application that wish to bypass usage of the network provided TURN = server, can propose a DTLS-encrypted STUN address (which will not be = stopped since the STUN cookie will not be detected). =20 /Karl =20 =20 =20 Fr=C3=A5n: tram [ = mailto:tram-bounces@ietf.org] F=C3=B6r Tirumaleswar Reddy (tireddy) Skickat: den 8 februari 2016 17:50 Till: Hutton, Andrew; Benjamin Schwartz Kopia: Prashanth Patil (praspati); tram@ietf.org =C3=84mne: Re: [tram] turn-server-discovery and return =20 Yup, will update draft. =20 -Tiru =20 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Hutton, Andrew Sent: Monday, February 08, 2016 10:03 PM To: Benjamin Schwartz Cc: Prashanth Patil (praspati); tram@ietf.org Subject: Re: [tram] turn-server-discovery and return =20 Works for me. =20 Andy =20 From: Benjamin Schwartz [mailto:bemasc@webrtc.org]=20 Sent: 08 February 2016 16:10 To: Hutton, Andrew Cc: Prashanth Patil (praspati); tram@ietf.org Subject: Re: [tram] turn-server-discovery and return =20 I think _all_ TURN servers identified by autodiscovery are = enterprise/local, by definition. =20 How about "WebRTC endpoints SHOULD treat any TURN server discovered through this = process as an enterprise/gateway server, in accordance with Recursively = Encapsulated TURN [I-D.ietf-rtcweb-return]." =20 On Mon, Feb 8, 2016 at 7:01 AM, Hutton, Andrew = wrote: In the latest update of the discovery draft = (https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-06#sec= tion-7.2) the following text was added. >7.2. Recursively Encapsulated TURN > > A TURN client could attempt to discover multiple TURN servers so as > to use recursively encapsulated TURN, as described in > [I-D.ietf-rtcweb-return], to route traffic through multiple TURN > servers for privacy. I don't think this is correct as the discovery mechanisms described in = the draft will not be used to discover multiple TURN servers. In the = -rtcweb-return- case the discovery mechanisms is used to discover the = return proxy and the application will provide the application specific = TURN server. I suggest the following text for this section: "The TURN server discovery may result in the discovery of an = enterprise/local TURN server being discovered and therefore in the case = where a WebRTC application also provides a TURN server the use of = Recursively Encapsulated TURN, as described in = [I-D.ietf-rtcweb-return]." Regards Andy _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 ------=_NextPart_000_0A1E_01D163EE.A9877C50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I = am also positive to the update below.

 

Fu= rther,

6.=C2=A0 Discovery using Anycast = ne= eds improvement.

It= has two flaws that easily can be remedied:

 

Cu= rrent method :

=E2=80=9CWhen a client requires TURN services, it = sends a TURN allocate request to the assigned anycast address.=C2=A0 The = TURN anycast server responds with a 300 (Try Alternate) error as = described in [RFC5766];=C2=A0 The response contains the TURN unicast = address in the ALTERNATE-SERVER attribute.=C2=A0 For subsequent = communication with the TURN server, the client uses the responding = server's unicast address.=E2=80=9D

 

Fl= aw 1: Turn servers do not respond differently (Try alternate or OK) = dependent on how they are addressed (by an anycast address or by a = unicast address), do they?

 

Fl= aw 2: As already pointed out under=C2=A0 9.=C2=A0 Security Considerations, = 9.3.=C2=A0 Anycast

=E2= =80=9CIn a = network without any TURN server that is aware of the TURN anycast = address, outgoing TURN requests could leak out onto the external = Internet, possibly revealing information. (I = would also add that a far away bad TURN server might be = used)... = Sensitive clients that do not wish to leak information about their = presence can set an IP TTL on their TURN requests that limits how far = they can travel into the public = Internet.=E2=80=9D

It= would be better, not to have to rely on the TTL = limitation.

 

Co= nsidering that a TURN server also includes a STUN server (when using the = binding request) and that the STUN server also can respond with 300 Try = alternate, I suggest the following modified = method:

=E2=80=9CWhen a client requires TURN services, it = sends a STUN binding request to the assigned anycast address.=C2=A0 The = STUN server responds with a 300 (Try Alternate) error as described in = [RFC5389];=C2=A0 The response contains a unicast address in the = ALTERNATE-SERVER attribute, which the client compares with the source = address of the response and if the addresses are the same, it is an = indication to use the TURN server at that address. For subsequent = communication with the TURN server, the client uses that responding = server's unicast address.=E2=80=9D

 

Or= simply, a STUN server pointing out it=E2=80=99s own IP address as the = alternate server, means that server it is a network provided TURN server = that should be used.

 

Fl= aw 1 does not occur.

 

Fl= aw 2 is completely avoided if=C2=A0 the client only tries this method = when the enterprise/ISP enforces a sealed configuration (according to = [I-D.ietf-rtcweb-return]) = by stopping STUN packets in the router/firewall/default gateway by = detecting the STUN cookie.

 

In= [I-D.ietf-rtcweb-return], = the WebRTC endpoint could then maintain its default leaky behavior, but = be signaled by the local TURN server deployment (stopping STUN packets) = to behave sealed, and only in such case try the (modified) anycast = method for TURN discovery. Thus, TURN requests will never leak out of = the local network.

 

We= have verified that common rule based firewalls (at least Linux = netfilter/IPtables based) can be configured to route the anycast STUN = packet, while still stopping other packets containing the STUN cookie. =

 

Co= nsidering that the anycast method works on all network types, and it = allows the TURN server network deployment to automatically signal sealed = behavior to a leaky WebRTC endpoint (by stopping STUN packets),=C2=A0 = this should be the preferred discovery method for WebRTC endpoints. A = web application that wish to bypass usage of the network provided TURN = server, can propose a DTLS-encrypted STUN address (which will not be = stopped since the STUN cookie will not be = detected).

 

/K= arl

 

 

 

Fr=C3=A5n: tram = [mailto:tram-bounces@ietf.org] = F=C3=B6r Tirumaleswar Reddy (tireddy)
Skickat: den 8 = februari 2016 17:50
Till: Hutton, Andrew; Benjamin = Schwartz
Kopia: Prashanth Patil (praspati); tram@ietf.org
=C3=84mne: Re: = [tram] turn-server-discovery and = return

 

Yup, will update draft.

 

-Tiru

 

From:= tram [mailto:tram-bounces@ietf.org] = On Behalf Of Hutton, Andrew
Sent: Monday, February 08, = 2016 10:03 PM
To: Benjamin Schwartz
Cc: Prashanth = Patil (praspati); tram@ietf.org
Subject: Re: = [tram] turn-server-discovery and = return

 

Works for me.

 

Andy

 

From:= Benjamin = Schwartz [mailto:bemasc@webrtc.org] =
Sent: 08 February 2016 16:10
To: Hutton, = Andrew
Cc: Prashanth Patil (praspati); tram@ietf.org
Subject: Re: = [tram] turn-server-discovery and = return

 

I think _all_ TURN servers identified by autodiscovery are = enterprise/local, by definition.

 

How = about

"WebRTC endpoints SHOULD = treat any TURN server discovered through this process as an = enterprise/gateway server, in accordance with Recursively Encapsulated = TURN [I-D.ietf-rtcweb-return]."

 

On Mon, Feb 8, 2016 at 7:01 AM, = Hutton, Andrew <andrew.hutton@unify.com> = wrote:

In = the latest update of the discovery draft (https://tools.ietf.org/html/draft-ietf-tram-turn-server= -discovery-06#section-7.2) the following text was = added.


>7.2.  Recursively Encapsulated = TURN
>
>   A TURN client could attempt to discover = multiple TURN servers so as
>   to use recursively = encapsulated TURN, as described in
>  =  [I-D.ietf-rtcweb-return], to route traffic through multiple = TURN
>   servers for privacy.


I don't think = this is correct as the discovery mechanisms described in the draft will = not be used to discover multiple TURN servers. In the -rtcweb-return- = case the discovery mechanisms is used to discover the return proxy and = the application will provide the application specific TURN server.
I = suggest the following text for this section:


"The TURN = server discovery may result in the discovery of an enterprise/local TURN = server being discovered and therefore in the case where a WebRTC = application also provides a TURN server the use of Recursively = Encapsulated TURN, as described in = [I-D.ietf-rtcweb-return]."


Regards
Andy

_______= ________________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

 

<= /html> ------=_NextPart_000_0A1E_01D163EE.A9877C50-- From nobody Wed Feb 10 08:44:14 2016 Return-Path: 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 9AF161ACE9D for ; Wed, 10 Feb 2016 08:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 yBiefX_wFm8b for ; Wed, 10 Feb 2016 08:44:07 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 21E3E1A92BD for ; Wed, 10 Feb 2016 08:44:06 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 256BF3F4020; Wed, 10 Feb 2016 16:44:06 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id D876C3F4008; Wed, 10 Feb 2016 16:44:05 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1455122645; bh=jiWboBbA1GtCGOVbagtpWCWAhCJsGhbUpCmbq/yxHKY=; l=8513; h=To:References:Cc:From:Date:In-Reply-To:From; b=gvqAEUoC91CJojrJMMO73ZcCsJppmmvrV4puN4pCHt+AioOwe+PMMviXQgHh7WL1y MhxNRt3p2Hebxq4jCVexcuCAvkiZHKMO+/SAgjhyQYyiY4ecFER/I1VyuZZBExL5BC yFcSDgh9YQz1pF+OW9SuEj43FbQmwD+qUXeA/g14= Received: from [172.28.113.49] (bowill.kendall.corp.akamai.com [172.28.113.49]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id B3C8D203F; Wed, 10 Feb 2016 16:43:53 +0000 (GMT) To: Karl Stahl , "'Tirumaleswar Reddy (tireddy)'" , "'Hutton, Andrew'" , 'Benjamin Schwartz' References: <20160107000242.2632.86853.idtracker@ietfa.amsl.com> <9F33F40F6F2CD847824537F3C4E37DDF1E99B5CF@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1E99BE7A@MCHP04MSX.global-ad.net> <0a1d01d163e6$47c31450$d7493cf0$@stahl@intertex.se> From: Brandon Williams Message-ID: <56BB68C9.2030202@akamai.com> Date: Wed, 10 Feb 2016 11:43:53 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <0a1d01d163e6$47c31450$d7493cf0$@stahl@intertex.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "'Prashanth Patil \(praspati\)'" , tram@ietf.org Subject: Re: [tram] turn-server-discovery and return 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 16:44:13 -0000 Hi Karl, I don't think I agree with your "Flaw 1" and the associated proposed change. Maybe I'm just not understanding your point. There is no reason why a TURN server can't check the destination address for the connection/packet when it arrives and take different action based on that. Also, most STUN binding messages will be unauthenticated, so an on-path attacker could easily redirect the client to an untrusted relay. On the other hand, using the TURN allocation for redirect purposes allows the TURN server to send the Try Alternate error in an authenticated response. I think it's better for the client to establish trust before being redirected, and requiring the client/server to use auth for STUN binding requests would be a bigger change than requiring a TURN server with anycast to check the destination address. Regarding your "flaw 2", I agree that that TTL should not be relied on as a security mechanism. There is no reasonable way for the client to determine an acceptable TTL to use for its current environment. That said, I also don't think it's reasonable to expect the client to know that the ISP has a sealed network configuration or to trust that the ISP has correctly implemented its sealed config. I also don't think it can trust the relay to tell it if the relay itself isn't already trusted, in which case the concern doesn't apply anyway. --Brandon On 02/10/2016 04:34 AM, Karl Stahl wrote: > I am also positive to the update below. > > Further, > > 6. Discovery using Anycast needs improvement. > > It has two flaws that easily can be remedied: > > Current method : > > “When a client requires TURN services, it sends a TURN allocate request > to the assigned anycast address. The TURN anycast server responds with > a 300 (Try Alternate) error as described in [RFC5766]; The response > contains the TURN unicast address in the ALTERNATE-SERVER attribute. > For subsequent communication with the TURN server, the client uses the > responding server's unicast address.” > > Flaw 1: Turn servers do not respond differently (Try alternate or OK) > dependent on how they are addressed (by an anycast address or by a > unicast address), do they? > > Flaw 2: As already pointed out under 9. Security Considerations, 9.3. > Anycast > > “In a network without any TURN server that is aware of the TURN anycast > address, outgoing TURN requests could leak out onto the external > Internet, possibly revealing information. (I would also add that a far > away bad TURN server might be used)... Sensitive clients that do not > wish to leak information about their presence can set an IP TTL on their > TURN requests that limits how far they can travel into the public Internet.” > > It would be better, not to have to rely on the TTL limitation. > > Considering that a TURN server also includes a STUN server (when using > the binding request) and that the STUN server also can respond with 300 > Try alternate, I suggest the following modified method: > > “When a client requires TURN services, it sends a STUN binding request > to the assigned anycast address. The STUN server responds with a 300 > (Try Alternate) error as described in [RFC5389]; The response contains > a unicast address in the ALTERNATE-SERVER attribute, which the client > compares with the source address of the response and if the addresses > are the same, it is an indication to use the TURN server at that > address. For subsequent communication with the TURN server, the client > uses that responding server's unicast address.” > > Or simply, a STUN server pointing out it’s own IP address as the > alternate server, means that server it is a network provided TURN server > that should be used. > > Flaw 1 does not occur. > > Flaw 2 is completely avoided if the client only tries this method when > the enterprise/ISP enforces a sealed configuration (according to > [I-D.ietf-rtcweb-return]) by stopping STUN packets in the > router/firewall/default gateway by detecting the STUN cookie. > > In [I-D.ietf-rtcweb-return], the WebRTC endpoint could then maintain its > default leaky behavior, but be signaled by the local TURN server > deployment (stopping STUN packets) to behave sealed, and only in such > case try the (modified) anycast method for TURN discovery. Thus, TURN > requests will never leak out of the local network. > > We have verified that common rule based firewalls (at least Linux > netfilter/IPtables based) can be configured to route the anycast STUN > packet, while still stopping other packets containing the STUN cookie. > > Considering that the anycast method works on all network types, and it > allows the TURN server network deployment to automatically signal sealed > behavior to a leaky WebRTC endpoint (by stopping STUN packets), this > should be the preferred discovery method for WebRTC endpoints. A web > application that wish to bypass usage of the network provided TURN > server, can propose a DTLS-encrypted STUN address (which will not be > stopped since the STUN cookie will not be detected). > > /Karl > > *Från:*tram [mailto:tram-bounces@ietf.org] *För *Tirumaleswar Reddy > (tireddy) > *Skickat:* den 8 februari 2016 17:50 > *Till:* Hutton, Andrew; Benjamin Schwartz > *Kopia:* Prashanth Patil (praspati); tram@ietf.org > *Ämne:* Re: [tram] turn-server-discovery and return > > Yup, will update draft. > > -Tiru > > *From:*tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Hutton, Andrew > *Sent:* Monday, February 08, 2016 10:03 PM > *To:* Benjamin Schwartz > *Cc:* Prashanth Patil (praspati); tram@ietf.org > *Subject:* Re: [tram] turn-server-discovery and return > > Works for me. > > Andy > > *From:*Benjamin Schwartz [mailto:bemasc@webrtc.org] > *Sent:* 08 February 2016 16:10 > *To:* Hutton, Andrew > *Cc:* Prashanth Patil (praspati); tram@ietf.org > *Subject:* Re: [tram] turn-server-discovery and return > > I think _all_ TURN servers identified by autodiscovery are > enterprise/local, by definition. > > How about > > "WebRTC endpoints SHOULD treat any TURN server discovered through this > process as an enterprise/gateway server, in accordance with Recursively > Encapsulated TURN [I-D.ietf-rtcweb-return]." > > On Mon, Feb 8, 2016 at 7:01 AM, Hutton, Andrew > wrote: > > In the latest update of the discovery draft > (https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-06#section-7.2 > ) > the following text was added. > > >>7.2. Recursively Encapsulated TURN >> >> A TURN client could attempt to discover multiple TURN servers so as >> to use recursively encapsulated TURN, as described in >> [I-D.ietf-rtcweb-return], to route traffic through multiple TURN >> servers for privacy. > > > I don't think this is correct as the discovery mechanisms described in > the draft will not be used to discover multiple TURN servers. In the > -rtcweb-return- case the discovery mechanisms is used to discover the > return proxy and the application will provide the application specific > TURN server. > I suggest the following text for this section: > > > "The TURN server discovery may result in the discovery of an > enterprise/local TURN server being discovered and therefore in the case > where a WebRTC application also provides a TURN server the use of > Recursively Encapsulated TURN, as described in [I-D.ietf-rtcweb-return]." > > > Regards > Andy > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > From nobody Thu Feb 11 04:53:01 2016 Return-Path: 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 3135A1B2B91 for ; Thu, 11 Feb 2016 04:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_FAIL=0.001] autolearn=no 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 gS_q3xVMlCwO for ; Thu, 11 Feb 2016 04:52:49 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D1E11B2BB8 for ; Thu, 11 Feb 2016 04:52:47 -0800 (PST) Received: from Kallei7 ([90.227.80.227]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201602111352459440; Thu, 11 Feb 2016 13:52:45 +0100 From: "Karl Stahl" To: "'Brandon Williams'" , "'Tirumaleswar Reddy \(tireddy\)'" , "'Hutton, Andrew'" , "'Benjamin Schwartz'" References: <20160107000242.2632.86853.idtracker@ietfa.amsl.com> <9F33F40F6F2CD847824537F3C4E37DDF1E99B5CF@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1E99BE7A@MCHP04MSX.global-ad.net> <0a1d01d163e6$47c31450$d7493cf0$@stahl@intertex.se> <56BB68C9.2030202@akamai.com> In-Reply-To: Date: Thu, 11 Feb 2016 13:52:43 +0100 Message-ID: <009601d164cb$19841400$4c8c3c00$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0097_01D164D3.7B487C00" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AdFkIkM6iQvig1eyTqq8j2keS+VWTQAksyVwAAVSjeA= Content-Language: sv Archived-At: Cc: "'Prashanth Patil \(praspati\)'" , tram@ietf.org Subject: Re: [tram] turn-server-discovery and return 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 12:53:00 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0097_01D164D3.7B487C00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Brandon, =20 You are bringing up a use case of a =93better authenticated TURN server=20 network=94 that we may hope is possible to implement in addition to=20 what we first of all need achieve =93being able to use good WebRTC=20 everywhere we can surf=94 (which I thought was the purpose of this=20 DISCOVERY draft and of the RETURN draft).=20 =20 If your use case also needs auto discovery, can=92t it use the same,=20 most optimal discovery method for the TURN server, and thereafter=20 do whatever authentication method(s) you want and need?=20 I actually think it can. =20 Short questions (after you read the inline below): Does my suggested=20 modified anycast method in any way disturb the use case you have in = mind? =20 Aren=92t removal of =93Flaw 1=94 (or whatever we chose to call it) and = Flaw 2,=20 also positive to your use case? =20 Or at least, it does not make things worse for you, does it? (If it does make things worse, I believe both anycast methods could live = in parallel and use the same IANA TURN server discovery address.=20 In the end =96 both anycast methods only address the network provided = TURN=20 server with its unicast address and the 300 Try Alternate could come=20 both from the binding and allocate request.) Would it really help to keep both methods (for your use case and the=20 general use case)?=20 =20 I hope we can focus and get this draft approved with at least one=20 reasonably useful and widely and easily deployable and safe/secure = enough=20 DISCOVERY method. And it would be helpful if we now also can get that=20 IANA allocated TURN server anycast address, so we can use/try the simple = anycast method IRL. =20 /Karl=20 =20 =20 -----Ursprungligt meddelande----- Fr=E5n: Brandon Williams [mailto:brandon.williams@akamai.com]=20 Skickat: den 10 februari 2016 17:44 Till: Karl Stahl; 'Tirumaleswar Reddy (tireddy)'; 'Hutton, Andrew'; 'Benjamin Schwartz' Kopia: 'Prashanth Patil (praspati)'; tram@ietf.org =C4mne: Re: [tram] turn-server-discovery and return =20 Hi Karl, =20 I don't think I agree with your "Flaw 1" and the associated proposed=20 change. Maybe I'm just not understanding your point. =20 There is no reason why a TURN server can't check the destination address = for the connection/packet when it arrives and take different action=20 based on that.=20 --- Of course such behavior can be specified and implemented, but = isn=92t=20 it better if we don=92t have to take such efforts? =20 Also, most STUN binding messages will be unauthenticated,=20 so an on-path attacker could easily redirect the client to an untrusted=20 relay. On the other hand, using the TURN allocation for redirect=20 purposes allows the TURN server to send the Try Alternate error in an=20 authenticated response.=20 --- But there is nothing stopping =93to send the Try Alternate error in = an=20 Authenticated=94 binding response, is there?=20 =20 to establish=20 trust before being redirected, and requiring the client/server to use=20 auth for STUN binding requests would be a bigger change than requiring a = TURN server with anycast to check the destination address. --- isn=92t that already in the standards (binding is not excluded from=20 auth is it)? =20 Regarding your "flaw 2", I agree that that TTL should not be relied on=20 as a security mechanism. There is no reasonable way for the client to=20 determine an acceptable TTL to use for its current environment. That=20 said, I also don't think it's reasonable to expect the client to know=20 that the ISP has a sealed network configuration=20 --- The big advantage with the suggested usage is, that while a=20 WebRTC browser by default assumes a leaky configuration (see the=20 RETURN draft), the suggested deployment by blocking STUN packets=20 through the default gateway, signals to the browser: =93Please look=20 for a network provided TURN server paralleling the firewall here=94=20 (In this way we get a good way for the network provider to enforce sealed usage here instead of leaky AND the huge benefit that local=20 call media does not have to go twice around in the TURN server, which=20 otherwise will happen if a sealed configuration is enforced generally=20 from the WebRTC browser side. See the RETURN draft.)=20 =20 or to trust that the ISP=20 has correctly implemented its sealed config. I also don't think it can=20 trust the relay to tell it if the relay itself isn't already trusted, in = which case the concern doesn't apply anyway. --- We have to start with that we have a certain trust level from the=20 network provider we choose to use =96 the same for both data and=20 real-time traffic, good or bad. Thereafter, you can add your = authentication stuff=20 for your =93better TURN server network=94 for your use case =96 I = don=92t see that the modified anycast method do other than positive things also=20 for your use case. (And we need the improvements for the general WebRTC browser use case =96 where your type of authentication will not=20 be used.)=20 =20 --Brandon =20 On 02/10/2016 04:34 AM, Karl Stahl wrote: > I am also positive to the update below. >=20 > Further, >=20 > 6. Discovery using Anycast needs improvement. >=20 > It has two flaws that easily can be remedied: >=20 > Current method : >=20 > =93When a client requires TURN services, it sends a TURN allocate = request > to the assigned anycast address. The TURN anycast server responds = with > a 300 (Try Alternate) error as described in [RFC5766]; The response > contains the TURN unicast address in the ALTERNATE-SERVER attribute. > For subsequent communication with the TURN server, the client uses the > responding server's unicast address.=94 >=20 > Flaw 1: Turn servers do not respond differently (Try alternate or OK) > dependent on how they are addressed (by an anycast address or by a > unicast address), do they? >=20 > Flaw 2: As already pointed out under 9. Security Considerations, 9.3. > Anycast >=20 > =93In a network without any TURN server that is aware of the TURN = anycast > address, outgoing TURN requests could leak out onto the external > Internet, possibly revealing information. (I would also add that a far > away bad TURN server might be used)... Sensitive clients that do not > wish to leak information about their presence can set an IP TTL on = their > TURN requests that limits how far they can travel into the public Internet.=94 >=20 > It would be better, not to have to rely on the TTL limitation. >=20 > Considering that a TURN server also includes a STUN server (when using > the binding request) and that the STUN server also can respond with = 300 > Try alternate, I suggest the following modified method: >=20 > =93When a client requires TURN services, it sends a STUN binding = request > to the assigned anycast address. The STUN server responds with a 300 > (Try Alternate) error as described in [RFC5389]; The response = contains > a unicast address in the ALTERNATE-SERVER attribute, which the client > compares with the source address of the response and if the addresses > are the same, it is an indication to use the TURN server at that > address. For subsequent communication with the TURN server, the client > uses that responding server's unicast address.=94 >=20 > Or simply, a STUN server pointing out it=92s own IP address as the > alternate server, means that server it is a network provided TURN = server > that should be used. >=20 > Flaw 1 does not occur. >=20 > Flaw 2 is completely avoided if the client only tries this method = when > the enterprise/ISP enforces a sealed configuration (according to > [I-D.ietf-rtcweb-return]) by stopping STUN packets in the > router/firewall/default gateway by detecting the STUN cookie. >=20 > In [I-D.ietf-rtcweb-return], the WebRTC endpoint could then maintain = its > default leaky behavior, but be signaled by the local TURN server > deployment (stopping STUN packets) to behave sealed, and only in such > case try the (modified) anycast method for TURN discovery. Thus, TURN > requests will never leak out of the local network. >=20 > We have verified that common rule based firewalls (at least Linux > netfilter/IPtables based) can be configured to route the anycast STUN > packet, while still stopping other packets containing the STUN cookie. >=20 > Considering that the anycast method works on all network types, and it > allows the TURN server network deployment to automatically signal = sealed > behavior to a leaky WebRTC endpoint (by stopping STUN packets), this > should be the preferred discovery method for WebRTC endpoints. A web > application that wish to bypass usage of the network provided TURN > server, can propose a DTLS-encrypted STUN address (which will not be > stopped since the STUN cookie will not be detected). >=20 > /Karl >=20 > *Fr=E5n:*tram [ = mailto:tram-bounces@ietf.org] *F=F6r *Tirumaleswar Reddy > (tireddy) > *Skickat:* den 8 februari 2016 17:50 > *Till:* Hutton, Andrew; Benjamin Schwartz > *Kopia:* Prashanth Patil (praspati); = tram@ietf.org < mailto:tram@ietf.org> > *=C4mne:* Re: [tram] turn-server-discovery and return >=20 > Yup, will update draft. >=20 > -Tiru >=20 > *From:*tram [ = mailto:tram-bounces@ietf.org] *On Behalf Of *Hutton, Andrew > *Sent:* Monday, February 08, 2016 10:03 PM > *To:* Benjamin Schwartz > *Cc:* Prashanth Patil (praspati); = tram@ietf.org < mailto:tram@ietf.org> > *Subject:* Re: [tram] turn-server-discovery and return >=20 > Works for me. >=20 > Andy >=20 > *From:*Benjamin Schwartz [ mailto:bemasc@webrtc.org] > *Sent:* 08 February 2016 16:10 > *To:* Hutton, Andrew > *Cc:* Prashanth Patil (praspati); = tram@ietf.org < mailto:tram@ietf.org> > *Subject:* Re: [tram] turn-server-discovery and return >=20 > I think _all_ TURN servers identified by autodiscovery are > enterprise/local, by definition. >=20 > How about >=20 > "WebRTC endpoints SHOULD treat any TURN server discovered through this > process as an enterprise/gateway server, in accordance with = Recursively > Encapsulated TURN [I-D.ietf-rtcweb-return]." >=20 > On Mon, Feb 8, 2016 at 7:01 AM, Hutton, Andrew = < mailto:andrew.hutton@unify.com>> = wrote: >=20 > In the latest update of the discovery draft > ( https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-06#sect= ion -7.2 > < https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_htm= l_dra ft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-2D06-23section-2D7.2&d=3DCwM= FaQ&c =3D96ZbZZcaMF4w0F4jpN6LZg&r=3DbwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg= &m=3DaE1H JYzmrPJyAVYgX-2Or-R6ZgrmBpeOZwf5h3I1z3U&s=3DcHnQcFQoFVxObJ2b-bAUJ1GaoQi_H= mjU1k fjT97qLRk&e=3D>) > the following text was added. >=20 >=20 >>7.2. Recursively Encapsulated TURN >>=20 >> A TURN client could attempt to discover multiple TURN servers so as >> to use recursively encapsulated TURN, as described in >> [I-D.ietf-rtcweb-return], to route traffic through multiple TURN >> servers for privacy. >=20 >=20 > I don't think this is correct as the discovery mechanisms described in > the draft will not be used to discover multiple TURN servers. In the > -rtcweb-return- case the discovery mechanisms is used to discover the > return proxy and the application will provide the application specific > TURN server. > I suggest the following text for this section: >=20 >=20 > "The TURN server discovery may result in the discovery of an > enterprise/local TURN server being discovered and therefore in the = case > where a WebRTC application also provides a TURN server the use of > Recursively Encapsulated TURN, as described in = [I-D.ietf-rtcweb-return]." >=20 >=20 > Regards > Andy >=20 > _______________________________________________ > tram mailing list > tram@ietf.org < mailto:tram@ietf.org> > https://www.ietf.org/mailman/listinfo/tram > < https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_li stinfo_tram&d=3DCwMFaQ&c=3D96ZbZZcaMF4w0F4jpN6LZg&r=3DbwZ-nnRGWmcGKRIuadq= 6-NSnsgwb BVUJa4mZfmEIBXg&m=3DaE1HJYzmrPJyAVYgX-2Or-R6ZgrmBpeOZwf5h3I1z3U&s=3DpYowz= t90bQR3 ruGnbzI21HRwXyslfnr6j0LzRts3Uzs&e=3D> >=20 >=20 >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram >=20 ------=_NextPart_000_0097_01D164D3.7B487C00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Brandon,

 

You are = bringing up a use case of a “better authenticated TURN server =

network” that we may hope is possible to = implement in addition to

what we = first of all need achieve “being able to use good WebRTC =

everywhere we can surf” (which I thought was = the purpose of this

DISCOVERY draft and of the RETURN = draft).

 

If your use = case also needs auto discovery, can’t it use the same, =

most optimal discovery method for the TURN server, = and thereafter

do whatever authentication method(s) = you want and need?

I actually think it = can.

 

Short = questions (after you read the inline below): Does my suggested =

modified anycast method in any way disturb the use = case you have in mind?

 

Aren’t removal of “Flaw 1” (or = whatever we chose to call it) and Flaw 2,

also = positive to your use case?

 

Or at = least, it does not make things worse for you, does = it?

(If it does make things worse, I believe both = anycast methods could live

in parallel = and use the same IANA TURN server discovery address. =

In the end – both anycast methods only = address the network provided TURN

server with = its unicast address and the 300 Try Alternate could come =

both from the binding and allocate = request.)

Would it really help to keep both = methods (for your use case and the

general use = case)?

 

I hope we = can focus and get this draft approved with at least one =

reasonably useful and widely and easily deployable = and safe/secure enough

DISCOVERY = method. And it would be helpful if we now also can get that =

IANA allocated TURN server anycast address, so we = can use/try the simple

anycast = method IRL.

 

/Karl =

 

 

-----Ursprungligt meddelande-----
Fr=E5n: = Brandon Williams [mailto:brandon.williams@akama= i.com]
Skickat: den 10 februari 2016 17:44
Till: Karl Stahl; = 'Tirumaleswar Reddy (tireddy)'; 'Hutton, Andrew'; 'Benjamin = Schwartz'
Kopia: 'Prashanth Patil (praspati)'; tram@ietf.org
=C4mne: Re: [tram] = turn-server-discovery and return

 

Hi = Karl,

 

I don't think I agree with your "Flaw 1" = and the associated proposed

change. Maybe I'm just not understanding your = point.

 

There is no reason why a TURN server can't check = the destination address

for the = connection/packet when it arrives and take different action =

based on that.

--- Of = course such behavior can be specified and implemented, but isn’t =

it better if we don’t have to take such = efforts?

 

Also, most STUN binding messages will be unauthenticated, =

so an on-path attacker = could easily redirect the client to an untrusted

relay. On the other hand, using the TURN allocation = for redirect

purposes allows the = TURN server to send the Try Alternate error in an

authenticated response.

--- But = there is nothing stopping “to send the Try Alternate error in an =

Authenticated” binding response, is there? =

 

to establish =

trust before being = redirected, and requiring the client/server to use

auth for STUN binding requests would be a bigger = change than requiring a

TURN = server with anycast to check the destination address.

--- = isn’t that already in the standards (binding is not excluded from =

auth is it)?

 

Regarding your "flaw 2", I agree that = that TTL should not be relied on

as a security mechanism. There is no reasonable way = for the client to

determine an = acceptable TTL to use for its current environment. That =

said, I also don't think it's = reasonable to expect the client to know

that the ISP has a sealed network configuration =

--- The big advantage with the suggested usage is, = that while a

WebRTC browser by default assumes a = leaky configuration (see the

RETURN = draft), the suggested deployment by blocking STUN packets =

through the default gateway, signals to the = browser: “Please look

for a = network provided TURN server paralleling the firewall here” =

(In this way we get a good way for the network = provider to enforce

sealed usage here instead of leaky AND = the huge benefit that local

call media = does not have to go twice around in the TURN server, which =

otherwise will happen if a sealed configuration is = enforced generally

from the WebRTC browser side. See the = RETURN draft.)

 

or to trust that the ISP

has correctly implemented its = sealed config. I also don't think it can

trust the relay to tell it if = the relay itself isn't already trusted, in

which case the concern doesn't apply = anyway.

--- We have to start with that we have a certain = trust level from the

network provider we choose to use = – the same for both data and

real-time = traffic, good or bad. Thereafter, you can add your authentication stuff =

for your “better TURN server network” = for your use case – I don’t see

that the = modified anycast method do other than positive things also =

for your use case. (And we need the improvements = for the general

WebRTC browser use case – where = your type of authentication will not

be used.) =

 

--Brandon

 

On 02/10/2016 04:34 AM, Karl = Stahl wrote:

> I am also positive to the update = below.

> 

> = Further,

> 

> 6.  Discovery = using Anycast needs improvement.

> 

> It has two flaws that easily can be = remedied:

> 

> Current method :

> 

> “When a client requires TURN services, = it sends a TURN allocate request

> to the assigned anycast address.  The = TURN anycast server responds with

> a 300 (Try Alternate) error as described in = [RFC5766];  The response

> = contains the TURN unicast address in the ALTERNATE-SERVER = attribute.

> For subsequent = communication with the TURN server, the client uses the

> responding server's unicast = address.”

> 

> Flaw 1: Turn servers do not respond = differently (Try alternate or OK)

> dependent on how they are addressed (by an = anycast address or by a

> = unicast address), do they?

> 

> Flaw 2: As already pointed out under 9.  = Security Considerations, 9.3.

> = Anycast

> 

> “In a network without any TURN server = that is aware of the TURN anycast

> address, outgoing TURN requests could leak out = onto the external

> Internet, = possibly revealing information. (I would also add that a = far

> away bad TURN server = might be used)... Sensitive clients that do not

> wish to leak information about their presence = can set an IP TTL on their

> = TURN requests that limits how far they can travel into the public = Internet.”

> 

> It would be better, not to have to rely on the = TTL limitation.

> 

> Considering that a TURN server also includes a = STUN server (when using

> the = binding request) and that the STUN server also can respond with = 300

> Try alternate, I suggest = the following modified method:

> 

> “When a client requires TURN services, = it sends a STUN binding request

> to the assigned anycast address.  The = STUN server responds with a 300

> (Try Alternate) error as described in = [RFC5389];  The response contains

> a unicast address in the ALTERNATE-SERVER = attribute, which the client

> = compares with the source address of the response and if the = addresses

> are the same, it is = an indication to use the TURN server at that

> address. For subsequent communication with the = TURN server, the client

> uses = that responding server's unicast address.”

> 

> Or simply, a STUN server pointing out = it’s own IP address as the

> alternate server, means that server it is a = network provided TURN server

> = that should be used.

> 

> Flaw 1 does not occur.

> 

> Flaw 2 is completely avoided if  the = client only tries this method when

> the enterprise/ISP enforces a sealed = configuration (according to

> = [I-D.ietf-rtcweb-return]) by stopping STUN packets in = the

> router/firewall/default = gateway by detecting the STUN cookie.

> 

> In [I-D.ietf-rtcweb-return], the WebRTC = endpoint could then maintain its

> default leaky behavior, but be signaled by the = local TURN server

> deployment = (stopping STUN packets) to behave sealed, and only in = such

> case try the (modified) = anycast method for TURN discovery. Thus, TURN

> requests will never leak out of the local = network.

> 

> We have verified that common rule based = firewalls (at least Linux

> = netfilter/IPtables based) can be configured to route the anycast = STUN

> packet, while still = stopping other packets containing the STUN cookie.

> 

> Considering that the anycast method works on = all network types, and it

> = allows the TURN server network deployment to automatically signal = sealed

> behavior to a leaky = WebRTC endpoint (by stopping STUN packets),  this

> should be the preferred discovery method for = WebRTC endpoints. A web

> = application that wish to bypass usage of the network provided = TURN

> server, can propose a = DTLS-encrypted STUN address (which will not be

> stopped since the STUN cookie will not be = detected).

> 

> /Karl

> 

> *Fr=E5n:*tram [mailto:tram-bounces@ietf.= org] *F=F6r *Tirumaleswar Reddy

> (tireddy)

> *Skickat:* den 8 februari 2016 = 17:50

> *Till:* Hutton, Andrew; = Benjamin Schwartz

> *Kopia:* = Prashanth Patil (praspati); tram@ietf.org = <mailto:tram@ietf.org>

> *=C4mne:* Re: = [tram] turn-server-discovery and return

> 

> Yup, will update draft.

> 

> -Tiru

> 

> *From:*tram [mailto:tram-bounces@ietf.= org] *On Behalf Of *Hutton, Andrew

> *Sent:* Monday, February 08, 2016 10:03 = PM

> *To:* Benjamin = Schwartz

> *Cc:* Prashanth = Patil (praspati); tram@ietf.org = <mailto:tram@ietf.org>

> *Subject:* Re: = [tram] turn-server-discovery and return

> 

> Works for me.

> 

> Andy

> 

> *From:*Benjamin Schwartz [mailto:bemasc@webrtc.org<= /span>]

> *Sent:* 08 = February 2016 16:10

> *To:* = Hutton, Andrew

> *Cc:* = Prashanth Patil (praspati); tram@ietf.org = <mailto:tram@ietf.org>

> *Subject:* Re: = [tram] turn-server-discovery and return

> 

> I think _all_ TURN servers identified by = autodiscovery are

> = enterprise/local, by definition.

> 

> How about

> 

> "WebRTC endpoints SHOULD treat any TURN = server discovered through this

> process as an enterprise/gateway server, in = accordance with Recursively

> = Encapsulated TURN [I-D.ietf-rtcweb-return]."

> 

> On Mon, Feb 8, 2016 at 7:01 AM, Hutton, Andrew = <andrew.hutton@unify.com

> = <mailto:andrew.hutton@unif= y.com>> wrote:

> 

> In the latest update of the discovery = draft

> (https://tools.ietf.org/ht= ml/draft-ietf-tram-turn-server-discovery-06#section-7.2

> <<= span = style=3D'color:windowtext;text-decoration:none'>https://urldefense.proofp= oint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html_draft-2Dietf-2Dtram-2Dt= urn-2Dserver-2Ddiscovery-2D06-23section-2D7.2&d=3DCwMFaQ&c=3D96Zb= ZZcaMF4w0F4jpN6LZg&r=3DbwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&am= p;m=3DaE1HJYzmrPJyAVYgX-2Or-R6ZgrmBpeOZwf5h3I1z3U&s=3DcHnQcFQoFVxObJ2= b-bAUJ1GaoQi_HmjU1kfjT97qLRk&e=3D>)

> the following text was added.

> 

> 

>>7.2.  Recursively Encapsulated = TURN

>> 

>>   A TURN client could attempt to = discover multiple TURN servers so as

>>   to use recursively = encapsulated TURN, as described in

>>   [I-D.ietf-rtcweb-return], to = route traffic through multiple TURN

>>   servers for = privacy.

> 

> 

> I don't think this is correct as the discovery = mechanisms described in

> the = draft will not be used to discover multiple TURN servers. In = the

> -rtcweb-return- case the = discovery mechanisms is used to discover the

> return proxy and the application will provide = the application specific

> TURN = server.

> I suggest the = following text for this section:

> 

> 

> "The TURN server discovery may result in = the discovery of an

> = enterprise/local TURN server being discovered and therefore in the = case

> where a WebRTC = application also provides a TURN server the use of

> Recursively Encapsulated TURN, as described in = [I-D.ietf-rtcweb-return]."

> 

> 

> Regards

> Andy

> 

> = _______________________________________________

> tram mailing list

> tram@ietf.org = <mailto:tram@ietf.org>

> https://www.ietf.org/mail= man/listinfo/tram

> = <https://urldefense.proofp= oint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_tram&d=3D= CwMFaQ&c=3D96ZbZZcaMF4w0F4jpN6LZg&r=3DbwZ-nnRGWmcGKRIuadq6-NSnsgw= bBVUJa4mZfmEIBXg&m=3DaE1HJYzmrPJyAVYgX-2Or-R6ZgrmBpeOZwf5h3I1z3U&= s=3DpYowzt90bQR3ruGnbzI21HRwXyslfnr6j0LzRts3Uzs&e=3D>

> 

> 

> 

> = _______________________________________________

> tram mailing list

> tram@ietf.org<= o:p>

> https://www.ietf.org/mail= man/listinfo/tram

> 

------=_NextPart_000_0097_01D164D3.7B487C00-- From nobody Thu Feb 11 05:39:54 2016 Return-Path: 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 D4F731B3197 for ; Thu, 11 Feb 2016 05:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] 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 E-z4DvtnDwtE for ; Thu, 11 Feb 2016 05:39:50 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 758B61B3196 for ; Thu, 11 Feb 2016 05:39:50 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id o6so18819902qkc.2 for ; Thu, 11 Feb 2016 05:39:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jive-com.20150623.gappssmtp.com; s=20150623; h=to:cc:from:subject:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=1iZdHD36Op9Uwf/k2f6BqcobnxKIfPtlqD+nhr+2tu8=; b=tddS6juSeEa4YTFD6QD29kYFE9SDj0ajw4joh/adoNYCA35gdB6YyBmLaNI3NjPRKE w1lpGrgE813sZ1s+IEKYIUID2qP5J1QRIqTLccH4KzHtpJarYcAhKacvAZ1icMVnSnlh SBm2HANAPDSG0VrsDnoincpWELExD3zHbLi3bAJ/5sgTkFs64zywMhJWaC4qAXGvXN02 L41hPu6pFA38KJgV5GrSbDxeLJt93Rz4LT+eHlf+IziGb/XItXmIix76ZUesSeJ2lpbQ 3ay8LNdf+p1cFtNlAyBcNUBwXsaJAgJYSLB9FBOo83f4XPzydessaT6utUOWfXVZWQyA u1iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version:content-type:content-transfer-encoding; bh=1iZdHD36Op9Uwf/k2f6BqcobnxKIfPtlqD+nhr+2tu8=; b=KA/0thjU6GfbGiHmC/EiJeD36s5OF3U8+iYtn6xrJfaeD5YBh2ClJPRw6blEZT7Ag6 DQsc1Tj0BuDMynfHZ30d1CPp190hKm7S6Kg29FSM3cabgWZnXsTiUWXiwiu3rZlQlzI5 5Ra9uoHWDRyH/K40012uPLZsW4cuRaBHH5/ZWw2G1IxiStN1NJIZV4caa+w37QnyfKcD J6qPpKRoXhraFK9E447Co15t/iBAAdnk++Tek5m0/N1j88L6/8X5xhyXVwVyGUcrDfAD BrNGkeL6dYpeOd2tVhLg8PPOG5uDWKfriM89/4jSAStSuETw+ko5Ej0AShfQDAkZRZNp fPdA== X-Gm-Message-State: AG10YOSs1eBv+gfcXUy3G+SgjjPj7IAw9YkiPuQaoOP6LnIyqHmOWYLmGlfZJG3rmROjadLZ X-Received: by 10.55.80.68 with SMTP id e65mr56151282qkb.46.1455197989540; Thu, 11 Feb 2016 05:39:49 -0800 (PST) Received: from Simons-MacBook-Air.local ([2001:470:b161:0:a1a5:690a:93d9:551d]) by smtp.googlemail.com with ESMTPSA id x136sm3389756qka.0.2016.02.11.05.39.48 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 11 Feb 2016 05:39:49 -0800 (PST) To: "tram@ietf.org" From: Simon Perreault Message-ID: <56BC8F23.2000701@jive.com> Date: Thu, 11 Feb 2016 08:39:47 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Gonzalo Camarillo Subject: [tram] Call for presentations 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 13:39:53 -0000 TRAMsters, If you plan on presenting during the TRAM session in Buenos Aires, please let us know so we can request a meeting slot of appropriate length. Thanks, Simon From nobody Thu Feb 11 12:08:41 2016 Return-Path: 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 853E11B39C1 for ; Thu, 11 Feb 2016 12:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 7Do7fD45r7GA for ; Thu, 11 Feb 2016 12:08:22 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 1CAEE1B39CA for ; Thu, 11 Feb 2016 12:08:21 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 41C4C433432; Thu, 11 Feb 2016 20:08:21 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 2B532433412; Thu, 11 Feb 2016 20:08:21 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1455221301; bh=MtcPNSwvahBCJkS70zuqM3ab1CHGqCsdt4aFYTI0+50=; l=16852; h=To:References:Cc:From:Date:In-Reply-To:From; b=hRRg0VxMybf30rWA/aTuU/eKDPmK4PNlKvsjYQQBfxnTGSu59eQAo9FdPWml8kRlC efuX8ksmqE0zfSUirhOGETkzHW9FN7UErblKE+roUuj7Jpy9EI0B9xySiMqoEA2PxO PHv87rakAo1kkUPxFOYXt89AWm4+MUNQxnNHy/v4= Received: from [172.28.113.49] (bowill.kendall.corp.akamai.com [172.28.113.49]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 22293202A; Thu, 11 Feb 2016 20:08:21 +0000 (GMT) To: Karl Stahl , "'Tirumaleswar Reddy (tireddy)'" , "'Hutton, Andrew'" , 'Benjamin Schwartz' References: <20160107000242.2632.86853.idtracker@ietfa.amsl.com> <9F33F40F6F2CD847824537F3C4E37DDF1E99B5CF@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1E99BE7A@MCHP04MSX.global-ad.net> <0a1d01d163e6$47c31450$d7493cf0$@stahl@intertex.se> <56BB68C9.2030202@akamai.com> <009601d164cb$19841400$4c8c3c00$@stahl@intertex.se> From: Brandon Williams Message-ID: <56BCEA35.4040608@akamai.com> Date: Thu, 11 Feb 2016 15:08:21 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <009601d164cb$19841400$4c8c3c00$@stahl@intertex.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "'Prashanth Patil \(praspati\)'" , tram@ietf.org Subject: Re: [tram] turn-server-discovery and return 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2016 20:08:37 -0000 Hi Karl, I'm a bit confused by your response. I don't think I'm describing a use case for a "better authenticated TURN server". I'm describing how authentication works today if you follow the recommendations from the STUN and TURN RFCs. The STUN RFC says that Binding requests SHOULD NOT use authentication and SHOULD NOT return alternate-server. You are suggesting either changing these recommendations or just ignoring the security risk associated with accepting an unauthenticated TryAlternate error. My suggestion is that we stick as close to the existing specifications as possible, not that we create some new authentication model. I think the current text sticks closer to the existing specifications than your proposal does. I do think that the idea of having a method for the client to determine whether it's in a sealed config could be a good idea to allow it to figure out whether it should look for a return server. I'm not sure we necessarily want to require sealed config before falling back to an auto-discovered relay, though. I'm also not sure whether it's good enough just to look at whether your STUN requests are getting dropped, since you can't know where they're being dropped. Someone who is in a position to hijack the anycast address may well be in a position to drop your requests and force you to try the anycast address. I think I've hit your high level questions here and in my inline responses below (look for "[bw]"). --Brandon On 02/11/2016 07:52 AM, Karl Stahl wrote: > Hi Brandon, > > You are bringing up a use case of a “better authenticated TURN server > > network” that we may hope is possible to implement in addition to > > what we first of all need achieve “being able to use good WebRTC > > everywhere we can surf” (which I thought was the purpose of this > > DISCOVERY draft and of the RETURN draft). > > If your use case also needs auto discovery, can’t it use the same, > > most optimal discovery method for the TURN server, and thereafter > > do whatever authentication method(s) you want and need? [bw] My use case cannot use the method you describe because (1) I don't consider it reasonable to add authentication to binding requests because it will add delay to reflexive address discovery and (2) I also don't think it's reasonable to ask the client to accept an unauthenticated TryAlternate error response (especially not if it contains an ALTERNATE-DOMAIN attribute). > > I actually think it can. > > Short questions (after you read the inline below): Does my suggested > > modified anycast method in any way disturb the use case you have in mind? > [bw] See above. I can't use the method you describe. As long as that's not the only documented method and neither method is required, then I think it meets both of our needs. I'm not usually supportive of specs providing multiple ways to handle something and not requiring either, though, because it adds significant interop risk. That's why my preference is to stick as close to what we already have as we can. > Aren’t removal of “Flaw 1” (or whatever we chose to call it) and Flaw 2, > > also positive to your use case? > > Or at least, it does not make things worse for you, does it? > > (If it does make things worse, I believe both anycast methods could live > > in parallel and use the same IANA TURN server discovery address. > > In the end – both anycast methods only address the network provided TURN > > server with its unicast address and the 300 Try Alternate could come > > both from the binding and allocate request.) > > Would it really help to keep both methods (for your use case and the > > general use case)? [bw] See above. IMO, "my" use case _is_ the "general" use case. I don't think we need to change the basics of STUN and TURN in order to get what we need for redirect, and I think sticking as close to the existing specs as possible is the best way to end up with something that is widely/easily deployable. > > I hope we can focus and get this draft approved with at least one > > reasonably useful and widely and easily deployable and safe/secure enough > > DISCOVERY method. And it would be helpful if we now also can get that > > IANA allocated TURN server anycast address, so we can use/try the simple > > anycast method IRL. > > /Karl > > -----Ursprungligt meddelande----- > Från: Brandon Williams [mailto:brandon.williams@akamai.com] > Skickat: den 10 februari 2016 17:44 > Till: Karl Stahl; 'Tirumaleswar Reddy (tireddy)'; 'Hutton, Andrew'; > 'Benjamin Schwartz' > Kopia: 'Prashanth Patil (praspati)'; tram@ietf.org > Ämne: Re: [tram] turn-server-discovery and return > > Hi Karl, > > I don't think I agree with your "Flaw 1" and the associated proposed > > change. Maybe I'm just not understanding your point. > > There is no reason why a TURN server can't check the destination address > > for the connection/packet when it arrives and take different action > > based on that. > > --- Of course such behavior can be specified and implemented, but isn’t > > it better if we don’t have to take such efforts? > > Also, most STUN binding messages will be unauthenticated, > > so an on-path attacker could easily redirect the client to an untrusted > > relay. On the other hand, using the TURN allocation for redirect > > purposes allows the TURN server to send the Try Alternate error in an > > authenticated response. > > --- But there is nothing stopping “to send the Try Alternate error in an > > Authenticated” binding response, is there? > > to establish > > trust before being redirected, and requiring the client/server to use > > auth for STUN binding requests would be a bigger change than requiring a > > TURN server with anycast to check the destination address. > > --- isn’t that already in the standards (binding is not excluded from > > auth is it)? > > Regarding your "flaw 2", I agree that that TTL should not be relied on > > as a security mechanism. There is no reasonable way for the client to > > determine an acceptable TTL to use for its current environment. That > > said, I also don't think it's reasonable to expect the client to know > > that the ISP has a sealed network configuration > > --- The big advantage with the suggested usage is, that while a > > WebRTC browser by default assumes a leaky configuration (see the > > RETURN draft), the suggested deployment by blocking STUN packets > > through the default gateway, signals to the browser: “Please look > > for a network provided TURN server paralleling the firewall here” > > (In this way we get a good way for the network provider to enforce > > sealed usage here instead of leaky AND the huge benefit that local > > call media does not have to go twice around in the TURN server, which > > otherwise will happen if a sealed configuration is enforced generally > > from the WebRTC browser side. See the RETURN draft.) > > or to trust that the ISP > > has correctly implemented its sealed config. I also don't think it can > > trust the relay to tell it if the relay itself isn't already trusted, in > > which case the concern doesn't apply anyway. > > --- We have to start with that we have a certain trust level from the > > network provider we choose to use – the same for both data and > > real-time traffic, good or bad. Thereafter, you can add your > authentication stuff > > for your “better TURN server network” for your use case – I don’t see > > that the modified anycast method do other than positive things also > > for your use case. (And we need the improvements for the general > > WebRTC browser use case – where your type of authentication will not > > be used.) > > --Brandon > > On 02/10/2016 04:34 AM, Karl Stahl wrote: > >> I am also positive to the update below. > >> > >> Further, > >> > >> 6. Discovery using Anycast needs improvement. > > > > > > It has two flaws that easily can be remedied: > > > > > > Current method : > > > > > > “When a client requires TURN services, it sends a TURN allocate request > > > to the assigned anycast address. The TURN anycast server responds with > > > a 300 (Try Alternate) error as described in [RFC5766]; The response > > > contains the TURN unicast address in the ALTERNATE-SERVER attribute. > > > For subsequent communication with the TURN server, the client uses the > > > responding server's unicast address.” > > > > > > Flaw 1: Turn servers do not respond differently (Try alternate or OK) > > > dependent on how they are addressed (by an anycast address or by a > > > unicast address), do they? > > > > > > Flaw 2: As already pointed out under 9. Security Considerations, 9.3. > > > Anycast > > > > > > “In a network without any TURN server that is aware of the TURN anycast > > > address, outgoing TURN requests could leak out onto the external > > > Internet, possibly revealing information. (I would also add that a far > > > away bad TURN server might be used)... Sensitive clients that do not > > > wish to leak information about their presence can set an IP TTL on their > > > TURN requests that limits how far they can travel into the public > Internet.” > > > > > > It would be better, not to have to rely on the TTL limitation. > > > > > > Considering that a TURN server also includes a STUN server (when using > > > the binding request) and that the STUN server also can respond with 300 > > > Try alternate, I suggest the following modified method: > > > > > > “When a client requires TURN services, it sends a STUN binding request > > > to the assigned anycast address. The STUN server responds with a 300 > > > (Try Alternate) error as described in [RFC5389]; The response contains > > > a unicast address in the ALTERNATE-SERVER attribute, which the client > > > compares with the source address of the response and if the addresses > > > are the same, it is an indication to use the TURN server at that > > > address. For subsequent communication with the TURN server, the client > > > uses that responding server's unicast address.” > > > > > > Or simply, a STUN server pointing out it’s own IP address as the > > > alternate server, means that server it is a network provided TURN server > > > that should be used. > > > > > > Flaw 1 does not occur. > > > > > > Flaw 2 is completely avoided if the client only tries this method when > > > the enterprise/ISP enforces a sealed configuration (according to > > > [I-D.ietf-rtcweb-return]) by stopping STUN packets in the > > > router/firewall/default gateway by detecting the STUN cookie. > > > > > > In [I-D.ietf-rtcweb-return], the WebRTC endpoint could then maintain its > > > default leaky behavior, but be signaled by the local TURN server > > > deployment (stopping STUN packets) to behave sealed, and only in such > > > case try the (modified) anycast method for TURN discovery. Thus, TURN > > > requests will never leak out of the local network. > > > > > > We have verified that common rule based firewalls (at least Linux > > > netfilter/IPtables based) can be configured to route the anycast STUN > > > packet, while still stopping other packets containing the STUN cookie. > > > > > > Considering that the anycast method works on all network types, and it > > > allows the TURN server network deployment to automatically signal sealed > > > behavior to a leaky WebRTC endpoint (by stopping STUN packets), this > > > should be the preferred discovery method for WebRTC endpoints. A web > > > application that wish to bypass usage of the network provided TURN > > > server, can propose a DTLS-encrypted STUN address (which will not be > > > stopped since the STUN cookie will not be detected). > > > > > > /Karl > > > > > > *Från:*tram [mailto:tram-bounces@ietf.org] *För *Tirumaleswar Reddy > > > (tireddy) > > > *Skickat:* den 8 februari 2016 17:50 > > > *Till:* Hutton, Andrew; Benjamin Schwartz > > > *Kopia:* Prashanth Patil (praspati); tram@ietf.org > > > > *Ämne:* Re: [tram] turn-server-discovery and return > > > > > > Yup, will update draft. > > > > > > -Tiru > > > > > > *From:*tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Hutton, Andrew > > > *Sent:* Monday, February 08, 2016 10:03 PM > > > *To:* Benjamin Schwartz > > > *Cc:* Prashanth Patil (praspati); tram@ietf.org > > > > *Subject:* Re: [tram] turn-server-discovery and return > > > > > > Works for me. > > > > > > Andy > > > > > > *From:*Benjamin Schwartz [mailto:bemasc@webrtc.org] > > > *Sent:* 08 February 2016 16:10 > > > *To:* Hutton, Andrew > > > *Cc:* Prashanth Patil (praspati); tram@ietf.org > > > > *Subject:* Re: [tram] turn-server-discovery and return > > > > > > I think _all_ TURN servers identified by autodiscovery are > > > enterprise/local, by definition. > > > > > > How about > > > > > > "WebRTC endpoints SHOULD treat any TURN server discovered through this > > > process as an enterprise/gateway server, in accordance with Recursively > > > Encapsulated TURN [I-D.ietf-rtcweb-return]." > > > > > > On Mon, Feb 8, 2016 at 7:01 AM, Hutton, Andrew > > > wrote: > > > > > > In the latest update of the discovery draft > > > > (https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-06#section-7.2 > > > > > ) > > > the following text was added. > > > > > > > > >>7.2. Recursively Encapsulated TURN > > >> > > >> A TURN client could attempt to discover multiple TURN servers so as > > >> to use recursively encapsulated TURN, as described in > > >> [I-D.ietf-rtcweb-return], to route traffic through multiple TURN > > >> servers for privacy. > > > > > > > > > I don't think this is correct as the discovery mechanisms described in > > > the draft will not be used to discover multiple TURN servers. In the > > > -rtcweb-return- case the discovery mechanisms is used to discover the > > > return proxy and the application will provide the application specific > > > TURN server. > > > I suggest the following text for this section: > > > > > > > > > "The TURN server discovery may result in the discovery of an > > > enterprise/local TURN server being discovered and therefore in the case > > > where a WebRTC application also provides a TURN server the use of > > > Recursively Encapsulated TURN, as described in [I-D.ietf-rtcweb-return]." > > > > > > > > > Regards > > > Andy > > > > > > _______________________________________________ > > > tram mailing list > > > tram@ietf.org > > > https://www.ietf.org/mailman/listinfo/tram > > > > > > > > > > > > > > > > > _______________________________________________ > > > tram mailing list > > > tram@ietf.org > > > https://www.ietf.org/mailman/listinfo/tram > > > > > -- Brandon Williams; Chief Architect Cloud Networking; Akamai Technologies Inc. From nobody Thu Feb 18 05:24:11 2016 Return-Path: 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 8CE311A86E0 for ; Thu, 18 Feb 2016 05:24:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 ytBbddFf9tcd for ; Thu, 18 Feb 2016 05:24:09 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26FB71A6F9D for ; Thu, 18 Feb 2016 05:24:08 -0800 (PST) X-AuditID: c1b4fb3a-f79ce6d000005138-0c-56c5c5f7fa5d Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 54.66.20792.7F5C5C65; Thu, 18 Feb 2016 14:24:07 +0100 (CET) Received: from [148.135.149.119] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.3.248.2; Thu, 18 Feb 2016 14:24:06 +0100 To: From: Gonzalo Camarillo Message-ID: <56C5C5F6.9070205@ericsson.com> Date: Thu, 18 Feb 2016 15:24:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM2K7tO73o0fDDG5uF7CY/fgdq8WHtRfY HJg8liz5yeQxteUqSwBTFJdNSmpOZllqkb5dAlfGv6ZvbAVLmCqWLmpmbWB8xtjFyMkhIWAi 8X7hGnYIW0ziwr31bF2MXBxCAocZJb60fYNy1jJK/PxzA6xDREBYYu7BuywgNrOAusSDH32s IDabgIXEllv3weLCAnoS81/eAYpzcPAKaEtMWMIJEmYRUJW4f2UdWLmoQIzExc4jTCA2r4Cg xMmZT1hAypkFNCXW79KHmC4vsf3tHGYQWwhoyvJnLSwTGPlnIemYhdAxC0nHAkbmVYyixanF xbnpRkZ6qUWZycXF+Xl6eaklmxiBoXdwy2+rHYwHnzseYhTgYFTi4S34fSRMiDWxrLgy9xCj BAezkgjv7r1Hw4R4UxIrq1KL8uOLSnNSiw8xSnOwKInzrnFeHyYkkJ5YkpqdmlqQWgSTZeLg lGpgLBPJjmrhTPpRudj4CM/drSwlos0Le7dXqP4RVp6YrnFC19rwYzrLq+3/Ls65G/548Vnm Ay8X/JogG+mySXfO71DztlnPDeqf1Oh7bN+2WP/9grMKAhtLr6s6nL3Wm2HMpFvV7ia1/YXG DD+R1W7zUl7veHnxCOvShSFvrFlnL71i21vV9kX0hxJLcUaioRZzUXEiABICn1A5AgAA Archived-At: Cc: Simon Perreault Subject: [tram] Do we need a session in Buenos Aires? 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 13:24:10 -0000 Folks, Simon and I are thinking about Buenos Aires. If we do not need face-to-face time in order to progress our working group items, we would not request a TRAM session. Please, let us know if you think a particular item needs face-to-face time in Buenos Aires. Thanks, Gonzalo From nobody Fri Feb 19 08:08:52 2016 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB9A1A21A1; Fri, 19 Feb 2016 05:47:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160219134758.20230.20073.idtracker@ietfa.amsl.com> Date: Fri, 19 Feb 2016 05:47:58 -0800 Archived-At: X-Mailman-Approved-At: Fri, 19 Feb 2016 08:08:50 -0800 Cc: sperreault@jive.com, spencerdawkins.ietf@gmail.com, tram@ietf.org, tram-chairs@ietf.org Subject: [tram] tram - Not having a session at IETF 95 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 13:47:58 -0000 Simon Perreault, a chair of the tram working group, indicated that the tram working group does not plan to hold a session at IETF 95. This message was generated and sent by the IETF Meeting Session Request Tool.