From nobody Mon Dec 1 01:10:55 2014 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 ED35C1A0379 for ; Mon, 1 Dec 2014 01:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 FEFcR1PQc13P for ; Mon, 1 Dec 2014 01:10:47 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 684EE1A00E0 for ; Mon, 1 Dec 2014 01:10:47 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id f15so8947620lbj.23 for ; Mon, 01 Dec 2014 01:10:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=Rwop7Cd4DbUfD22kUIZZcf/A8wjfsBH97zHQYdlj75U=; b=X2W5GX7+rTfzkb5nFrOheukuau8OyAgHA3HKOgJoGPdc6aMMtPOEa92DmuUZ0lh/i6 25qBFd3nawHnmMEZnSiiWs5mJ2yRmq0j5lPcg/G9NJdFWJ5vFQVAMTbE96VlIaVDqE+5 AAiiIHd5SCplYgOj+VFeZuBQibgtY7OntxGlbtAmoKFqCgVqQjVIBH6HsgFZuSwciILx qA3EZs/28CxXhnwCsl3pxRB8RySiJGKqEVefG0zvpq/ncovLdT4S7QQqDE/KiNenAIHc I8RpBI8uPtNrRYRa2sbo2MlLmA0Gytu2EWRZ9bPT/1wRTkOE/HRySDBphGw+uaXDnJua 2Ohw== MIME-Version: 1.0 X-Received: by 10.112.199.138 with SMTP id jk10mr10597857lbc.86.1417425045866; Mon, 01 Dec 2014 01:10:45 -0800 (PST) Received: by 10.25.205.201 with HTTP; Mon, 1 Dec 2014 01:10:45 -0800 (PST) Date: Mon, 1 Dec 2014 10:10:45 +0100 Message-ID: From: Victor Pascual Avila To: tram@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/WIGiCGKNoGM5sPFnK05PBJmwyzU Cc: draft-chenxin-behave-turn-websocket@tools.ietf.org Subject: [tram] TURN over WebSocket 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, 01 Dec 2014 09:10:51 -0000 Hi, last year we put together this I-D: https://tools.ietf.org/html/draft-chenxin-behave-turn-websocket-01 We have recently received some emails indicating there's interest in reviving this work. Use case: only traffic on ports 80 and 443 are allowed and the need/requirement to run both HTTPS and TURN servers on port 443, on the same IP address. Shall we create a new milestone for this? Cheers, -Victor From nobody Mon Dec 1 07:15:30 2014 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 B78271A1DE2 for ; Mon, 1 Dec 2014 07:15:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 DmdE0A2ylocg for ; Mon, 1 Dec 2014 07:15:06 -0800 (PST) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A13D1A1BFF for ; Mon, 1 Dec 2014 07:15:04 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id f15so9621354lbj.27 for ; Mon, 01 Dec 2014 07:15:02 -0800 (PST) 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=Q57/85dcrnNQwt3PvuRuL4B8TI1VlbfZfV2ItUBuWM0=; b=nIcnjKmyjdxoaBVM6TsdpplurmUlaqtHvLTxQ1h65adh2Y+vOKdwAKG/mj7YOSFSfF TtQFYbO2DLuuruEdG7b/Ai3gNOnPeMY9rMbxyOqOLIagnC4hVZ3gKTvtJRbXRroVNEZ0 p89WdQFNSa6j1T03jzY0K5DKV/4GblOEJr3BEaHSp8zHYm7KRePa3g0bIus5XMnyy7f2 8VXRWP0bLyE5NfQe6T9XIM3E1LxtiMd1IEGjEGr4UjdnRi3rvIKsJeAFbvfagFiDjL1/ nrgJo94S2RTettHXEGfMg4I5vzCpQBpzKMfRrf26konWzgaJSAA5XJvXBzkv+X9BLnuN bahg== X-Gm-Message-State: ALoCoQlNuHdyHVgB9z6nKg72y7rdoniOmiDkjE0ah2d7QPn3AMmUUK/hs9sNT64LmgNfLfv2lutp MIME-Version: 1.0 X-Received: by 10.152.45.41 with SMTP id j9mr27115230lam.59.1417446902675; Mon, 01 Dec 2014 07:15:02 -0800 (PST) Received: by 10.25.84.145 with HTTP; Mon, 1 Dec 2014 07:15:02 -0800 (PST) In-Reply-To: References: Date: Mon, 1 Dec 2014 10:15:02 -0500 Message-ID: From: Simon Perreault To: Victor Pascual Avila Content-Type: multipart/alternative; boundary=001a11c29bca1f4d8f05092913c5 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ae9NIMx-VBwoj2vb7vEs0ZiC8i8 Cc: "draft-chenxin-behave-turn-websocket@tools.ietf.org" , "tram@ietf.org" Subject: Re: [tram] TURN over WebSocket 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, 01 Dec 2014 15:15:16 -0000 --001a11c29bca1f4d8f05092913c5 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 1, 2014 at 4:10 AM, Victor Pascual Avila < victor.pascual.avila@gmail.com> wrote: > Shall we create a new milestone for this? All, Note that this question from Victor is intended for the working group. The chairs are in listening mode! :) Simon --001a11c29bca1f4d8f05092913c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Dec 1, 2014 at 4:10 AM, Victor Pascual Avila <victor.pasc= ual.avila@gmail.com> wrote:
Shall we create a new milestone for this?

All,

Note that t= his question from Victor is intended for the working group. The chairs are = in listening mode! :)

Simon
--001a11c29bca1f4d8f05092913c5-- From nobody Mon Dec 1 07:50:08 2014 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 5FC401A6EFE for ; Mon, 1 Dec 2014 07:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 H-qSFo5JNI76 for ; Mon, 1 Dec 2014 07:50:00 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66CE01A6EFF for ; Mon, 1 Dec 2014 07:49:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6948; q=dns/txt; s=iport; t=1417448961; x=1418658561; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=iWkADCH0pPNaNN6Z+M7rLX00lxZSTZ7oklsK++c3yUg=; b=YkWWeDe0KFbpKkaNKxXPQSt+NX+k2TAdZyTSYXvnt4XSWj1L3TH7kPbp 5Xg5LsOPcbDPxuh74Fq5+94KiUuIku/kxIXhcgFVed3akYyskeH2BRl2j M+R4+3bxdHW9qGyrUB9lS5MTJ95lzVeyOPaXig8Cuaoi7NjHwp7DMQDP1 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkIAH+NfFStJV2T/2dsb2JhbABbgkJEUVgEgwHBOIIohk4CHHkWAQEBAQF9hAIBAQEEIwpMEAIBCA4DBAEBCx0DAgICHxEUCQgCBAENBQiIIwMSDb4QkBkNhhwBAQEBAQEBAQEBAQEBAQEBAQEBAQETBI5DggctBAYBgnU0gR8FkQWETYR0gy+DO4oMhk6De28BgUWBAQEBAQ X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208,217";a="101554646" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-4.cisco.com with ESMTP; 01 Dec 2014 15:49:20 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id sB1FnKXY009138 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Dec 2014 15:49:20 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.204]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Mon, 1 Dec 2014 09:49:20 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault , Victor Pascual Avila Thread-Topic: [tram] TURN over WebSocket Thread-Index: AQHQDUa9YM/RGzude0ywfRjFvgaMfpx7PS8A//+jYLA= Date: Mon, 1 Dec 2014 15:49:19 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2837AA78@xmb-rcd-x10.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.67.53] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A2837AA78xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Jw1TDtQJCn8l0Flr1J81SQbogmg Cc: "draft-chenxin-behave-turn-websocket@tools.ietf.org" , "tram@ietf.org" Subject: Re: [tram] TURN over WebSocket 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, 01 Dec 2014 15:50:06 -0000 --_000_913383AAA69FF945B8F946018B75898A2837AA78xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaHR0cGJpcy10dW5uZWwtcHJv dG9jb2wtMDAgYWxyZWFkeSBzb2x2ZXMgdGhlIHByb2JsZW0gd2l0aCBmaXJld2FsbCBvbmx5IHBl cm1pdHRpbmcgSFRUUChTKSBmbG93cyB0aHJvdWdoIGEgcHJveHkuIFBsZWFzZSBleHBsYWluIHRo ZSBmaXJld2FsbCBjb25maWd1cmF0aW9uIGluIHdoaWNoIHRoZSBhYm92ZSB0ZWNobmlxdWUgd2ls bCBub3Qgd29yay4NCg0KLVRpcnUNCg0KRnJvbTogdHJhbSBbbWFpbHRvOnRyYW0tYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNpbW9uIFBlcnJlYXVsdA0KU2VudDogTW9uZGF5LCBEZWNl bWJlciAwMSwgMjAxNCA4OjQ1IFBNDQpUbzogVmljdG9yIFBhc2N1YWwgQXZpbGENCkNjOiBkcmFm dC1jaGVueGluLWJlaGF2ZS10dXJuLXdlYnNvY2tldEB0b29scy5pZXRmLm9yZzsgdHJhbUBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFt0cmFtXSBUVVJOIG92ZXIgV2ViU29ja2V0DQoNCk9uIE1vbiwg RGVjIDEsIDIwMTQgYXQgNDoxMCBBTSwgVmljdG9yIFBhc2N1YWwgQXZpbGEgPHZpY3Rvci5wYXNj dWFsLmF2aWxhQGdtYWlsLmNvbTxtYWlsdG86dmljdG9yLnBhc2N1YWwuYXZpbGFAZ21haWwuY29t Pj4gd3JvdGU6DQpTaGFsbCB3ZSBjcmVhdGUgYSBuZXcgbWlsZXN0b25lIGZvciB0aGlzPw0KDQpB bGwsDQoNCk5vdGUgdGhhdCB0aGlzIHF1ZXN0aW9uIGZyb20gVmljdG9yIGlzIGludGVuZGVkIGZv ciB0aGUgd29ya2luZyBncm91cC4gVGhlIGNoYWlycyBhcmUgaW4gbGlzdGVuaW5nIG1vZGUhIDop DQoNClNpbW9uDQo= --_000_913383AAA69FF945B8F946018B75898A2837AA78xmbrcdx10ciscoc_ 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 LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaHR0cGJpcy10dW5uZWwtcHJvdG9jb2wt MDAiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWh0dHBiaXMtdHVubmVs LXByb3RvY29sLTAwPC9hPiBhbHJlYWR5IHNvbHZlcw0KIHRoZSBwcm9ibGVtIHdpdGggZmlyZXdh bGwgb25seSBwZXJtaXR0aW5nIEhUVFAoUykgZmxvd3MgdGhyb3VnaCBhIHByb3h5LiBQbGVhc2Ug ZXhwbGFpbiB0aGUgZmlyZXdhbGwgY29uZmlndXJhdGlvbiBpbiB3aGljaCB0aGUgYWJvdmUgdGVj aG5pcXVlIHdpbGwgbm90IHdvcmsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tVGlydTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4g NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiB0cmFtIFttYWlsdG86dHJhbS1ib3VuY2VzQGlldGYu b3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5TaW1vbiBQZXJyZWF1bHQ8YnI+DQo8Yj5TZW50Ojwv Yj4gTW9uZGF5LCBEZWNlbWJlciAwMSwgMjAxNCA4OjQ1IFBNPGJyPg0KPGI+VG86PC9iPiBWaWN0 b3IgUGFzY3VhbCBBdmlsYTxicj4NCjxiPkNjOjwvYj4gZHJhZnQtY2hlbnhpbi1iZWhhdmUtdHVy bi13ZWJzb2NrZXRAdG9vbHMuaWV0Zi5vcmc7IHRyYW1AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFt0cmFtXSBUVVJOIG92ZXIgV2ViU29ja2V0PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBE ZWMgMSwgMjAxNCBhdCA0OjEwIEFNLCBWaWN0b3IgUGFzY3VhbCBBdmlsYSAmbHQ7PGEgaHJlZj0i bWFpbHRvOnZpY3Rvci5wYXNjdWFsLmF2aWxhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZp Y3Rvci5wYXNjdWFsLmF2aWxhQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2hhbGwgd2UgY3JlYXRlIGEgbmV3IG1pbGVzdG9uZSBm b3IgdGhpcz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QWxsLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQpOb3RlIHRoYXQgdGhpcyBxdWVzdGlvbiBmcm9tIFZpY3RvciBpcyBpbnRlbmRlZCBmb3Ig dGhlIHdvcmtpbmcgZ3JvdXAuIFRoZSBjaGFpcnMgYXJlIGluIGxpc3RlbmluZyBtb2RlISA6KTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaW1v bjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_913383AAA69FF945B8F946018B75898A2837AA78xmbrcdx10ciscoc_-- From nobody Mon Dec 1 07:57:27 2014 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 4DFBC1A6F01 for ; Mon, 1 Dec 2014 07:57:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, 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 fVivE_y73WQI for ; Mon, 1 Dec 2014 07:57:25 -0800 (PST) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 996271A6EFF for ; Mon, 1 Dec 2014 07:57:24 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id bs8so27078421wib.3 for ; Mon, 01 Dec 2014 07:57:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=UVFm7mbwVcqkdSY3QIVBm7P4IDKPBEFYFdbdpR/ueNU=; b=NaaDPHuqhkou6JmaclrzowcoPdEAIc5k8/2UTF/S96LXFcy5rVAdPuhbExgOEpOydq gmIRYLPCtccBIpcdYOVIyPLHpAD/XV7P8kDDg115iTWb67P2t4EeX0TUrUZt/wMpGbfr Bc5VY7fA14dwfMDaBfcWE2b0NugM6h0cKx46yr3PfAzIl0WUsdCEGgziGuGZbFto42+u hcszgcO4oQwhAHwk9OinyjGK7q9yxlbxoedNMCzA0j6qXVGAAyPZsMo7xTM0xLQbTlFZ N/fZWc34iUejicrtGcUTbFEq0QyX78VLg9RwxhSTaYpcCrLLs7va/CNeYZ2tOJeOgUwR R+QA== X-Received: by 10.194.119.193 with SMTP id kw1mr95664994wjb.37.1417449443370; Mon, 01 Dec 2014 07:57:23 -0800 (PST) Received: from [192.168.1.37] (136.Red-81-39-109.dynamicIP.rima-tde.net. [81.39.109.136]) by mx.google.com with ESMTPSA id he3sm28121334wjc.15.2014.12.01.07.57.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Dec 2014 07:57:22 -0800 (PST) Message-ID: <547C8FE1.3020208@gmail.com> Date: Mon, 01 Dec 2014 16:57:21 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , Simon Perreault , Victor Pascual Avila References: <913383AAA69FF945B8F946018B75898A2837AA78@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2837AA78@xmb-rcd-x10.cisco.com> Content-Type: multipart/alternative; boundary="------------020407030000090408090304" Archived-At: http://mailarchive.ietf.org/arch/msg/tram/3TtpQz_-Zv2-4-RStzeFDQeHZeQ Cc: "draft-chenxin-behave-turn-websocket@tools.ietf.org" , "tram@ietf.org" Subject: Re: [tram] TURN over WebSocket 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, 01 Dec 2014 15:57:26 -0000 This is a multi-part message in MIME format. --------------020407030000090408090304 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Transparent proxying for example Best regards Sergio On 01/12/2014 16:49, Tirumaleswar Reddy (tireddy) wrote: > > https://tools.ietf.org/html/draft-ietf-httpbis-tunnel-protocol-00 > already solves the problem with firewall only permitting HTTP(S) flows > through a proxy. Please explain the firewall configuration in which > the above technique will not work. > > -Tiru > > *From:*tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Simon Perreault > *Sent:* Monday, December 01, 2014 8:45 PM > *To:* Victor Pascual Avila > *Cc:* draft-chenxin-behave-turn-websocket@tools.ietf.org; tram@ietf.org > *Subject:* Re: [tram] TURN over WebSocket > > On Mon, Dec 1, 2014 at 4:10 AM, Victor Pascual Avila > > wrote: > > Shall we create a new milestone for this? > > All, > > > Note that this question from Victor is intended for the working group. > The chairs are in listening mode! :) > > Simon > --------------020407030000090408090304 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Transparent proxying for example

Best regards
Sergio

On 01/12/2014 16:49, Tirumaleswar Reddy (tireddy) wrote:

https://tools.ietf.org/html/draft-ietf-httpbis-tunnel-protocol-00 already solves the problem with firewall only permitting HTTP(S) flows through a proxy. Please explain the firewall configuration in which the above technique will not work.

 

-Tiru

 

From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Simon Perreault
Sent: Monday, December 01, 2014 8:45 PM
To: Victor Pascual Avila
Cc: draft-chenxin-behave-turn-websocket@tools.ietf.org; tram@ietf.org
Subject: Re: [tram] TURN over WebSocket

 

On Mon, Dec 1, 2014 at 4:10 AM, Victor Pascual Avila <victor.pascual.avila@gmail.com> wrote:

Shall we create a new milestone for this?

 

All,


Note that this question from Victor is intended for the working group. The chairs are in listening mode! :)

 

Simon


--------------020407030000090408090304-- From nobody Mon Dec 1 09:06:52 2014 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 36D4E1A700C for ; Mon, 1 Dec 2014 09:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 B5VcEn3QYYjq for ; Mon, 1 Dec 2014 09:06:33 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 455121A701D for ; Mon, 1 Dec 2014 09:06:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12066; q=dns/txt; s=iport; t=1417453563; x=1418663163; h=from:to:cc:subject:date:message-id:mime-version; bh=LL/vC+jmbSJjsmkXcXt2ZQmInTukpkig9oQDcEFKW/g=; b=i4g3Y5q8+HWzQ91d8iU/SFZKsdW4xVRs24LEPgX/Oi+xVlNQZ0bZPDuj /Hp8vZN6+eWmRwjfURSQZKTd+a+kq2NmIQOuGyFkevvG9H8FXMexSpK/3 vXI9WrvOrq/4Nx/gJ81r6HpEIdQeMIaJqvTpqUFaiw+rgBFhPIL039mKc k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkIAIyffFStJA2G/2dsb2JhbABbgkJEUVgEgwHBOIIohk4CHHoWAQEBAQF9hAIBAQEEIwpMEgEIEQQBAQsdAwIEHxEUCQkBBAENBQiIIwMSDb4ZkC0NhhwBAQEBAQEBAQEBAQEBAQEBAQEBAQETBI5DggcWFwQGgnY0gR8FkQWETYR0gy+DO4oMhk6De28BgUWBAQEBAQ X-IronPort-AV: E=Sophos;i="5.07,494,1413244800"; d="scan'208,217";a="101523414" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP; 01 Dec 2014 17:06:02 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sB1H614c031806 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Dec 2014 17:06:01 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.204]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Mon, 1 Dec 2014 11:06:01 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Sergio Garcia Murillo , Simon Perreault , Victor Pascual Avila Thread-Topic: [tram] TURN over WebSocket Thread-Index: AdANiRFG6X70S29YQzixzirX+f0pqQ== Date: Mon, 1 Dec 2014 17:06:00 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.67.53] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A2837AB1Fxmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/j4NhxQpV7e69c1RRbpifeqtv41M Cc: "draft-chenxin-behave-turn-websocket@tools.ietf.org" , "tram@ietf.org" Subject: Re: [tram] TURN over WebSocket 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, 01 Dec 2014 17:06:36 -0000 --_000_913383AAA69FF945B8F946018B75898A2837AB1Fxmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBIVFRQYmlzIFdHIGlzIGRpc2N1c3NpbmcgdGhhdCBleHBsaWNpdCBwcm94eSBpcyBw cmVmZXJyZWQgb3ZlciB0cmFuc3BhcmVudCBwcm94eS4NCg0KLVRpcnUNCg0KRnJvbTogU2VyZ2lv IEdhcmNpYSBNdXJpbGxvIFttYWlsdG86c2VyZ2lvLmdhcmNpYS5tdXJpbGxvQGdtYWlsLmNvbV0N ClNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgMDEsIDIwMTQgOToyNyBQTQ0KVG86IFRpcnVtYWxlc3dh ciBSZWRkeSAodGlyZWRkeSk7IFNpbW9uIFBlcnJlYXVsdDsgVmljdG9yIFBhc2N1YWwgQXZpbGEN CkNjOiBkcmFmdC1jaGVueGluLWJlaGF2ZS10dXJuLXdlYnNvY2tldEB0b29scy5pZXRmLm9yZzsg dHJhbUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt0cmFtXSBUVVJOIG92ZXIgV2ViU29ja2V0DQoN ClRyYW5zcGFyZW50IHByb3h5aW5nIGZvciBleGFtcGxlDQoNCkJlc3QgcmVnYXJkcw0KU2VyZ2lv DQoNCk9uIDAxLzEyLzIwMTQgMTY6NDksIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgd3Jv dGU6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1odHRwYmlzLXR1bm5l bC1wcm90b2NvbC0wMCBhbHJlYWR5IHNvbHZlcyB0aGUgcHJvYmxlbSB3aXRoIGZpcmV3YWxsIG9u bHkgcGVybWl0dGluZyBIVFRQKFMpIGZsb3dzIHRocm91Z2ggYSBwcm94eS4gUGxlYXNlIGV4cGxh aW4gdGhlIGZpcmV3YWxsIGNvbmZpZ3VyYXRpb24gaW4gd2hpY2ggdGhlIGFib3ZlIHRlY2huaXF1 ZSB3aWxsIG5vdCB3b3JrLg0KDQotVGlydQ0KDQpGcm9tOiB0cmFtIFttYWlsdG86dHJhbS1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU2ltb24gUGVycmVhdWx0DQpTZW50OiBNb25kYXks IERlY2VtYmVyIDAxLCAyMDE0IDg6NDUgUE0NClRvOiBWaWN0b3IgUGFzY3VhbCBBdmlsYQ0KQ2M6 IGRyYWZ0LWNoZW54aW4tYmVoYXZlLXR1cm4td2Vic29ja2V0QHRvb2xzLmlldGYub3JnPG1haWx0 bzpkcmFmdC1jaGVueGluLWJlaGF2ZS10dXJuLXdlYnNvY2tldEB0b29scy5pZXRmLm9yZz47IHRy YW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3RyYW1dIFRV Uk4gb3ZlciBXZWJTb2NrZXQNCg0KT24gTW9uLCBEZWMgMSwgMjAxNCBhdCA0OjEwIEFNLCBWaWN0 b3IgUGFzY3VhbCBBdmlsYSA8dmljdG9yLnBhc2N1YWwuYXZpbGFAZ21haWwuY29tPG1haWx0bzp2 aWN0b3IucGFzY3VhbC5hdmlsYUBnbWFpbC5jb20+PiB3cm90ZToNClNoYWxsIHdlIGNyZWF0ZSBh IG5ldyBtaWxlc3RvbmUgZm9yIHRoaXM/DQoNCkFsbCwNCg0KTm90ZSB0aGF0IHRoaXMgcXVlc3Rp b24gZnJvbSBWaWN0b3IgaXMgaW50ZW5kZWQgZm9yIHRoZSB3b3JraW5nIGdyb3VwLiBUaGUgY2hh aXJzIGFyZSBpbiBsaXN0ZW5pbmcgbW9kZSEgOikNCg0KU2ltb24NCg0K --_000_913383AAA69FF945B8F946018B75898A2837AB1Fxmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29s b3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0 YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uQmFsbG9vblRleHRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUx OQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgSFRUUGJpcyBXRyBp cyBkaXNjdXNzaW5nIHRoYXQgZXhwbGljaXQgcHJveHkgaXMgcHJlZmVycmVkIG92ZXIgdHJhbnNw YXJlbnQgcHJveHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tVGlydTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gU2VyZ2lv IEdhcmNpYSBNdXJpbGxvIFttYWlsdG86c2VyZ2lvLmdhcmNpYS5tdXJpbGxvQGdtYWlsLmNvbV0N Cjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIERlY2VtYmVyIDAxLCAyMDE0IDk6MjcgUE08YnI+ DQo8Yj5Ubzo8L2I+IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk7IFNpbW9uIFBlcnJlYXVs dDsgVmljdG9yIFBhc2N1YWwgQXZpbGE8YnI+DQo8Yj5DYzo8L2I+IGRyYWZ0LWNoZW54aW4tYmVo YXZlLXR1cm4td2Vic29ja2V0QHRvb2xzLmlldGYub3JnOyB0cmFtQGlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbdHJhbV0gVFVSTiBvdmVyIFdlYlNvY2tldDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UcmFuc3BhcmVudCBwcm94 eWluZyBmb3IgZXhhbXBsZTxicj4NCjxicj4NCkJlc3QgcmVnYXJkczxicj4NClNlcmdpbzxicj4N Cjxicj4NCk9uIDAxLzEyLzIwMTQgMTY6NDksIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaHR0cGJpcy10dW5u ZWwtcHJvdG9jb2wtMDAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaHR0cGJpcy10dW5uZWwtcHJvdG9jb2wtMDA8L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4NCiBhbHJl YWR5IHNvbHZlcyB0aGUgcHJvYmxlbSB3aXRoIGZpcmV3YWxsIG9ubHkgcGVybWl0dGluZyBIVFRQ KFMpIGZsb3dzIHRocm91Z2ggYSBwcm94eS4gUGxlYXNlIGV4cGxhaW4gdGhlIGZpcmV3YWxsIGNv bmZpZ3VyYXRpb24gaW4gd2hpY2ggdGhlIGFib3ZlIHRlY2huaXF1ZSB3aWxsIG5vdCB3b3JrLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+LVRpcnU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4gdHJhbSBbPC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmciPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5tYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnPC9z cGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+XQ0KPGI+T24gQmVoYWxmIE9mIDwv Yj5TaW1vbiBQZXJyZWF1bHQ8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBEZWNlbWJlciAwMSwg MjAxNCA4OjQ1IFBNPGJyPg0KPGI+VG86PC9iPiBWaWN0b3IgUGFzY3VhbCBBdmlsYTxicj4NCjxi PkNjOjwvYj4gPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkcmFmdC1jaGVueGluLWJlaGF2ZS10dXJu LXdlYnNvY2tldEB0b29scy5pZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmRy YWZ0LWNoZW54aW4tYmVoYXZlLXR1cm4td2Vic29ja2V0QHRvb2xzLmlldGYub3JnPC9zcGFuPjwv YT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Ow0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0 cmFtQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+dHJhbUBpZXRmLm9yZzwv c3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW3RyYW1dIFRVUk4gb3ZlciBXZWJTb2NrZXQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIERlYyAx LCAyMDE0IGF0IDQ6MTAgQU0sIFZpY3RvciBQYXNjdWFsIEF2aWxhICZsdDs8YSBocmVmPSJtYWls dG86dmljdG9yLnBhc2N1YWwuYXZpbGFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmljdG9y LnBhc2N1YWwuYXZpbGFAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5TaGFsbCB3ZSBjcmVhdGUgYSBuZXcgbWlsZXN0b25lIGZvciB0 aGlzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5BbGwsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N Ck5vdGUgdGhhdCB0aGlzIHF1ZXN0aW9uIGZyb20gVmljdG9yIGlzIGludGVuZGVkIGZvciB0aGUg d29ya2luZyBncm91cC4gVGhlIGNoYWlycyBhcmUgaW4gbGlzdGVuaW5nIG1vZGUhIDopPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNpbW9uPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_913383AAA69FF945B8F946018B75898A2837AB1Fxmbrcdx10ciscoc_-- From nobody Mon Dec 1 12:46:23 2014 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 7F4921A87E0 for ; Mon, 1 Dec 2014 12:46:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, 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 UL5FG-Zb0aOb for ; Mon, 1 Dec 2014 12:46:17 -0800 (PST) Received: from server209.appriver.com (server209f.appriver.com [8.31.233.121]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D81A71A7004 for ; Mon, 1 Dec 2014 12:46:16 -0800 (PST) X-Note-AR-ScanTimeLocal: 12/1/2014 3:46:13 PM X-Policy: vidyo.com - vidyo.com X-Policy: vidyo.com - vidyo.com X-Policy: vidyo.com - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: SecureTide Build: 11/21/2014 10:58:18 PM UTC X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-342/SG:2 12/1/2014 3:45:32 PM X-GBUdb-Analysis: 0, 67.231.157.197, Ugly c=0.690766 p=-0.953374 Source White X-Signature-Violations: 0-0-0-3548-c X-Note-419: 0 ms. Fail:0 Chk:1328 of 1328 total X-Note: SCH-CT/SI:0-1328/SG:1 12/1/2014 3:46:11 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL->UNITED STATES-> X-Note-Sending-IP: 67.231.157.197 X-Note-Reverse-DNS: mx0b-00198e01.pphosted.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G251 G252 G253 G254 G258 G259 G371 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [67.231.157.197] (HELO mx0b-00198e01.pphosted.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTP id 31048792; Mon, 01 Dec 2014 15:46:13 -0500 Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.14.7/8.14.7) with SMTP id sB1KidxY002855; Mon, 1 Dec 2014 15:46:13 -0500 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 1qn2nkq84w-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 01 Dec 2014 15:46:13 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Mon, 1 Dec 2014 14:46:13 -0600 From: Jonathan Lennox To: Victor Pascual Avila Thread-Topic: [tram] TURN over WebSocket Thread-Index: AQHQDYZvgoYU7Jer0kaRa9GealJqA5x7mTcA Date: Mon, 1 Dec 2014 20:46:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2014-12-01_04:2014-12-01,2014-12-01,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1412010197 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/HOMmeZUtIN3AV0l5MSyLIvEVTrU Cc: "draft-chenxin-behave-turn-websocket@tools.ietf.org" , "tram@ietf.org" Subject: Re: [tram] TURN over WebSocket 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, 01 Dec 2014 20:46:21 -0000 I am in favor of adopting this. On Dec 1, 2014, at 4:10 AM, Victor Pascual Avila wrote: > Hi, >=20 > last year we put together this I-D: > https://tools.ietf.org/html/draft-chenxin-behave-turn-websocket-01 >=20 > We have recently received some emails indicating there's interest in > reviving this work. >=20 > Use case: only traffic on ports 80 and 443 are allowed and the > need/requirement to run both HTTPS and TURN servers on port 443, on > the same IP address. >=20 > Shall we create a new milestone for this? >=20 > Cheers, > -Victor >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram >=20 From nobody Mon Dec 1 12:49:11 2014 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 041631A90B9 for ; Mon, 1 Dec 2014 12:49:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, 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 f7s772yYizCB for ; Mon, 1 Dec 2014 12:49:06 -0800 (PST) Received: from server209.appriver.com (server209c.appriver.com [8.31.233.118]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7ACA1A90B6 for ; Mon, 1 Dec 2014 12:49:05 -0800 (PST) X-Note-AR-ScanTimeLocal: 12/1/2014 3:49:03 PM X-Policy: vidyo.com - vidyo.com X-Policy: vidyo.com - vidyo.com X-Policy: vidyo.com - vidyo.com X-Policy: vidyo.com - vidyo.com X-Policy: vidyo.com - vidyo.com X-Policy: Too many policies to list X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: SecureTide Build: 11/21/2014 10:58:18 PM UTC X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-880/SG:5 12/1/2014 3:48:32 PM X-GBUdb-Analysis: 0, 67.231.157.197, Ugly c=0.691144 p=-0.953545 Source White X-Signature-Violations: 0-0-0-17142-c X-Note-419: 15.6269 ms. Fail:1 Chk:1328 of 1328 total X-Note: SCH-CT/SI:1-1328/SG:1 12/1/2014 3:48:51 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL->UNITED STATES-> X-Note-Sending-IP: 67.231.157.197 X-Note-Reverse-DNS: mx0b-00198e01.pphosted.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G251 G252 G253 G254 G258 G259 G371 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [67.231.157.197] (HELO mx0b-00198e01.pphosted.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTP id 31050174; Mon, 01 Dec 2014 15:49:02 -0500 Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.14.7/8.14.7) with SMTP id sB1KjagC003588; Mon, 1 Dec 2014 15:49:03 -0500 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 1qn2nkq864-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 01 Dec 2014 15:49:02 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Mon, 1 Dec 2014 14:49:02 -0600 From: Jonathan Lennox To: "Tirumaleswar Reddy (tireddy)" Thread-Topic: [tram] TURN over WebSocket Thread-Index: AdANiRFGgoYU7Jer0kaRa9GealJqAwAUXYoA Date: Mon, 1 Dec 2014 20:49:02 +0000 Message-ID: <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_78A0E6E23F1D4F02A552688AACCBE683vidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2014-12-01_04:2014-12-01,2014-12-01,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1412010197 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/YhuRYVvmSWUqSt4ENeYr_94g86E Cc: "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Simon Perreault , Sergio Garcia Murillo , "tram@ietf.org" , Victor Pascual Avila Subject: Re: [tram] TURN over WebSocket 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, 01 Dec 2014 20:49:10 -0000 --_000_78A0E6E23F1D4F02A552688AACCBE683vidyocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I prefer explicit proxies too. Unfortunately, many networks where my custo= mers are located deploy transparent proxies anyway. On Dec 1, 2014, at 12:06 PM, Tirumaleswar Reddy (tireddy) > wrote: I think HTTPbis WG is discussing that explicit proxy is preferred over tran= sparent proxy. -Tiru From: Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com] Sent: Monday, December 01, 2014 9:27 PM To: Tirumaleswar Reddy (tireddy); Simon Perreault; Victor Pascual Avila Cc: draft-chenxin-behave-turn-websocket@tools.ietf.org; tram@ietf.org Subject: Re: [tram] TURN over WebSocket Transparent proxying for example Best regards Sergio On 01/12/2014 16:49, Tirumaleswar Reddy (tireddy) wrote: https://tools.ietf.org/html/draft-ietf-httpbis-tunnel-protocol-00 already s= olves the problem with firewall only permitting HTTP(S) flows through a pro= xy. Please explain the firewall configuration in which the above technique = will not work. -Tiru From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Simon Perreault Sent: Monday, December 01, 2014 8:45 PM To: Victor Pascual Avila Cc: draft-chenxin-behave-turn-websocket@tools.ietf.org; tram@ietf.org Subject: Re: [tram] TURN over WebSocket On Mon, Dec 1, 2014 at 4:10 AM, Victor Pascual Avila > wrote: Shall we create a new milestone for this? All, Note that this question from Victor is intended for the working group. The = chairs are in listening mode! :) Simon _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram --_000_78A0E6E23F1D4F02A552688AACCBE683vidyocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
I prefer explicit proxies too.  Unfortunately, many networks wher= e my customers are located deploy transparent proxies anyway.

On Dec 1, 2014, at 12:06 PM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:

I think HTTPbis WG is discussing that explicit proxy is pr= eferred over transparent proxy.
 
-Tiru
 
From: Sergio Garcia Murillo [mailto:s= ergio.garcia.murillo@gmail.com]&n= bsp;
Sent: Monday, Dece= mber 01, 2014 9:27 PM
To: Tirumaleswar R= eddy (tireddy); Simon Perreault; Victor Pascual Avila
Cc: draft-chenxin-behave-turn-websocket@tools= .ietf.org; tram@ietf.org
Subject: Re: [tram= ] TURN over WebSocket
 
Transparent proxying for example

Best regards
Sergio

On 01/12/2014 16:49, Tirumaleswar Reddy (tireddy) wrote:
https://tools.ietf.org/html= /draft-ietf-httpbis-tunnel-protocol-00 already solves the problem with firewall only permitting HTTP(S) flows through a p= roxy. Please explain the firewall configuration in which the above techniqu= e will not work.
 
-Tiru
 
From:<= /span> tram [= mailto:tram-bounces@ietf.org] = On Behalf Of Simon Perr= eault
Sent: Monday, Dece= mber 01, 2014 8:45 PM
To: Victor Pascual= Avila
Cc: draft-chenxin-behave-turn-websocket@tools.i= etf.org; tram@= ietf.org
Subject: Re: [tram= ] TURN over WebSocket
 
On Mon, Dec 1, 2014 at 4:10 AM, Victor Pascual Avila <victor.pascual.avila@gmail.com> wrote:
Shall we create a new milestone for this?
 
All,

Note that this question from Victor is intended for the working group. The = chairs are in listening mode! :)
 
Simon
 
_______________________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram=

--_000_78A0E6E23F1D4F02A552688AACCBE683vidyocom_-- From nobody Mon Dec 1 13:05:55 2014 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 B06E81A9129 for ; Mon, 1 Dec 2014 13:05:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.749 X-Spam-Level: X-Spam-Status: No, score=-0.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, 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 P2VRP-arL7At for ; Mon, 1 Dec 2014 13:05:44 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFC631A9124 for ; Mon, 1 Dec 2014 13:05:43 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id ey11so11947878pad.10 for ; Mon, 01 Dec 2014 13:05:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=LveAYtMBjPsj9U3Qogqo46xhf6WS8fmtUso/GMoNQ48=; b=coDkrEcAnvB8vE2gdFIiwVBYpoOOo2+MiSnLr8svQh7BEB5PtbFcX8prbCKVmQKBq9 HVXMuRe7P1o2bt1jrBwx1xFZTAOrQPttFyKnbJ1E7bXVmETA6qkg0jSqiOsSHFS5bxXm 8wZtlbENV0I0BCJlJ+kC6UdtoslmpYkOCw14REoibYX7B3zvZWiiuQmTAMhJOyeibZnx B6ElrFHIaCFhOrXi25fKu9wtRU3ryIh/6ogz4POJWkxGWXBNehL9Q/uqOOWk7B+7bRp4 gKib+nOZj+52wdvF5pUBNZunuIl2lgpodNupAX57xXla9kr9/k5z2UfJu+EfB8LDZymg vGoQ== X-Received: by 10.68.211.7 with SMTP id my7mr104954262pbc.115.1417467932676; Mon, 01 Dec 2014 13:05:32 -0800 (PST) Received: from [100.113.213.82] (188.sub-70-211-70.myvzw.com. [70.211.70.188]) by mx.google.com with ESMTPSA id b4sm18374081pdm.82.2014.12.01.13.05.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Dec 2014 13:05:31 -0800 (PST) References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> Mime-Version: 1.0 (1.0) In-Reply-To: <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> Content-Type: multipart/alternative; boundary=Apple-Mail-AF5921B5-D19E-4F6D-BBE5-70C8F13718B1 Content-Transfer-Encoding: 7bit Message-Id: <6B7FC4D9-AEAD-4D08-852D-DDCF95D4278A@gmail.com> X-Mailer: iPhone Mail (11D201) From: Oleg Moskalenko Date: Mon, 1 Dec 2014 13:05:20 -0800 To: Jonathan Lennox Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Uee7nFf7XD7RSQeUDzlWN1ii3_s Cc: "tram@ietf.org" , Sergio Garcia Murillo , Victor Pascual Avila , "Tirumaleswar Reddy \(tireddy\)" , "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Simon Perreault Subject: Re: [tram] TURN over WebSocket 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, 01 Dec 2014 21:05:48 -0000 --Apple-Mail-AF5921B5-D19E-4F6D-BBE5-70C8F13718B1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Yeah... That is the main problem. Sent from my iPhone > On Dec 1, 2014, at 12:49 PM, Jonathan Lennox wrote: >=20 > I prefer explicit proxies too. Unfortunately, many networks where my cust= omers are located deploy transparent proxies anyway. >=20 >> On Dec 1, 2014, at 12:06 PM, Tirumaleswar Reddy (tireddy) wrote: >>=20 >> I think HTTPbis WG is discussing that explicit proxy is preferred over tr= ansparent proxy. >> =20 >> -Tiru >> =20 >> From: Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com]=20 >> Sent: Monday, December 01, 2014 9:27 PM >> To: Tirumaleswar Reddy (tireddy); Simon Perreault; Victor Pascual Avila >> Cc: draft-chenxin-behave-turn-websocket@tools.ietf.org; tram@ietf.org >> Subject: Re: [tram] TURN over WebSocket >> =20 >> Transparent proxying for example >>=20 >> Best regards >> Sergio >>=20 >> On 01/12/2014 16:49, Tirumaleswar Reddy (tireddy) wrote: >> https://tools.ietf.org/html/draft-ietf-httpbis-tunnel-protocol-00 already= solves the problem with firewall only permitting HTTP(S) flows through a pr= oxy. Please explain the firewall configuration in which the above technique w= ill not work. >> =20 >> -Tiru >> =20 >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Simon Perreault >> Sent: Monday, December 01, 2014 8:45 PM >> To: Victor Pascual Avila >> Cc: draft-chenxin-behave-turn-websocket@tools.ietf.org; tram@ietf.org >> Subject: Re: [tram] TURN over WebSocket >> =20 >> On Mon, Dec 1, 2014 at 4:10 AM, Victor Pascual Avila wrote: >> Shall we create a new milestone for this? >> =20 >> All, >>=20 >> Note that this question from Victor is intended for the working group. Th= e chairs are in listening mode! :) >> =20 >> Simon >> =20 >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram --Apple-Mail-AF5921B5-D19E-4F6D-BBE5-70C8F13718B1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Yeah... That is the main problem.

Sent from my iPhone

On Dec 1, 2014, at 12:49 PM, Jonathan Lennox <jonathan@vidyo.com> wrote:

I prefer explicit proxies too.  Unfortunately, many networks where my customers are located deploy transparent proxies anyway.

On Dec 1, 2014, at 12:06 PM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:

I think HTTPbis WG is discussing that explicit proxy is preferred over transparent proxy.
 
-Tiru
 
From: Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com] 
Sent: Monday, December 01, 2014 9:27 PM
To: Tirumaleswar Reddy (tireddy); Simon Perreault; Victor Pascual Avila
Cc: draft-chenxin-behave-turn-websocket@tools.ietf.org; tram@ietf.org
Subject: Re: [tram] TURN over WebSocket
 
Transparent proxying for example

Best regards
Sergio

On 01/12/2014 16:49, Tirumaleswar Reddy (tireddy) wrote:
https://tools.ietf.org/html/draft-ietf-httpbis-tunnel-protocol-00 already solves the problem with firewall only permitting HTTP(S) flows through a proxy. Please explain the firewall configuration in which the above technique will not work.
 
-Tiru
 
From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Simon Perreault
Sent: Monday, December 01, 2014 8:45 PM
To: Victor Pascual Avila
Cc: draft-chenxin-behave-turn-websocket@tools.ietf.org; tram@ietf.org
Subject: Re: [tram] TURN over WebSocket
 
On Mon, Dec 1, 2014 at 4:10 AM, Victor Pascual Avila <victor.pascual.avila@gmail.com> wrote:
Shall we create a new milestone for this?
 
All,

Note that this question from Victor is intended for the working group. The chairs are in listening mode! :)
 
Simon
 
_______________________________________________
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
--Apple-Mail-AF5921B5-D19E-4F6D-BBE5-70C8F13718B1-- From nobody Mon Dec 1 14:46:30 2014 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 457CE1ACD54 for ; Mon, 1 Dec 2014 14:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qM2Mq21hc2PO for ; Mon, 1 Dec 2014 14:46:26 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 908421ACD44 for ; Mon, 1 Dec 2014 14:46:18 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B9E892850F; Mon, 1 Dec 2014 22:46:17 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id A3EAE2850A; Mon, 1 Dec 2014 22:46:17 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id A06D480040; Mon, 1 Dec 2014 22:46:17 +0000 (GMT) Message-ID: <547CEFB9.105@akamai.com> Date: Mon, 01 Dec 2014 17:46:17 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Victor Pascual Avila , "tram@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/kf6QQPusNCBO_h-jeVTDiKcUd60 Cc: "draft-chenxin-behave-turn-websocket@tools.ietf.org" Subject: Re: [tram] TURN over WebSocket 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, 01 Dec 2014 22:46:28 -0000 Hi Victor, Can't ALPN be used to allow both servers to run on port 443? What justifies the greater complexity of using WSS? Thanks, --Brandon On 12/01/2014 04:10 AM, Victor Pascual Avila wrote: > Hi, > > last year we put together this I-D: > https://tools.ietf.org/html/draft-chenxin-behave-turn-websocket-01 > > We have recently received some emails indicating there's interest in > reviving this work. > > Use case: only traffic on ports 80 and 443 are allowed and the > need/requirement to run both HTTPS and TURN servers on port 443, on > the same IP address. > > Shall we create a new milestone for this? > > Cheers, > -Victor > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Mon Dec 1 14:51:06 2014 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 9F4581ACD95 for ; Mon, 1 Dec 2014 14:51:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nance3uGm0-o for ; Mon, 1 Dec 2014 14:51:03 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA981ACD08 for ; Mon, 1 Dec 2014 14:51:02 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B24F7475B1; Mon, 1 Dec 2014 22:51:01 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 9BF91475AD; Mon, 1 Dec 2014 22:51:01 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 773A4202E; Mon, 1 Dec 2014 22:51:00 +0000 (GMT) Message-ID: <547CF0D4.1010006@akamai.com> Date: Mon, 01 Dec 2014 17:51:00 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Oleg Moskalenko , Jonathan Lennox References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <6B7FC4D9-AEAD-4D08-852D-DDCF95D4278A@gmail.com> In-Reply-To: <6B7FC4D9-AEAD-4D08-852D-DDCF95D4278A@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/T3bF-mODuDf9JGgUN3oG6cjSqMI Cc: "tram@ietf.org" , Sergio Garcia Murillo , Victor Pascual Avila , "Tirumaleswar Reddy \(tireddy\)" , "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Simon Perreault Subject: Re: [tram] TURN over WebSocket 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, 01 Dec 2014 22:51:05 -0000 Does this websockets approach actually work for those customers who are behind transparent proxies? And is it intentional that it works? Or will it be disabled once someone notices that their transparent proxy is being misused (in their opinion)? I'm just curious whether someone has seen this approach work reliably on the Internet. I'm always a bit dubious of methods that look like they're intended to circumvent someone's security architecture (whether or not that's the true intent). --Brandon On 12/01/2014 04:05 PM, Oleg Moskalenko wrote: > Yeah... That is the main problem. > > Sent from my iPhone > > On Dec 1, 2014, at 12:49 PM, Jonathan Lennox > wrote: > >> I prefer explicit proxies too. Unfortunately, many networks where my >> customers are located deploy transparent proxies anyway. >> >> On Dec 1, 2014, at 12:06 PM, Tirumaleswar Reddy (tireddy) >> > wrote: >> >>> I think HTTPbis WG is discussing that explicit proxy is preferred >>> over transparent proxy. >>> -Tiru >>> *From:*Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com] >>> *Sent:*Monday, December 01, 2014 9:27 PM >>> *To:*Tirumaleswar Reddy (tireddy); Simon Perreault; Victor Pascual Avila >>> *Cc:*draft-chenxin-behave-turn-websocket@tools.ietf.org >>> ;tram@ietf.org >>> >>> *Subject:*Re: [tram] TURN over WebSocket >>> Transparent proxying for example >>> >>> Best regards >>> Sergio >>> >>> On 01/12/2014 16:49, Tirumaleswar Reddy (tireddy) wrote: >>> >>> https://tools.ietf.org/html/draft-ietf-httpbis-tunnel-protocol-00already >>> solves the problem with firewall only permitting HTTP(S) flows >>> through a proxy. Please explain the firewall configuration in >>> which the above technique will not work. >>> -Tiru >>> *From:*tram [mailto:tram-bounces@ietf.org]*On Behalf Of*Simon >>> Perreault >>> *Sent:*Monday, December 01, 2014 8:45 PM >>> *To:*Victor Pascual Avila >>> *Cc:*draft-chenxin-behave-turn-websocket@tools.ietf.org >>> ;tram@ietf.org >>> >>> *Subject:*Re: [tram] TURN over WebSocket >>> On Mon, Dec 1, 2014 at 4:10 AM, Victor Pascual Avila >>> >> > wrote: >>> Shall we create a new milestone for this? >>> All, >>> >>> Note that this question from Victor is intended for the working >>> group. The chairs are in listening mode! :) >>> Simon >>> >>> _______________________________________________ >>> 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; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Mon Dec 1 20:29:20 2014 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 1506D1A00E6 for ; Mon, 1 Dec 2014 20:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 ey3fSXPoITqQ for ; Mon, 1 Dec 2014 20:29:17 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 315321A00D6 for ; Mon, 1 Dec 2014 20:29:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3035; q=dns/txt; s=iport; t=1417494557; x=1418704157; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=bEbqBSe7kAV6CCcu7hR3JGeJuduG8FYuXSGn1IzV5Sk=; b=IgxXEaUFmuuuLhUSLciXmrBcdI2xPiSyOBkfyiKl+NsXvEHHxcm/S0Dq BAokQo5IWt5Jq8ELh3eLIMTrTk2ThjKoLGpFB9jaJBfiYdNHDI1u6WQ48 8UvyOYdxObJnn0gTIJzWKw35SExBcxFWwC51HWQnDz23OKLM7OgfoKLzV M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFAJU/fVStJV2S/2dsb2JhbABSCYMGUVgExE+CHAqGHwKBHBYBAQEBAX2EAgEBAQQBAQE3NAMUBgEIEQQBAQsUCS4LFAkJAQQBEgiIOA3VVQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEkBQqPoMjgR8FkGGgRoN7b4FGgQEBAQE X-IronPort-AV: E=Sophos;i="5.07,498,1413244800"; d="scan'208";a="376760021" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-3.cisco.com with ESMTP; 02 Dec 2014 04:29:16 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sB24TGbc002654 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Dec 2014 04:29:16 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.204]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Mon, 1 Dec 2014 22:29:16 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , "tram@ietf.org" Thread-Topic: [tram] STUN Origin Security Considerations Thread-Index: AdAN6ITObaT++RtRSz+CGr248HBOuQ== Date: Tue, 2 Dec 2014 04:29:15 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2837B05B@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.52.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/bhaULzSQhz8GVxB5EmjAM6tRBoc Subject: Re: [tram] STUN Origin Security Considerations 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: Tue, 02 Dec 2014 04:29:19 -0000 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams > Sent: Wednesday, November 19, 2014 6:55 AM > To: tram@ietf.org > Subject: [tram] STUN Origin Security Considerations >=20 > Hi all, >=20 > In the meeting, I promised to follow up on this with a note to the list. >=20 > Text in the current draft states the following: >=20 > The STUN ORIGIN attribute also has privacy implications in that the > origin information is shared with a STUN or TURN server which > otherwise might not know this information. This information could be > used to track usage of real-time communication services. A STUN or > TURN server will always know the public IP address of each user, but > the ORIGIN attribute provides more information about which service or > provider is being used. The particular STUN and TURN servers used > are selected by the real-time communications service provider (i.e. > the web provider for WebRTC or the SIP or XMPP service provider). In > addition, they are usually also run by the same provider, or by a > trusted partner, especially for TURN. However, a service or provider > using a public STUN server needs to recognize that the operator of > the public STUN server will learn the identity of the service or > provider through this extension. >=20 > The last three sentences give the impression that the privacy concern doe= s > not apply to TURN servers, only to STUN servers, because TURN servers are > more likely to be run by the application provider or a trusted partner of= the > application provider. This might not be true for auto-discovered, public,= and > other types of untrusted 3rd party TURN servers. The draft refers to "pub= lic > STUN server" privacy implications, but I think the language could be > broadened to cover all untrusted 3rd party relay servers. >=20 > I propose the following minor modifications to the text, which I think cl= arify > the intent. My changes are inclosed in [ ]. >=20 > The particular STUN and TURN servers used are [usually] selected by > the real-time communications provider ... >=20 > However, a service or provider using an [untrusted third party] STUN > [or TURN] server needs to recognize that the operator of the > [third party] STUN [or TURN] server will learn the identity of the > service or provider through this extension. >=20 > Does this seem reasonable ? Yes, draft-patil-tram-turn-serv-selection in the selection criteria discuss= es that client if discovers multiple TURN servers then it should prefer a T= URN server whose authenticity can be ascertained. -Tiru >=20 > --Brandon >=20 > -- > Brandon Williams; Senior Principal Software Engineer Emerging Products > Engineering; Akamai Technologies Inc. >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Mon Dec 1 20:45:13 2014 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 B7B2F1A00D8 for ; Mon, 1 Dec 2014 20:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 TRAVTb7rMpG8 for ; Mon, 1 Dec 2014 20:45:09 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80EF61A00D6 for ; Mon, 1 Dec 2014 20:45:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14910; q=dns/txt; s=iport; t=1417495509; x=1418705109; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Ox9FVgniNuSel3ehS0XdJtRquuDinXUvMuz0jhy1OMY=; b=PsFWLtFvCZBSxlUH2Gn+WZargHwdZlblVLT9eb5/H+w3UF42zXsdiI7N 7xNf6nd4RlxAxhsubMz4s3/Tm4mTdj4yVr9EHfSo+PnKkNhDRN6Ice8Uf smig8jQvdSFkpVv9VZ28SjpiKdJFfFHTx3L1jh/UE8U5XUI5Qe022o1HU A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmMFAOhCfVStJV2T/2dsb2JhbABbgkJEUVgExFQ8gWABC4YdAoEdFgEBAQEBfYQCAQEBBAEBASpBCxACAQgRBAEBCx0HIQYLFAkIAQEEDgUIiCMDEg3PIg2GJQEBAQEBAQEBAQEBAQEBAQEBAQEBAReOOIIGLQQGAYMpgR8FkGGEPoRogys6gn6JeIZFg3tvAYFFgQEBAQE X-IronPort-AV: E=Sophos;i="5.07,498,1413244800"; d="scan'208,217";a="376762145" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-3.cisco.com with ESMTP; 02 Dec 2014 04:45:08 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id sB24j86Z030914 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Dec 2014 04:45:08 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.204]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Mon, 1 Dec 2014 22:45:08 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Jonathan Lennox Thread-Topic: [tram] TURN over WebSocket Thread-Index: AdANiRFG6X70S29YQzixzirX+f0pqQAUXYoAAAPQ0HA= Date: Tue, 2 Dec 2014 04:45:08 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> In-Reply-To: <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.52.41] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A2837B095xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/rtyrRdByWVDC1eJ9Upx3_qlR0C8 Cc: "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Simon Perreault , Sergio Garcia Murillo , "tram@ietf.org" , Victor Pascual Avila Subject: Re: [tram] TURN over WebSocket 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: Tue, 02 Dec 2014 04:45:12 -0000 --_000_913383AAA69FF945B8F946018B75898A2837B095xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, but the problem is transparent proxy acts as MIM (without the consent = of the user). http://tools.ietf.org/html/draft-nottingham-http-proxy-proble= m-00#section-6.1 discusses this issue. -Tiru From: Jonathan Lennox [mailto:jonathan@vidyo.com] Sent: Tuesday, December 02, 2014 2:19 AM To: Tirumaleswar Reddy (tireddy) Cc: Sergio Garcia Murillo; Simon Perreault; Victor Pascual Avila; draft-che= nxin-behave-turn-websocket@tools.ietf.org; tram@ietf.org Subject: Re: [tram] TURN over WebSocket I prefer explicit proxies too. Unfortunately, many networks where my custo= mers are located deploy transparent proxies anyway. On Dec 1, 2014, at 12:06 PM, Tirumaleswar Reddy (tireddy) > wrote: I think HTTPbis WG is discussing that explicit proxy is preferred over tran= sparent proxy. -Tiru From: Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com] Sent: Monday, December 01, 2014 9:27 PM To: Tirumaleswar Reddy (tireddy); Simon Perreault; Victor Pascual Avila Cc: draft-chenxin-behave-turn-websocket@tools.ietf.org; tram@ietf.org Subject: Re: [tram] TURN over WebSocket Transparent proxying for example Best regards Sergio On 01/12/2014 16:49, Tirumaleswar Reddy (tireddy) wrote: https://tools.ietf.org/html/draft-ietf-httpbis-tunnel-protocol-00 already s= olves the problem with firewall only permitting HTTP(S) flows through a pro= xy. Please explain the firewall configuration in which the above technique = will not work. -Tiru From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Simon Perreault Sent: Monday, December 01, 2014 8:45 PM To: Victor Pascual Avila Cc: draft-chenxin-behave-turn-websocket@tools.ietf.org; tram@ietf.org Subject: Re: [tram] TURN over WebSocket On Mon, Dec 1, 2014 at 4:10 AM, Victor Pascual Avila > wrote: Shall we create a new milestone for this? All, Note that this question from Victor is intended for the working group. The = chairs are in listening mode! :) Simon _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram --_000_913383AAA69FF945B8F946018B75898A2837B095xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, but the problem is t= ransparent proxy acts as MIM (without the consent of the user). http://tools.ietf.org/html/draft-nottingham-http-proxy-problem-00#section-6= .1 discusses this issue.

 <= /p>

-Tiru

 <= /p>

From: Jonathan= Lennox [mailto:jonathan@vidyo.com]
Sent: Tuesday, December 02, 2014 2:19 AM
To: Tirumaleswar Reddy (tireddy)
Cc: Sergio Garcia Murillo; Simon Perreault; Victor Pascual Avila; dr= aft-chenxin-behave-turn-websocket@tools.ietf.org; tram@ietf.org
Subject: Re: [tram] TURN over WebSocket

 

I prefer explicit proxies too.  Unfortunately, = many networks where my customers are located deploy transparent proxies any= way.

 

On Dec 1, 2014, at 12:06 PM, Tirumaleswar Reddy (tir= eddy) <tireddy@cisco.com> wr= ote:



I think HTTPbis WG is dis= cussing that explicit proxy is preferred over transparent proxy.

 <= /p>

-Tiru

 <= /p>

From: Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com] 
Sent: Monday, Dece= mber 01, 2014 9:27 PM
To: Tirumaleswar R= eddy (tireddy); Simon Perreault; Victor Pascual Avila
Cc: draft-chenxin-behave-turn-websocket@tools.ietf.org; tram@ietf.org
Subject: Re: [tram= ] TURN over WebSocket

 

Transparent proxying for example

Best regards
Sergio

On 01/12/2014 16:49, Tirumaleswar Reddy (tireddy) wrote:

https://tools.ietf.org/= html/draft-ietf-httpbis-tunnel-protocol-00 already solves the problem with firewall only permitting HTTP(S) flows through a p= roxy. Please explain the firewall configuration in which the above techniqu= e will not work.

 <= /p>

-Tiru

 <= /p>

From: tram [= mailto:tram-bounces@ietf.org] On Behalf Of Simon Perr= eault
Sent: Monday, Dece= mber 01, 2014 8:45 PM
To: Victor Pascual= Avila
Cc: draft-chenxin-behave-turn-websocket@tools.ietf.org= ; tram@ietf.org<= /a>
Subject: Re: [tram= ] TURN over WebSocket

 

 

All,


Note that this question from Victor is intended for the working group. The = chairs are in listening mode! :)

 

Simon

 

______________________________________= _________
tram mailing list
tram@ietf.org=
https://www.ietf.org/mailman/listinfo/tram

 

--_000_913383AAA69FF945B8F946018B75898A2837B095xmbrcdx10ciscoc_-- From nobody Tue Dec 2 01:36:19 2014 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 D706C1A1A1C for ; Tue, 2 Dec 2014 01:36:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, 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 ItCJoEJ14rjP for ; Tue, 2 Dec 2014 01:36:16 -0800 (PST) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91F691A19EF for ; Tue, 2 Dec 2014 01:36:14 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id n12so8159627wgh.8 for ; Tue, 02 Dec 2014 01:36:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=BwEpY8yiFPu3ZLKVwf871prV9TKP97N6X5CRZS+dyjE=; b=cXIwGQDOx2TB4GCxoM1vZdSZhCKIkcdq3GDoybcPMyHqRCE9MQ34Z1bb3gYaFDIWWe N8w1zNE8NInqjUKsYbPNItXEOiC5h/Fkt5V6XjLQr9IbTZxje5yydemiLjyoA8BdRaDk oNRWU6xrLd+0GqGoetE3mGeVjvvfRGpQ17xvh2NyWBpZaI88lTFQVimJh6EHn/S3Xpa0 MqPDYhaFLG7Qgtun8hd2gi9zPisEpe2craToXxqNA9ZUmaHs3DRYhEzSoGMVsaN7xxBH n+fuxXU6YLi6QTUq0IvMXkhj3yVSLFsVIp4Nl5oRRozE1RXYBoiRQQ1hCf/HISAEvbCH gZUA== X-Received: by 10.180.94.230 with SMTP id df6mr3681396wib.25.1417512973570; Tue, 02 Dec 2014 01:36:13 -0800 (PST) Received: from [192.168.1.37] (136.Red-81-39-109.dynamicIP.rima-tde.net. [81.39.109.136]) by mx.google.com with ESMTPSA id fk12sm11417586wic.6.2014.12.02.01.36.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Dec 2014 01:36:12 -0800 (PST) Message-ID: <547D880D.4030909@gmail.com> Date: Tue, 02 Dec 2014 10:36:13 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , Jonathan Lennox References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> Content-Type: multipart/alternative; boundary="------------070704010506010503070906" Archived-At: http://mailarchive.ietf.org/arch/msg/tram/4BhCra9g0hMbQzahXESPSQOxDkE Cc: "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Simon Perreault , Victor Pascual Avila , "tram@ietf.org" Subject: Re: [tram] TURN over WebSocket 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: Tue, 02 Dec 2014 09:36:18 -0000 This is a multi-part message in MIME format. --------------070704010506010503070906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit More arguments in favor of adopting this draft. If transparent proxies are considered MITM, then there should be no objections about bypassing any IT security mechanism. And we will allow webrtc to work on an scenario that currently doesn't work. Best regards Sergio On 02/12/2014 5:45, Tirumaleswar Reddy (tireddy) wrote: > > Yes, but the problem is transparent proxy acts as MIM (without the > consent of the user). > http://tools.ietf.org/html/draft-nottingham-http-proxy-problem-00#section-6.1 > discusses this issue. > > -Tiru > > *From:*Jonathan Lennox [mailto:jonathan@vidyo.com] > *Sent:* Tuesday, December 02, 2014 2:19 AM > *To:* Tirumaleswar Reddy (tireddy) > *Cc:* Sergio Garcia Murillo; Simon Perreault; Victor Pascual Avila; > draft-chenxin-behave-turn-websocket@tools.ietf.org; tram@ietf.org > *Subject:* Re: [tram] TURN over WebSocket > > I prefer explicit proxies too. Unfortunately, many networks where my > customers are located deploy transparent proxies anyway. > > On Dec 1, 2014, at 12:06 PM, Tirumaleswar Reddy (tireddy) > > wrote: > > > > I think HTTPbis WG is discussing that explicit proxy is preferred over > transparent proxy. > > -Tiru > > *From:*Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com] > *Sent:*Monday, December 01, 2014 9:27 PM > *To:*Tirumaleswar Reddy (tireddy); Simon Perreault; Victor Pascual Avila > *Cc:*draft-chenxin-behave-turn-websocket@tools.ietf.org > ;tram@ietf.org > > *Subject:*Re: [tram] TURN over WebSocket > > Transparent proxying for example > > Best regards > Sergio > > On 01/12/2014 16:49, Tirumaleswar Reddy (tireddy) wrote: > > https://tools.ietf.org/html/draft-ietf-httpbis-tunnel-protocol-00already > solves the problem with firewall only permitting HTTP(S) flows > through a proxy. Please explain the firewall configuration in > which the above technique will not work. > > -Tiru > > *From:*tram [mailto:tram-bounces@ietf.org]*On Behalf Of*Simon > Perreault > *Sent:*Monday, December 01, 2014 8:45 PM > *To:*Victor Pascual Avila > *Cc:*draft-chenxin-behave-turn-websocket@tools.ietf.org > ;tram@ietf.org > > *Subject:*Re: [tram] TURN over WebSocket > > On Mon, Dec 1, 2014 at 4:10 AM, Victor Pascual Avila > > wrote: > > Shall we create a new milestone for this? > > All, > > > Note that this question from Victor is intended for the working > group. The chairs are in listening mode! :) > > Simon > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --------------070704010506010503070906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
More arguments in favor of adopting this draft.

If transparent proxies are considered MITM, then there should be no objections about bypassing any IT security mechanism. And we will allow webrtc to work on an scenario that currently doesn't work.

Best regards
Sergio

On 02/12/2014 5:45, Tirumaleswar Reddy (tireddy) wrote:

Yes, but the problem is transparent proxy acts as MIM (without the consent of the user). http://tools.ietf.org/html/draft-nottingham-http-proxy-problem-00#section-6.1 discusses this issue.

 

-Tiru

 

From: Jonathan Lennox [mailto:jonathan@vidyo.com]
Sent: Tuesday, December 02, 2014 2:19 AM
To: Tirumaleswar Reddy (tireddy)
Cc: Sergio Garcia Murillo; Simon Perreault; Victor Pascual Avila; draft-chenxin-behave-turn-websocket@tools.ietf.org; tram@ietf.org
Subject: Re: [tram] TURN over WebSocket

 

I prefer explicit proxies too.  Unfortunately, many networks where my customers are located deploy transparent proxies anyway.

 

On Dec 1, 2014, at 12:06 PM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:



I think HTTPbis WG is discussing that explicit proxy is preferred over transparent proxy.

 

-Tiru

 

From: Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com] 
Sent: Monday, December 01, 2014 9:27 PM
To: Tirumaleswar Reddy (tireddy); Simon Perreault; Victor Pascual Avila
Cc: draft-chenxin-behave-turn-websocket@tools.ietf.org; tram@ietf.org
Subject: Re: [tram] TURN over WebSocket

 

Transparent proxying for example

Best regards
Sergio

On 01/12/2014 16:49, Tirumaleswar Reddy (tireddy) wrote:

https://tools.ietf.org/html/draft-ietf-httpbis-tunnel-protocol-00 already solves the problem with firewall only permitting HTTP(S) flows through a proxy. Please explain the firewall configuration in which the above technique will not work.

 

-Tiru

 

From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Simon Perreault
Sent: Monday, December 01, 2014 8:45 PM
To: Victor Pascual Avila
Cc: draft-chenxin-behave-turn-websocket@tools.ietf.org; tram@ietf.org
Subject: Re: [tram] TURN over WebSocket

 

On Mon, Dec 1, 2014 at 4:10 AM, Victor Pascual Avila <victor.pascual.avila@gmail.com> wrote:

Shall we create a new milestone for this?

 

All,


Note that this question from Victor is intended for the working group. The chairs are in listening mode! :)

 

Simon

 

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

 


--------------070704010506010503070906-- From nobody Tue Dec 2 07:08:50 2014 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 C197B1ACE00 for ; Tue, 2 Dec 2014 07:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 BDCjEP6sGgwP for ; Tue, 2 Dec 2014 07:08:24 -0800 (PST) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D32571ACE1E for ; Tue, 2 Dec 2014 07:07:42 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id ge10so6227801lab.16 for ; Tue, 02 Dec 2014 07:07:41 -0800 (PST) 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=5xtC3d6qPXrHnXn3TpHmDffH3zRt1U94vIXiRkhdXK0=; b=LaxC8bHNwa89hBl9vtnOeiq/kZqHwQtFfbhMQJ/BVR5zzVu+Wut3Wm2pjWhl0ZNtkc Y/IIAphPahHSdL3PdiBJHCnl6koDGZUUjLDCYngRbESKXrXfc5MezXS2A/qS6wajt7M3 ccTbY7XR8ICdCrOneE+ggYdd5ijwNwLfGBrSTJj5UqMvPzrXHN8loU0HoxJaXBQAdln3 gOyGKLEwb2HYTfpiWetTGJDiErVeIxkruA30jPsdWJxgaC5zYO3PKH4OitvDxFgJI/CS X9R2t5QtoUj5MYrVIQiiFHUrEEAcPf7YbLq9tUNd7tQ3/lWurq6V/5tQI5fXTZMTNXTh V08Q== X-Gm-Message-State: ALoCoQl4lVLXhIka3HUXOZPhVVsgC+t4ee9kj80FKb5PoCCyvvc6y8Hc2nMKZ2aQEyM5b2/8VPNx MIME-Version: 1.0 X-Received: by 10.152.206.67 with SMTP id lm3mr62261016lac.16.1417532861164; Tue, 02 Dec 2014 07:07:41 -0800 (PST) Received: by 10.25.84.145 with HTTP; Tue, 2 Dec 2014 07:07:41 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> Date: Tue, 2 Dec 2014 08:07:41 -0700 Message-ID: From: Simon Perreault To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=001a113494b2a5cae305093d16f7 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/oG4oYKQC6ETezwqsgWyhv-lNQKA Cc: "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Jonathan Lennox , Sergio Garcia Murillo , "tram@ietf.org" , Victor Pascual Avila Subject: Re: [tram] TURN over WebSocket 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: Tue, 02 Dec 2014 15:08:31 -0000 --001a113494b2a5cae305093d16f7 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 1, 2014 at 9:45 PM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > Yes, but the problem is transparent proxy acts as MIM (without the consent > of the user). IMHO arguing that "transparent proxies are wrong", or "transparent proxies are not the IETF's preferred way of doing things" is irrelevant. The fact is that they are extremely common today and in the foreseeable future. In fact, if "X is wrong" was a good reason to not work around X, then STUN/TURN/ICE would not exist (with X = NATs). Simon --001a113494b2a5cae305093d16f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Dec 1, 2014 at 9:45 PM, Tirumaleswar Reddy (tireddy) <tireddy@cisc= o.com> wrote:
Yes, but the problem is tra= nsparent proxy acts as MIM (without the consent of the user).
<= /div>
IMHO arguing that "transparent proxies are wrong", or &q= uot;transparent proxies are not the IETF's preferred way of doing thing= s" is irrelevant.=C2=A0The fact is that they are extremely common toda= y and in the foreseeable future.

=
In fact, if "X is wrong" was a good re= ason to not work around X, then STUN/TURN/ICE would not exist (with X =3D N= ATs).

= Simon
--001a113494b2a5cae305093d16f7-- From nobody Tue Dec 2 08:34:07 2014 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 4C0BD1A038D for ; Tue, 2 Dec 2014 08:34:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 PJ71AIhRqc2T for ; Tue, 2 Dec 2014 08:34:01 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B2B41A1BF4 for ; Tue, 2 Dec 2014 08:34:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8392; q=dns/txt; s=iport; t=1417538041; x=1418747641; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4vDHdCgHZm7tU/AjxnzokwiR4VvoOLLx5u+3sOVEnoc=; b=BWrrtAgw75iOFAYBk0Gs5Atow8t+k62RMtQtlsfLHSSGkFZdYOR2ZUZU V5pomQXX062yDL+c5gd0/Gd3BpXxvZ8jUSjvvqzm8Jx3oYKOJSztgc53h cyWSral8ymhfSbsGsx4jOZZP7XbY80iVn6UcZlfMJ+rQh/oiTUb/zdvrG E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggJANzofVStJV2b/2dsb2JhbABbgkNEUlkEgwHBZYhFAhyBBhYBAQEBAX2EAgEBAQQjCkwQAgEIDgMEAQELHQMCAgIwFAkIAQEEDgUIiDi/bZZjAQEBAQEBAQEBAQEBAQEBAQEBAQEBF5AtETEGAYJ1NIEfBZBhoEaDe2+BBkCBAQEBAQ X-IronPort-AV: E=Sophos;i="5.07,501,1413244800"; d="scan'208,217";a="101956270" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP; 02 Dec 2014 16:34:01 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sB2GY0ec007108 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Dec 2014 16:34:00 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.204]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Tue, 2 Dec 2014 10:34:00 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault Thread-Topic: [tram] TURN over WebSocket Thread-Index: AdANiRFG6X70S29YQzixzirX+f0pqQAUXYoAAAPQ0HAAIo3igAAJyMCQ Date: Tue, 2 Dec 2014 16:34:00 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.52.41] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A2837B709xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/fyJfHBMgXWOKg2Dk9AQBHVtdbZA Cc: "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Jonathan Lennox , Sergio Garcia Murillo , "tram@ietf.org" , Victor Pascual Avila Subject: Re: [tram] TURN over WebSocket 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: Tue, 02 Dec 2014 16:34:03 -0000 --_000_913383AAA69FF945B8F946018B75898A2837B709xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU2ltb24sDQoNClRyYW5zcGFyZW50IHByb3hpZXMgbGlrZSBmaXJld2FsbHMga2VlcCBnZXR0 aW5nIHVwZ3JhZGVkIGZyZXF1ZW50bHkgdG8gaGFuZGxlIG5ldyBhcHBsaWNhdGlvbnMsIHRocmVh dHMgZXRjLiBJZiBmaXJld2FsbCBoYXMgYSBmZWF0dXJlIHRvIGJsb2NrIFdlYlJUQyB0cmFmZmlj IHRoZW4gYnkgc2VuZGluZyB0cmFmZmljIG92ZXIgV2ViU29ja2V0IHdpbGwgbm90IHNvbHZlIHRo ZSBwcm9ibGVtLg0KDQpDaGVlcnMsDQotVGlydQ0KDQpGcm9tOiBTaW1vbiBQZXJyZWF1bHQgW21h aWx0bzpzcGVycmVhdWx0QGppdmUuY29tXQ0KU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMDIsIDIw MTQgODozOCBQTQ0KVG86IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkNCkNjOiBKb25hdGhh biBMZW5ub3g7IFNlcmdpbyBHYXJjaWEgTXVyaWxsbzsgVmljdG9yIFBhc2N1YWwgQXZpbGE7IGRy YWZ0LWNoZW54aW4tYmVoYXZlLXR1cm4td2Vic29ja2V0QHRvb2xzLmlldGYub3JnOyB0cmFtQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW3RyYW1dIFRVUk4gb3ZlciBXZWJTb2NrZXQNCg0KDQpPbiBN b24sIERlYyAxLCAyMDE0IGF0IDk6NDUgUE0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkg PHRpcmVkZHlAY2lzY28uY29tPG1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbT4+IHdyb3RlOg0KWWVz LCBidXQgdGhlIHByb2JsZW0gaXMgdHJhbnNwYXJlbnQgcHJveHkgYWN0cyBhcyBNSU0gKHdpdGhv dXQgdGhlIGNvbnNlbnQgb2YgdGhlIHVzZXIpLg0KDQpJTUhPIGFyZ3VpbmcgdGhhdCAidHJhbnNw YXJlbnQgcHJveGllcyBhcmUgd3JvbmciLCBvciAidHJhbnNwYXJlbnQgcHJveGllcyBhcmUgbm90 IHRoZSBJRVRGJ3MgcHJlZmVycmVkIHdheSBvZiBkb2luZyB0aGluZ3MiIGlzIGlycmVsZXZhbnQu IFRoZSBmYWN0IGlzIHRoYXQgdGhleSBhcmUgZXh0cmVtZWx5IGNvbW1vbiB0b2RheSBhbmQgaW4g dGhlIGZvcmVzZWVhYmxlIGZ1dHVyZS4NCg0KSW4gZmFjdCwgaWYgIlggaXMgd3JvbmciIHdhcyBh IGdvb2QgcmVhc29uIHRvIG5vdCB3b3JrIGFyb3VuZCBYLCB0aGVuIFNUVU4vVFVSTi9JQ0Ugd291 bGQgbm90IGV4aXN0ICh3aXRoIFggPSBOQVRzKS4NCg0KU2ltb24NCg== --_000_913383AAA69FF945B8F946018B75898A2837B709xmbrcdx10ciscoc_ 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 LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgU2ltb24sPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5UcmFuc3BhcmVudCBwcm94aWVzIGxpa2UgZmlyZXdhbGxzIGtlZXAgZ2V0dGluZyB1cGdy YWRlZCBmcmVxdWVudGx5IHRvIGhhbmRsZSBuZXcgYXBwbGljYXRpb25zLCB0aHJlYXRzIGV0Yy4g SWYgZmlyZXdhbGwgaGFzIGEgZmVhdHVyZSB0byBibG9jayBXZWJSVEMgdHJhZmZpYw0KIHRoZW4g Ynkgc2VuZGluZyB0cmFmZmljIG92ZXIgV2ViU29ja2V0IHdpbGwgbm90IHNvbHZlIHRoZSBwcm9i bGVtLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LVRp cnU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gU2ltb24gUGVy cmVhdWx0IFttYWlsdG86c3BlcnJlYXVsdEBqaXZlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBU dWVzZGF5LCBEZWNlbWJlciAwMiwgMjAxNCA4OjM4IFBNPGJyPg0KPGI+VG86PC9iPiBUaXJ1bWFs ZXN3YXIgUmVkZHkgKHRpcmVkZHkpPGJyPg0KPGI+Q2M6PC9iPiBKb25hdGhhbiBMZW5ub3g7IFNl cmdpbyBHYXJjaWEgTXVyaWxsbzsgVmljdG9yIFBhc2N1YWwgQXZpbGE7IGRyYWZ0LWNoZW54aW4t YmVoYXZlLXR1cm4td2Vic29ja2V0QHRvb2xzLmlldGYub3JnOyB0cmFtQGlldGYub3JnPGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbdHJhbV0gVFVSTiBvdmVyIFdlYlNvY2tldDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBEZWMg MSwgMjAxNCBhdCA5OjQ1IFBNLCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpICZsdDs8YSBo cmVmPSJtYWlsdG86dGlyZWRkeUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj50aXJlZGR5QGNp c2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+WWVzLCBidXQgdGhlIHByb2JsZW0gaXMgdHJhbnNwYXJlbnQgcHJveHkgYWN0cyBhcyBNSU0g KHdpdGhvdXQgdGhlIGNvbnNlbnQgb2YgdGhlIHVzZXIpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpJTUhPIGFyZ3VpbmcgdGhhdCAmcXVvdDt0cmFu c3BhcmVudCBwcm94aWVzIGFyZSB3cm9uZyZxdW90Oywgb3IgJnF1b3Q7dHJhbnNwYXJlbnQgcHJv eGllcyBhcmUgbm90IHRoZSBJRVRGJ3MgcHJlZmVycmVkIHdheSBvZiBkb2luZyB0aGluZ3MmcXVv dDsgaXMgaXJyZWxldmFudC4mbmJzcDtUaGUgZmFjdCBpcyB0aGF0IHRoZXkgYXJlIGV4dHJlbWVs eSBjb21tb24gdG9kYXkgYW5kIGluIHRoZSBmb3Jlc2VlYWJsZSBmdXR1cmUuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIGZhY3QsIGlmICZx dW90O1ggaXMgd3JvbmcmcXVvdDsgd2FzIGEgZ29vZCByZWFzb24gdG8gbm90IHdvcmsgYXJvdW5k IFgsIHRoZW4gU1RVTi9UVVJOL0lDRSB3b3VsZCBub3QgZXhpc3QgKHdpdGggWCA9IE5BVHMpLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaW1v bjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_913383AAA69FF945B8F946018B75898A2837B709xmbrcdx10ciscoc_-- From nobody Tue Dec 2 08:49:17 2014 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 7C53A1A1EF5 for ; Tue, 2 Dec 2014 08:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 OcdIOfxgzULm for ; Tue, 2 Dec 2014 08:49:15 -0800 (PST) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC1311A1EF1 for ; Tue, 2 Dec 2014 08:49:14 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id n15so10910635lbi.30 for ; Tue, 02 Dec 2014 08:49:13 -0800 (PST) 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=q15M9qu6cOPPPRFsPQUoRr/kzurdieoS8RzwJTpxNLY=; b=XbCdFZoNMIZtYqt7v4q3u7+FKRoe23G3Qd9MoW0+U2rRVzaH+qU7ZPc0veAq0gaQTq WKL7ukVRDdXTw06aZmoufk9UQJDvR+09fCIRGvh3faj4nDkXOJ/SPXCIjOPaU3KGLzyT 9TxWjHwKq1vXFMOwyZ1GlS9PWbujXGH9QeNzFDtOjOfbsberN+8NIYrk1FaxtjrDR7e/ 6SYCx0HynRH4KCiUkg3WH7PDC9+LCrDUYeXgnjlLUhyauaNUUtJzTsANZA5AzOIGKc6H Ry6F8GQXT2gljeXN4TuqOfddJ61qqdmzaYtZ5nLob/Nc2QQzsdIZnXJY9xwtX2TnqAR5 V6WQ== X-Gm-Message-State: ALoCoQkHy9cMgS/Uxm7geH5t8VLDv7sNDrstZqtXhMtCyVeX3WSC32+uae1NBw/MAnxdJ2PQ2JXN MIME-Version: 1.0 X-Received: by 10.152.2.74 with SMTP id 10mr249051las.38.1417538952439; Tue, 02 Dec 2014 08:49:12 -0800 (PST) Received: by 10.25.84.145 with HTTP; Tue, 2 Dec 2014 08:49:12 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> Date: Tue, 2 Dec 2014 09:49:12 -0700 Message-ID: From: Simon Perreault To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=089e01228e5ab743e505093e8189 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/LtenBB0viUbjGnoVUNtBz-9LW0Y Cc: "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Jonathan Lennox , Sergio Garcia Murillo , "tram@ietf.org" , Victor Pascual Avila Subject: Re: [tram] TURN over WebSocket 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: Tue, 02 Dec 2014 16:49:16 -0000 --089e01228e5ab743e505093e8189 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > Transparent proxies like firewalls keep getting upgraded frequently to > handle new applications, threats etc. If firewall has a feature to block > WebRTC traffic then by sending traffic over WebSocket will not solve the > problem. (As a participant...) This has also been discussed before. TURN-over-WebSockets is not a way for applications to circumvent policy. The problem is there are networks that are set up so that "the web" is open, through a transparent proxy. WebRTC is part of "the web". Making TURN fit the mould of "the web" is is not circumventing policy, it's making WebRTC work. You should not need to update your proxy/firewall config for WebRTC to just work if "the web" already does work. Simon --089e01228e5ab743e505093e8189 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar Reddy (tireddy) <tireddy@cisc= o.com> wrote:
Transparent p= roxies like firewalls keep getting upgraded frequently to handle new applic= ations, threats etc. If firewall has a feature to block WebRTC traffic then by sending traffic over WebSocket will not solve the problem.

(As a participant...)
=

This has also been discussed before. TURN-ov= er-WebSockets is not a way for applications to circumvent policy.

The problem is = there are networks that are set up so that "the web" is open, thr= ough a transparent proxy. WebRTC is part of "the web". Making TUR= N fit the mould of "the web" is is not circumventing policy, it&#= 39;s making WebRTC work. You should not need to update your proxy/firewall = config for WebRTC to just work if "the web" already does work.

Simon
--089e01228e5ab743e505093e8189-- From nobody Tue Dec 2 08:58:21 2014 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 D5B111A1EF9 for ; Tue, 2 Dec 2014 08:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 dnsqYUIZBFyX for ; Tue, 2 Dec 2014 08:58:19 -0800 (PST) Received: from mail-ee0-x22b.google.com (mail-ee0-x22b.google.com [IPv6:2a00:1450:4013:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05C4B1A1EEE for ; Tue, 2 Dec 2014 08:58:16 -0800 (PST) Received: by mail-ee0-f43.google.com with SMTP id d49so80218eek.30 for ; Tue, 02 Dec 2014 08:58:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=iPEuvq9sgVjYKWXW3a46GiA0F2f9PfWrbXAN1d4nqwQ=; b=Lx0gdQIja4333mfbkifksrVrS5zIbeFSvUuUX9wEjqi19tKsKWf2NwvQeXINRF5Trl LrE+6VZmr6uanNJ6Ro+9oD6Zol9Hp7G5aEzZloQGEYZK2I9mA5GxAehvpNyb0NND/85s vcMz+N4VdHjYbvZx2Xn5khr3tbzfuwfyFOgr3HXFObGP+yiKAr4umnfdK+AhK09HyQ36 qeonxuSb+Tu7/Ur6h34PG5LKVflHOsNe1hL7TzvFO86qLYgxfGBV7kAq5zqMdWwcligq e5Q+jAU15JnwHPHFQwqSsvdv6OPe9sQLpxZ3v/75hvDPsfHJY6uCiSMe8aoGBVyuaYzy mGzA== X-Received: by 10.194.24.103 with SMTP id t7mr208357wjf.15.1417539047297; Tue, 02 Dec 2014 08:50:47 -0800 (PST) Received: from [192.168.1.37] (136.Red-81-39-109.dynamicIP.rima-tde.net. [81.39.109.136]) by mx.google.com with ESMTPSA id h2sm33491111wix.5.2014.12.02.08.50.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Dec 2014 08:50:46 -0800 (PST) Message-ID: <547DEDE6.5050500@gmail.com> Date: Tue, 02 Dec 2014 17:50:46 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , Simon Perreault References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> Content-Type: multipart/alternative; boundary="------------020002030200010002090905" Archived-At: http://mailarchive.ietf.org/arch/msg/tram/X2CXBKTDEvTjK7dYG3GEDgezaMM Cc: "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Jonathan Lennox , Victor Pascual Avila , "tram@ietf.org" Subject: Re: [tram] TURN over WebSocket 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: Tue, 02 Dec 2014 16:58:21 -0000 This is a multi-part message in MIME format. --------------020002030200010002090905 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Tiru, We don't want to bypass any FW, in fact the ws connection is tagged as TURN so the IT policies can be enforced if webrtc is explicitly disabled. Could you try to sum up what are you concerns about this draft so we can address them? Would be easier to discuss and move things forward. Best regards Sergio On 02/12/2014 17:34, Tirumaleswar Reddy (tireddy) wrote: > > Hi Simon, > > Transparent proxies like firewalls keep getting upgraded frequently to > handle new applications, threats etc. If firewall has a feature to > block WebRTC traffic then by sending traffic over WebSocket will not > solve the problem. > > Cheers, > > -Tiru > > *From:*Simon Perreault [mailto:sperreault@jive.com] > *Sent:* Tuesday, December 02, 2014 8:38 PM > *To:* Tirumaleswar Reddy (tireddy) > *Cc:* Jonathan Lennox; Sergio Garcia Murillo; Victor Pascual Avila; > draft-chenxin-behave-turn-websocket@tools.ietf.org; tram@ietf.org > *Subject:* Re: [tram] TURN over WebSocket > > On Mon, Dec 1, 2014 at 9:45 PM, Tirumaleswar Reddy (tireddy) > > wrote: > > Yes, but the problem is transparent proxy acts as MIM (without the > consent of the user). > > > IMHO arguing that "transparent proxies are wrong", or "transparent > proxies are not the IETF's preferred way of doing things" is > irrelevant. The fact is that they are extremely common today and in > the foreseeable future. > > In fact, if "X is wrong" was a good reason to not work around X, then > STUN/TURN/ICE would not exist (with X = NATs). > > Simon > --------------020002030200010002090905 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hi Tiru,

We don't want to bypass any FW, in fact the ws connection is tagged as TURN so the IT policies can be enforced if webrtc is explicitly disabled.

Could you try to sum up what are you concerns about this draft so we can address them? Would be easier to discuss and move things forward.

Best regards
Sergio
On 02/12/2014 17:34, Tirumaleswar Reddy (tireddy) wrote:

Hi Simon,

 

Transparent proxies like firewalls keep getting upgraded frequently to handle new applications, threats etc. If firewall has a feature to block WebRTC traffic then by sending traffic over WebSocket will not solve the problem.

 

Cheers,

-Tiru

 

From: Simon Perreault [mailto:sperreault@jive.com]
Sent: Tuesday, December 02, 2014 8:38 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Jonathan Lennox; Sergio Garcia Murillo; Victor Pascual Avila; draft-chenxin-behave-turn-websocket@tools.ietf.org; tram@ietf.org
Subject: Re: [tram] TURN over WebSocket

 

 

On Mon, Dec 1, 2014 at 9:45 PM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:

Yes, but the problem is transparent proxy acts as MIM (without the consent of the user).


IMHO arguing that "transparent proxies are wrong", or "transparent proxies are not the IETF's preferred way of doing things" is irrelevant. The fact is that they are extremely common today and in the foreseeable future.

 

In fact, if "X is wrong" was a good reason to not work around X, then STUN/TURN/ICE would not exist (with X = NATs).

 

Simon


--------------020002030200010002090905-- From nobody Tue Dec 2 09:37:51 2014 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 6E67A1A1B4D; Tue, 2 Dec 2014 09:37:43 -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] 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 y-8BjfTbgOEk; Tue, 2 Dec 2014 09:37:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 799F01A1B51; Tue, 2 Dec 2014 09:37:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141202173735.17933.63498.idtracker@ietfa.amsl.com> Date: Tue, 02 Dec 2014 09:37:35 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/N1Z-g8vrZCM9VHdIUJPNyr1NJ_g Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-stun-origin-03.txt 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: Tue, 02 Dec 2014 17:37:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TURN Revised and Modernized Working Group of the IETF. Title : An Origin Attribute for the STUN Protocol Authors : Alan Johnston Justin Uberti John Yoakum Kundan Singh Filename : draft-ietf-tram-stun-origin-03.txt Pages : 13 Date : 2014-12-02 Abstract: STUN, or Session Traversal Utilities for NAT, is a protocol used to assist other protocols traverse Network Address Translators or NATs. STUN, and STUN extensions such as TURN, or Traversal Using Relays around NAT, and ICE, Interactive Communications Establishment, have been around for many years but with WebRTC, Web Real-Time Communications, STUN and related extensions are about to see major deployments and implementation due to these protocols being implemented in browsers. This specification defines an ORIGIN attribute for STUN that can be used in similar ways to the HTTP header field of the same name. WebRTC browsers utilizing STUN and TURN would include this attribute which would provide servers with additional information about the STUN and TURN requests they receive. This specification defines the usage of the STUN ORIGIN attribute for web and SIP contexts. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-stun-origin/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tram-stun-origin-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stun-origin-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 2 09:53:44 2014 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 E09031A6F2A for ; Tue, 2 Dec 2014 09:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] 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 SbRAs2oKOIWP for ; Tue, 2 Dec 2014 09:53:40 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4F11A3BA3 for ; Tue, 2 Dec 2014 09:53:40 -0800 (PST) Received: from [IPv6:2001:470:40b8:0:e454:eae5:1bff:fe85] (unknown [IPv6:2001:470:40b8:0:e454:eae5:1bff:fe85]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 945772025A; Tue, 2 Dec 2014 18:53:38 +0100 (CET) Message-ID: <547DFCA0.6070907@acm.org> Date: Tue, 02 Dec 2014 10:53:36 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.2.0 MIME-Version: 1.0 To: Simon Perreault , "Tirumaleswar Reddy (tireddy)" References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/BgMLqcuRiir_8wAsnU0fa0L14Mc Cc: "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Jonathan Lennox , Sergio Garcia Murillo , "tram@ietf.org" , Victor Pascual Avila Subject: Re: [tram] TURN over WebSocket 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: Tue, 02 Dec 2014 17:53:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 12/02/2014 09:49 AM, Simon Perreault wrote: > > On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar Reddy (tireddy) > wrote: > > Transparent proxies like firewalls keep getting upgraded frequently to handle new applications, threats etc. If firewall has a feature to block WebRTC traffic then by sending traffic over WebSocket will not solve the problem. > > > (As a participant...) > > This has also been discussed before. TURN-over-WebSockets is not a way for applications to circumvent policy. > > The problem is there are networks that are set up so that "the web" is open, through a transparent proxy. WebRTC is part of "the web". Making TURN fit the mould of "the web" is is not circumventing policy, it's making WebRTC work. You should not need to update your proxy/firewall config for WebRTC to just work if "the web" already does work. > Yes, that is a fundamental point, IMO. If a webrtc app is successfully loaded, then the underlying network stuff MUST work, and TURN over WS is the ultimate way that we have to make this happen. If on the other hand a network admin does not want this to happen, then s/he should prevent the app to load, not make it fail in mysterious ways. By using TURN over WS we are in fact obeying the admin intent, not going around it. So, +1 for TURN over WS. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJUffygAAoJECnERZXWan7E9NIP/3C+jCxw9IXENkLLUa21J7ga YpsIROUhfTN4YZ5I1fS/z8KQENhdn4c3kl/J97xYkyvBVKgbQwxV8e2QlMdWmA23 dkL+wo4H/y2jA/kudn/CoSEdV6WgtE4zgfwTBAkjnLzv6Jj1mqtZjS6E87x7DJc7 I+gNHVMh/uIiDY0agWqYMOsAOw/hknQyLcszV3Erlyj9eXujHM5eptxX9c83y4du 1fil97Q10MhhK52FK86uYHJy8Yn6qRy3qsudYogpcDDrKNhHETAgPF1c1GHLoC/b U2iwkRWcT70a8ynZg29L6caydq4U2olTZFjM4XqCFVlg7Wl8A+EQTW/4WlQztqYK Gi+yPGvyGVDwiZnfTvy6n64elUH4t/ghhQxrJPDgwo3NW7VPktgmBNVzu1Tli8M4 6d+qvk4O548zthCljEe+eYbDOiIIM8UM+qTvHHtzWwy0O7Lq08dM77Tmji7PsaLm epLgjvnOCTv8oL3CKbvx8a5nNKunVDOh5UsXNb+Zemy8N19XlbQYqHMe8lDf6CNw 18tTWja4C1rr3KrWGj5UqueOJAqNqUlFLyiqCbxgoXPKsvDlyrPzXvRm4izXAATh WY2LgJPFESMNz5RI07c7hewmGHKm/qzN114h1dTQKdXJEE0YlAqB9/fuAM+jV5cB hdSa9jW8E5vh/vIPgo8c =+CNf -----END PGP SIGNATURE----- From nobody Tue Dec 2 11:04:22 2014 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 904151A1B36 for ; Tue, 2 Dec 2014 11:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 cQMMkvetVCbB for ; Tue, 2 Dec 2014 11:04:14 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D17D81A1EF2 for ; Tue, 2 Dec 2014 11:04:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8408; q=dns/txt; s=iport; t=1417547053; x=1418756653; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3/FenAE36fftyjTirt4mVgDEvefH7CAOJuUATYNWDaA=; b=jeK6kYGDgi2vjfVRiWedujowT1h62de21xsDZW2hynKhVB9+HLWXuOcN gZBtIoFKZ/+J7Y6m1MsEBM+qVouc4Dw3SVcx0yoRXoncUeTmMWgrRfvyP PmZf8NYPbEPziqJUMnoxO6GWDgpoNap+VQQ3HnkiMlR4c1hwSIQ4VpL16 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggJAEgMflStJV2T/2dsb2JhbABbgkNEUlkEgwHBZohFAhyBCRYBAQEBAX2EAgEBAQQjCkwQAgEIDgMEAQELHQMCAgIwFAkIAgQOBQiIOMAhllYBAQEBAQEBAQEBAQEBAQEBAQEBAQEXkC0RFhsGAYJ1NIEfBZBhjFGMdIJ/hAKDe2+BBkCBAQEBAQ X-IronPort-AV: E=Sophos;i="5.07,502,1413244800"; d="scan'208,217";a="373842418" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-1.cisco.com with ESMTP; 02 Dec 2014 19:04:12 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id sB2J4CBw013775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Dec 2014 19:04:12 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.204]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Tue, 2 Dec 2014 13:04:12 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault Thread-Topic: [tram] TURN over WebSocket Thread-Index: AdANiRFG6X70S29YQzixzirX+f0pqQAUXYoAAAPQ0HAAIo3igAAJyMCQ///OFwCAAEFhgA== Date: Tue, 2 Dec 2014 19:04:11 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2837B8E7@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.41.253] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A2837B8E7xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/UGBRxl5b0GoAEIf5Ta6Oe86aRpg Cc: "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Jonathan Lennox , Sergio Garcia Murillo , "tram@ietf.org" , Victor Pascual Avila Subject: Re: [tram] TURN over WebSocket 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: Tue, 02 Dec 2014 19:04:16 -0000 --_000_913383AAA69FF945B8F946018B75898A2837B8E7xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogU2ltb24gUGVycmVhdWx0IFttYWlsdG86c3BlcnJlYXVsdEBqaXZlLmNvbV0NClNlbnQ6 IFR1ZXNkYXksIERlY2VtYmVyIDAyLCAyMDE0IDEwOjE5IFBNDQpUbzogVGlydW1hbGVzd2FyIFJl ZGR5ICh0aXJlZGR5KQ0KQ2M6IEpvbmF0aGFuIExlbm5veDsgU2VyZ2lvIEdhcmNpYSBNdXJpbGxv OyBWaWN0b3IgUGFzY3VhbCBBdmlsYTsgZHJhZnQtY2hlbnhpbi1iZWhhdmUtdHVybi13ZWJzb2Nr ZXRAdG9vbHMuaWV0Zi5vcmc7IHRyYW1AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdHJhbV0gVFVS TiBvdmVyIFdlYlNvY2tldA0KDQoNCk9uIFR1ZSwgRGVjIDIsIDIwMTQgYXQgOTozNCBBTSwgVGly dW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSA8dGlyZWRkeUBjaXNjby5jb208bWFpbHRvOnRpcmVk ZHlAY2lzY28uY29tPj4gd3JvdGU6DQpUcmFuc3BhcmVudCBwcm94aWVzIGxpa2UgZmlyZXdhbGxz IGtlZXAgZ2V0dGluZyB1cGdyYWRlZCBmcmVxdWVudGx5IHRvIGhhbmRsZSBuZXcgYXBwbGljYXRp b25zLCB0aHJlYXRzIGV0Yy4gSWYgZmlyZXdhbGwgaGFzIGEgZmVhdHVyZSB0byBibG9jayBXZWJS VEMgdHJhZmZpYyB0aGVuIGJ5IHNlbmRpbmcgdHJhZmZpYyBvdmVyIFdlYlNvY2tldCB3aWxsIG5v dCBzb2x2ZSB0aGUgcHJvYmxlbS4NCg0KKEFzIGEgcGFydGljaXBhbnQuLi4pDQoNClRoaXMgaGFz IGFsc28gYmVlbiBkaXNjdXNzZWQgYmVmb3JlLiBUVVJOLW92ZXItV2ViU29ja2V0cyBpcyBub3Qg YSB3YXkgZm9yIGFwcGxpY2F0aW9ucyB0byBjaXJjdW12ZW50IHBvbGljeS4NCg0KVGhlIHByb2Js ZW0gaXMgdGhlcmUgYXJlIG5ldHdvcmtzIHRoYXQgYXJlIHNldCB1cCBzbyB0aGF0ICJ0aGUgd2Vi IiBpcyBvcGVuLCB0aHJvdWdoIGEgdHJhbnNwYXJlbnQgcHJveHkuIFdlYlJUQyBpcyBwYXJ0IG9m ICJ0aGUgd2ViIi4gTWFraW5nIFRVUk4gZml0IHRoZSBtb3VsZCBvZiAidGhlIHdlYiIgaXMgaXMg bm90IGNpcmN1bXZlbnRpbmcgcG9saWN5LCBpdCdzIG1ha2luZyBXZWJSVEMgd29yay4gWW91IHNo b3VsZCBub3QgbmVlZCB0byB1cGRhdGUgeW91ciBwcm94eS9maXJld2FsbCBjb25maWcgZm9yIFdl YlJUQyB0byBqdXN0IHdvcmsgaWYgInRoZSB3ZWIiIGFscmVhZHkgZG9lcyB3b3JrLg0KDQpbVFJd IE9rYXksIHNvIGxvb2tzIGxpa2UgdGhlIHByb2JsZW0gY2FuIGFsc28gYmUgc29sdmVkIGJ5IHJ1 bm5pbmcgVFVSTiBvdmVyIDQ0MyBzaW1pbGFyIHRvIHByb3Bvc2FscyBpbiBEUFJJVkUgV0cgdG8g cnVuIEROUyBvdmVyIDQ0My4NCg0KLVRpcnUNCg0KU2ltb24NCg== --_000_913383AAA69FF945B8F946018B75898A2837B8E7xmbrcdx10ciscoc_ 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 LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBTaW1vbiBQZXJyZWF1bHQgW21haWx0bzpzcGVycmVhdWx0QGpp dmUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIERlY2VtYmVyIDAyLCAyMDE0IDEw OjE5IFBNPGJyPg0KPGI+VG86PC9iPiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpPGJyPg0K PGI+Q2M6PC9iPiBKb25hdGhhbiBMZW5ub3g7IFNlcmdpbyBHYXJjaWEgTXVyaWxsbzsgVmljdG9y IFBhc2N1YWwgQXZpbGE7IGRyYWZ0LWNoZW54aW4tYmVoYXZlLXR1cm4td2Vic29ja2V0QHRvb2xz LmlldGYub3JnOyB0cmFtQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHJhbV0g VFVSTiBvdmVyIFdlYlNvY2tldDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBEZWMgMiwgMjAxNCBhdCA5OjM0IEFNLCBUaXJ1bWFs ZXN3YXIgUmVkZHkgKHRpcmVkZHkpICZsdDs8YSBocmVmPSJtYWlsdG86dGlyZWRkeUBjaXNjby5j b20iIHRhcmdldD0iX2JsYW5rIj50aXJlZGR5QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VHJhbnNwYXJlbnQgcHJveGllcyBsaWtl IGZpcmV3YWxscyBrZWVwIGdldHRpbmcgdXBncmFkZWQgZnJlcXVlbnRseSB0byBoYW5kbGUgbmV3 IGFwcGxpY2F0aW9ucywgdGhyZWF0cyBldGMuIElmIGZpcmV3YWxsIGhhcyBhIGZlYXR1cmUgdG8g YmxvY2sgV2ViUlRDIHRyYWZmaWMgdGhlbiBieSBzZW5kaW5nIHRyYWZmaWMgb3ZlciBXZWJTb2Nr ZXQgd2lsbCBub3Qgc29sdmUgdGhlIHByb2JsZW0uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+KEFzIGEgcGFydGljaXBhbnQuLi4pPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpUaGlzIGhhcyBhbHNv IGJlZW4gZGlzY3Vzc2VkIGJlZm9yZS4gVFVSTi1vdmVyLVdlYlNvY2tldHMgaXMgbm90IGEgd2F5 IGZvciBhcHBsaWNhdGlvbnMgdG8gY2lyY3VtdmVudCBwb2xpY3kuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBwcm9ibGVtIGlzIHRoZXJl IGFyZSBuZXR3b3JrcyB0aGF0IGFyZSBzZXQgdXAgc28gdGhhdCAmcXVvdDt0aGUgd2ViJnF1b3Q7 IGlzIG9wZW4sIHRocm91Z2ggYSB0cmFuc3BhcmVudCBwcm94eS4gV2ViUlRDIGlzIHBhcnQgb2Yg JnF1b3Q7dGhlIHdlYiZxdW90Oy4gTWFraW5nIFRVUk4gZml0IHRoZSBtb3VsZCBvZiAmcXVvdDt0 aGUgd2ViJnF1b3Q7IGlzIGlzIG5vdCBjaXJjdW12ZW50aW5nIHBvbGljeSwgaXQncyBtYWtpbmcg V2ViUlRDIHdvcmsuIFlvdSBzaG91bGQNCiBub3QgbmVlZCB0byB1cGRhdGUgeW91ciBwcm94eS9m aXJld2FsbCBjb25maWcgZm9yIFdlYlJUQyB0byBqdXN0IHdvcmsgaWYgJnF1b3Q7dGhlIHdlYiZx dW90OyBhbHJlYWR5IGRvZXMgd29yay48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1RSXSBPa2F5LCBzbyBsb29rcyBsaWtlIHRoZSBw cm9ibGVtIGNhbiBhbHNvIGJlIHNvbHZlZCBieSBydW5uaW5nIFRVUk4gb3ZlciA0NDMgc2ltaWxh ciB0byBwcm9wb3NhbHMgaW4gRFBSSVZFIFdHIHRvIHJ1biBETlMgb3ZlciA0NDMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4tVGlydTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+U2ltb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_913383AAA69FF945B8F946018B75898A2837B8E7xmbrcdx10ciscoc_-- From nobody Tue Dec 2 11:21:51 2014 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 00E081A1BE9 for ; Tue, 2 Dec 2014 11:21:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 B613LvMHaTVN for ; Tue, 2 Dec 2014 11:21:48 -0800 (PST) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 229A01A1B03 for ; Tue, 2 Dec 2014 11:21:48 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id rl12so12289792iec.30 for ; Tue, 02 Dec 2014 11:21:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4Qyh9g9gfqLrD9nkom1im+1c8TC3UW1LMAdMO/keK9A=; b=NomCCb8IbYLyKERS7B2RzZv7QEiBMdZE0TXBAD+33uz4AgNbk6XTwUsgCRDHUec/9W AaalWmYlYYEpfP8nayI69T5fhkeQTvouOtILt0mLmdDp0auSOA9c9+2ihQzuVQ0FuQub qe1M6uibWTPRb+dGw3NhqbApKl9VPkpeN6X13gA38lrQx4zmS6SSupAXWS8+MovgP0q1 xqOdv6BuIbXW7ZcE3LIDXoUNdLMlyeBiv2btSXw6Eh0td0KalOl8z18tDvnSFpMIV284 SLfsSWg6WSMpuxGAixnThtoH8pXyxBL+PK+x2b3ujwsKK/SR7Tb2euTvfhEdwX0cesPe Mcvg== MIME-Version: 1.0 X-Received: by 10.50.109.195 with SMTP id hu3mr43377726igb.15.1417548107188; Tue, 02 Dec 2014 11:21:47 -0800 (PST) Received: by 10.107.133.31 with HTTP; Tue, 2 Dec 2014 11:21:47 -0800 (PST) Received: by 10.107.133.31 with HTTP; Tue, 2 Dec 2014 11:21:47 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A2837B8E7@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B8E7@xmb-rcd-x10.cisco.com> Date: Tue, 2 Dec 2014 20:21:47 +0100 Message-ID: From: Sergio Garcia Murillo To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=089e0118458e61922b050940a301 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/rjP_MhODXBZ4RuloRTQwUFeEFJ4 Cc: "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Jonathan Lennox , "\[ACME\] Victor Pascual Avila" , "tram@ietf.org" , Simon Perreault Subject: Re: [tram] TURN over WebSocket 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: Tue, 02 Dec 2014 19:21:50 -0000 --089e0118458e61922b050940a301 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable El 02/12/2014 20:04, "Tirumaleswar Reddy (tireddy)" escribi=C3=B3: > > From: Simon Perreault [mailto:sperreault@jive.com] > Sent: Tuesday, December 02, 2014 10:19 PM > > To: Tirumaleswar Reddy (tireddy) > Cc: Jonathan Lennox; Sergio Garcia Murillo; Victor Pascual Avila; draft-chenxin-behave-turn-websocket@tools.ietf.org; tram@ietf.org > Subject: Re: [tram] TURN over WebSocket > > > > > > On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > > Transparent proxies like firewalls keep getting upgraded frequently to handle new applications, threats etc. If firewall has a feature to block WebRTC traffic then by sending traffic over WebSocket will not solve the problem. > > > > (As a participant...) > > > This has also been discussed before. TURN-over-WebSockets is not a way for applications to circumvent policy. > > > > The problem is there are networks that are set up so that "the web" is open, through a transparent proxy. WebRTC is part of "the web". Making TURN fit the mould of "the web" is is not circumventing policy, it's making WebRTC work. You should not need to update your proxy/firewall config for WebRTC to just work if "the web" already does work. > > > > [TR] Okay, so looks like the problem can also be solved by running TURN over 443 similar to proposals in DPRIVE WG to run DNS over 443. > > Good try! Unlucky enough, doesn't work. Best regards Sergio --089e0118458e61922b050940a301 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


El 02/12/2014 20:04, "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com> escribi=C3=B3:
>
> From: Simon Perreault [mailto:s= perreault@jive.com]
> Sent: Tuesday, December 02, 2014 10:19 PM
>
> To: Tirumaleswar Reddy (tireddy)
> Cc: Jonathan Lennox; Sergio Garcia Murillo; Victor Pascual Avila; draft-che= nxin-behave-turn-websocket@tools.ietf.org; tram@ietf.org
> Subject: Re: [tram] TURN over WebSocket
>
> =C2=A0
>
> =C2=A0
>
> On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:
>
> Transparent proxies like firewalls keep getting upgraded frequently to= handle new applications, threats etc. If firewall has a feature to block W= ebRTC traffic then by sending traffic over WebSocket will not solve the pro= blem.
>
> =C2=A0
>
> (As a participant...)
>
>
> This has also been discussed before. TURN-over-WebSockets is not a way= for applications to circumvent policy.
>
> =C2=A0
>
> The problem is there are networks that are set up so that "the we= b" is open, through a transparent proxy. WebRTC is part of "the w= eb". Making TURN fit the mould of "the web" is is not circum= venting policy, it's making WebRTC work. You should not need to update = your proxy/firewall config for WebRTC to just work if "the web" a= lready does work.
>
> =C2=A0
>
> [TR] Okay, so looks like the problem can also be solved by running TUR= N over 443 similar to proposals in DPRIVE WG to run DNS over 443.
>
> =C2=A0

Good try! Unlucky enough, doesn't work.

Best regards
Sergio

--089e0118458e61922b050940a301-- From nobody Tue Dec 2 11:44:17 2014 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 C740C1A1EF7 for ; Tue, 2 Dec 2014 11:44:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 gWk95dsNccmp for ; Tue, 2 Dec 2014 11:44:15 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2C6E1A1EE9 for ; Tue, 2 Dec 2014 11:44:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10448; q=dns/txt; s=iport; t=1417549455; x=1418759055; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=u7ar2vslH6X/IbgXJkLVTC0WVKSTYnB4rdIrWpsUNUc=; b=dZ1P3QfCed8fhCpdSSIiv3FIeR2jQlRMFy1yGg9stk0B2RI+U6PHX/Id sg5VLmB/d3nde2t6ck19SnO0wopH2k2WDxyTWejjp725sxwxkL97LYfzB 9UwXvCciWAey3lKRJJPzDUMN/WjPZ0WjhY1pwRbga5CooWDUCl/pqBzoN E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggJAJgVflStJV2b/2dsb2JhbABbgkNEUlkEgwHBaohFAhyBChYBAQEBAX2EAgEBAQQjCkwQAgEIEQQBAQEKHQMCAgIfERQJCAIEDgUIiCMDEsAGkE0NhXsBAQEBAQEBAQEBAQEBAQEBAQEBAQEXjjiBdREWGwYBgnU0gR8FkGGJJoMrjHQ8gkOEAoN7bwGBBUCBAQEBAQ X-IronPort-AV: E=Sophos;i="5.07,502,1413244800"; d="scan'208,217";a="102006785" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-6.cisco.com with ESMTP; 02 Dec 2014 19:44:14 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sB2JiDGg016925 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Dec 2014 19:44:14 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.204]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Tue, 2 Dec 2014 13:44:13 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Sergio Garcia Murillo Thread-Topic: [tram] TURN over WebSocket Thread-Index: AdANiRFG6X70S29YQzixzirX+f0pqQAUXYoAAAPQ0HAAIo3igAAJyMCQ///OFwCAAEFhgP//6UCAgABem8A= Date: Tue, 2 Dec 2014 19:44:13 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2837B9B5@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B8E7@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.41.253] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A2837B9B5xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ULJBajrBD1qJSvyt2hJYufhfsBA Cc: "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Jonathan Lennox , "\[ACME\] Victor Pascual Avila" , "tram@ietf.org" , Simon Perreault Subject: Re: [tram] TURN over WebSocket 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: Tue, 02 Dec 2014 19:44:17 -0000 --_000_913383AAA69FF945B8F946018B75898A2837B9B5xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 d2h5IHdpbGwgaXQgbm90IHdvcmsgd2hlbiBBTFBOIGlzIHVzZWQgPw0KDQotVGlydQ0KDQpGcm9t OiBTZXJnaW8gR2FyY2lhIE11cmlsbG8gW21haWx0bzpzZXJnaW8uZ2FyY2lhLm11cmlsbG9AZ21h aWwuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAwMywgMjAxNCAxMjo1MiBBTQ0KVG86 IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkNCkNjOiBKb25hdGhhbiBMZW5ub3g7IFtBQ01F XSBWaWN0b3IgUGFzY3VhbCBBdmlsYTsgU2ltb24gUGVycmVhdWx0OyB0cmFtQGlldGYub3JnOyBk cmFmdC1jaGVueGluLWJlaGF2ZS10dXJuLXdlYnNvY2tldEB0b29scy5pZXRmLm9yZw0KU3ViamVj dDogUkU6IFt0cmFtXSBUVVJOIG92ZXIgV2ViU29ja2V0DQoNCg0KRWwgMDIvMTIvMjAxNCAyMDow NCwgIlRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkiIDx0aXJlZGR5QGNpc2NvLmNvbTxtYWls dG86dGlyZWRkeUBjaXNjby5jb20+PiBlc2NyaWJpw7M6DQo+DQo+IEZyb206IFNpbW9uIFBlcnJl YXVsdCBbbWFpbHRvOnNwZXJyZWF1bHRAaml2ZS5jb208bWFpbHRvOnNwZXJyZWF1bHRAaml2ZS5j b20+XQ0KPiBTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAwMiwgMjAxNCAxMDoxOSBQTQ0KPg0KPiBU bzogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KQ0KPiBDYzogSm9uYXRoYW4gTGVubm94OyBT ZXJnaW8gR2FyY2lhIE11cmlsbG87IFZpY3RvciBQYXNjdWFsIEF2aWxhOyBkcmFmdC1jaGVueGlu LWJlaGF2ZS10dXJuLXdlYnNvY2tldEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtY2hlbnhp bi1iZWhhdmUtdHVybi13ZWJzb2NrZXRAdG9vbHMuaWV0Zi5vcmc+OyB0cmFtQGlldGYub3JnPG1h aWx0bzp0cmFtQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW3RyYW1dIFRVUk4gb3ZlciBXZWJT b2NrZXQNCj4NCj4NCj4NCj4NCj4NCj4gT24gVHVlLCBEZWMgMiwgMjAxNCBhdCA5OjM0IEFNLCBU aXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpIDx0aXJlZGR5QGNpc2NvLmNvbTxtYWlsdG86dGly ZWRkeUBjaXNjby5jb20+PiB3cm90ZToNCj4NCj4gVHJhbnNwYXJlbnQgcHJveGllcyBsaWtlIGZp cmV3YWxscyBrZWVwIGdldHRpbmcgdXBncmFkZWQgZnJlcXVlbnRseSB0byBoYW5kbGUgbmV3IGFw cGxpY2F0aW9ucywgdGhyZWF0cyBldGMuIElmIGZpcmV3YWxsIGhhcyBhIGZlYXR1cmUgdG8gYmxv Y2sgV2ViUlRDIHRyYWZmaWMgdGhlbiBieSBzZW5kaW5nIHRyYWZmaWMgb3ZlciBXZWJTb2NrZXQg d2lsbCBub3Qgc29sdmUgdGhlIHByb2JsZW0uDQo+DQo+DQo+DQo+IChBcyBhIHBhcnRpY2lwYW50 Li4uKQ0KPg0KPg0KPiBUaGlzIGhhcyBhbHNvIGJlZW4gZGlzY3Vzc2VkIGJlZm9yZS4gVFVSTi1v dmVyLVdlYlNvY2tldHMgaXMgbm90IGEgd2F5IGZvciBhcHBsaWNhdGlvbnMgdG8gY2lyY3VtdmVu dCBwb2xpY3kuDQo+DQo+DQo+DQo+IFRoZSBwcm9ibGVtIGlzIHRoZXJlIGFyZSBuZXR3b3JrcyB0 aGF0IGFyZSBzZXQgdXAgc28gdGhhdCAidGhlIHdlYiIgaXMgb3BlbiwgdGhyb3VnaCBhIHRyYW5z cGFyZW50IHByb3h5LiBXZWJSVEMgaXMgcGFydCBvZiAidGhlIHdlYiIuIE1ha2luZyBUVVJOIGZp dCB0aGUgbW91bGQgb2YgInRoZSB3ZWIiIGlzIGlzIG5vdCBjaXJjdW12ZW50aW5nIHBvbGljeSwg aXQncyBtYWtpbmcgV2ViUlRDIHdvcmsuIFlvdSBzaG91bGQgbm90IG5lZWQgdG8gdXBkYXRlIHlv dXIgcHJveHkvZmlyZXdhbGwgY29uZmlnIGZvciBXZWJSVEMgdG8ganVzdCB3b3JrIGlmICJ0aGUg d2ViIiBhbHJlYWR5IGRvZXMgd29yay4NCj4NCj4NCj4NCj4gW1RSXSBPa2F5LCBzbyBsb29rcyBs aWtlIHRoZSBwcm9ibGVtIGNhbiBhbHNvIGJlIHNvbHZlZCBieSBydW5uaW5nIFRVUk4gb3ZlciA0 NDMgc2ltaWxhciB0byBwcm9wb3NhbHMgaW4gRFBSSVZFIFdHIHRvIHJ1biBETlMgb3ZlciA0NDMu DQo+DQo+DQoNCkdvb2QgdHJ5ISBVbmx1Y2t5IGVub3VnaCwgZG9lc24ndCB3b3JrLg0KDQpCZXN0 IHJlZ2FyZHMNClNlcmdpbw0K --_000_913383AAA69FF945B8F946018B75898A2837B9B5xmbrcdx10ciscoc_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PndoeSB3aWxsIGl0IG5vdCB3b3JrIHdoZW4gQUxQTiBpcyB1c2VkID88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1UaXJ1 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFNlcmdpbyBHYXJj aWEgTXVyaWxsbyBbbWFpbHRvOnNlcmdpby5nYXJjaWEubXVyaWxsb0BnbWFpbC5jb21dDQo8YnI+ DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBEZWNlbWJlciAwMywgMjAxNCAxMjo1MiBBTTxicj4N CjxiPlRvOjwvYj4gVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTxicj4NCjxiPkNjOjwvYj4g Sm9uYXRoYW4gTGVubm94OyBbQUNNRV0gVmljdG9yIFBhc2N1YWwgQXZpbGE7IFNpbW9uIFBlcnJl YXVsdDsgdHJhbUBpZXRmLm9yZzsgZHJhZnQtY2hlbnhpbi1iZWhhdmUtdHVybi13ZWJzb2NrZXRA dG9vbHMuaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFt0cmFtXSBUVVJOIG92ZXIg V2ViU29ja2V0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+PGJyPg0KRWwgMDIvMTIvMjAx NCAyMDowNCwgJnF1b3Q7VGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSZxdW90OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOnRpcmVkZHlAY2lzY28uY29tIj50aXJlZGR5QGNpc2NvLmNvbTwvYT4mZ3Q7 IGVzY3JpYmnDszo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBGcm9tOiBTaW1vbiBQZXJyZWF1bHQgW21h aWx0bzo8YSBocmVmPSJtYWlsdG86c3BlcnJlYXVsdEBqaXZlLmNvbSI+c3BlcnJlYXVsdEBqaXZl LmNvbTwvYT5dDQo8YnI+DQomZ3Q7IFNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDAyLCAyMDE0IDEw OjE5IFBNPGJyPg0KJmd0Ozxicj4NCiZndDsgVG86IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRk eSk8YnI+DQomZ3Q7IENjOiBKb25hdGhhbiBMZW5ub3g7IFNlcmdpbyBHYXJjaWEgTXVyaWxsbzsg VmljdG9yIFBhc2N1YWwgQXZpbGE7IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1jaGVueGluLWJlaGF2 ZS10dXJuLXdlYnNvY2tldEB0b29scy5pZXRmLm9yZyI+DQpkcmFmdC1jaGVueGluLWJlaGF2ZS10 dXJuLXdlYnNvY2tldEB0b29scy5pZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzp0cmFtQGll dGYub3JnIj4NCnRyYW1AaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyBTdWJqZWN0OiBSZTogW3RyYW1d IFRVUk4gb3ZlciBXZWJTb2NrZXQ8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDs8YnI+DQomZ3Q7 PGJyPg0KJmd0OyAmbmJzcDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiBUdWUsIERlYyAyLCAyMDE0 IGF0IDk6MzQgQU0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgJmx0OzxhIGhyZWY9Im1h aWx0bzp0aXJlZGR5QGNpc2NvLmNvbSI+dGlyZWRkeUBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8 YnI+DQomZ3Q7PGJyPg0KJmd0OyBUcmFuc3BhcmVudCBwcm94aWVzIGxpa2UgZmlyZXdhbGxzIGtl ZXAgZ2V0dGluZyB1cGdyYWRlZCBmcmVxdWVudGx5IHRvIGhhbmRsZSBuZXcgYXBwbGljYXRpb25z LCB0aHJlYXRzIGV0Yy4gSWYgZmlyZXdhbGwgaGFzIGEgZmVhdHVyZSB0byBibG9jayBXZWJSVEMg dHJhZmZpYyB0aGVuIGJ5IHNlbmRpbmcgdHJhZmZpYyBvdmVyIFdlYlNvY2tldCB3aWxsIG5vdCBz b2x2ZSB0aGUgcHJvYmxlbS48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDs8YnI+DQomZ3Q7PGJy Pg0KJmd0OyAoQXMgYSBwYXJ0aWNpcGFudC4uLik8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZn dDsgVGhpcyBoYXMgYWxzbyBiZWVuIGRpc2N1c3NlZCBiZWZvcmUuIFRVUk4tb3Zlci1XZWJTb2Nr ZXRzIGlzIG5vdCBhIHdheSBmb3IgYXBwbGljYXRpb25zIHRvIGNpcmN1bXZlbnQgcG9saWN5Ljxi cj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOzxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBwcm9ibGVt IGlzIHRoZXJlIGFyZSBuZXR3b3JrcyB0aGF0IGFyZSBzZXQgdXAgc28gdGhhdCAmcXVvdDt0aGUg d2ViJnF1b3Q7IGlzIG9wZW4sIHRocm91Z2ggYSB0cmFuc3BhcmVudCBwcm94eS4gV2ViUlRDIGlz IHBhcnQgb2YgJnF1b3Q7dGhlIHdlYiZxdW90Oy4gTWFraW5nIFRVUk4gZml0IHRoZSBtb3VsZCBv ZiAmcXVvdDt0aGUgd2ViJnF1b3Q7IGlzIGlzIG5vdCBjaXJjdW12ZW50aW5nIHBvbGljeSwgaXQn cyBtYWtpbmcgV2ViUlRDIHdvcmsuIFlvdSBzaG91bGQgbm90IG5lZWQgdG8gdXBkYXRlDQogeW91 ciBwcm94eS9maXJld2FsbCBjb25maWcgZm9yIFdlYlJUQyB0byBqdXN0IHdvcmsgaWYgJnF1b3Q7 dGhlIHdlYiZxdW90OyBhbHJlYWR5IGRvZXMgd29yay48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJz cDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBbVFJdIE9rYXksIHNvIGxvb2tzIGxpa2UgdGhlIHByb2Js ZW0gY2FuIGFsc28gYmUgc29sdmVkIGJ5IHJ1bm5pbmcgVFVSTiBvdmVyIDQ0MyBzaW1pbGFyIHRv IHByb3Bvc2FscyBpbiBEUFJJVkUgV0cgdG8gcnVuIEROUyBvdmVyIDQ0My48YnI+DQomZ3Q7PGJy Pg0KJmd0OyAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPkdvb2QgdHJ5ISBVbmx1Y2t5IGVub3Vn aCwgZG9lc24ndCB3b3JrLiA8bzpwPjwvbzpwPjwvcD4NCjxwPkJlc3QgcmVnYXJkczxicj4NClNl cmdpbzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_913383AAA69FF945B8F946018B75898A2837B9B5xmbrcdx10ciscoc_-- From nobody Tue Dec 2 11:53:51 2014 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 86FDB1A1BC4 for ; Tue, 2 Dec 2014 11:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, 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 kgeAqzkZB7bX for ; Tue, 2 Dec 2014 11:53:38 -0800 (PST) Received: from server209.appriver.com (server209c.appriver.com [8.31.233.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E6CC1A1B4A for ; Tue, 2 Dec 2014 11:53:37 -0800 (PST) X-Note-AR-ScanTimeLocal: 12/2/2014 2:53:35 PM X-Policy: vidyo.com - vidyo.com X-Policy: vidyo.com - vidyo.com X-Policy: vidyo.com - vidyo.com X-Policy: vidyo.com - vidyo.com X-Policy: vidyo.com - vidyo.com X-Policy: Too many policies to list X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: SecureTide Build: 11/21/2014 10:58:18 PM UTC X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-315/SG:5 12/2/2014 2:52:38 PM X-GBUdb-Analysis: 0, 67.231.157.197, Ugly c=0.673159 p=-0.941776 Source White X-Signature-Violations: 0-0-0-8589-c X-Note-419: 15.6262 ms. Fail:0 Chk:1328 of 1328 total X-Note: SCH-CT/SI:0-1328/SG:1 12/2/2014 2:53:27 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL->UNITED STATES-> X-Note-Sending-IP: 67.231.157.197 X-Note-Reverse-DNS: mx0b-00198e01.pphosted.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G251 G252 G253 G254 G258 G259 G371 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [67.231.157.197] (HELO mx0b-00198e01.pphosted.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTP id 175582954; Tue, 02 Dec 2014 14:53:35 -0500 Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.14.7/8.14.7) with SMTP id sB2JqlNs024270; Tue, 2 Dec 2014 14:53:35 -0500 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 1qn2nkqq76-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 02 Dec 2014 14:53:35 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Tue, 2 Dec 2014 13:53:34 -0600 From: Jonathan Lennox To: "Tirumaleswar Reddy (tireddy)" Thread-Topic: [tram] TURN over WebSocket Thread-Index: AdANiRFGgoYU7Jer0kaRa9GealJqAwAUXYoAABCgqgAAFb4IgAADA7sAAACH5gAABLbZgAABuV+A Date: Tue, 2 Dec 2014 19:53:33 +0000 Message-ID: <3569659C-2774-4152-9E9F-2E37D7EF89FF@vidyo.com> References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B8E7@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2837B8E7@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_3569659C277441529E9F2E37D7EF89FFvidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2014-12-02_08:2014-12-02,2014-12-02,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1412020170 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/RolmT_tA1ALrwD3BuyWUkELB2zA Cc: "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Simon Perreault , Sergio Garcia Murillo , "tram@ietf.org" , Victor Pascual Avila Subject: Re: [tram] TURN over WebSocket 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: Tue, 02 Dec 2014 19:53:40 -0000 --_000_3569659C277441529E9F2E37D7EF89FFvidyocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Dec 2, 2014, at 2:04 PM, Tirumaleswar Reddy (tireddy) > wrote: The problem is there are networks that are set up so that "the web" is open= , through a transparent proxy. WebRTC is part of "the web". Making TURN fit= the mould of "the web" is is not circumventing policy, it's making WebRTC = work. You should not need to update your proxy/firewall config for WebRTC t= o just work if "the web" already does work. [TR] Okay, so looks like the problem can also be solved by running TURN ove= r 443 similar to proposals in DPRIVE WG to run DNS over 443. Unfortunately, this forces you to get two IPv4 addresses =97 one for your h= ttps server, one for your TURN server =97 since they both have to listen on= port 443. Due to IPv4 address exhaustion, this can be a substantial expen= se for small providers. --_000_3569659C277441529E9F2E37D7EF89FFvidyocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5DF9935D7F2EB34CA06FA2FF11F0552A@vidyo.com> Content-Transfer-Encoding: quoted-printable
On Dec 2, 2014, at 2:04 PM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:

 
The problem is there are networks that are set up so that "the web&quo= t; is open, through a transparent proxy. WebRTC is part of "the web&qu= ot;. Making TURN fit the mould of "the web" is is not circumventi= ng policy, it's making WebRTC work. You should not need to update your proxy/firewall config for WebRTC to just work if "the web" = already does work.
 
[TR] Okay, so looks like the problem can also be solved by= running TURN over 443 similar to proposals in DPRIVE WG to run DNS over 44= 3.

Unfortunately, this forces you to get two IPv4 addresses =97 one for y= our https server, one for your TURN server =97 since they both have to list= en on port 443.  Due to IPv4 address exhaustion, this can be a substan= tial expense for small providers.

--_000_3569659C277441529E9F2E37D7EF89FFvidyocom_-- From nobody Tue Dec 2 12:23:59 2014 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 7A3B01A6FD6 for ; Tue, 2 Dec 2014 12:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 zPh0Q9naJPGX for ; Tue, 2 Dec 2014 12:23:56 -0800 (PST) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9C731A6FBE for ; Tue, 2 Dec 2014 12:23:55 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id gm9so11248150lab.26 for ; Tue, 02 Dec 2014 12:23:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=MiKvCSQt3iTIbNZjtiEZI4xpMb1E3pSNfb8IqARY3Ws=; b=Yvf9P5Bnz5XTspjvz3InuAHpFoU1FAExi0mRq9X+BJYE1kd10u/tkfXR4iXWgRGQah PG/HrwqU913y5H7Zq8/jjGr7qOdCMCq2ua/7dmikuWQG9oVcLQrJ/9V6kVrgLzx8CkoY FO8/3+toNz+A9tB4Y8Sytc7YcIjL1ZyMBMvcSxuWBwPEKwDj7MYONEaoaoMnypj2k0qf Cda/4IeE5cL5OOUd6dhth4wJ9eLEFvS804HadOsomH15q3ZyY9T4M6Y4UAlqMC9LXHnP FXBmVZ9xQGkQhDf6/TtLA3ojsIhUC7C50bpSeTBT4wR8HAXK0885MHVjeClnh7GOONff bNAw== X-Gm-Message-State: ALoCoQkKK6uPsnQAQ7l6fwEa60xEbIv5yUaFD5Jw/YB+ysklBvaP6Gdhrf6jJOtSwbzzYwcNwLEx MIME-Version: 1.0 X-Received: by 10.152.37.38 with SMTP id v6mr1132839laj.10.1417551834396; Tue, 02 Dec 2014 12:23:54 -0800 (PST) Received: by 10.25.84.145 with HTTP; Tue, 2 Dec 2014 12:23:54 -0800 (PST) Date: Tue, 2 Dec 2014 13:23:54 -0700 Message-ID: From: Simon Perreault To: "tram@ietf.org" Content-Type: multipart/alternative; boundary=089e0160b5f28a6cb805094181c7 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/RjlpL5Tg1ODoIhVbZmKOaBZNGx4 Subject: [tram] WGLC draft-ietf-tram-stun-origin-03 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: Tue, 02 Dec 2014 20:23:58 -0000 --089e0160b5f28a6cb805094181c7 Content-Type: text/plain; charset=UTF-8 TRAMsters, This email initiates a two-week working-group last call on this draft: https://tools.ietf.org/html/draft-ietf-tram-stun-origin-03 Please read it now. Substantial comments should be addressed to the group. Nits should be snt directly to the authors. Thanks, Simon & Gonzalo --089e0160b5f28a6cb805094181c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
TRAMsters,

This email initiates a two-w= eek working-group last call on this draft:


Please read it now. Substantial comments should be addressed to the g= roup. Nits should be snt directly to the authors.

= Thanks,
Simon & Gonzalo
--089e0160b5f28a6cb805094181c7-- From nobody Tue Dec 2 12:26:22 2014 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 CF6F51A6FD6 for ; Tue, 2 Dec 2014 12:26:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 b1oEcGNyQTwJ for ; Tue, 2 Dec 2014 12:26:18 -0800 (PST) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56A2D1A6D3F for ; Tue, 2 Dec 2014 12:26:18 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id em10so2704397wid.5 for ; Tue, 02 Dec 2014 12:26:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=6vIlwf74v5WDu8//ucaO8/7q44OJ6E5G3SUPJVX/mNA=; b=WOdXrqojeMu80P50bJJHVla4Y65n5yCM+uOX8SjnLMOk8XF6IKtyribuqz8GF/rxXa OBue8qN8gT0yA7lXc8LMw/MMH/5w2kQcEmE6yzck2a0GLDMbxvyMojRcOXpDarCGWkbW k6p19G58cPEn0wqOWt2zyRm0DpDfwYdFyz5vVsi0D1QBRJGa/PagzdEhQ6CvMUqg1/3r jCmHhe0p0B7lalJduX6fiQqodvcw4QLcC90qR2Gl+w5TvZ4DznA1LyYTsXeeJB2PQVF/ Ag4Umyi0SxCXwEJfAxbant8h379CRCJtqwaQ+ZjV53LQiaDBmLGYBJ9DLkRItm3cGHv3 DCUg== X-Received: by 10.180.103.162 with SMTP id fx2mr2964077wib.42.1417551977099; Tue, 02 Dec 2014 12:26:17 -0800 (PST) Received: from [192.168.0.193] ([95.61.111.78]) by mx.google.com with ESMTPSA id gl11sm8010153wjc.40.2014.12.02.12.26.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Dec 2014 12:26:16 -0800 (PST) Message-ID: <547E2069.4050307@gmail.com> Date: Tue, 02 Dec 2014 21:26:17 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B8E7@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B9B5@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2837B9B5@xmb-rcd-x10.cisco.com> Content-Type: multipart/alternative; boundary="------------020602010000020206070709" Archived-At: http://mailarchive.ietf.org/arch/msg/tram/oj8o-vq7n6Xyo2fdH4-8GrwVD0E Cc: "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Jonathan Lennox , "\[ACME\] Victor Pascual Avila" , "tram@ietf.org" , Simon Perreault Subject: Re: [tram] TURN over WebSocket 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: Tue, 02 Dec 2014 20:26:21 -0000 This is a multi-part message in MIME format. --------------020602010000020206070709 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit We control the client and the server, and you are asking me to wait until what is not in our control is changed. Obviously, not working for me BTW, I am talking about real life experiences, when WSS works and TURNS over 443 doesn't. Best regards Sergio On 02/12/2014 20:44, Tirumaleswar Reddy (tireddy) wrote: > > why will it not work when ALPN is used ? > > -Tiru > > *From:*Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com] ? > > *Sent:* Wednesday, December 03, 2014 12:52 AM > *To:* Tirumaleswar Reddy (tireddy) > *Cc:* Jonathan Lennox; [ACME] Victor Pascual Avila; Simon Perreault; > tram@ietf.org; draft-chenxin-behave-turn-websocket@tools.ietf.org > *Subject:* RE: [tram] TURN over WebSocket > > > El 02/12/2014 20:04, "Tirumaleswar Reddy (tireddy)" > escribió: > > > > From: Simon Perreault [mailto:sperreault@jive.com > ] > > Sent: Tuesday, December 02, 2014 10:19 PM > > > > To: Tirumaleswar Reddy (tireddy) > > Cc: Jonathan Lennox; Sergio Garcia Murillo; Victor Pascual Avila; > draft-chenxin-behave-turn-websocket@tools.ietf.org > ; > tram@ietf.org > > Subject: Re: [tram] TURN over WebSocket > > > > > > > > > > > > On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar Reddy (tireddy) > > wrote: > > > > Transparent proxies like firewalls keep getting upgraded frequently > to handle new applications, threats etc. If firewall has a feature to > block WebRTC traffic then by sending traffic over WebSocket will not > solve the problem. > > > > > > > > (As a participant...) > > > > > > This has also been discussed before. TURN-over-WebSockets is not a > way for applications to circumvent policy. > > > > > > > > The problem is there are networks that are set up so that "the web" > is open, through a transparent proxy. WebRTC is part of "the web". > Making TURN fit the mould of "the web" is is not circumventing policy, > it's making WebRTC work. You should not need to update your > proxy/firewall config for WebRTC to just work if "the web" already > does work. > > > > > > > > [TR] Okay, so looks like the problem can also be solved by running > TURN over 443 similar to proposals in DPRIVE WG to run DNS over 443. > > > > > > Good try! Unlucky enough, doesn't work. > > Best regards > Sergio > --------------020602010000020206070709 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
We control the client and the server, and you are asking me to wait until what is not in our control is changed. Obviously, not working for me

BTW, I am talking about real life experiences, when WSS works and TURNS over 443 doesn't.

Best regards
Sergio

On 02/12/2014 20:44, Tirumaleswar Reddy (tireddy) wrote:

why will it not work when ALPN is used ?

 

-Tiru

 

From: Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com] ?

Sent: Wednesday, December 03, 2014 12:52 AM
To: Tirumaleswar Reddy (tireddy)
Cc: Jonathan Lennox; [ACME] Victor Pascual Avila; Simon Perreault; tram@ietf.org; draft-chenxin-behave-turn-websocket@tools.ietf.org
Subject: RE: [tram] TURN over WebSocket

 


El 02/12/2014 20:04, "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com> escribió:
>
> From: Simon Perreault [mailto:sperreault@jive.com]
> Sent: Tuesday, December 02, 2014 10:19 PM
>
> To: Tirumaleswar Reddy (tireddy)
> Cc: Jonathan Lennox; Sergio Garcia Murillo; Victor Pascual Avila; draft-chenxin-behave-turn-websocket@tools.ietf.org; tram@ietf.org
> Subject: Re: [tram] TURN over WebSocket
>
>  
>
>  
>
> On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:
>
> Transparent proxies like firewalls keep getting upgraded frequently to handle new applications, threats etc. If firewall has a feature to block WebRTC traffic then by sending traffic over WebSocket will not solve the problem.
>
>  
>
> (As a participant...)
>
>
> This has also been discussed before. TURN-over-WebSockets is not a way for applications to circumvent policy.
>
>  
>
> The problem is there are networks that are set up so that "the web" is open, through a transparent proxy. WebRTC is part of "the web". Making TURN fit the mould of "the web" is is not circumventing policy, it's making WebRTC work. You should not need to update your proxy/firewall config for WebRTC to just work if "the web" already does work.
>
>  
>
> [TR] Okay, so looks like the problem can also be solved by running TURN over 443 similar to proposals in DPRIVE WG to run DNS over 443.
>
>  

Good try! Unlucky enough, doesn't work.

Best regards
Sergio


--------------020602010000020206070709-- From nobody Tue Dec 2 16:58:15 2014 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 114401A8850 for ; Tue, 2 Dec 2014 16:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRMtogsk_RTF for ; Tue, 2 Dec 2014 16:58:12 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3E11A87EA for ; Tue, 2 Dec 2014 16:58:11 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E074228526; Wed, 3 Dec 2014 00:58:10 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id C1DE328521; Wed, 3 Dec 2014 00:58:10 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id B92DD8005C; Wed, 3 Dec 2014 00:58:10 +0000 (GMT) Message-ID: <547E6022.5030101@akamai.com> Date: Tue, 02 Dec 2014 19:58:10 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Sergio Garcia Murillo , "Tirumaleswar Reddy (tireddy)" References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B8E7@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B9B5@xmb-rcd-x10.cisco.com> <547E2069.4050307@gmail.com> In-Reply-To: <547E2069.4050307@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/RB2MDgRVlyLVVpRJIEjkrQnCiKE Cc: "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Jonathan Lennox , "\[ACME\] Victor Pascual Avila" , "tram@ietf.org" , Simon Perreault Subject: Re: [tram] TURN over WebSocket 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, 03 Dec 2014 00:58:14 -0000 What part of ALPN is not under your control? If you're doing WSS, then you've already got TLS in the picture, so ALPN and WSS seem to both solve the server-side multiplexing problem from the original problem statement. What part of the problem statement does WSS solve that ALPN does not? If you're concerned about unencrypted TURN multiplexing with unencrypted HTTP on port 80, then I can see WS solving a problem that ALPN can't solve. --Brandon On 12/02/2014 03:26 PM, Sergio Garcia Murillo wrote: > We control the client and the server, and you are asking me to wait > until what is not in our control is changed. Obviously, not working for me > > BTW, I am talking about real life experiences, when WSS works and TURNS > over 443 doesn't. > > Best regards > Sergio > > On 02/12/2014 20:44, Tirumaleswar Reddy (tireddy) wrote: >> >> why will it not work when ALPN is used ? >> >> -Tiru >> >> *From:*Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com] ? >> >> *Sent:* Wednesday, December 03, 2014 12:52 AM >> *To:* Tirumaleswar Reddy (tireddy) >> *Cc:* Jonathan Lennox; [ACME] Victor Pascual Avila; Simon Perreault; >> tram@ietf.org; draft-chenxin-behave-turn-websocket@tools.ietf.org >> *Subject:* RE: [tram] TURN over WebSocket >> >> >> El 02/12/2014 20:04, "Tirumaleswar Reddy (tireddy)" > > escribió: >> > >> > From: Simon Perreault [mailto:sperreault@jive.com >> ] >> > Sent: Tuesday, December 02, 2014 10:19 PM >> > >> > To: Tirumaleswar Reddy (tireddy) >> > Cc: Jonathan Lennox; Sergio Garcia Murillo; Victor Pascual Avila; >> draft-chenxin-behave-turn-websocket@tools.ietf.org >> ; >> tram@ietf.org >> > Subject: Re: [tram] TURN over WebSocket >> > >> > >> > >> > >> > >> > On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar Reddy (tireddy) >> > wrote: >> > >> > Transparent proxies like firewalls keep getting upgraded frequently >> to handle new applications, threats etc. If firewall has a feature to >> block WebRTC traffic then by sending traffic over WebSocket will not >> solve the problem. >> > >> > >> > >> > (As a participant...) >> > >> > >> > This has also been discussed before. TURN-over-WebSockets is not a >> way for applications to circumvent policy. >> > >> > >> > >> > The problem is there are networks that are set up so that "the web" >> is open, through a transparent proxy. WebRTC is part of "the web". >> Making TURN fit the mould of "the web" is is not circumventing policy, >> it's making WebRTC work. You should not need to update your >> proxy/firewall config for WebRTC to just work if "the web" already >> does work. >> > >> > >> > >> > [TR] Okay, so looks like the problem can also be solved by running >> TURN over 443 similar to proposals in DPRIVE WG to run DNS over 443. >> > >> > >> >> Good try! Unlucky enough, doesn't work. >> >> Best regards >> Sergio >> > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Tue Dec 2 19:45:10 2014 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 CCA341A0062 for ; Tue, 2 Dec 2014 19:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 RGFIyrzmumKK for ; Tue, 2 Dec 2014 19:45:06 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 991E51A0045 for ; Tue, 2 Dec 2014 19:45:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6747; q=dns/txt; s=iport; t=1417578306; x=1418787906; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vnO71QvsouXJSz+uU0hA2ddTezE1HTjsJTKm0zrcRqk=; b=Lpqr8n43iDtZzpb6f4imaGo2mT9E6sYlmkDVERiXT+2Xw4ddnu35fY8R tuefnipmjfoo/12FvKtmJruxpNWb6q/cbchdVZBkntf4gPoaO77OfaIe/ 1HO+duraSn4tIYvxPSQQ6L/7vVNg0xLSWh4LPO20S4NAvIIxGtmsEQcym g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAFWGflStJA2H/2dsb2JhbABbgkNEUlkExG6IRQKBFRYBAQEBAX2EAgEBAQQtTBACAQgRBAEBCx0HMhQJCAIEDgUIiDjWGwEBAQEBAQEBAQEBAQEBAQEBAQEBAReQPjEGAYMpgR8FkGGMUYx0gn+EAoN7b4FGgQEBAQE X-IronPort-AV: E=Sophos;i="5.07,505,1413244800"; d="scan'208,217";a="102122396" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-3.cisco.com with ESMTP; 03 Dec 2014 03:45:05 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sB33j5ni008108 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Dec 2014 03:45:05 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.204]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Tue, 2 Dec 2014 21:45:05 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Jonathan Lennox Thread-Topic: [tram] TURN over WebSocket Thread-Index: AdANiRFG6X70S29YQzixzirX+f0pqQAUXYoAAAPQ0HAAIo3igAAJyMCQ///OFwCAAEFhgP//8iCA///hqYA= Date: Wed, 3 Dec 2014 03:45:05 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2837BD5C@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B8E7@xmb-rcd-x10.cisco.com> <3569659C-2774-4152-9E9F-2E37D7EF89FF@vidyo.com> In-Reply-To: <3569659C-2774-4152-9E9F-2E37D7EF89FF@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.50.199] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A2837BD5Cxmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/fufwOCA8ZjMedRivPX5G9e3Zsmk Cc: "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Simon Perreault , Sergio Garcia Murillo , "tram@ietf.org" , Victor Pascual Avila Subject: Re: [tram] TURN over WebSocket 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, 03 Dec 2014 03:45:09 -0000 --_000_913383AAA69FF945B8F946018B75898A2837BD5Cxmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agreed it's a problem and but can be resolved using draft-ietf-tram-alpn. -Tiru From: Jonathan Lennox [mailto:jonathan@vidyo.com] Sent: Wednesday, December 03, 2014 1:24 AM To: Tirumaleswar Reddy (tireddy) Cc: Simon Perreault; Sergio Garcia Murillo; Victor Pascual Avila; draft-che= nxin-behave-turn-websocket@tools.ietf.org; tram@ietf.org Subject: Re: [tram] TURN over WebSocket On Dec 2, 2014, at 2:04 PM, Tirumaleswar Reddy (tireddy) > wrote: The problem is there are networks that are set up so that "the web" is open= , through a transparent proxy. WebRTC is part of "the web". Making TURN fit= the mould of "the web" is is not circumventing policy, it's making WebRTC = work. You should not need to update your proxy/firewall config for WebRTC t= o just work if "the web" already does work. [TR] Okay, so looks like the problem can also be solved by running TURN ove= r 443 similar to proposals in DPRIVE WG to run DNS over 443. Unfortunately, this forces you to get two IPv4 addresses - one for your htt= ps server, one for your TURN server - since they both have to listen on por= t 443. Due to IPv4 address exhaustion, this can be a substantial expense f= or small providers. --_000_913383AAA69FF945B8F946018B75898A2837BD5Cxmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agreed it’s a probl= em and but can be resolved using draft-ietf-tram-alpn.

 <= /p>

-Tiru

 <= /p>

From: Jonathan= Lennox [mailto:jonathan@vidyo.com]
Sent: Wednesday, December 03, 2014 1:24 AM
To: Tirumaleswar Reddy (tireddy)
Cc: Simon Perreault; Sergio Garcia Murillo; Victor Pascual Avila; dr= aft-chenxin-behave-turn-websocket@tools.ietf.org; tram@ietf.org
Subject: Re: [tram] TURN over WebSocket

 

 

On Dec 2, 2014, at 2:04 PM, Tirumaleswar Reddy (tire= ddy) <tireddy@cisco.com> wro= te:



 

The problem is there are networks that are set up so= that "the web" is open, through a transparent proxy. WebRTC is p= art of "the web". Making TURN fit the mould of "the web"= ; is is not circumventing policy, it's making WebRTC work. You should not need to update your proxy/firewall config for WebRTC to just work if &= quot;the web" already does work.

 <= /p>

[TR] Okay, so looks like = the problem can also be solved by running TURN over 443 similar to proposal= s in DPRIVE WG to run DNS over 443.

 

Unfortunately, this forces you to get two IPv4 addre= sses — one for your https server, one for your TURN server — si= nce they both have to listen on port 443.  Due to IPv4 address exhaust= ion, this can be a substantial expense for small providers.

 

--_000_913383AAA69FF945B8F946018B75898A2837BD5Cxmbrcdx10ciscoc_-- From nobody Wed Dec 3 00:29:06 2014 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 88AF61A6F2E for ; Tue, 2 Dec 2014 13:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 l6HSSNjtluot for ; Tue, 2 Dec 2014 13:55:42 -0800 (PST) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EACA1A6F40 for ; Tue, 2 Dec 2014 13:55:41 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id k14so18099367wgh.38 for ; Tue, 02 Dec 2014 13:55:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=7gRl3U5Rty4cNEVG0H//81zc7v3yc9sYEskb+53HkOE=; b=g8ZFjC2MKzv2WsXM2NIqH8ZkxEdwyJCrwm5ul5k5zZSaCkruRiMSZK/xWtStl6SKMm Fj6/X+M9Zqg0eC08AA64k7vfwd7BtisWawlGk3hTCa33JifTuFnrRD/NAF0AAg9HH4h0 OeHnEb89udNBsD1vQPswnsNJMbS/1ulqQhdj67UJoe/QBQyJ0jbf7Lw1wo0fDDK2gXVq 8Lq8VQFu4quI6AUtnB9q1E057G3VECTPbC4vIk/Qc4Wfm+lGkixwPW9lZW3NhxHE023C 5hQSQCQPM4/KLAtZ41SD/a5VTEu532QTZmjO3IKJdQW1JEndq/GtVkvXKxiiI1jTTdKM RHWw== X-Gm-Message-State: ALoCoQkkkTDNzOMZu981bPXQ1p7oYsB44DUfs3STYb7flhwC0KQE9LBT5yQPAoDT2EFvDqIiSToT X-Received: by 10.180.82.170 with SMTP id j10mr97450918wiy.35.1417557340473; Tue, 02 Dec 2014 13:55:40 -0800 (PST) Received: from [100.66.145.80] (36.212-142-235.dynamic.clientes.euskaltel.es. [212.142.235.36]) by mx.google.com with ESMTPSA id p1sm33606924wjy.22.2014.12.02.13.55.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Dec 2014 13:55:39 -0800 (PST) References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B8E7@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B9B5@xmb-rcd-x10.cisco.com> <547E2069.4050307@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <547E2069.4050307@gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-944EFB63-E39F-425F-8A57-D566F3382C1D Content-Transfer-Encoding: 7bit Message-Id: <400774A5-BCCF-4CD4-A805-D88C13C34E22@quobis.com> X-Mailer: iPhone Mail (11D201) From: Victor Pascual Date: Tue, 2 Dec 2014 22:55:24 +0100 To: Sergio Garcia Murillo Archived-At: http://mailarchive.ietf.org/arch/msg/tram/WdK9Jk_hxOLrUUDHanjntsUOR0c X-Mailman-Approved-At: Wed, 03 Dec 2014 00:29:04 -0800 Cc: Jonathan Lennox , "tram@ietf.org" , "\[ACME\] Victor Pascual Avila" , "Tirumaleswar Reddy \(tireddy\)" , "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Simon Perreault Subject: Re: [tram] TURN over WebSocket 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: Tue, 02 Dec 2014 21:55:45 -0000 --Apple-Mail-944EFB63-E39F-425F-8A57-D566F3382C1D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Agree with Sergio. We're experiencing the same -Victor > On Dec 2, 2014, at 9:26 PM, Sergio Garcia Murillo wrote: >=20 > We control the client and the server, and you are asking me to wait u= ntil what is not in our control is changed. Obviously, not working for me >=20 > BTW, I am talking about real life experiences, when WSS works and TURNS ov= er 443 doesn't.=20 >=20 > Best regards > Sergio >=20 >> On 02/12/2014 20:44, Tirumaleswar Reddy (tireddy) wrote: >> why will it not work when ALPN is used ? >> =20 >> -Tiru >> =20 >> From: Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com] ? >> Sent: Wednesday, December 03, 2014 12:52 AM >> To: Tirumaleswar Reddy (tireddy) >> Cc: Jonathan Lennox; [ACME] Victor Pascual Avila; Simon Perreault; tram@i= etf.org; draft-chenxin-behave-turn-websocket@tools.ietf.org >> Subject: RE: [tram] TURN over WebSocket >> =20 >>=20 >> El 02/12/2014 20:04, "Tirumaleswar Reddy (tireddy)" = escribi=C3=B3: >> > >> > From: Simon Perreault [mailto:sperreault@jive.com]=20 >> > Sent: Tuesday, December 02, 2014 10:19 PM >> > >> > To: Tirumaleswar Reddy (tireddy) >> > Cc: Jonathan Lennox; Sergio Garcia Murillo; Victor Pascual Avila; draft= -chenxin-behave-turn-websocket@tools.ietf.org; tram@ietf.org >> > Subject: Re: [tram] TURN over WebSocket >> > >> > =20 >> > >> > =20 >> > >> > On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar Reddy (tireddy) wrote: >> > >> > Transparent proxies like firewalls keep getting upgraded frequently to h= andle new applications, threats etc. If firewall has a feature to block WebR= TC traffic then by sending traffic over WebSocket will not solve the problem= . >> > >> > =20 >> > >> > (As a participant...) >> > >> > >> > This has also been discussed before. TURN-over-WebSockets is not a way f= or applications to circumvent policy. >> > >> > =20 >> > >> > The problem is there are networks that are set up so that "the web" is o= pen, through a transparent proxy. WebRTC is part of "the web". Making TURN f= it the mould of "the web" is is not circumventing policy, it's making WebRTC= work. You should not need to update your proxy/firewall config for WebRTC t= o just work if "the web" already does work. >> > >> > =20 >> > >> > [TR] Okay, so looks like the problem can also be solved by running TURN= over 443 similar to proposals in DPRIVE WG to run DNS over 443. >> > >> > =20 >>=20 >> Good try! Unlucky enough, doesn't work. >>=20 >> Best regards >> Sergio >>=20 >=20 --Apple-Mail-944EFB63-E39F-425F-8A57-D566F3382C1D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Agree with Sergio. We're experiencing t= he same

-Victor

On Dec 2, 2014, a= t 9:26 PM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

=20 =20 =20
We control the client and the server, and you are asking me to wait until what is not in our control is changed. Obviously, not working for me

BTW, I am talking about real life experiences, when WSS works and TURNS over 443 doesn't.

Best regards
Sergio

On 02/12/2014 20:44, Tirumaleswar Reddy (tireddy) wrote:

why will it not work when ALPN is used ?

 

-Tiru

 

From: Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com] ?

Sent: Wednesday, December 03, 2014 12:52 AM
To: Tirumaleswar Reddy (tireddy)
Cc: Jonathan Lennox; [ACME] Victor Pascual Avila; Simon Perreault; tram@ietf.org; draft-chenxin-behave-turn-web= socket@tools.ietf.org
Subject: RE: [tram] TURN over WebSocket<= /span>

 


El 02/12/2014 20:04, "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com&= gt; escribi=C3=B3:
>
> From: Simon Perreault [mailto:sperreault@jive.com]
> Sent: Tuesday, December 02, 2014 10:19 PM
>
> To: Tirumaleswar Reddy (tireddy)
> Cc: Jonathan Lennox; Sergio Garcia Murillo; Victor Pascual Avila; draft-chenxin-behave-turn-websocket@tools.ietf.org; tram@ietf.org
> Subject: Re: [tram] TURN over WebSocket
>
>  
>
>  
>
> On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:
>
> Transparent proxies like firewalls keep getting upgraded frequently to handle new applications, threats etc. If firewall has a feature to block WebRTC traffic then by sending traffic over WebSocket will not solve the problem.
>
>  
>
> (As a participant...)
>
>
> This has also been discussed before. TURN-over-WebSockets is not a way for applications to circumvent policy.
>
>  
>
> The problem is there are networks that are set up so that "the web" is open, through a transparent proxy. WebRTC is part of "the web". Making TURN fit the mould of "the web" is is not circumventing policy, it's making WebRTC work. You should not need to update your proxy/firewall config for WebRTC to just work if "the web" already does work.
>
>  
>
> [TR] Okay, so looks like the problem can also be solved by running TURN over 443 similar to proposals in DPRIVE WG to run DNS over 443.
>
>  

Good try! Unlucky enough, doesn't work.

Best regards
Sergio


=20
= --Apple-Mail-944EFB63-E39F-425F-8A57-D566F3382C1D-- From nobody Wed Dec 3 01:00:32 2014 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 C3F8C1A1A5B for ; Wed, 3 Dec 2014 01:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4eOIt7gMlCq for ; Wed, 3 Dec 2014 01:00:24 -0800 (PST) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0001A1A19 for ; Wed, 3 Dec 2014 01:00:24 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id E36941EB8421; Wed, 3 Dec 2014 10:00:22 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.125]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 10:00:22 +0100 From: "Hutton, Andrew" To: Victor Pascual , Sergio Garcia Murillo Thread-Topic: [tram] TURN over WebSocket Thread-Index: AQHQDtM3D1e3+t0AIUS5ldoZP7bRhJx9ioGw Date: Wed, 3 Dec 2014 09:00:22 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E61FB1B@MCHP04MSX.global-ad.net> References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B8E7@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B9B5@xmb-rcd-x10.cisco.com> <547E2069.4050307@gmail.com> <400774A5-BCCF-4CD4-A805-D88C13C34E22@quobis.com> In-Reply-To: <400774A5-BCCF-4CD4-A805-D88C13C34E22@quobis.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF1E61FB1BMCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ptLZsLLHShMVlWpZA6HrQxIETmo Cc: Jonathan Lennox , "tram@ietf.org" , "\[ACME\] Victor Pascual Avila" , "Tirumaleswar Reddy \(tireddy\)" , "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Simon Perreault Subject: Re: [tram] TURN over WebSocket 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, 03 Dec 2014 09:00:29 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF1E61FB1BMCHP04MSXglobal_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3b3VsZCBiZSBnb29kIHRvIGNsb3NlIGFzIG1hbnkgaG9sZXMgYXMgcG9zc2libGUgd2l0aCBy ZWdhcmRzIHRvIHdlYnJ0YyBjb25uZWN0aXZpdHkgYnV0IHdlIGhhdmUgdG8gYmUgY2xlYXIgb24g d2hpY2ggcGFydGljdWxhciBob2xlIHdlIGFyZSB0cnlpbmcgdG8gY2xvc2UuDQoNCklmIEkgcmVh ZCB0aGUgdGhyZWFkIGNvcnJlY3RseSBpdCBsb29rcyBsaWtlIHRoZSBjYXNlIHdlIGRvbuKAmXQg Y3VycmVudGx5IGhhdmUgYSBzb2x1dGlvbiBmb3IgaXMgd2hlbiB1c2luZyBhIHRyYW5zcGFyZW50 IHByb3h5IHdpdGggdW5lbmNyeXB0ZWQgVFVSTiBvbiBwb3J0IDgwLiAgSSB3b3VsZCBsaWtlIHRv IHVuZGVyc3RhbmQgd2h5IGluIHRoZSBzY2VuYXJpbyB0aGF0IFNlcmdpbyBtZW50aW9uZWQgdGhh dCBXU1Mgd29ya3MgYnV0IG5vdCBUVVJOUyBvdmVyIDQ0MyBhbmQgd2hldGhlciBzdXBwb3J0IGZv ciBBTFBOIHdvdWxkIGZpeCB0aGF0Lg0KDQpUaGlzIGlzIGFsbCBhYm91dCB3ZWJydGMgc28gSSB0 aGluayB0aGVyZSBpcyBhbiBpc3N1ZSBhbHNvIHdpdGggaW5jcmVhc2luZyBjb21wbGV4aXR5IGlu IHRoZSBicm93c2VyIHdoaWNoIG5lZWRzIHRvIGltcGxlbWVudCBhbGwgdGhlIGRpZmZlcmVudCBt ZWNoYW5pc21zIGFuZCBhbHNvIHByb2JhYmx5IGEgYmlnZ2VyIGlzc3VlIGlzIGdldHRpbmcgdGhl IHJ0Y3dlYiB3b3JraW5nIGdyb3VwIGFuZCB0aGUgYnJvd3NlciB2ZW5kb3JzIHRvIHN1cHBvcnQg dGhpcyBtZWNoYW5pc20gYW5kIHJlZmVyIHRvIGl0IGluIGRyYWZ0LWlldGYtcnRjd2ViLXRyYW5z cG9ydHMuDQoNClNvIEkgd291bGQgc2F5IEkgYW0gc3ltcGF0aGV0aWMgdG8gdGhpcyBidXQgbm90 IHlldCB0b3RhbGx5IGNvbnZpbmNlZCBpdCBjbG9zZXMgYSBiaWcgZW5vdWdoIGhvbGUgdG8gbWFr ZSBpdCBjb21wZWxsaW5nIGZvciB0aGUgYnJvd3NlciB2ZW5kb3JzIHRvIGltcGxlbWVudC4NCg0K UmVnYXJkcw0KQW5keQ0KDQoNCg0KDQpGcm9tOiB0cmFtIFttYWlsdG86dHJhbS1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgVmljdG9yIFBhc2N1YWwNClNlbnQ6IDAyIERlY2VtYmVyIDIw MTQgMjE6NTUNClRvOiBTZXJnaW8gR2FyY2lhIE11cmlsbG8NCkNjOiBKb25hdGhhbiBMZW5ub3g7 IHRyYW1AaWV0Zi5vcmc7IFtBQ01FXSBWaWN0b3IgUGFzY3VhbCBBdmlsYTsgVGlydW1hbGVzd2Fy IFJlZGR5ICh0aXJlZGR5KTsgZHJhZnQtY2hlbnhpbi1iZWhhdmUtdHVybi13ZWJzb2NrZXRAdG9v bHMuaWV0Zi5vcmc7IFNpbW9uIFBlcnJlYXVsdA0KU3ViamVjdDogUmU6IFt0cmFtXSBUVVJOIG92 ZXIgV2ViU29ja2V0DQoNCkFncmVlIHdpdGggU2VyZ2lvLiBXZSdyZSBleHBlcmllbmNpbmcgdGhl IHNhbWUNCg0KLVZpY3Rvcg0KDQpPbiBEZWMgMiwgMjAxNCwgYXQgOToyNiBQTSwgU2VyZ2lvIEdh cmNpYSBNdXJpbGxvIDxzZXJnaW8uZ2FyY2lhLm11cmlsbG9AZ21haWwuY29tPG1haWx0bzpzZXJn aW8uZ2FyY2lhLm11cmlsbG9AZ21haWwuY29tPj4gd3JvdGU6DQpXZSBjb250cm9sIHRoZSBjbGll bnQgYW5kIHRoZSBzZXJ2ZXIsIGFuZCB5b3UgYXJlIGFza2luZyBtZSB0byB3YWl0IHVudGlsIHdo YXQgaXMgbm90IGluIG91ciBjb250cm9sIGlzIGNoYW5nZWQuIE9idmlvdXNseSwgbm90IHdvcmtp bmcgZm9yIG1lDQoNCkJUVywgSSBhbSB0YWxraW5nIGFib3V0IHJlYWwgbGlmZSBleHBlcmllbmNl cywgd2hlbiBXU1Mgd29ya3MgYW5kIFRVUk5TIG92ZXIgNDQzIGRvZXNuJ3QuDQoNCkJlc3QgcmVn YXJkcw0KU2VyZ2lvDQoNCk9uIDAyLzEyLzIwMTQgMjA6NDQsIFRpcnVtYWxlc3dhciBSZWRkeSAo dGlyZWRkeSkgd3JvdGU6DQp3aHkgd2lsbCBpdCBub3Qgd29yayB3aGVuIEFMUE4gaXMgdXNlZCA/ DQoNCi1UaXJ1DQoNCkZyb206IFNlcmdpbyBHYXJjaWEgTXVyaWxsbyBbbWFpbHRvOnNlcmdpby5n YXJjaWEubXVyaWxsb0BnbWFpbC5jb21dID8NClNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMDMs IDIwMTQgMTI6NTIgQU0NClRvOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQpDYzogSm9u YXRoYW4gTGVubm94OyBbQUNNRV0gVmljdG9yIFBhc2N1YWwgQXZpbGE7IFNpbW9uIFBlcnJlYXVs dDsgdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz47IGRyYWZ0LWNoZW54aW4tYmVo YXZlLXR1cm4td2Vic29ja2V0QHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1jaGVueGluLWJl aGF2ZS10dXJuLXdlYnNvY2tldEB0b29scy5pZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbdHJhbV0g VFVSTiBvdmVyIFdlYlNvY2tldA0KDQoNCkVsIDAyLzEyLzIwMTQgMjA6MDQsICJUaXJ1bWFsZXN3 YXIgUmVkZHkgKHRpcmVkZHkpIiA8dGlyZWRkeUBjaXNjby5jb208bWFpbHRvOnRpcmVkZHlAY2lz Y28uY29tPj4gZXNjcmliacOzOg0KPg0KPiBGcm9tOiBTaW1vbiBQZXJyZWF1bHQgW21haWx0bzpz cGVycmVhdWx0QGppdmUuY29tPG1haWx0bzpzcGVycmVhdWx0QGppdmUuY29tPl0NCj4gU2VudDog VHVlc2RheSwgRGVjZW1iZXIgMDIsIDIwMTQgMTA6MTkgUE0NCj4NCj4gVG86IFRpcnVtYWxlc3dh ciBSZWRkeSAodGlyZWRkeSkNCj4gQ2M6IEpvbmF0aGFuIExlbm5veDsgU2VyZ2lvIEdhcmNpYSBN dXJpbGxvOyBWaWN0b3IgUGFzY3VhbCBBdmlsYTsgZHJhZnQtY2hlbnhpbi1iZWhhdmUtdHVybi13 ZWJzb2NrZXRAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWNoZW54aW4tYmVoYXZlLXR1cm4t d2Vic29ja2V0QHRvb2xzLmlldGYub3JnPjsgdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRm Lm9yZz4NCj4gU3ViamVjdDogUmU6IFt0cmFtXSBUVVJOIG92ZXIgV2ViU29ja2V0DQo+DQo+DQo+ DQo+DQo+DQo+IE9uIFR1ZSwgRGVjIDIsIDIwMTQgYXQgOTozNCBBTSwgVGlydW1hbGVzd2FyIFJl ZGR5ICh0aXJlZGR5KSA8dGlyZWRkeUBjaXNjby5jb208bWFpbHRvOnRpcmVkZHlAY2lzY28uY29t Pj4gd3JvdGU6DQo+DQo+IFRyYW5zcGFyZW50IHByb3hpZXMgbGlrZSBmaXJld2FsbHMga2VlcCBn ZXR0aW5nIHVwZ3JhZGVkIGZyZXF1ZW50bHkgdG8gaGFuZGxlIG5ldyBhcHBsaWNhdGlvbnMsIHRo cmVhdHMgZXRjLiBJZiBmaXJld2FsbCBoYXMgYSBmZWF0dXJlIHRvIGJsb2NrIFdlYlJUQyB0cmFm ZmljIHRoZW4gYnkgc2VuZGluZyB0cmFmZmljIG92ZXIgV2ViU29ja2V0IHdpbGwgbm90IHNvbHZl IHRoZSBwcm9ibGVtLg0KPg0KPg0KPg0KPiAoQXMgYSBwYXJ0aWNpcGFudC4uLikNCj4NCj4NCj4g VGhpcyBoYXMgYWxzbyBiZWVuIGRpc2N1c3NlZCBiZWZvcmUuIFRVUk4tb3Zlci1XZWJTb2NrZXRz IGlzIG5vdCBhIHdheSBmb3IgYXBwbGljYXRpb25zIHRvIGNpcmN1bXZlbnQgcG9saWN5Lg0KPg0K Pg0KPg0KPiBUaGUgcHJvYmxlbSBpcyB0aGVyZSBhcmUgbmV0d29ya3MgdGhhdCBhcmUgc2V0IHVw IHNvIHRoYXQgInRoZSB3ZWIiIGlzIG9wZW4sIHRocm91Z2ggYSB0cmFuc3BhcmVudCBwcm94eS4g V2ViUlRDIGlzIHBhcnQgb2YgInRoZSB3ZWIiLiBNYWtpbmcgVFVSTiBmaXQgdGhlIG1vdWxkIG9m ICJ0aGUgd2ViIiBpcyBpcyBub3QgY2lyY3VtdmVudGluZyBwb2xpY3ksIGl0J3MgbWFraW5nIFdl YlJUQyB3b3JrLiBZb3Ugc2hvdWxkIG5vdCBuZWVkIHRvIHVwZGF0ZSB5b3VyIHByb3h5L2ZpcmV3 YWxsIGNvbmZpZyBmb3IgV2ViUlRDIHRvIGp1c3Qgd29yayBpZiAidGhlIHdlYiIgYWxyZWFkeSBk b2VzIHdvcmsuDQo+DQo+DQo+DQo+IFtUUl0gT2theSwgc28gbG9va3MgbGlrZSB0aGUgcHJvYmxl bSBjYW4gYWxzbyBiZSBzb2x2ZWQgYnkgcnVubmluZyBUVVJOIG92ZXIgNDQzIHNpbWlsYXIgdG8g cHJvcG9zYWxzIGluIERQUklWRSBXRyB0byBydW4gRE5TIG92ZXIgNDQzLg0KPg0KPg0KDQpHb29k IHRyeSEgVW5sdWNreSBlbm91Z2gsIGRvZXNuJ3Qgd29yay4NCg0KQmVzdCByZWdhcmRzDQpTZXJn aW8NCg0K --_000_9F33F40F6F2CD847824537F3C4E37DDF1E61FB1BMCHP04MSXglobal_ 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 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENo YXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4 LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+SSB3b3VsZCBiZSBnb29kIHRvIGNsb3NlIGFzIG1hbnkgaG9sZXMg YXMgcG9zc2libGUgd2l0aCByZWdhcmRzIHRvIHdlYnJ0YyBjb25uZWN0aXZpdHkgYnV0IHdlIGhh dmUgdG8gYmUgY2xlYXIgb24gd2hpY2ggcGFydGljdWxhciBob2xlIHdlIGFyZSB0cnlpbmcgdG8g Y2xvc2UuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIEkgcmVhZCB0aGUgdGhyZWFkIGNvcnJlY3RseSBpdCBsb29r cyBsaWtlIHRoZSBjYXNlIHdlIGRvbuKAmXQgY3VycmVudGx5IGhhdmUgYSBzb2x1dGlvbiBmb3Ig aXMgd2hlbiB1c2luZyBhIHRyYW5zcGFyZW50IHByb3h5IHdpdGggdW5lbmNyeXB0ZWQgVFVSTiBv biBwb3J0DQogODAuJm5ic3A7IEkgd291bGQgbGlrZSB0byB1bmRlcnN0YW5kIHdoeSBpbiB0aGUg c2NlbmFyaW8gdGhhdCBTZXJnaW8gbWVudGlvbmVkIHRoYXQgV1NTIHdvcmtzIGJ1dCBub3QgVFVS TlMgb3ZlciA0NDMgYW5kIHdoZXRoZXIgc3VwcG9ydCBmb3IgQUxQTiB3b3VsZCBmaXggdGhhdC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlRoaXMgaXMgYWxsIGFib3V0IHdlYnJ0YyBzbyBJIHRoaW5rIHRoZXJlIGlzIGFu IGlzc3VlIGFsc28gd2l0aCBpbmNyZWFzaW5nIGNvbXBsZXhpdHkgaW4gdGhlIGJyb3dzZXIgd2hp Y2ggbmVlZHMgdG8gaW1wbGVtZW50IGFsbCB0aGUgZGlmZmVyZW50IG1lY2hhbmlzbXMgYW5kDQog YWxzbyBwcm9iYWJseSBhIGJpZ2dlciBpc3N1ZSBpcyBnZXR0aW5nIHRoZSBydGN3ZWIgd29ya2lu ZyBncm91cCBhbmQgdGhlIGJyb3dzZXIgdmVuZG9ycyB0byBzdXBwb3J0IHRoaXMgbWVjaGFuaXNt IGFuZCByZWZlciB0byBpdCBpbiBkcmFmdC1pZXRmLXJ0Y3dlYi10cmFuc3BvcnRzLg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5TbyBJIHdvdWxkIHNheSBJIGFtIHN5bXBhdGhldGljIHRvIHRoaXMgYnV0IG5vdCB5ZXQg dG90YWxseSBjb252aW5jZWQgaXQgY2xvc2VzIGEgYmlnIGVub3VnaCBob2xlIHRvIG1ha2UgaXQg Y29tcGVsbGluZyBmb3IgdGhlIGJyb3dzZXIgdmVuZG9ycyB0byBpbXBsZW1lbnQuDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QW5keTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiB0cmFtIFttYWlsdG86dHJhbS1ib3VuY2Vz QGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5WaWN0b3IgUGFzY3VhbDxicj4NCjxiPlNl bnQ6PC9iPiAwMiBEZWNlbWJlciAyMDE0IDIxOjU1PGJyPg0KPGI+VG86PC9iPiBTZXJnaW8gR2Fy Y2lhIE11cmlsbG88YnI+DQo8Yj5DYzo8L2I+IEpvbmF0aGFuIExlbm5veDsgdHJhbUBpZXRmLm9y ZzsgW0FDTUVdIFZpY3RvciBQYXNjdWFsIEF2aWxhOyBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVk ZHkpOyBkcmFmdC1jaGVueGluLWJlaGF2ZS10dXJuLXdlYnNvY2tldEB0b29scy5pZXRmLm9yZzsg U2ltb24gUGVycmVhdWx0PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHJhbV0gVFVSTiBvdmVy IFdlYlNvY2tldDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5BZ3JlZSB3aXRoIFNlcmdpby4gV2UncmUgZXhwZXJpZW5jaW5nIHRoZSBzYW1lPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1WaWN0 b3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gRGVjIDIsIDIwMTQsIGF0IDk6MjYg UE0sIFNlcmdpbyBHYXJjaWEgTXVyaWxsbyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNlcmdpby5nYXJj aWEubXVyaWxsb0BnbWFpbC5jb20iPnNlcmdpby5nYXJjaWEubXVyaWxsb0BnbWFpbC5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPldlIGNvbnRyb2wgdGhlIGNsaWVudCBhbmQgdGhlIHNlcnZlciwgYW5k IHlvdSBhcmUgYXNraW5nIG1lIHRvIHdhaXQgdW50aWwgd2hhdCBpcyBub3QgaW4gb3VyIGNvbnRy b2wgaXMgY2hhbmdlZC4gT2J2aW91c2x5LCBub3Qgd29ya2luZyBmb3IgbWU8YnI+DQo8YnI+DQpC VFcsIEkgYW0gdGFsa2luZyBhYm91dCByZWFsIGxpZmUgZXhwZXJpZW5jZXMsIHdoZW4gV1NTIHdv cmtzIGFuZCBUVVJOUyBvdmVyIDQ0MyBkb2Vzbid0Lg0KPGJyPg0KPGJyPg0KQmVzdCByZWdhcmRz PGJyPg0KU2VyZ2lvPGJyPg0KPGJyPg0KT24gMDIvMTIvMjAxNCAyMDo0NCwgVGlydW1hbGVzd2Fy IFJlZGR5ICh0aXJlZGR5KSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ d2h5IHdpbGwgaXQgbm90IHdvcmsgd2hlbiBBTFBOIGlzIHVzZWQgPzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LVRpcnU8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gU2VyZ2lvIEdhcmNp YSBNdXJpbGxvIFs8YSBocmVmPSJtYWlsdG86c2VyZ2lvLmdhcmNpYS5tdXJpbGxvQGdtYWlsLmNv bSI+bWFpbHRvOnNlcmdpby5nYXJjaWEubXVyaWxsb0BnbWFpbC5jb208L2E+XQ0KID88L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNl bnQ6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFdlZG5lc2RheSwgRGVj ZW1iZXIgMDMsIDIwMTQgMTI6NTIgQU08YnI+DQo8Yj5Ubzo8L2I+IFRpcnVtYWxlc3dhciBSZWRk eSAodGlyZWRkeSk8YnI+DQo8Yj5DYzo8L2I+IEpvbmF0aGFuIExlbm5veDsgW0FDTUVdIFZpY3Rv ciBQYXNjdWFsIEF2aWxhOyBTaW1vbiBQZXJyZWF1bHQ7IDxhIGhyZWY9Im1haWx0bzp0cmFtQGll dGYub3JnIj4NCnRyYW1AaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtY2hlbnhp bi1iZWhhdmUtdHVybi13ZWJzb2NrZXRAdG9vbHMuaWV0Zi5vcmciPg0KZHJhZnQtY2hlbnhpbi1i ZWhhdmUtdHVybi13ZWJzb2NrZXRAdG9vbHMuaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJFOiBbdHJhbV0gVFVSTiBvdmVyIFdlYlNvY2tldDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwPjxicj4NCkVsIDAyLzEyLzIwMTQgMjA6MDQsICZxdW90O1RpcnVtYWxlc3dhciBSZWRk eSAodGlyZWRkeSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbSI+ dGlyZWRkeUBjaXNjby5jb208L2E+Jmd0OyBlc2NyaWJpw7M6PGJyPg0KJmd0Ozxicj4NCiZndDsg RnJvbTogU2ltb24gUGVycmVhdWx0IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNwZXJyZWF1bHRA aml2ZS5jb20iPnNwZXJyZWF1bHRAaml2ZS5jb208L2E+XQ0KPGJyPg0KJmd0OyBTZW50OiBUdWVz ZGF5LCBEZWNlbWJlciAwMiwgMjAxNCAxMDoxOSBQTTxicj4NCiZndDs8YnI+DQomZ3Q7IFRvOiBU aXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpPGJyPg0KJmd0OyBDYzogSm9uYXRoYW4gTGVubm94 OyBTZXJnaW8gR2FyY2lhIE11cmlsbG87IFZpY3RvciBQYXNjdWFsIEF2aWxhOyA8YSBocmVmPSJt YWlsdG86ZHJhZnQtY2hlbnhpbi1iZWhhdmUtdHVybi13ZWJzb2NrZXRAdG9vbHMuaWV0Zi5vcmci Pg0KZHJhZnQtY2hlbnhpbi1iZWhhdmUtdHVybi13ZWJzb2NrZXRAdG9vbHMuaWV0Zi5vcmc8L2E+ OyA8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyI+DQp0cmFtQGlldGYub3JnPC9hPjxicj4N CiZndDsgU3ViamVjdDogUmU6IFt0cmFtXSBUVVJOIG92ZXIgV2ViU29ja2V0PGJyPg0KJmd0Ozxi cj4NCiZndDsgJm5ic3A7PGJyPg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7PGJyPg0KJmd0Ozxicj4N CiZndDsgT24gVHVlLCBEZWMgMiwgMjAxNCBhdCA5OjM0IEFNLCBUaXJ1bWFsZXN3YXIgUmVkZHkg KHRpcmVkZHkpICZsdDs8YSBocmVmPSJtYWlsdG86dGlyZWRkeUBjaXNjby5jb20iPnRpcmVkZHlA Y2lzY28uY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgVHJhbnNwYXJlbnQg cHJveGllcyBsaWtlIGZpcmV3YWxscyBrZWVwIGdldHRpbmcgdXBncmFkZWQgZnJlcXVlbnRseSB0 byBoYW5kbGUgbmV3IGFwcGxpY2F0aW9ucywgdGhyZWF0cyBldGMuIElmIGZpcmV3YWxsIGhhcyBh IGZlYXR1cmUgdG8gYmxvY2sgV2ViUlRDIHRyYWZmaWMgdGhlbiBieSBzZW5kaW5nIHRyYWZmaWMg b3ZlciBXZWJTb2NrZXQgd2lsbCBub3Qgc29sdmUgdGhlIHByb2JsZW0uPGJyPg0KJmd0Ozxicj4N CiZndDsgJm5ic3A7PGJyPg0KJmd0Ozxicj4NCiZndDsgKEFzIGEgcGFydGljaXBhbnQuLi4pPGJy Pg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFRoaXMgaGFzIGFsc28gYmVlbiBkaXNjdXNzZWQg YmVmb3JlLiBUVVJOLW92ZXItV2ViU29ja2V0cyBpcyBub3QgYSB3YXkgZm9yIGFwcGxpY2F0aW9u cyB0byBjaXJjdW12ZW50IHBvbGljeS48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDs8YnI+DQom Z3Q7PGJyPg0KJmd0OyBUaGUgcHJvYmxlbSBpcyB0aGVyZSBhcmUgbmV0d29ya3MgdGhhdCBhcmUg c2V0IHVwIHNvIHRoYXQgJnF1b3Q7dGhlIHdlYiZxdW90OyBpcyBvcGVuLCB0aHJvdWdoIGEgdHJh bnNwYXJlbnQgcHJveHkuIFdlYlJUQyBpcyBwYXJ0IG9mICZxdW90O3RoZSB3ZWImcXVvdDsuIE1h a2luZyBUVVJOIGZpdCB0aGUgbW91bGQgb2YgJnF1b3Q7dGhlIHdlYiZxdW90OyBpcyBpcyBub3Qg Y2lyY3VtdmVudGluZyBwb2xpY3ksIGl0J3MgbWFraW5nIFdlYlJUQyB3b3JrLiBZb3Ugc2hvdWxk IG5vdCBuZWVkIHRvIHVwZGF0ZQ0KIHlvdXIgcHJveHkvZmlyZXdhbGwgY29uZmlnIGZvciBXZWJS VEMgdG8ganVzdCB3b3JrIGlmICZxdW90O3RoZSB3ZWImcXVvdDsgYWxyZWFkeSBkb2VzIHdvcmsu PGJyPg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7PGJyPg0KJmd0Ozxicj4NCiZndDsgW1RSXSBPa2F5 LCBzbyBsb29rcyBsaWtlIHRoZSBwcm9ibGVtIGNhbiBhbHNvIGJlIHNvbHZlZCBieSBydW5uaW5n IFRVUk4gb3ZlciA0NDMgc2ltaWxhciB0byBwcm9wb3NhbHMgaW4gRFBSSVZFIFdHIHRvIHJ1biBE TlMgb3ZlciA0NDMuPGJyPg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7PG86cD48L286cD48L3A+DQo8 cD5Hb29kIHRyeSEgVW5sdWNreSBlbm91Z2gsIGRvZXNuJ3Qgd29yay4gPG86cD48L286cD48L3A+ DQo8cD5CZXN0IHJlZ2FyZHM8YnI+DQpTZXJnaW88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9F33F40F6F2CD847824537F3C4E37DDF1E61FB1BMCHP04MSXglobal_-- From nobody Wed Dec 3 01:13:59 2014 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 349581A01F2 for ; Wed, 3 Dec 2014 01:13:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 C4AKaVSaZyIV for ; Wed, 3 Dec 2014 01:13:54 -0800 (PST) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 002691A01E1 for ; Wed, 3 Dec 2014 01:13:53 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id a1so19182554wgh.11 for ; Wed, 03 Dec 2014 01:13:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=1knMppQ5CcSpfmWm3T2PEr9xgJXZKe3E+Ik67xWmxeM=; b=TyJzZ6DQvGORuKDYcrTNHOQBSyTCdj9bIagDIekhKtvdjiDfpUzhpFKWYlBm+cCPtQ tASb/YwgSQ1+Rzmu2MKSX8Ynl0MkQmrjqwb34fal4dgGBer3ng05x9ENUAkB1fuoATth y8cB15yIp+vm/h5TDF6t/eTXHQFtIR/LeCkrybxnRTnfgm0e9cWnx2hHoyCMkUb8SX+9 cO85AFLwpWp/InlEGToTMhrzx1JpGUgX29Elnw97ODYxEsbvk/s/N0SLV5V8HwuWZdO7 acpCcv9zo2pGXMNlb2nqQ+st03phOPdZsrHPzfYLT48nNCPrLawFU69io4vUmLLnRRjD wDNA== X-Received: by 10.180.108.167 with SMTP id hl7mr11637179wib.68.1417598032632; Wed, 03 Dec 2014 01:13:52 -0800 (PST) Received: from [192.168.1.37] (136.Red-81-39-109.dynamicIP.rima-tde.net. [81.39.109.136]) by mx.google.com with ESMTPSA id vy7sm35412611wjc.27.2014.12.03.01.13.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 01:13:51 -0800 (PST) Message-ID: <547ED451.1020307@gmail.com> Date: Wed, 03 Dec 2014 10:13:53 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Hutton, Andrew" , Victor Pascual References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B8E7@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B9B5@xmb-rcd-x10.cisco.com> <547E2069.4050307@gmail.com> <400774A5-BCCF-4CD4-A805-D88C13C34E22@quobis.com> <9F33F40F6F2CD847824537F3C4E37DDF1E61FB1B@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E61FB1B@MCHP04MSX.global-ad.net> Content-Type: multipart/alternative; boundary="------------060505050308080704020109" Archived-At: http://mailarchive.ietf.org/arch/msg/tram/vF1aP61N42-nWVM4vOTcRaZAURY Cc: Jonathan Lennox , "tram@ietf.org" , "\[ACME\] Victor Pascual Avila" , "Tirumaleswar Reddy \(tireddy\)" , "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Simon Perreault Subject: Re: [tram] TURN over WebSocket 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, 03 Dec 2014 09:13:57 -0000 This is a multi-part message in MIME format. --------------060505050308080704020109 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Andrew, Completely agree with your statements, my concerns are about been able to have the same level of connectivity in webrtc than in other proprietary solutions (like Skype/Webex). In my setup I have TURN over udp and tcp and TURNS at port 443, and I still having issues in some scenarios when TURN is failing to connect. In those scenarios I have no problems at all with the signaling which goes over WSS. I don't have anything personal in favor of turn over ws, but I (and propably any company trying to do any kind of busyness arround webrtc) need a solution that can be deployed in a "months" time frame and not a "years" one, and that don't have the prerequisite of been in control of the intermediary elements (FW,s proxies, etc). So if there is any other solution easier and better than the one we are proposing I will be more than willing to collaborate with it. Best regards Sergio On 03/12/2014 10:00, Hutton, Andrew wrote: > > I would be good to close as many holes as possible with regards to > webrtc connectivity but we have to be clear on which particular hole > we are trying to close. > > If I read the thread correctly it looks like the case we don’t > currently have a solution for is when using a transparent proxy with > unencrypted TURN on port 80. I would like to understand why in the > scenario that Sergio mentioned that WSS works but not TURNS over 443 > and whether support for ALPN would fix that. > > This is all about webrtc so I think there is an issue also with > increasing complexity in the browser which needs to implement all the > different mechanisms and also probably a bigger issue is getting the > rtcweb working group and the browser vendors to support this mechanism > and refer to it in draft-ietf-rtcweb-transports. > > So I would say I am sympathetic to this but not yet totally convinced > it closes a big enough hole to make it compelling for the browser > vendors to implement. > > Regards > > Andy > > *From:*tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Victor Pascual > *Sent:* 02 December 2014 21:55 > *To:* Sergio Garcia Murillo > *Cc:* Jonathan Lennox; tram@ietf.org; [ACME] Victor Pascual Avila; > Tirumaleswar Reddy (tireddy); > draft-chenxin-behave-turn-websocket@tools.ietf.org; Simon Perreault > *Subject:* Re: [tram] TURN over WebSocket > > Agree with Sergio. We're experiencing the same > > -Victor > > > On Dec 2, 2014, at 9:26 PM, Sergio Garcia Murillo > > wrote: > > We control the client and the server, and you are asking me to > wait until what is not in our control is changed. Obviously, not > working for me > > BTW, I am talking about real life experiences, when WSS works and > TURNS over 443 doesn't. > > Best regards > Sergio > > On 02/12/2014 20:44, Tirumaleswar Reddy (tireddy) wrote: > > why will it not work when ALPN is used ? > > -Tiru > > *From:*Sergio Garcia Murillo > [mailto:sergio.garcia.murillo@gmail.com] ? > > *Sent:*Wednesday, December 03, 2014 12:52 AM > *To:* Tirumaleswar Reddy (tireddy) > *Cc:* Jonathan Lennox; [ACME] Victor Pascual Avila; Simon > Perreault; tram@ietf.org ; > draft-chenxin-behave-turn-websocket@tools.ietf.org > > *Subject:* RE: [tram] TURN over WebSocket > > > El 02/12/2014 20:04, "Tirumaleswar Reddy (tireddy)" > > escribió: > > > > From: Simon Perreault [mailto:sperreault@jive.com > ] > > Sent: Tuesday, December 02, 2014 10:19 PM > > > > To: Tirumaleswar Reddy (tireddy) > > Cc: Jonathan Lennox; Sergio Garcia Murillo; Victor Pascual > Avila; draft-chenxin-behave-turn-websocket@tools.ietf.org > ; > tram@ietf.org > > Subject: Re: [tram] TURN over WebSocket > > > > > > > > > > > > On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar Reddy (tireddy) > > wrote: > > > > Transparent proxies like firewalls keep getting upgraded > frequently to handle new applications, threats etc. If > firewall has a feature to block WebRTC traffic then by sending > traffic over WebSocket will not solve the problem. > > > > > > > > (As a participant...) > > > > > > This has also been discussed before. TURN-over-WebSockets is > not a way for applications to circumvent policy. > > > > > > > > The problem is there are networks that are set up so that > "the web" is open, through a transparent proxy. WebRTC is part > of "the web". Making TURN fit the mould of "the web" is is not > circumventing policy, it's making WebRTC work. You should not > need to update your proxy/firewall config for WebRTC to just > work if "the web" already does work. > > > > > > > > [TR] Okay, so looks like the problem can also be solved by > running TURN over 443 similar to proposals in DPRIVE WG to run > DNS over 443. > > > > > > Good try! Unlucky enough, doesn't work. > > Best regards > Sergio > --------------060505050308080704020109 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hi Andrew,

Completely agree with your statements, my concerns are about been able to have the same level of connectivity in webrtc than in other proprietary solutions (like Skype/Webex).

In my setup I have TURN over udp and  tcp and TURNS at port 443, and I still having issues in some scenarios when TURN is failing to connect. In those scenarios I have no problems at all with the signaling which goes over WSS.

I don't have anything personal in favor of turn over ws, but I (and propably any company trying to do any kind of busyness arround webrtc) need a solution that can be deployed in a "months" time frame and not a "years" one, and that don't have the prerequisite of been in control of the intermediary elements (FW,s proxies, etc). So if there is any other solution easier and better than the one we are proposing I will be more than willing to collaborate with it.

Best regards
Sergio

On 03/12/2014 10:00, Hutton, Andrew wrote:

I would be good to close as many holes as possible with regards to webrtc connectivity but we have to be clear on which particular hole we are trying to close.

 

If I read the thread correctly it looks like the case we don’t currently have a solution for is when using a transparent proxy with unencrypted TURN on port 80.  I would like to understand why in the scenario that Sergio mentioned that WSS works but not TURNS over 443 and whether support for ALPN would fix that.

 

This is all about webrtc so I think there is an issue also with increasing complexity in the browser which needs to implement all the different mechanisms and also probably a bigger issue is getting the rtcweb working group and the browser vendors to support this mechanism and refer to it in draft-ietf-rtcweb-transports.

 

So I would say I am sympathetic to this but not yet totally convinced it closes a big enough hole to make it compelling for the browser vendors to implement.

 

Regards

Andy

 

 

 

 

From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Victor Pascual
Sent: 02 December 2014 21:55
To: Sergio Garcia Murillo
Cc: Jonathan Lennox; tram@ietf.org; [ACME] Victor Pascual Avila; Tirumaleswar Reddy (tireddy); draft-chenxin-behave-turn-websocket@tools.ietf.org; Simon Perreault
Subject: Re: [tram] TURN over WebSocket

 

Agree with Sergio. We're experiencing the same

 

-Victor


On Dec 2, 2014, at 9:26 PM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

We control the client and the server, and you are asking me to wait until what is not in our control is changed. Obviously, not working for me

BTW, I am talking about real life experiences, when WSS works and TURNS over 443 doesn't.

Best regards
Sergio

On 02/12/2014 20:44, Tirumaleswar Reddy (tireddy) wrote:

why will it not work when ALPN is used ?

 

-Tiru

 

From: Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com] ?

Sent: Wednesday, December 03, 2014 12:52 AM
To: Tirumaleswar Reddy (tireddy)
Cc: Jonathan Lennox; [ACME] Victor Pascual Avila; Simon Perreault; tram@ietf.org; draft-chenxin-behave-turn-websocket@tools.ietf.org
Subject: RE: [tram] TURN over WebSocket

 


El 02/12/2014 20:04, "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com> escribió:
>
> From: Simon Perreault [mailto:sperreault@jive.com]
> Sent: Tuesday, December 02, 2014 10:19 PM
>
> To: Tirumaleswar Reddy (tireddy)
> Cc: Jonathan Lennox; Sergio Garcia Murillo; Victor Pascual Avila; draft-chenxin-behave-turn-websocket@tools.ietf.org; tram@ietf.org
> Subject: Re: [tram] TURN over WebSocket
>
>  
>
>  
>
> On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:
>
> Transparent proxies like firewalls keep getting upgraded frequently to handle new applications, threats etc. If firewall has a feature to block WebRTC traffic then by sending traffic over WebSocket will not solve the problem.
>
>  
>
> (As a participant...)
>
>
> This has also been discussed before. TURN-over-WebSockets is not a way for applications to circumvent policy.
>
>  
>
> The problem is there are networks that are set up so that "the web" is open, through a transparent proxy. WebRTC is part of "the web". Making TURN fit the mould of "the web" is is not circumventing policy, it's making WebRTC work. You should not need to update your proxy/firewall config for WebRTC to just work if "the web" already does work.
>
>  
>
> [TR] Okay, so looks like the problem can also be solved by running TURN over 443 similar to proposals in DPRIVE WG to run DNS over 443.
>
>  

Good try! Unlucky enough, doesn't work.

Best regards
Sergio

 


--------------060505050308080704020109-- From nobody Wed Dec 3 01:19:59 2014 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 57D3B1A0222 for ; Wed, 3 Dec 2014 01:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 Un-8Oteq5kMc for ; Wed, 3 Dec 2014 01:19:48 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51DDB1A0211 for ; Wed, 3 Dec 2014 01:19:48 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id n3so23635805wiv.13 for ; Wed, 03 Dec 2014 01:19:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=XldLhx40s5qB23Zf+iqlNYojqkrM8fcOI6PmH+OELE8=; b=GXSOKJxB2bFPcZj2tfD7eI5kd0dyqvWGpqUMLHeBXUryomvmwEDHn1RTvT2uvL0L77 yn5dfJ7usbxgeh/zSiXlLl4XR9FME2TznvExUibHSzasa8y2u4rHdtQQTbDju/yxVZlb 7dr0M+POZWkZc5DCDTYExw6e3G1oCrgnJygMmcaUNcD0lpwqXyfnEc2LgrgUwK3IGaHB igeU8+o2slYBlweLnD/nl/iUsVYmJYhSWQK0b9Nl8bdkcN8rtJ5LITM4uUADHKk+HfAZ G06WYzY+vOZvPfbuK+sG7QfHLnoVAbNDxoZa/GZ119EkbYik2tNYyVkpEh3o5XOzwa66 4IUA== X-Received: by 10.180.76.211 with SMTP id m19mr11939426wiw.73.1417598387094; Wed, 03 Dec 2014 01:19:47 -0800 (PST) Received: from [192.168.1.37] (136.Red-81-39-109.dynamicIP.rima-tde.net. [81.39.109.136]) by mx.google.com with ESMTPSA id pf4sm35432726wjb.36.2014.12.03.01.19.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 01:19:46 -0800 (PST) Message-ID: <547ED5B3.7070102@gmail.com> Date: Wed, 03 Dec 2014 10:19:47 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brandon Williams , "Tirumaleswar Reddy (tireddy)" References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B8E7@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B9B5@xmb-rcd-x10.cisco.com> <547E2069.4050307@gmail.com> <547E6022.5030101@akamai.com> In-Reply-To: <547E6022.5030101@akamai.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/G755UUCVdzhwhLauBNJ1uwNj928 Cc: "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Jonathan Lennox , "\[ACME\] Victor Pascual Avila" , "tram@ietf.org" , Simon Perreault Subject: Re: [tram] TURN over WebSocket 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, 03 Dec 2014 09:19:50 -0000 Am I supposed to change every hotel, cafe or airport wifi in the world in order to make it work? That's what I mean. Don't take me wrong, ALPN seems a good solution, as good as ipv6 is for removing NAT, but it is something out my control to have it deployed worldwide, so I can't rely on it as a solution. From a webrtc point of view we only control the client and the turn server, everything in between should be considered hostile. Best regards Sergio On 03/12/2014 1:58, Brandon Williams wrote: > What part of ALPN is not under your control? If you're doing WSS, then > you've already got TLS in the picture, so ALPN and WSS seem to both > solve the server-side multiplexing problem from the original problem > statement. What part of the problem statement does WSS solve that ALPN > does not? > > If you're concerned about unencrypted TURN multiplexing with > unencrypted HTTP on port 80, then I can see WS solving a problem that > ALPN can't solve. > > --Brandon > > On 12/02/2014 03:26 PM, Sergio Garcia Murillo wrote: >> We control the client and the server, and you are asking me to wait >> until what is not in our control is changed. Obviously, not working >> for me >> >> BTW, I am talking about real life experiences, when WSS works and TURNS >> over 443 doesn't. >> >> Best regards >> Sergio >> >> On 02/12/2014 20:44, Tirumaleswar Reddy (tireddy) wrote: >>> >>> why will it not work when ALPN is used ? >>> >>> -Tiru >>> >>> *From:*Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com] ? >>> >>> *Sent:* Wednesday, December 03, 2014 12:52 AM >>> *To:* Tirumaleswar Reddy (tireddy) >>> *Cc:* Jonathan Lennox; [ACME] Victor Pascual Avila; Simon Perreault; >>> tram@ietf.org; draft-chenxin-behave-turn-websocket@tools.ietf.org >>> *Subject:* RE: [tram] TURN over WebSocket >>> >>> >>> El 02/12/2014 20:04, "Tirumaleswar Reddy (tireddy)" >> > escribió: >>> > >>> > From: Simon Perreault [mailto:sperreault@jive.com >>> ] >>> > Sent: Tuesday, December 02, 2014 10:19 PM >>> > >>> > To: Tirumaleswar Reddy (tireddy) >>> > Cc: Jonathan Lennox; Sergio Garcia Murillo; Victor Pascual Avila; >>> draft-chenxin-behave-turn-websocket@tools.ietf.org >>> ; >>> tram@ietf.org >>> > Subject: Re: [tram] TURN over WebSocket >>> > >>> > >>> > >>> > >>> > >>> > On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar Reddy (tireddy) >>> > wrote: >>> > >>> > Transparent proxies like firewalls keep getting upgraded frequently >>> to handle new applications, threats etc. If firewall has a feature to >>> block WebRTC traffic then by sending traffic over WebSocket will not >>> solve the problem. >>> > >>> > >>> > >>> > (As a participant...) >>> > >>> > >>> > This has also been discussed before. TURN-over-WebSockets is not a >>> way for applications to circumvent policy. >>> > >>> > >>> > >>> > The problem is there are networks that are set up so that "the web" >>> is open, through a transparent proxy. WebRTC is part of "the web". >>> Making TURN fit the mould of "the web" is is not circumventing policy, >>> it's making WebRTC work. You should not need to update your >>> proxy/firewall config for WebRTC to just work if "the web" already >>> does work. >>> > >>> > >>> > >>> > [TR] Okay, so looks like the problem can also be solved by running >>> TURN over 443 similar to proposals in DPRIVE WG to run DNS over 443. >>> > >>> > >>> >>> Good try! Unlucky enough, doesn't work. >>> >>> Best regards >>> Sergio >>> >> > From nobody Wed Dec 3 01:20:01 2014 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 C9FC01A0211 for ; Wed, 3 Dec 2014 01:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_NONE=-0.0001] 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 q6DEXaIYn6Pa for ; Wed, 3 Dec 2014 01:19:48 -0800 (PST) Received: from smtpdg12.aruba.it (smtpdg228.aruba.it [62.149.158.228]) by ietfa.amsl.com (Postfix) with ESMTP id E95F21A020B for ; Wed, 3 Dec 2014 01:19:47 -0800 (PST) Received: from lminiero ([79.31.58.38]) by smtpcmd04.ad.aruba.it with bizsmtp id NxKj1p00p0pVAvB01xKjup; Wed, 03 Dec 2014 10:19:45 +0100 Date: Wed, 3 Dec 2014 10:19:41 +0100 From: Lorenzo Miniero To: Sergio Garcia Murillo Message-ID: <20141203101941.6f31aefb@lminiero> In-Reply-To: <547ED451.1020307@gmail.com> References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B8E7@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B9B5@xmb-rcd-x10.cisco.com> <547E2069.4050307@gmail.com> <400774A5-BCCF-4CD4-A805-D88C13C34E22@quobis.com> <9F33F40F6F2CD847824537F3C4E37DDF1E61FB1B@MCHP04MSX.global-ad.net> <547ED451.1020307@gmail.com> Organization: Meetecho X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tram/RuU6ClNEq48GiA64nSMFg95qIT8 Cc: Jonathan Lennox , "tram@ietf.org" , "Hutton, Andrew" , "\[ACME\] Victor Pascual Avila" , Victor Pascual , "Tirumaleswar Reddy \(tireddy\)" , "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Simon Perreault Subject: Re: [tram] TURN over WebSocket 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, 03 Dec 2014 09:19:51 -0000 +1, edge cases are not so rare anymore, and we really don't want people saying that WebRTC doesn't work. Besides, as Sergio pointed out, the solution can be controllable both by network admins that want to filter most of the non-web traffic but want to allow WebRTC, and those who *really* want to prevent WebRTC as well. Lorenzo On Wed, 03 Dec 2014 10:13:53 +0100 Sergio Garcia Murillo wrote: > Hi Andrew, >=20 > Completely agree with your statements, my concerns are about been > able to have the same level of connectivity in webrtc than in other=20 > proprietary solutions (like Skype/Webex). >=20 > In my setup I have TURN over udp and tcp and TURNS at port 443, and > I still having issues in some scenarios when TURN is failing to > connect. In those scenarios I have no problems at all with the > signaling which goes over WSS. >=20 > I don't have anything personal in favor of turn over ws, but I (and=20 > propably any company trying to do any kind of busyness arround > webrtc) need a solution that can be deployed in a "months" time frame > and not a "years" one, and that don't have the prerequisite of been > in control of the intermediary elements (FW,s proxies, etc). So if > there is any other solution easier and better than the one we are > proposing I will be more than willing to collaborate with it. >=20 > Best regards > Sergio >=20 > On 03/12/2014 10:00, Hutton, Andrew wrote: > > > > I would be good to close as many holes as possible with regards to=20 > > webrtc connectivity but we have to be clear on which particular > > hole we are trying to close. > > > > If I read the thread correctly it looks like the case we don=E2=80=99t= =20 > > currently have a solution for is when using a transparent proxy > > with unencrypted TURN on port 80. I would like to understand why > > in the scenario that Sergio mentioned that WSS works but not TURNS > > over 443 and whether support for ALPN would fix that. > > > > This is all about webrtc so I think there is an issue also with=20 > > increasing complexity in the browser which needs to implement all > > the different mechanisms and also probably a bigger issue is > > getting the rtcweb working group and the browser vendors to support > > this mechanism and refer to it in draft-ietf-rtcweb-transports. > > > > So I would say I am sympathetic to this but not yet totally > > convinced it closes a big enough hole to make it compelling for the > > browser vendors to implement. > > > > Regards > > > > Andy > > > > *From:*tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Victor > > Pascual *Sent:* 02 December 2014 21:55 > > *To:* Sergio Garcia Murillo > > *Cc:* Jonathan Lennox; tram@ietf.org; [ACME] Victor Pascual Avila;=20 > > Tirumaleswar Reddy (tireddy);=20 > > draft-chenxin-behave-turn-websocket@tools.ietf.org; Simon Perreault > > *Subject:* Re: [tram] TURN over WebSocket > > > > Agree with Sergio. We're experiencing the same > > > > -Victor > > > > > > On Dec 2, 2014, at 9:26 PM, Sergio Garcia Murillo=20 > > > > wrote: > > > > We control the client and the server, and you are asking me to > > wait until what is not in our control is changed. Obviously, not > > working for me > > > > BTW, I am talking about real life experiences, when WSS works > > and TURNS over 443 doesn't. > > > > Best regards > > Sergio > > > > On 02/12/2014 20:44, Tirumaleswar Reddy (tireddy) wrote: > > > > why will it not work when ALPN is used ? > > > > -Tiru > > > > *From:*Sergio Garcia Murillo > > [mailto:sergio.garcia.murillo@gmail.com] ? > > > > *Sent:*Wednesday, December 03, 2014 12:52 AM > > *To:* Tirumaleswar Reddy (tireddy) > > *Cc:* Jonathan Lennox; [ACME] Victor Pascual Avila; Simon > > Perreault; tram@ietf.org ; > > draft-chenxin-behave-turn-websocket@tools.ietf.org > > > > *Subject:* RE: [tram] TURN over WebSocket > > > > > > El 02/12/2014 20:04, "Tirumaleswar Reddy (tireddy)" > > > escribi=C3=B3: > > > > > > From: Simon Perreault [mailto:sperreault@jive.com > > ] > > > Sent: Tuesday, December 02, 2014 10:19 PM > > > > > > To: Tirumaleswar Reddy (tireddy) > > > Cc: Jonathan Lennox; Sergio Garcia Murillo; Victor Pascual > > Avila; draft-chenxin-behave-turn-websocket@tools.ietf.org > > ; > > tram@ietf.org > > > Subject: Re: [tram] TURN over WebSocket > > > > > > > > > > > > > > > > > > On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar Reddy > > > (tireddy) > > > wrote: > > > > > > Transparent proxies like firewalls keep getting upgraded > > frequently to handle new applications, threats etc. If > > firewall has a feature to block WebRTC traffic then by > > sending traffic over WebSocket will not solve the problem. > > > > > > > > > > > > (As a participant...) > > > > > > > > > This has also been discussed before. TURN-over-WebSockets > > > is > > not a way for applications to circumvent policy. > > > > > > > > > > > > The problem is there are networks that are set up so that > > "the web" is open, through a transparent proxy. WebRTC is > > part of "the web". Making TURN fit the mould of "the web" is is not > > circumventing policy, it's making WebRTC work. You should > > not need to update your proxy/firewall config for WebRTC to just > > work if "the web" already does work. > > > > > > > > > > > > [TR] Okay, so looks like the problem can also be solved by > > running TURN over 443 similar to proposals in DPRIVE WG to > > run DNS over 443. > > > > > > > > > > Good try! Unlucky enough, doesn't work. > > > > Best regards > > Sergio > > >=20 From nobody Wed Dec 3 01:24:24 2014 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 E37601A020B for ; Wed, 3 Dec 2014 01:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 v12-xxLH_7DV for ; Wed, 3 Dec 2014 01:24:17 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E96D1A0211 for ; Wed, 3 Dec 2014 01:24:17 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id r20so30693637wiv.12 for ; Wed, 03 Dec 2014 01:24:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YJP5ByQtSExwW5kpceMufl8jbm+PMsVpwsR4AB1qAx4=; b=INKo9h75NiR1pNnVw08f+22MKfPGS9bLZW+tTBpcMogYzwgyFEdH02FMBswKhH87bg ipi0YN3R3/kSyClZfO4QUyXRvkfRxPSZlZ4QutETKwlxjkr8LnvVN2I+eic2JAOeEW62 TnHDanyC/2nnMTsRGKl9abzZJDDZhBV9HW4Zh9kuYTsPgpEl4nj1+tQpIxf1ksvzxbBb wybR/4z+rcLWGeAZ+KaPYs7xmm0bDjZ+9Kh5BZWKXa7geMJmMT8Ci2QnL8vrLSpK6+iP uSpy82TWjRS0iPLltf2vQWnNyOQQRG2iqh2fT+PfHaumXN/bwzvXIoihN5sljwMQhsXG B3zw== MIME-Version: 1.0 X-Received: by 10.180.75.199 with SMTP id e7mr100824738wiw.21.1417598655866; Wed, 03 Dec 2014 01:24:15 -0800 (PST) Received: by 10.194.171.73 with HTTP; Wed, 3 Dec 2014 01:24:15 -0800 (PST) In-Reply-To: <547ED5B3.7070102@gmail.com> References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B8E7@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B9B5@xmb-rcd-x10.cisco.com> <547E2069.4050307@gmail.com> <547E6022.5030101@akamai.com> <547ED5B3.7070102@gmail.com> Date: Wed, 3 Dec 2014 01:24:15 -0800 Message-ID: From: Oleg Moskalenko To: Sergio Garcia Murillo Content-Type: multipart/alternative; boundary=f46d04389577512e1105094c68e1 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/oLwSPbRMscZTZjFWZmxXbUdeDoY Cc: Jonathan Lennox , "tram@ietf.org" , Brandon Williams , "\[ACME\] Victor Pascual Avila" , "Tirumaleswar Reddy \(tireddy\)" , "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Simon Perreault Subject: Re: [tram] TURN over WebSocket 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, 03 Dec 2014 09:24:23 -0000 --f46d04389577512e1105094c68e1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That is a good point. A solution must not require changing every wifi network in the world. A "pure" ALPN solution is a great way to kill the whole WebRTC idea. On Wed, Dec 3, 2014 at 1:19 AM, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > Am I supposed to change every hotel, cafe or airport wifi in the world in > order to make it work? That's what I mean. > > Don't take me wrong, ALPN seems a good solution, as good as ipv6 is for > removing NAT, but it is something out my control to have it deployed > worldwide, so I can't rely on it as a solution. From a webrtc point of vi= ew > we only control the client and the turn server, everything in between > should be considered hostile. > > Best regards > Sergio > > > On 03/12/2014 1:58, Brandon Williams wrote: > >> What part of ALPN is not under your control? If you're doing WSS, then >> you've already got TLS in the picture, so ALPN and WSS seem to both solv= e >> the server-side multiplexing problem from the original problem statement= . >> What part of the problem statement does WSS solve that ALPN does not? >> >> If you're concerned about unencrypted TURN multiplexing with unencrypted >> HTTP on port 80, then I can see WS solving a problem that ALPN can't sol= ve. >> >> --Brandon >> >> On 12/02/2014 03:26 PM, Sergio Garcia Murillo wrote: >> >>> We control the client and the server, and you are asking me to wait >>> until what is not in our control is changed. Obviously, not working for >>> me >>> >>> BTW, I am talking about real life experiences, when WSS works and TURNS >>> over 443 doesn't. >>> >>> Best regards >>> Sergio >>> >>> On 02/12/2014 20:44, Tirumaleswar Reddy (tireddy) wrote: >>> >>>> >>>> why will it not work when ALPN is used ? >>>> >>>> -Tiru >>>> >>>> *From:*Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com] = ? >>>> >>>> *Sent:* Wednesday, December 03, 2014 12:52 AM >>>> *To:* Tirumaleswar Reddy (tireddy) >>>> *Cc:* Jonathan Lennox; [ACME] Victor Pascual Avila; Simon Perreault; >>>> tram@ietf.org; draft-chenxin-behave-turn-websocket@tools.ietf.org >>>> *Subject:* RE: [tram] TURN over WebSocket >>>> >>>> >>>> El 02/12/2014 20:04, "Tirumaleswar Reddy (tireddy)" >>> > escribi=C3=B3: >>>> > >>>> > From: Simon Perreault [mailto:sperreault@jive.com >>>> ] >>>> > Sent: Tuesday, December 02, 2014 10:19 PM >>>> > >>>> > To: Tirumaleswar Reddy (tireddy) >>>> > Cc: Jonathan Lennox; Sergio Garcia Murillo; Victor Pascual Avila; >>>> draft-chenxin-behave-turn-websocket@tools.ietf.org >>>> ; >>>> tram@ietf.org >>>> > Subject: Re: [tram] TURN over WebSocket >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar Reddy (tireddy) >>>> > wrote: >>>> > >>>> > Transparent proxies like firewalls keep getting upgraded frequently >>>> to handle new applications, threats etc. If firewall has a feature to >>>> block WebRTC traffic then by sending traffic over WebSocket will not >>>> solve the problem. >>>> > >>>> > >>>> > >>>> > (As a participant...) >>>> > >>>> > >>>> > This has also been discussed before. TURN-over-WebSockets is not a >>>> way for applications to circumvent policy. >>>> > >>>> > >>>> > >>>> > The problem is there are networks that are set up so that "the web" >>>> is open, through a transparent proxy. WebRTC is part of "the web". >>>> Making TURN fit the mould of "the web" is is not circumventing policy, >>>> it's making WebRTC work. You should not need to update your >>>> proxy/firewall config for WebRTC to just work if "the web" already >>>> does work. >>>> > >>>> > >>>> > >>>> > [TR] Okay, so looks like the problem can also be solved by running >>>> TURN over 443 similar to proposals in DPRIVE WG to run DNS over 443. >>>> > >>>> > >>>> >>>> Good try! Unlucky enough, doesn't work. >>>> >>>> Best regards >>>> Sergio >>>> >>>> >>> >> > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --f46d04389577512e1105094c68e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That is a good point. A solution must not require changing= every wifi=20 network in the world. A "pure" ALPN=C2=A0 solution is a great way= to kill the whole WebRTC idea.

On Wed, Dec 3, 2014 at 1:19 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
Am I supposed to change every hotel, cafe or airport wifi i= n the world in order to make it work? That's what I mean.

Don't take me wrong, ALPN seems a good solution, as good as ipv6 is for= removing NAT, but it is something out my control to have it deployed world= wide, so I can't rely on it as a solution. From a webrtc point of view = we only control the client and the turn server, everything in between shoul= d be considered hostile.

Best regards
Sergio


On 03/12/2014 1:58, Brandon Williams wrote:
What part of ALPN is not under your control? If you're doing WSS, then = you've already got TLS in the picture, so ALPN and WSS seem to both sol= ve the server-side multiplexing problem from the original problem statement= . What part of the problem statement does WSS solve that ALPN does not?

If you're concerned about unencrypted TURN multiplexing with unencrypte= d HTTP on port 80, then I can see WS solving a problem that ALPN can't = solve.

--Brandon

On 12/02/2014 03:26 PM, Sergio Garcia Murillo wrote:
We control the client and the server, and you are asking me to wait
until what is not in our control is changed. Obviously, not working for me<= br>
BTW, I am talking about real life experiences, when WSS works and TURNS
over 443 doesn't.

Best regards
Sergio

On 02/12/2014 20:44, Tirumaleswar Reddy (tireddy) wrote:

why will it not work when ALPN is used ?

-Tiru

*From:*Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com] = ?

*Sent:* Wednesday, December 03, 2014 12:52 AM
*To:* Tirumaleswar Reddy (tireddy)
*Cc:* Jonathan Lennox; [ACME] Victor Pascual Avila; Simon Perreault;
tram@ietf.org; draft-chenxin-behave-turn-websocket@tools.ietf.org
*Subject:* RE: [tram] TURN over WebSocket


El 02/12/2014 20:04, "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com
<mailto:tireddy@c= isco.com>> escribi=C3=B3:
>
> From: Simon Perreault [mailto:sperreault@jive.com
<mailto:sperrea= ult@jive.com>]
> Sent: Tuesday, December 02, 2014 10:19 PM
>
> To: Tirumaleswar Reddy (tireddy)
> Cc: Jonathan Lennox; Sergio Garcia Murillo; Victor Pascual Avila;
draft-chenxin-behave-turn-websocket@tools.ietf.org<= br> <mailto:draft-chenxin-behave-turn-websocket@tools.ie= tf.org>;
tram@ietf.org <ma= ilto:tram@ietf.org&g= t;
> Subject: Re: [tram] TURN over WebSocket
>
>
>
>
>
> On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar Reddy (tireddy)
<tireddy@cisco.co= m <mailto:tir= eddy@cisco.com>> wrote:
>
> Transparent proxies like firewalls keep getting upgraded frequently to handle new applications, threats etc. If firewall has a feature to
block WebRTC traffic then by sending traffic over WebSocket will not
solve the problem.
>
>
>
> (As a participant...)
>
>
> This has also been discussed before. TURN-over-WebSockets is not a
way for applications to circumvent policy.
>
>
>
> The problem is there are networks that are set up so that "the we= b"
is open, through a transparent proxy. WebRTC is part of "the web"= .
Making TURN fit the mould of "the web" is is not circumventing po= licy,
it's making WebRTC work. You should not need to update your
proxy/firewall config for WebRTC to just work if "the web" alread= y
does work.
>
>
>
> [TR] Okay, so looks like the problem can also be solved by running
TURN over 443 similar to proposals in DPRIVE WG to run DNS over 443.
>
>

Good try! Unlucky enough, doesn't work.

Best regards
Sergio




_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--f46d04389577512e1105094c68e1-- From nobody Wed Dec 3 02:47:38 2014 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 BE1B41A1A06 for ; Wed, 3 Dec 2014 02:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 RPm5JZP3yvLa for ; Wed, 3 Dec 2014 02:47:34 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB9641A0461 for ; Wed, 3 Dec 2014 02:47:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6286; q=dns/txt; s=iport; t=1417603653; x=1418813253; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9Q5z5QuN6i7wb7UbgRddXnX7jjWqTh5uPqjNp0kY3FM=; b=M/WZH7jBpKhggjpnHDVGAe5z7kfLUxeFcJCeqF15zBe7RQwEXuuU2xoO 950ayIRj4Xhg5UUQh/RxcPK4sT5W5S9qd9Uxir2VALK6a49Uzp02VRKCG Zceizr5xVnebM1mckVUEwgb7FBx/9q4T67aFsb6b3HOoIQfNq1YYZsHFN k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0IAPDpflStJA2M/2dsb2JhbABagwZSWASDAcEehCEBhBsCHHcWAQEBAQF9hAIBAQEEIxFFDAQCAQgRBAEBAQICBh0DAgICHxEUAQgIAgQBDQUIEQKIDgMSv0CQWQ2FdQEBAQEBAQEBAQEBAQEBAQEBAQEBAReBK40FgXQRFhsHBoJrM4EeBZAPhjiCIIMUjBs8gjSDaYN4bwGBBECBAAEBAQ X-IronPort-AV: E=Sophos;i="5.07,507,1413244800"; d="scan'208";a="102243327" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-8.cisco.com with ESMTP; 03 Dec 2014 10:47:32 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id sB3AlWHn024612 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Dec 2014 10:47:32 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.204]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 04:47:32 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Sergio Garcia Murillo , Brandon Williams Thread-Topic: [tram] TURN over WebSocket Thread-Index: AdANiRFG6X70S29YQzixzirX+f0pqQAUXYoAAAPQ0HAAIo3igAAJyMCQ///OFwCAAEFhgP//6UCAgABem8D//7NrgIAAS/YAgACMJ4CAAEzXYA== Date: Wed, 3 Dec 2014 10:47:32 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2837D203@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B8E7@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B9B5@xmb-rcd-x10.cisco.com> <547E2069.4050307@gmail.com> <547E6022.5030101@akamai.com> <547ED5B3.7070102@gmail.com> In-Reply-To: <547ED5B3.7070102@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.127.12.199] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/G3jZabZS3QBOVZiHPbDd7eHr9T0 Cc: "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Jonathan Lennox , "\[ACME\] Victor Pascual Avila" , "tram@ietf.org" , Simon Perreault Subject: Re: [tram] TURN over WebSocket 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, 03 Dec 2014 10:47:35 -0000 QUxQTiBvbmx5IHJlcXVpcmVzIGNoYW5nZXMgdG8gdGhlIGNsaWVudCBhbmQgc2VydmVyLiBXaXRo IFRMUyAxLjMgQUxQTiB3aWxsIGJlIGVuY3J5cHRlZCBhbmQgbWF5IG5vdCBiZSBhbnkgdXNlIHRv IGludGVybWVkaWF0ZSBkZXZpY2VzIGZvciBhbnkgcG9saWN5IGVuZm9yY2VtZW50LiBJIGRvbid0 IHVuZGVyc3RhbmQgd2h5IEFMUE4gY2Fubm90IGJlIHVzZWQgdG8gc29sdmUgdGhpcyBwcm9ibGVt ID8NCg0KLVRpcnUgDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU2Vy Z2lvIEdhcmNpYSBNdXJpbGxvIFttYWlsdG86c2VyZ2lvLmdhcmNpYS5tdXJpbGxvQGdtYWlsLmNv bV0NCj4gU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAwMywgMjAxNCAyOjUwIFBNDQo+IFRvOiBC cmFuZG9uIFdpbGxpYW1zOyBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQo+IENjOiBkcmFm dC1jaGVueGluLWJlaGF2ZS10dXJuLXdlYnNvY2tldEB0b29scy5pZXRmLm9yZzsgSm9uYXRoYW4g TGVubm94Ow0KPiBbQUNNRV0gVmljdG9yIFBhc2N1YWwgQXZpbGE7IHRyYW1AaWV0Zi5vcmc7IFNp bW9uIFBlcnJlYXVsdA0KPiBTdWJqZWN0OiBSZTogW3RyYW1dIFRVUk4gb3ZlciBXZWJTb2NrZXQN Cj4gDQo+IEFtIEkgc3VwcG9zZWQgdG8gY2hhbmdlIGV2ZXJ5IGhvdGVsLCBjYWZlIG9yIGFpcnBv cnQgd2lmaSBpbiB0aGUgd29ybGQgaW4NCj4gb3JkZXIgdG8gbWFrZSBpdCB3b3JrPyBUaGF0J3Mg d2hhdCBJIG1lYW4uDQo+IA0KPiBEb24ndCB0YWtlIG1lIHdyb25nLCBBTFBOIHNlZW1zIGEgZ29v ZCBzb2x1dGlvbiwgYXMgZ29vZCBhcyBpcHY2IGlzIGZvcg0KPiByZW1vdmluZyBOQVQsIGJ1dCBp dCBpcyBzb21ldGhpbmcgb3V0IG15IGNvbnRyb2wgdG8gaGF2ZSBpdCBkZXBsb3llZA0KPiB3b3Js ZHdpZGUsIHNvIEkgY2FuJ3QgcmVseSBvbiBpdCBhcyBhIHNvbHV0aW9uLiBGcm9tIGEgd2VicnRj IHBvaW50IG9mIHZpZXcgd2UNCj4gb25seSBjb250cm9sIHRoZSBjbGllbnQgYW5kIHRoZSB0dXJu IHNlcnZlciwgZXZlcnl0aGluZyBpbiBiZXR3ZWVuIHNob3VsZCBiZQ0KPiBjb25zaWRlcmVkIGhv c3RpbGUuDQo+IA0KPiBCZXN0IHJlZ2FyZHMNCj4gU2VyZ2lvDQo+IA0KPiBPbiAwMy8xMi8yMDE0 IDE6NTgsIEJyYW5kb24gV2lsbGlhbXMgd3JvdGU6DQo+ID4gV2hhdCBwYXJ0IG9mIEFMUE4gaXMg bm90IHVuZGVyIHlvdXIgY29udHJvbD8gSWYgeW91J3JlIGRvaW5nIFdTUywgdGhlbg0KPiA+IHlv dSd2ZSBhbHJlYWR5IGdvdCBUTFMgaW4gdGhlIHBpY3R1cmUsIHNvIEFMUE4gYW5kIFdTUyBzZWVt IHRvIGJvdGgNCj4gPiBzb2x2ZSB0aGUgc2VydmVyLXNpZGUgbXVsdGlwbGV4aW5nIHByb2JsZW0g ZnJvbSB0aGUgb3JpZ2luYWwgcHJvYmxlbQ0KPiA+IHN0YXRlbWVudC4gV2hhdCBwYXJ0IG9mIHRo ZSBwcm9ibGVtIHN0YXRlbWVudCBkb2VzIFdTUyBzb2x2ZSB0aGF0IEFMUE4NCj4gPiBkb2VzIG5v dD8NCj4gPg0KPiA+IElmIHlvdSdyZSBjb25jZXJuZWQgYWJvdXQgdW5lbmNyeXB0ZWQgVFVSTiBt dWx0aXBsZXhpbmcgd2l0aA0KPiA+IHVuZW5jcnlwdGVkIEhUVFAgb24gcG9ydCA4MCwgdGhlbiBJ IGNhbiBzZWUgV1Mgc29sdmluZyBhIHByb2JsZW0gdGhhdA0KPiA+IEFMUE4gY2FuJ3Qgc29sdmUu DQo+ID4NCj4gPiAtLUJyYW5kb24NCj4gPg0KPiA+IE9uIDEyLzAyLzIwMTQgMDM6MjYgUE0sIFNl cmdpbyBHYXJjaWEgTXVyaWxsbyB3cm90ZToNCj4gPj4gV2UgY29udHJvbCB0aGUgY2xpZW50IGFu ZCB0aGUgc2VydmVyLCBhbmQgeW91IGFyZSBhc2tpbmcgbWUgdG8gd2FpdA0KPiA+PiB1bnRpbCB3 aGF0IGlzIG5vdCBpbiBvdXIgY29udHJvbCBpcyBjaGFuZ2VkLiBPYnZpb3VzbHksIG5vdCB3b3Jr aW5nDQo+ID4+IGZvciBtZQ0KPiA+Pg0KPiA+PiBCVFcsIEkgYW0gdGFsa2luZyBhYm91dCByZWFs IGxpZmUgZXhwZXJpZW5jZXMsIHdoZW4gV1NTIHdvcmtzIGFuZA0KPiA+PiBUVVJOUyBvdmVyIDQ0 MyBkb2Vzbid0Lg0KPiA+Pg0KPiA+PiBCZXN0IHJlZ2FyZHMNCj4gPj4gU2VyZ2lvDQo+ID4+DQo+ ID4+IE9uIDAyLzEyLzIwMTQgMjA6NDQsIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgd3Jv dGU6DQo+ID4+Pg0KPiA+Pj4gd2h5IHdpbGwgaXQgbm90IHdvcmsgd2hlbiBBTFBOIGlzIHVzZWQg Pw0KPiA+Pj4NCj4gPj4+IC1UaXJ1DQo+ID4+Pg0KPiA+Pj4gKkZyb206KlNlcmdpbyBHYXJjaWEg TXVyaWxsbyBbbWFpbHRvOnNlcmdpby5nYXJjaWEubXVyaWxsb0BnbWFpbC5jb21dID8NCj4gPj4+ DQo+ID4+PiAqU2VudDoqIFdlZG5lc2RheSwgRGVjZW1iZXIgMDMsIDIwMTQgMTI6NTIgQU0NCj4g Pj4+ICpUbzoqIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkNCj4gPj4+ICpDYzoqIEpvbmF0 aGFuIExlbm5veDsgW0FDTUVdIFZpY3RvciBQYXNjdWFsIEF2aWxhOyBTaW1vbiBQZXJyZWF1bHQ7 DQo+ID4+PiB0cmFtQGlldGYub3JnOyBkcmFmdC1jaGVueGluLWJlaGF2ZS10dXJuLXdlYnNvY2tl dEB0b29scy5pZXRmLm9yZw0KPiA+Pj4gKlN1YmplY3Q6KiBSRTogW3RyYW1dIFRVUk4gb3ZlciBX ZWJTb2NrZXQNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gRWwgMDIvMTIvMjAxNCAyMDowNCwgIlRpcnVt YWxlc3dhciBSZWRkeSAodGlyZWRkeSkiDQo+ID4+PiA8dGlyZWRkeUBjaXNjby5jb20gPG1haWx0 bzp0aXJlZGR5QGNpc2NvLmNvbT4+IGVzY3JpYmnDszoNCj4gPj4+ID4NCj4gPj4+ID4gRnJvbTog U2ltb24gUGVycmVhdWx0IFttYWlsdG86c3BlcnJlYXVsdEBqaXZlLmNvbQ0KPiA+Pj4gPG1haWx0 bzpzcGVycmVhdWx0QGppdmUuY29tPl0NCj4gPj4+ID4gU2VudDogVHVlc2RheSwgRGVjZW1iZXIg MDIsIDIwMTQgMTA6MTkgUE0NCj4gPj4+ID4NCj4gPj4+ID4gVG86IFRpcnVtYWxlc3dhciBSZWRk eSAodGlyZWRkeSkNCj4gPj4+ID4gQ2M6IEpvbmF0aGFuIExlbm5veDsgU2VyZ2lvIEdhcmNpYSBN dXJpbGxvOyBWaWN0b3IgUGFzY3VhbCBBdmlsYTsNCj4gPj4+IGRyYWZ0LWNoZW54aW4tYmVoYXZl LXR1cm4td2Vic29ja2V0QHRvb2xzLmlldGYub3JnDQo+ID4+PiA8bWFpbHRvOmRyYWZ0LWNoZW54 aW4tYmVoYXZlLXR1cm4td2Vic29ja2V0QHRvb2xzLmlldGYub3JnPjsNCj4gPj4+IHRyYW1AaWV0 Zi5vcmcgPG1haWx0bzp0cmFtQGlldGYub3JnPg0KPiA+Pj4gPiBTdWJqZWN0OiBSZTogW3RyYW1d IFRVUk4gb3ZlciBXZWJTb2NrZXQNCj4gPj4+ID4NCj4gPj4+ID4NCj4gPj4+ID4NCj4gPj4+ID4N Cj4gPj4+ID4NCj4gPj4+ID4gT24gVHVlLCBEZWMgMiwgMjAxNCBhdCA5OjM0IEFNLCBUaXJ1bWFs ZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQo+ID4+PiA8dGlyZWRkeUBjaXNjby5jb20gPG1haWx0bzp0 aXJlZGR5QGNpc2NvLmNvbT4+IHdyb3RlOg0KPiA+Pj4gPg0KPiA+Pj4gPiBUcmFuc3BhcmVudCBw cm94aWVzIGxpa2UgZmlyZXdhbGxzIGtlZXAgZ2V0dGluZyB1cGdyYWRlZA0KPiA+Pj4gPiBmcmVx dWVudGx5DQo+ID4+PiB0byBoYW5kbGUgbmV3IGFwcGxpY2F0aW9ucywgdGhyZWF0cyBldGMuIElm IGZpcmV3YWxsIGhhcyBhIGZlYXR1cmUNCj4gPj4+IHRvIGJsb2NrIFdlYlJUQyB0cmFmZmljIHRo ZW4gYnkgc2VuZGluZyB0cmFmZmljIG92ZXIgV2ViU29ja2V0IHdpbGwNCj4gPj4+IG5vdCBzb2x2 ZSB0aGUgcHJvYmxlbS4NCj4gPj4+ID4NCj4gPj4+ID4NCj4gPj4+ID4NCj4gPj4+ID4gKEFzIGEg cGFydGljaXBhbnQuLi4pDQo+ID4+PiA+DQo+ID4+PiA+DQo+ID4+PiA+IFRoaXMgaGFzIGFsc28g YmVlbiBkaXNjdXNzZWQgYmVmb3JlLiBUVVJOLW92ZXItV2ViU29ja2V0cyBpcyBub3QgYQ0KPiA+ Pj4gd2F5IGZvciBhcHBsaWNhdGlvbnMgdG8gY2lyY3VtdmVudCBwb2xpY3kuDQo+ID4+PiA+DQo+ ID4+PiA+DQo+ID4+PiA+DQo+ID4+PiA+IFRoZSBwcm9ibGVtIGlzIHRoZXJlIGFyZSBuZXR3b3Jr cyB0aGF0IGFyZSBzZXQgdXAgc28gdGhhdCAidGhlIHdlYiINCj4gPj4+IGlzIG9wZW4sIHRocm91 Z2ggYSB0cmFuc3BhcmVudCBwcm94eS4gV2ViUlRDIGlzIHBhcnQgb2YgInRoZSB3ZWIiLg0KPiA+ Pj4gTWFraW5nIFRVUk4gZml0IHRoZSBtb3VsZCBvZiAidGhlIHdlYiIgaXMgaXMgbm90IGNpcmN1 bXZlbnRpbmcNCj4gPj4+IHBvbGljeSwgaXQncyBtYWtpbmcgV2ViUlRDIHdvcmsuIFlvdSBzaG91 bGQgbm90IG5lZWQgdG8gdXBkYXRlIHlvdXINCj4gPj4+IHByb3h5L2ZpcmV3YWxsIGNvbmZpZyBm b3IgV2ViUlRDIHRvIGp1c3Qgd29yayBpZiAidGhlIHdlYiIgYWxyZWFkeQ0KPiA+Pj4gZG9lcyB3 b3JrLg0KPiA+Pj4gPg0KPiA+Pj4gPg0KPiA+Pj4gPg0KPiA+Pj4gPiBbVFJdIE9rYXksIHNvIGxv b2tzIGxpa2UgdGhlIHByb2JsZW0gY2FuIGFsc28gYmUgc29sdmVkIGJ5IHJ1bm5pbmcNCj4gPj4+ IFRVUk4gb3ZlciA0NDMgc2ltaWxhciB0byBwcm9wb3NhbHMgaW4gRFBSSVZFIFdHIHRvIHJ1biBE TlMgb3ZlciA0NDMuDQo+ID4+PiA+DQo+ID4+PiA+DQo+ID4+Pg0KPiA+Pj4gR29vZCB0cnkhIFVu bHVja3kgZW5vdWdoLCBkb2Vzbid0IHdvcmsuDQo+ID4+Pg0KPiA+Pj4gQmVzdCByZWdhcmRzDQo+ ID4+PiBTZXJnaW8NCj4gPj4+DQo+ID4+DQo+ID4NCg0K From nobody Wed Dec 3 03:22:15 2014 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 6674C1A1A40 for ; Wed, 3 Dec 2014 03:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 1Tkuz1JVOeoy for ; Wed, 3 Dec 2014 03:22:10 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D20FB1A0A6A for ; Wed, 3 Dec 2014 03:22:09 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id y19so19493360wgg.14 for ; Wed, 03 Dec 2014 03:22:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=zdC8aCkwy8xgYCu7VDUPpkRTMWaREEzuJ04wMuVjRMU=; b=QCCQaLO+2jTHHG7S9Dsl0i00xFuEHexAHZXXbIA5ubB3J03Q9bRpRCDQnV7N7YCKGz hW4eMlYd3b05GX6eLD8LJzYGmkuFzvjDZ+C/X6l4EsYdum+vExZJ4lvmFV/D6xuAhPzJ FH8nDOv4QC6MOb2gy3OCsiFOOlAvDgexG2Skt0GDhsJome4XFFNTjClX81ZcOyEEoIh0 JyItoxAwgh5sHZlWRxX9NhydWuYxXn56D8BLhYCoaLqpxOkW8JSVmwoPg42p/hm+U/Ec 2zI+GntGJokawOp7cYyR0ev+sKKEnWZjLUU+7oOfZpNVYGTrCrjtxcAG/6tnq1O+jaGM FfnA== X-Received: by 10.180.84.98 with SMTP id x2mr12521777wiy.14.1417605728611; Wed, 03 Dec 2014 03:22:08 -0800 (PST) Received: from [192.168.1.37] (136.Red-81-39-109.dynamicIP.rima-tde.net. [81.39.109.136]) by mx.google.com with ESMTPSA id fo12sm50324064wic.19.2014.12.03.03.22.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 03:22:07 -0800 (PST) Message-ID: <547EF260.3050103@gmail.com> Date: Wed, 03 Dec 2014 12:22:08 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , Brandon Williams References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B8E7@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B9B5@xmb-rcd-x10.cisco.com> <547E2069.4050307@gmail.com> <547E6022.5030101@akamai.com> <547ED5B3.7070102@gmail.com> <913383AAA69FF945B8F946018B75898A2837D203@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2837D203@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/7D_XIX-xtP4sSHWHY9hnKUxPQ1E Cc: "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Jonathan Lennox , "\[ACME\] Victor Pascual Avila" , "tram@ietf.org" , Simon Perreault Subject: Re: [tram] TURN over WebSocket 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, 03 Dec 2014 11:22:12 -0000 I will ask it otherwise. I am in a hotel that allows http/https/wss/wss but turns on 443 doesn't work. How is ALPN supposed to help in that scenario? Best regards Sergio On 03/12/2014 11:47, Tirumaleswar Reddy (tireddy) wrote: > ALPN only requires changes to the client and server. With TLS 1.3 ALPN will be encrypted and may not be any use to intermediate devices for any policy enforcement. I don't understand why ALPN cannot be used to solve this problem ? > > -Tiru > >> -----Original Message----- >> From: Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com] >> Sent: Wednesday, December 03, 2014 2:50 PM >> To: Brandon Williams; Tirumaleswar Reddy (tireddy) >> Cc: draft-chenxin-behave-turn-websocket@tools.ietf.org; Jonathan Lennox; >> [ACME] Victor Pascual Avila; tram@ietf.org; Simon Perreault >> Subject: Re: [tram] TURN over WebSocket >> >> Am I supposed to change every hotel, cafe or airport wifi in the world in >> order to make it work? That's what I mean. >> >> Don't take me wrong, ALPN seems a good solution, as good as ipv6 is for >> removing NAT, but it is something out my control to have it deployed >> worldwide, so I can't rely on it as a solution. From a webrtc point of view we >> only control the client and the turn server, everything in between should be >> considered hostile. >> >> Best regards >> Sergio >> >> On 03/12/2014 1:58, Brandon Williams wrote: >>> What part of ALPN is not under your control? If you're doing WSS, then >>> you've already got TLS in the picture, so ALPN and WSS seem to both >>> solve the server-side multiplexing problem from the original problem >>> statement. What part of the problem statement does WSS solve that ALPN >>> does not? >>> >>> If you're concerned about unencrypted TURN multiplexing with >>> unencrypted HTTP on port 80, then I can see WS solving a problem that >>> ALPN can't solve. >>> >>> --Brandon >>> >>> On 12/02/2014 03:26 PM, Sergio Garcia Murillo wrote: >>>> We control the client and the server, and you are asking me to wait >>>> until what is not in our control is changed. Obviously, not working >>>> for me >>>> >>>> BTW, I am talking about real life experiences, when WSS works and >>>> TURNS over 443 doesn't. >>>> >>>> Best regards >>>> Sergio >>>> >>>> On 02/12/2014 20:44, Tirumaleswar Reddy (tireddy) wrote: >>>>> why will it not work when ALPN is used ? >>>>> >>>>> -Tiru >>>>> >>>>> *From:*Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com] ? >>>>> >>>>> *Sent:* Wednesday, December 03, 2014 12:52 AM >>>>> *To:* Tirumaleswar Reddy (tireddy) >>>>> *Cc:* Jonathan Lennox; [ACME] Victor Pascual Avila; Simon Perreault; >>>>> tram@ietf.org; draft-chenxin-behave-turn-websocket@tools.ietf.org >>>>> *Subject:* RE: [tram] TURN over WebSocket >>>>> >>>>> >>>>> El 02/12/2014 20:04, "Tirumaleswar Reddy (tireddy)" >>>>> > escribió: >>>>>> From: Simon Perreault [mailto:sperreault@jive.com >>>>> ] >>>>>> Sent: Tuesday, December 02, 2014 10:19 PM >>>>>> >>>>>> To: Tirumaleswar Reddy (tireddy) >>>>>> Cc: Jonathan Lennox; Sergio Garcia Murillo; Victor Pascual Avila; >>>>> draft-chenxin-behave-turn-websocket@tools.ietf.org >>>>> ; >>>>> tram@ietf.org >>>>>> Subject: Re: [tram] TURN over WebSocket >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar Reddy (tireddy) >>>>> > wrote: >>>>>> Transparent proxies like firewalls keep getting upgraded >>>>>> frequently >>>>> to handle new applications, threats etc. If firewall has a feature >>>>> to block WebRTC traffic then by sending traffic over WebSocket will >>>>> not solve the problem. >>>>>> >>>>>> >>>>>> (As a participant...) >>>>>> >>>>>> >>>>>> This has also been discussed before. TURN-over-WebSockets is not a >>>>> way for applications to circumvent policy. >>>>>> >>>>>> >>>>>> The problem is there are networks that are set up so that "the web" >>>>> is open, through a transparent proxy. WebRTC is part of "the web". >>>>> Making TURN fit the mould of "the web" is is not circumventing >>>>> policy, it's making WebRTC work. You should not need to update your >>>>> proxy/firewall config for WebRTC to just work if "the web" already >>>>> does work. >>>>>> >>>>>> >>>>>> [TR] Okay, so looks like the problem can also be solved by running >>>>> TURN over 443 similar to proposals in DPRIVE WG to run DNS over 443. >>>>>> >>>>> Good try! Unlucky enough, doesn't work. >>>>> >>>>> Best regards >>>>> Sergio >>>>> From nobody Wed Dec 3 03:47:00 2014 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 5B7A71A1A7B for ; Wed, 3 Dec 2014 03:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 lshfsbBSYBHl for ; Wed, 3 Dec 2014 03:46:56 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20DF21A1A48 for ; Wed, 3 Dec 2014 03:46:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7514; q=dns/txt; s=iport; t=1417607216; x=1418816816; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NGfnKWEKiiK4CTQTOOj/Xw8m1OFNnQUU5tH3byvwsek=; b=GB6bkK/MqBFGQ2Ymq6LOpEJonCLbMPipZ4s1JwpDLAjvwPBT/paTkat6 1zIJQHC04lFABg4HuU/3xm/CGCrfUnDIrC4UCVLj/+4dvkVHxte9J8o+c csRDxtFEZyAyJ21vbk3hxmAYfQ5FeY+xIJRj4kbFWteHJVknXqTCMW293 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0IAMf3flStJA2F/2dsb2JhbABQCoMGUlgEgwHBHoQhAYQbAhx4FgEBAQEBfYQCAQEBAwEjEUUMBAIBCBEEAQEBAgIGHQMCAgIfERQBCAgCBAENBQgRAogOAwkJvziQXA2FdQEBAQEBAQEBAQEBAQEBAQEBAQEBAReBK40FgVoaERYbBwaCazOBHgWQD4Y4giCDFIwbPII0g2mDeG8BgQRAgQABAQE X-IronPort-AV: E=Sophos;i="5.07,507,1413244800"; d="scan'208";a="377173255" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-5.cisco.com with ESMTP; 03 Dec 2014 11:46:55 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id sB3Bkt7Q015926 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Dec 2014 11:46:55 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.204]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 05:46:55 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Sergio Garcia Murillo , Brandon Williams Thread-Topic: [tram] TURN over WebSocket Thread-Index: AdANiRFG6X70S29YQzixzirX+f0pqQAUXYoAAAPQ0HAAIo3igAAJyMCQ///OFwCAAEFhgP//6UCAgABem8D//7NrgIAAS/YAgACMJ4CAAEzXYP//1VgAAAvE2pA= Date: Wed, 3 Dec 2014 11:46:54 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2837D346@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B8E7@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B9B5@xmb-rcd-x10.cisco.com> <547E2069.4050307@gmail.com> <547E6022.5030101@akamai.com> <547ED5B3.7070102@gmail.com> <913383AAA69FF945B8F946018B75898A2837D203@xmb-rcd-x10.cisco.com> <547EF260.3050103@gmail.com> In-Reply-To: <547EF260.3050103@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.18.98] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/eMpTfN8vG7Y7jmEwjwBVDxfY1uU Cc: "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Jonathan Lennox , "\[ACME\] Victor Pascual Avila" , "tram@ietf.org" , Simon Perreault Subject: Re: [tram] TURN over WebSocket 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, 03 Dec 2014 11:46:58 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTZXJnaW8gR2FyY2lhIE11cmls bG8gW21haWx0bzpzZXJnaW8uZ2FyY2lhLm11cmlsbG9AZ21haWwuY29tXQ0KPiBTZW50OiBXZWRu ZXNkYXksIERlY2VtYmVyIDAzLCAyMDE0IDQ6NTIgUE0NCj4gVG86IFRpcnVtYWxlc3dhciBSZWRk eSAodGlyZWRkeSk7IEJyYW5kb24gV2lsbGlhbXMNCj4gQ2M6IGRyYWZ0LWNoZW54aW4tYmVoYXZl LXR1cm4td2Vic29ja2V0QHRvb2xzLmlldGYub3JnOyBKb25hdGhhbiBMZW5ub3g7DQo+IFtBQ01F XSBWaWN0b3IgUGFzY3VhbCBBdmlsYTsgdHJhbUBpZXRmLm9yZzsgU2ltb24gUGVycmVhdWx0DQo+ IFN1YmplY3Q6IFJlOiBbdHJhbV0gVFVSTiBvdmVyIFdlYlNvY2tldA0KPiANCj4gSSB3aWxsIGFz ayBpdCBvdGhlcndpc2UuDQo+IA0KPiBJIGFtIGluIGEgaG90ZWwgdGhhdCBhbGxvd3MgaHR0cC9o dHRwcy93c3Mvd3NzIGJ1dCB0dXJucyBvbiA0NDMgZG9lc24ndA0KPiB3b3JrLiBIb3cgaXMgQUxQ TiBzdXBwb3NlZCB0byBoZWxwIGluIHRoYXQgc2NlbmFyaW8gPw0KDQpIb3cgd2lsbCB0aGUgaG90 ZWwgZmlyZXdhbGwgaWRlbnRpZnkgdGhhdCBpdCdzIFRVUk4gdHJhZmZpYyBzZW50IG92ZXIgNDQz ID8NCg0KLVRpcnUNCg0KPiANCj4gQmVzdCByZWdhcmRzDQo+IFNlcmdpbw0KPiBPbiAwMy8xMi8y MDE0IDExOjQ3LCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpIHdyb3RlOg0KPiA+IEFMUE4g b25seSByZXF1aXJlcyBjaGFuZ2VzIHRvIHRoZSBjbGllbnQgYW5kIHNlcnZlci4gV2l0aCBUTFMg MS4zIEFMUE4gd2lsbA0KPiBiZSBlbmNyeXB0ZWQgYW5kIG1heSBub3QgYmUgYW55IHVzZSB0byBp bnRlcm1lZGlhdGUgZGV2aWNlcyBmb3IgYW55IHBvbGljeQ0KPiBlbmZvcmNlbWVudC4gSSBkb24n dCB1bmRlcnN0YW5kIHdoeSBBTFBOIGNhbm5vdCBiZSB1c2VkIHRvIHNvbHZlIHRoaXMNCj4gcHJv YmxlbSA/DQo+ID4NCj4gPiAtVGlydQ0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+ID4+IEZyb206IFNlcmdpbyBHYXJjaWEgTXVyaWxsbyBbbWFpbHRvOnNlcmdpby5nYXJj aWEubXVyaWxsb0BnbWFpbC5jb21dDQo+ID4+IFNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMDMs IDIwMTQgMjo1MCBQTQ0KPiA+PiBUbzogQnJhbmRvbiBXaWxsaWFtczsgVGlydW1hbGVzd2FyIFJl ZGR5ICh0aXJlZGR5KQ0KPiA+PiBDYzogZHJhZnQtY2hlbnhpbi1iZWhhdmUtdHVybi13ZWJzb2Nr ZXRAdG9vbHMuaWV0Zi5vcmc7IEpvbmF0aGFuDQo+IExlbm5veDsNCj4gPj4gW0FDTUVdIFZpY3Rv ciBQYXNjdWFsIEF2aWxhOyB0cmFtQGlldGYub3JnOyBTaW1vbiBQZXJyZWF1bHQNCj4gPj4gU3Vi amVjdDogUmU6IFt0cmFtXSBUVVJOIG92ZXIgV2ViU29ja2V0DQo+ID4+DQo+ID4+IEFtIEkgc3Vw cG9zZWQgdG8gY2hhbmdlIGV2ZXJ5IGhvdGVsLCBjYWZlIG9yIGFpcnBvcnQgd2lmaSBpbiB0aGUg d29ybGQgaW4NCj4gPj4gb3JkZXIgdG8gbWFrZSBpdCB3b3JrPyBUaGF0J3Mgd2hhdCBJIG1lYW4u DQo+ID4+DQo+ID4+IERvbid0IHRha2UgbWUgd3JvbmcsIEFMUE4gc2VlbXMgYSBnb29kIHNvbHV0 aW9uLCBhcyBnb29kIGFzIGlwdjYgaXMgZm9yDQo+ID4+IHJlbW92aW5nIE5BVCwgYnV0IGl0IGlz IHNvbWV0aGluZyBvdXQgbXkgY29udHJvbCB0byBoYXZlIGl0IGRlcGxveWVkDQo+ID4+IHdvcmxk d2lkZSwgc28gSSBjYW4ndCByZWx5IG9uIGl0IGFzIGEgc29sdXRpb24uIEZyb20gYSB3ZWJydGMg cG9pbnQgb2Ygdmlldw0KPiB3ZQ0KPiA+PiBvbmx5IGNvbnRyb2wgdGhlIGNsaWVudCBhbmQgdGhl IHR1cm4gc2VydmVyLCBldmVyeXRoaW5nIGluIGJldHdlZW4gc2hvdWxkDQo+IGJlDQo+ID4+IGNv bnNpZGVyZWQgaG9zdGlsZS4NCj4gPj4NCj4gPj4gQmVzdCByZWdhcmRzDQo+ID4+IFNlcmdpbw0K PiA+Pg0KPiA+PiBPbiAwMy8xMi8yMDE0IDE6NTgsIEJyYW5kb24gV2lsbGlhbXMgd3JvdGU6DQo+ ID4+PiBXaGF0IHBhcnQgb2YgQUxQTiBpcyBub3QgdW5kZXIgeW91ciBjb250cm9sPyBJZiB5b3Un cmUgZG9pbmcgV1NTLCB0aGVuDQo+ID4+PiB5b3UndmUgYWxyZWFkeSBnb3QgVExTIGluIHRoZSBw aWN0dXJlLCBzbyBBTFBOIGFuZCBXU1Mgc2VlbSB0byBib3RoDQo+ID4+PiBzb2x2ZSB0aGUgc2Vy dmVyLXNpZGUgbXVsdGlwbGV4aW5nIHByb2JsZW0gZnJvbSB0aGUgb3JpZ2luYWwgcHJvYmxlbQ0K PiA+Pj4gc3RhdGVtZW50LiBXaGF0IHBhcnQgb2YgdGhlIHByb2JsZW0gc3RhdGVtZW50IGRvZXMg V1NTIHNvbHZlIHRoYXQNCj4gQUxQTg0KPiA+Pj4gZG9lcyBub3Q/DQo+ID4+Pg0KPiA+Pj4gSWYg eW91J3JlIGNvbmNlcm5lZCBhYm91dCB1bmVuY3J5cHRlZCBUVVJOIG11bHRpcGxleGluZyB3aXRo DQo+ID4+PiB1bmVuY3J5cHRlZCBIVFRQIG9uIHBvcnQgODAsIHRoZW4gSSBjYW4gc2VlIFdTIHNv bHZpbmcgYSBwcm9ibGVtIHRoYXQNCj4gPj4+IEFMUE4gY2FuJ3Qgc29sdmUuDQo+ID4+Pg0KPiA+ Pj4gLS1CcmFuZG9uDQo+ID4+Pg0KPiA+Pj4gT24gMTIvMDIvMjAxNCAwMzoyNiBQTSwgU2VyZ2lv IEdhcmNpYSBNdXJpbGxvIHdyb3RlOg0KPiA+Pj4+IFdlIGNvbnRyb2wgdGhlIGNsaWVudCBhbmQg dGhlIHNlcnZlciwgYW5kIHlvdSBhcmUgYXNraW5nIG1lIHRvIHdhaXQNCj4gPj4+PiB1bnRpbCB3 aGF0IGlzIG5vdCBpbiBvdXIgY29udHJvbCBpcyBjaGFuZ2VkLiBPYnZpb3VzbHksIG5vdCB3b3Jr aW5nDQo+ID4+Pj4gZm9yIG1lDQo+ID4+Pj4NCj4gPj4+PiBCVFcsIEkgYW0gdGFsa2luZyBhYm91 dCByZWFsIGxpZmUgZXhwZXJpZW5jZXMsIHdoZW4gV1NTIHdvcmtzIGFuZA0KPiA+Pj4+IFRVUk5T IG92ZXIgNDQzIGRvZXNuJ3QuDQo+ID4+Pj4NCj4gPj4+PiBCZXN0IHJlZ2FyZHMNCj4gPj4+PiBT ZXJnaW8NCj4gPj4+Pg0KPiA+Pj4+IE9uIDAyLzEyLzIwMTQgMjA6NDQsIFRpcnVtYWxlc3dhciBS ZWRkeSAodGlyZWRkeSkgd3JvdGU6DQo+ID4+Pj4+IHdoeSB3aWxsIGl0IG5vdCB3b3JrIHdoZW4g QUxQTiBpcyB1c2VkID8NCj4gPj4+Pj4NCj4gPj4+Pj4gLVRpcnUNCj4gPj4+Pj4NCj4gPj4+Pj4g KkZyb206KlNlcmdpbyBHYXJjaWEgTXVyaWxsbw0KPiBbbWFpbHRvOnNlcmdpby5nYXJjaWEubXVy aWxsb0BnbWFpbC5jb21dID8NCj4gPj4+Pj4NCj4gPj4+Pj4gKlNlbnQ6KiBXZWRuZXNkYXksIERl Y2VtYmVyIDAzLCAyMDE0IDEyOjUyIEFNDQo+ID4+Pj4+ICpUbzoqIFRpcnVtYWxlc3dhciBSZWRk eSAodGlyZWRkeSkNCj4gPj4+Pj4gKkNjOiogSm9uYXRoYW4gTGVubm94OyBbQUNNRV0gVmljdG9y IFBhc2N1YWwgQXZpbGE7IFNpbW9uIFBlcnJlYXVsdDsNCj4gPj4+Pj4gdHJhbUBpZXRmLm9yZzsg ZHJhZnQtY2hlbnhpbi1iZWhhdmUtdHVybi13ZWJzb2NrZXRAdG9vbHMuaWV0Zi5vcmcNCj4gPj4+ Pj4gKlN1YmplY3Q6KiBSRTogW3RyYW1dIFRVUk4gb3ZlciBXZWJTb2NrZXQNCj4gPj4+Pj4NCj4g Pj4+Pj4NCj4gPj4+Pj4gRWwgMDIvMTIvMjAxNCAyMDowNCwgIlRpcnVtYWxlc3dhciBSZWRkeSAo dGlyZWRkeSkiDQo+ID4+Pj4+IDx0aXJlZGR5QGNpc2NvLmNvbSA8bWFpbHRvOnRpcmVkZHlAY2lz Y28uY29tPj4gZXNjcmliacOzOg0KPiA+Pj4+Pj4gRnJvbTogU2ltb24gUGVycmVhdWx0IFttYWls dG86c3BlcnJlYXVsdEBqaXZlLmNvbQ0KPiA+Pj4+PiA8bWFpbHRvOnNwZXJyZWF1bHRAaml2ZS5j b20+XQ0KPiA+Pj4+Pj4gU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMDIsIDIwMTQgMTA6MTkgUE0N Cj4gPj4+Pj4+DQo+ID4+Pj4+PiBUbzogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KQ0KPiA+ Pj4+Pj4gQ2M6IEpvbmF0aGFuIExlbm5veDsgU2VyZ2lvIEdhcmNpYSBNdXJpbGxvOyBWaWN0b3Ig UGFzY3VhbCBBdmlsYTsNCj4gPj4+Pj4gZHJhZnQtY2hlbnhpbi1iZWhhdmUtdHVybi13ZWJzb2Nr ZXRAdG9vbHMuaWV0Zi5vcmcNCj4gPj4+Pj4gPG1haWx0bzpkcmFmdC1jaGVueGluLWJlaGF2ZS10 dXJuLXdlYnNvY2tldEB0b29scy5pZXRmLm9yZz47DQo+ID4+Pj4+IHRyYW1AaWV0Zi5vcmcgPG1h aWx0bzp0cmFtQGlldGYub3JnPg0KPiA+Pj4+Pj4gU3ViamVjdDogUmU6IFt0cmFtXSBUVVJOIG92 ZXIgV2ViU29ja2V0DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+ Pj4+Pj4NCj4gPj4+Pj4+IE9uIFR1ZSwgRGVjIDIsIDIwMTQgYXQgOTozNCBBTSwgVGlydW1hbGVz d2FyIFJlZGR5ICh0aXJlZGR5KQ0KPiA+Pj4+PiA8dGlyZWRkeUBjaXNjby5jb20gPG1haWx0bzp0 aXJlZGR5QGNpc2NvLmNvbT4+IHdyb3RlOg0KPiA+Pj4+Pj4gVHJhbnNwYXJlbnQgcHJveGllcyBs aWtlIGZpcmV3YWxscyBrZWVwIGdldHRpbmcgdXBncmFkZWQNCj4gPj4+Pj4+IGZyZXF1ZW50bHkN Cj4gPj4+Pj4gdG8gaGFuZGxlIG5ldyBhcHBsaWNhdGlvbnMsIHRocmVhdHMgZXRjLiBJZiBmaXJl d2FsbCBoYXMgYSBmZWF0dXJlDQo+ID4+Pj4+IHRvIGJsb2NrIFdlYlJUQyB0cmFmZmljIHRoZW4g Ynkgc2VuZGluZyB0cmFmZmljIG92ZXIgV2ViU29ja2V0IHdpbGwNCj4gPj4+Pj4gbm90IHNvbHZl IHRoZSBwcm9ibGVtLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiAoQXMgYSBwYXJ0aWNp cGFudC4uLikNCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gVGhpcyBoYXMgYWxzbyBiZWVu IGRpc2N1c3NlZCBiZWZvcmUuIFRVUk4tb3Zlci1XZWJTb2NrZXRzIGlzIG5vdCBhDQo+ID4+Pj4+ IHdheSBmb3IgYXBwbGljYXRpb25zIHRvIGNpcmN1bXZlbnQgcG9saWN5Lg0KPiA+Pj4+Pj4NCj4g Pj4+Pj4+DQo+ID4+Pj4+PiBUaGUgcHJvYmxlbSBpcyB0aGVyZSBhcmUgbmV0d29ya3MgdGhhdCBh cmUgc2V0IHVwIHNvIHRoYXQgInRoZSB3ZWIiDQo+ID4+Pj4+IGlzIG9wZW4sIHRocm91Z2ggYSB0 cmFuc3BhcmVudCBwcm94eS4gV2ViUlRDIGlzIHBhcnQgb2YgInRoZSB3ZWIiLg0KPiA+Pj4+PiBN YWtpbmcgVFVSTiBmaXQgdGhlIG1vdWxkIG9mICJ0aGUgd2ViIiBpcyBpcyBub3QgY2lyY3VtdmVu dGluZw0KPiA+Pj4+PiBwb2xpY3ksIGl0J3MgbWFraW5nIFdlYlJUQyB3b3JrLiBZb3Ugc2hvdWxk IG5vdCBuZWVkIHRvIHVwZGF0ZSB5b3VyDQo+ID4+Pj4+IHByb3h5L2ZpcmV3YWxsIGNvbmZpZyBm b3IgV2ViUlRDIHRvIGp1c3Qgd29yayBpZiAidGhlIHdlYiIgYWxyZWFkeQ0KPiA+Pj4+PiBkb2Vz IHdvcmsuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFtUUl0gT2theSwgc28gbG9va3Mg bGlrZSB0aGUgcHJvYmxlbSBjYW4gYWxzbyBiZSBzb2x2ZWQgYnkgcnVubmluZw0KPiA+Pj4+PiBU VVJOIG92ZXIgNDQzIHNpbWlsYXIgdG8gcHJvcG9zYWxzIGluIERQUklWRSBXRyB0byBydW4gRE5T IG92ZXINCj4gNDQzLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4gR29vZCB0cnkhIFVubHVja3kgZW5vdWdo LCBkb2Vzbid0IHdvcmsuDQo+ID4+Pj4+DQo+ID4+Pj4+IEJlc3QgcmVnYXJkcw0KPiA+Pj4+PiBT ZXJnaW8NCj4gPj4+Pj4NCg0K From nobody Wed Dec 3 03:56:13 2014 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 574BA1A1A7A for ; Wed, 3 Dec 2014 03:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 LKb0siNjCjsE for ; Wed, 3 Dec 2014 03:56:11 -0800 (PST) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAB2E1A1A40 for ; Wed, 3 Dec 2014 03:56:10 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id ex7so24175129wid.0 for ; Wed, 03 Dec 2014 03:56:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8tBSu6wDxmav/YiLtdq1NucyZZNGr5nhDNIiphmCiyE=; b=fWI+6XrdGGrtlDjsA1QJP2B7nfzIuyQSaVxlYyQu7CudGCAla6rvTroMLmaXBN/jNi aEGPQEG8it4tn52/069uFHWpX41D8i6CgAEBbt1ufAzYxvpikKGRVGlnU5r5kJMy7PLi 6YZbpkWY4srFbkF7sh4UpoQ6QC1bW0FfoG73GvgMHXPVNvXzk/DX6s14dPZoWNf6MD+4 K9zkYzE4y1ZWFXFGaYQ4Jhd8eMZP8x6lOBMzFkyCQ5MkHfvIpjrmnnb0YAerDZSl6HXb XfGN/g7E7xAzMPjLxfb4+HglBrTp0qd20www6rMr0CV/KKBGGSFEuSdqVJXn87MJCdMw 33qw== X-Received: by 10.194.161.202 with SMTP id xu10mr7083400wjb.4.1417607769804; Wed, 03 Dec 2014 03:56:09 -0800 (PST) Received: from [192.168.1.37] (136.Red-81-39-109.dynamicIP.rima-tde.net. [81.39.109.136]) by mx.google.com with ESMTPSA id w10sm35977707wje.10.2014.12.03.03.56.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 03:56:09 -0800 (PST) Message-ID: <547EFA5A.4050500@gmail.com> Date: Wed, 03 Dec 2014 12:56:10 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , Brandon Williams References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B8E7@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B9B5@xmb-rcd-x10.cisco.com> <547E2069.4050307@gmail.com> <547E6022.5030101@akamai.com> <547ED5B3.7070102@gmail.com> <913383AAA69FF945B8F946018B75898A2837D203@xmb-rcd-x10.cisco.com> <547EF260.3050103@gmail.com> <913383AAA69FF945B8F946018B75898A2837D346@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2837D346@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/PQfz2AR1kypFjOLpaTQbhv6gHzw Cc: "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Jonathan Lennox , "\[ACME\] Victor Pascual Avila" , "tram@ietf.org" , Simon Perreault Subject: Re: [tram] TURN over WebSocket 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, 03 Dec 2014 11:56:12 -0000 On 03/12/2014 12:46, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com] >> Sent: Wednesday, December 03, 2014 4:52 PM >> To: Tirumaleswar Reddy (tireddy); Brandon Williams >> Cc: draft-chenxin-behave-turn-websocket@tools.ietf.org; Jonathan Lennox; >> [ACME] Victor Pascual Avila; tram@ietf.org; Simon Perreault >> Subject: Re: [tram] TURN over WebSocket >> >> I will ask it otherwise. >> >> I am in a hotel that allows http/https/wss/wss but turns on 443 doesn't >> work. How is ALPN supposed to help in that scenario ? > How will the hotel firewall identify that it's TURN traffic sent over 443 ? Ask the hotel wifi administrators... ;) I don't know how it works (DPI most probably) but the fact is that I have found this kind of scenarios in real life. BR Sergio From nobody Wed Dec 3 05:59:10 2014 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 68B151A1B2E for ; Wed, 3 Dec 2014 05:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9oXepp2-lIk for ; Wed, 3 Dec 2014 05:59:07 -0800 (PST) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 95E8C1A1B35 for ; Wed, 3 Dec 2014 05:58:59 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id B1D921EB84BF; Wed, 3 Dec 2014 14:58:58 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.125]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 14:58:58 +0100 From: "Hutton, Andrew" To: Sergio Garcia Murillo , "Tirumaleswar Reddy (tireddy)" , Brandon Williams Thread-Topic: [tram] TURN over WebSocket Thread-Index: AQHQDvAgD1e3+t0AIUS5ldoZP7bRhJx946Ag Date: Wed, 3 Dec 2014 13:58:57 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E620267@MCHP04MSX.global-ad.net> References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B8E7@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B9B5@xmb-rcd-x10.cisco.com> <547E2069.4050307@gmail.com> <547E6022.5030101@akamai.com> <547ED5B3.7070102@gmail.com> <913383AAA69FF945B8F946018B75898A2837D203@xmb-rcd-x10.cisco.com> <547EF260.3050103@gmail.com> <913383AAA69FF945B8F946018B75898A2837D346@xmb-rcd-x10.cisco.com> <547EFA5A.4050500@gmail.com> In-Reply-To: <547EFA5A.4050500@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/tmLIkGyiST1qJ7T0MfUx7Z4Czvo Cc: "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Jonathan Lennox , "\[ACME\] Victor Pascual Avila" , "tram@ietf.org" , Simon Perreault Subject: Re: [tram] TURN over WebSocket 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, 03 Dec 2014 13:59:08 -0000 On: 03 December 2014 11:56 Sergio Garcia Murillo Wrote: > To: Tirumaleswar Reddy (tireddy); Brandon Williams > Cc: draft-chenxin-behave-turn-websocket@tools.ietf.org; Jonathan > Lennox; [ACME] Victor Pascual Avila; tram@ietf.org; Simon Perreault > Subject: Re: [tram] TURN over WebSocket >=20 > On 03/12/2014 12:46, Tirumaleswar Reddy (tireddy) wrote: > >> -----Original Message----- > >> From: Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com] > >> Sent: Wednesday, December 03, 2014 4:52 PM > >> To: Tirumaleswar Reddy (tireddy); Brandon Williams > >> Cc: draft-chenxin-behave-turn-websocket@tools.ietf.org; Jonathan > Lennox; > >> [ACME] Victor Pascual Avila; tram@ietf.org; Simon Perreault > >> Subject: Re: [tram] TURN over WebSocket > >> > >> I will ask it otherwise. > >> > >> I am in a hotel that allows http/https/wss/wss but turns on 443 > doesn't > >> work. How is ALPN supposed to help in that scenario ? > > How will the hotel firewall identify that it's TURN traffic sent over > 443 ? >=20 > Ask the hotel wifi administrators... ;) >=20 > I don't know how it works (DPI most probably) but the fact is that I > have found this kind of scenarios in real life. >=20 If it is DPI detecting that the traffic looks like media then who is to say= that the DPI will not block the media when it is going over a websockets c= onnection. Again, I am not saying this is a bad idea I just think we have to understan= d the problem very clearly. Andy From nobody Wed Dec 3 06:25:41 2014 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 D7D571A1B2A for ; Wed, 3 Dec 2014 06:25:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwvpRXGMjXpe for ; Wed, 3 Dec 2014 06:25:36 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABD91A1B22 for ; Wed, 3 Dec 2014 06:25:36 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E923447567; Wed, 3 Dec 2014 14:25:35 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id DC8A94755F; Wed, 3 Dec 2014 14:25:35 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id D68AA202F; Wed, 3 Dec 2014 14:25:35 +0000 (GMT) Message-ID: <547F1D5F.8080302@akamai.com> Date: Wed, 03 Dec 2014 09:25:35 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Hutton, Andrew" , Sergio Garcia Murillo , "Tirumaleswar Reddy (tireddy)" References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B8E7@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B9B5@xmb-rcd-x10.cisco.com> <547E2069.4050307@gmail.com> <547E6022.5030101@akamai.com> <547ED5B3.7070102@gmail.com> <913383AAA69FF945B8F946018B75898A2837D203@xmb-rcd-x10.cisco.com> <547EF260.3050103@gmail.com> <913383AAA69FF945B8F946018B75898A2837D346@xmb-rcd-x10.cisco.com> <547EFA5A.4050500@gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF1E620267@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E620267@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/An0Zzgr38SHznGcIlOTJ3rAi22U Cc: "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Jonathan Lennox , "\[ACME\] Victor Pascual Avila" , "tram@ietf.org" , Simon Perreault Subject: Re: [tram] TURN over WebSocket 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, 03 Dec 2014 14:25:38 -0000 +1 On 12/03/2014 08:58 AM, Hutton, Andrew wrote: > On: 03 December 2014 11:56 Sergio Garcia Murillo Wrote: >> To: Tirumaleswar Reddy (tireddy); Brandon Williams >> Cc: draft-chenxin-behave-turn-websocket@tools.ietf.org; Jonathan >> Lennox; [ACME] Victor Pascual Avila; tram@ietf.org; Simon Perreault >> Subject: Re: [tram] TURN over WebSocket >> >> On 03/12/2014 12:46, Tirumaleswar Reddy (tireddy) wrote: >>>> -----Original Message----- >>>> From: Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com] >>>> Sent: Wednesday, December 03, 2014 4:52 PM >>>> To: Tirumaleswar Reddy (tireddy); Brandon Williams >>>> Cc: draft-chenxin-behave-turn-websocket@tools.ietf.org; Jonathan >> Lennox; >>>> [ACME] Victor Pascual Avila; tram@ietf.org; Simon Perreault >>>> Subject: Re: [tram] TURN over WebSocket >>>> >>>> I will ask it otherwise. >>>> >>>> I am in a hotel that allows http/https/wss/wss but turns on 443 >> doesn't >>>> work. How is ALPN supposed to help in that scenario ? >>> How will the hotel firewall identify that it's TURN traffic sent over >> 443 ? >> >> Ask the hotel wifi administrators... ;) >> >> I don't know how it works (DPI most probably) but the fact is that I >> have found this kind of scenarios in real life. >> > > If it is DPI detecting that the traffic looks like media then who is to say that the DPI will not block the media when it is going over a websockets connection. > > Again, I am not saying this is a bad idea I just think we have to understand the problem very clearly. > > Andy > > > > > > > > > > > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Wed Dec 3 06:27:12 2014 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 9A42B1A1B72 for ; Wed, 3 Dec 2014 06:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 WkPX67SGGgmq for ; Wed, 3 Dec 2014 06:27:04 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6CB1A1B22 for ; Wed, 3 Dec 2014 06:27:04 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B9921475F6 for ; Wed, 3 Dec 2014 14:27:03 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id AB221475F5 for ; Wed, 3 Dec 2014 14:27:03 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 92D38205A for ; Wed, 3 Dec 2014 14:27:03 +0000 (GMT) Message-ID: <547F1DB7.9080101@akamai.com> Date: Wed, 03 Dec 2014 09:27:03 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 CC: "tram@ietf.org" References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B8E7@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B9B5@xmb-rcd-x10.cisco.com> <547E2069.4050307@gmail.com> <547E6022.5030101@akamai.com> <547ED5B3.7070102@gmail.com> In-Reply-To: <547ED5B3.7070102@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/RsDV_5odaPurdx45Ct79p4o5TTY Subject: Re: [tram] TURN over WebSocket 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, 03 Dec 2014 14:27:08 -0000 I'm sorry Sergio, but I simply don't understand why WSS would work but ALPN would not. Why would ALPN require changing "every hotel, cafe or airport wifi"? Are you saying that they are transparently terminating TLS sessions (in which case it's not just a wifi), and that they aren't forwarding the ALPN designator downstream? In the absence of a middlebox that splits the TLS session, I don't see why ALPN support would need to be present anywhere other than the client that the TURN relay. --Brandon On 12/03/2014 04:19 AM, Sergio Garcia Murillo wrote: > Am I supposed to change every hotel, cafe or airport wifi in the world > in order to make it work? That's what I mean. > > Don't take me wrong, ALPN seems a good solution, as good as ipv6 is for > removing NAT, but it is something out my control to have it deployed > worldwide, so I can't rely on it as a solution. From a webrtc point of > view we only control the client and the turn server, everything in > between should be considered hostile. > > Best regards > Sergio > > On 03/12/2014 1:58, Brandon Williams wrote: >> What part of ALPN is not under your control? If you're doing WSS, then >> you've already got TLS in the picture, so ALPN and WSS seem to both >> solve the server-side multiplexing problem from the original problem >> statement. What part of the problem statement does WSS solve that ALPN >> does not? >> >> If you're concerned about unencrypted TURN multiplexing with >> unencrypted HTTP on port 80, then I can see WS solving a problem that >> ALPN can't solve. >> >> --Brandon >> >> On 12/02/2014 03:26 PM, Sergio Garcia Murillo wrote: >>> We control the client and the server, and you are asking me to wait >>> until what is not in our control is changed. Obviously, not working >>> for me >>> >>> BTW, I am talking about real life experiences, when WSS works and TURNS >>> over 443 doesn't. >>> >>> Best regards >>> Sergio >>> >>> On 02/12/2014 20:44, Tirumaleswar Reddy (tireddy) wrote: >>>> >>>> why will it not work when ALPN is used ? >>>> >>>> -Tiru >>>> >>>> *From:*Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com] ? >>>> >>>> *Sent:* Wednesday, December 03, 2014 12:52 AM >>>> *To:* Tirumaleswar Reddy (tireddy) >>>> *Cc:* Jonathan Lennox; [ACME] Victor Pascual Avila; Simon Perreault; >>>> tram@ietf.org; draft-chenxin-behave-turn-websocket@tools.ietf.org >>>> *Subject:* RE: [tram] TURN over WebSocket >>>> >>>> >>>> El 02/12/2014 20:04, "Tirumaleswar Reddy (tireddy)" >>> > escribió: >>>>> >>>>> From: Simon Perreault [mailto:sperreault@jive.com >>>> ] >>>>> Sent: Tuesday, December 02, 2014 10:19 PM >>>>> >>>>> To: Tirumaleswar Reddy (tireddy) >>>>> Cc: Jonathan Lennox; Sergio Garcia Murillo; Victor Pascual Avila; >>>> draft-chenxin-behave-turn-websocket@tools.ietf.org >>>> ; >>>> tram@ietf.org >>>>> Subject: Re: [tram] TURN over WebSocket >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar Reddy (tireddy) >>>> > wrote: >>>>> >>>>> Transparent proxies like firewalls keep getting upgraded frequently >>>> to handle new applications, threats etc. If firewall has a feature to >>>> block WebRTC traffic then by sending traffic over WebSocket will not >>>> solve the problem. >>>>> >>>>> >>>>> >>>>> (As a participant...) >>>>> >>>>> >>>>> This has also been discussed before. TURN-over-WebSockets is not a >>>> way for applications to circumvent policy. >>>>> >>>>> >>>>> >>>>> The problem is there are networks that are set up so that "the web" >>>> is open, through a transparent proxy. WebRTC is part of "the web". >>>> Making TURN fit the mould of "the web" is is not circumventing policy, >>>> it's making WebRTC work. You should not need to update your >>>> proxy/firewall config for WebRTC to just work if "the web" already >>>> does work. >>>>> >>>>> >>>>> >>>>> [TR] Okay, so looks like the problem can also be solved by running >>>> TURN over 443 similar to proposals in DPRIVE WG to run DNS over 443. >>>>> >>>>> >>>> >>>> Good try! Unlucky enough, doesn't work. >>>> >>>> Best regards >>>> Sergio >>>> >>> >> > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Wed Dec 3 06:28:02 2014 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 079A71A1A66 for ; Wed, 3 Dec 2014 06:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 6Gv0WMEfNqL2 for ; Wed, 3 Dec 2014 06:27:54 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 224871A1BB3 for ; Wed, 3 Dec 2014 06:27:43 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 0C1BA47567 for ; Wed, 3 Dec 2014 14:27:43 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id B7EB2475FD for ; Wed, 3 Dec 2014 14:27:42 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id B344E205A for ; Wed, 3 Dec 2014 14:27:42 +0000 (GMT) Message-ID: <547F1DDE.7030903@akamai.com> Date: Wed, 03 Dec 2014 09:27:42 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 CC: "tram@ietf.org" References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B8E7@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B9B5@xmb-rcd-x10.cisco.com> <547E2069.4050307@gmail.com> <547E6022.5030101@akamai.com> <547ED5B3.7070102@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/fq8X-IXSyOeAKfXyTa8zAEjZotY Subject: Re: [tram] TURN over WebSocket 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, 03 Dec 2014 14:27:56 -0000 What am I missing? Why would ALPN require changing the wifi network? I can accept that it may be necessary, but in the absence of someone explaining why the wifi network needs to care, it really doesn't make sense to me. --Brandon On 12/03/2014 04:24 AM, Oleg Moskalenko wrote: > That is a good point. A solution must not require changing every wifi > network in the world. A "pure" ALPN solution is a great way to kill the > whole WebRTC idea. > > On Wed, Dec 3, 2014 at 1:19 AM, Sergio Garcia Murillo > > wrote: > > Am I supposed to change every hotel, cafe or airport wifi in the > world in order to make it work? That's what I mean. > > Don't take me wrong, ALPN seems a good solution, as good as ipv6 is > for removing NAT, but it is something out my control to have it > deployed worldwide, so I can't rely on it as a solution. From a > webrtc point of view we only control the client and the turn server, > everything in between should be considered hostile. > > Best regards > Sergio > > > On 03/12/2014 1:58, Brandon Williams wrote: > > What part of ALPN is not under your control? If you're doing > WSS, then you've already got TLS in the picture, so ALPN and WSS > seem to both solve the server-side multiplexing problem from the > original problem statement. What part of the problem statement > does WSS solve that ALPN does not? > > If you're concerned about unencrypted TURN multiplexing with > unencrypted HTTP on port 80, then I can see WS solving a problem > that ALPN can't solve. > > --Brandon > > On 12/02/2014 03:26 PM, Sergio Garcia Murillo wrote: > > We control the client and the server, and you are asking me > to wait > until what is not in our control is changed. Obviously, not > working for me > > BTW, I am talking about real life experiences, when WSS > works and TURNS > over 443 doesn't. > > Best regards > Sergio > > On 02/12/2014 20:44, Tirumaleswar Reddy (tireddy) wrote: > > > why will it not work when ALPN is used ? > > -Tiru > > *From:*Sergio Garcia Murillo > [mailto:sergio.garcia.murillo@__gmail.com > ] ? > > *Sent:* Wednesday, December 03, 2014 12:52 AM > *To:* Tirumaleswar Reddy (tireddy) > *Cc:* Jonathan Lennox; [ACME] Victor Pascual Avila; > Simon Perreault; > tram@ietf.org ; > draft-chenxin-behave-turn-__websocket@tools.ietf.org > > *Subject:* RE: [tram] TURN over WebSocket > > > El 02/12/2014 20:04, "Tirumaleswar Reddy (tireddy)" > > >> > escribió: > > > > From: Simon Perreault [mailto:sperreault@jive.com > > >] > > Sent: Tuesday, December 02, 2014 10:19 PM > > > > To: Tirumaleswar Reddy (tireddy) > > Cc: Jonathan Lennox; Sergio Garcia Murillo; Victor > Pascual Avila; > draft-chenxin-behave-turn-__websocket@tools.ietf.org > > >__; > tram@ietf.org > > > > Subject: Re: [tram] TURN over WebSocket > > > > > > > > > > > > On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar Reddy > (tireddy) > > >> > wrote: > > > > Transparent proxies like firewalls keep getting > upgraded frequently > to handle new applications, threats etc. If firewall has > a feature to > block WebRTC traffic then by sending traffic over > WebSocket will not > solve the problem. > > > > > > > > (As a participant...) > > > > > > This has also been discussed before. > TURN-over-WebSockets is not a > way for applications to circumvent policy. > > > > > > > > The problem is there are networks that are set up so > that "the web" > is open, through a transparent proxy. WebRTC is part of > "the web". > Making TURN fit the mould of "the web" is is not > circumventing policy, > it's making WebRTC work. You should not need to update your > proxy/firewall config for WebRTC to just work if "the > web" already > does work. > > > > > > > > [TR] Okay, so looks like the problem can also be > solved by running > TURN over 443 similar to proposals in DPRIVE WG to run > DNS over 443. > > > > > > Good try! Unlucky enough, doesn't work. > > Best regards > Sergio > > > > > _________________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/__listinfo/tram > > > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Wed Dec 3 06:28:27 2014 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 209D41A1B66 for ; Wed, 3 Dec 2014 06:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 TdbqqSdzhb4h for ; Wed, 3 Dec 2014 06:28:17 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id A5DB01A1A66 for ; Wed, 3 Dec 2014 06:28:13 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 58453475F8 for ; Wed, 3 Dec 2014 14:28:13 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 4C2ED475F5 for ; Wed, 3 Dec 2014 14:28:13 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 365CE205A for ; Wed, 3 Dec 2014 14:28:13 +0000 (GMT) Message-ID: <547F1DFD.7030304@akamai.com> Date: Wed, 03 Dec 2014 09:28:13 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 CC: "tram@ietf.org" References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B8E7@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B9B5@xmb-rcd-x10.cisco.com> <547E2069.4050307@gmail.com> <547E6022.5030101@akamai.com> <547ED5B3.7070102@gmail.com> <913383AAA69FF945B8F946018B75898A2837D203@xmb-rcd-x10.cisco.com> <547EF260.3050103@gmail.com> In-Reply-To: <547EF260.3050103@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/gMbxP3ueAmt77jhtT13jx_ZFnso Subject: Re: [tram] TURN over WebSocket 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, 03 Dec 2014 14:28:19 -0000 Please explain why TURNS on 443 doesn't work in this context. The only thing that makes sense is that there is a restrictive device transparently terminating the TLS session (how is it able to do that without you knowing?). How else would it tell the difference between TURNS and HTTPS if it can't see the data? This is not called out as part of the use case anywhere in your document or the e-mail thread up to this point. --Brandon On 12/03/2014 06:22 AM, Sergio Garcia Murillo wrote: > I will ask it otherwise. > > I am in a hotel that allows http/https/wss/wss but turns on 443 doesn't > work. How is ALPN supposed to help in that scenario? > > Best regards > Sergio > On 03/12/2014 11:47, Tirumaleswar Reddy (tireddy) wrote: >> ALPN only requires changes to the client and server. With TLS 1.3 ALPN will be encrypted and may not be any use to intermediate devices for any policy enforcement. I don't understand why ALPN cannot be used to solve this problem ? >> >> -Tiru >> >>> -----Original Message----- >>> From: Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com] >>> Sent: Wednesday, December 03, 2014 2:50 PM >>> To: Brandon Williams; Tirumaleswar Reddy (tireddy) >>> Cc: draft-chenxin-behave-turn-websocket@tools.ietf.org; Jonathan Lennox; >>> [ACME] Victor Pascual Avila; tram@ietf.org; Simon Perreault >>> Subject: Re: [tram] TURN over WebSocket >>> >>> Am I supposed to change every hotel, cafe or airport wifi in the world in >>> order to make it work? That's what I mean. >>> >>> Don't take me wrong, ALPN seems a good solution, as good as ipv6 is for >>> removing NAT, but it is something out my control to have it deployed >>> worldwide, so I can't rely on it as a solution. From a webrtc point of view we >>> only control the client and the turn server, everything in between should be >>> considered hostile. >>> >>> Best regards >>> Sergio >>> >>> On 03/12/2014 1:58, Brandon Williams wrote: >>>> What part of ALPN is not under your control? If you're doing WSS, then >>>> you've already got TLS in the picture, so ALPN and WSS seem to both >>>> solve the server-side multiplexing problem from the original problem >>>> statement. What part of the problem statement does WSS solve that ALPN >>>> does not? >>>> >>>> If you're concerned about unencrypted TURN multiplexing with >>>> unencrypted HTTP on port 80, then I can see WS solving a problem that >>>> ALPN can't solve. >>>> >>>> --Brandon >>>> >>>> On 12/02/2014 03:26 PM, Sergio Garcia Murillo wrote: >>>>> We control the client and the server, and you are asking me to wait >>>>> until what is not in our control is changed. Obviously, not working >>>>> for me >>>>> >>>>> BTW, I am talking about real life experiences, when WSS works and >>>>> TURNS over 443 doesn't. >>>>> >>>>> Best regards >>>>> Sergio >>>>> >>>>> On 02/12/2014 20:44, Tirumaleswar Reddy (tireddy) wrote: >>>>>> why will it not work when ALPN is used ? >>>>>> >>>>>> -Tiru >>>>>> >>>>>> *From:*Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com] ? >>>>>> >>>>>> *Sent:* Wednesday, December 03, 2014 12:52 AM >>>>>> *To:* Tirumaleswar Reddy (tireddy) >>>>>> *Cc:* Jonathan Lennox; [ACME] Victor Pascual Avila; Simon Perreault; >>>>>> tram@ietf.org; draft-chenxin-behave-turn-websocket@tools.ietf.org >>>>>> *Subject:* RE: [tram] TURN over WebSocket >>>>>> >>>>>> >>>>>> El 02/12/2014 20:04, "Tirumaleswar Reddy (tireddy)" >>>>>> > escribió: >>>>>>> From: Simon Perreault [mailto:sperreault@jive.com >>>>>> ] >>>>>>> Sent: Tuesday, December 02, 2014 10:19 PM >>>>>>> >>>>>>> To: Tirumaleswar Reddy (tireddy) >>>>>>> Cc: Jonathan Lennox; Sergio Garcia Murillo; Victor Pascual Avila; >>>>>> draft-chenxin-behave-turn-websocket@tools.ietf.org >>>>>> ; >>>>>> tram@ietf.org >>>>>>> Subject: Re: [tram] TURN over WebSocket >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar Reddy (tireddy) >>>>>> > wrote: >>>>>>> Transparent proxies like firewalls keep getting upgraded >>>>>>> frequently >>>>>> to handle new applications, threats etc. If firewall has a feature >>>>>> to block WebRTC traffic then by sending traffic over WebSocket will >>>>>> not solve the problem. >>>>>>> >>>>>>> >>>>>>> (As a participant...) >>>>>>> >>>>>>> >>>>>>> This has also been discussed before. TURN-over-WebSockets is not a >>>>>> way for applications to circumvent policy. >>>>>>> >>>>>>> >>>>>>> The problem is there are networks that are set up so that "the web" >>>>>> is open, through a transparent proxy. WebRTC is part of "the web". >>>>>> Making TURN fit the mould of "the web" is is not circumventing >>>>>> policy, it's making WebRTC work. You should not need to update your >>>>>> proxy/firewall config for WebRTC to just work if "the web" already >>>>>> does work. >>>>>>> >>>>>>> >>>>>>> [TR] Okay, so looks like the problem can also be solved by running >>>>>> TURN over 443 similar to proposals in DPRIVE WG to run DNS over 443. >>>>>>> >>>>>> Good try! Unlucky enough, doesn't work. >>>>>> >>>>>> Best regards >>>>>> Sergio >>>>>> > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Wed Dec 3 06:39:15 2014 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 B696C1A1B2C for ; Wed, 3 Dec 2014 06:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 4sebb4lRLfFv for ; Wed, 3 Dec 2014 06:39:11 -0800 (PST) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 010611A1AD9 for ; Wed, 3 Dec 2014 06:39:11 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id y19so20019101wgg.7 for ; Wed, 03 Dec 2014 06:39:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=1G0D9m8pjo6Co/FICi5lmp6N7VExRB5jpTieK1XWHHA=; b=uIdsIKgj2Oj8DbwAMEaO8HYYTwosFINvTfzwBjnN030RPWGYfhTwxFJaYu569668Ti gyDxFQJmDR5TNiWQKUHyjgzkx+2oc9/HdtZ42UyqKjGB1tX6Ho2TAHADJDt8PMzcBhTS mS5deaJKJvnAf+oGOx6MpphaiGi89Gmpm/ShIZxG0QjWGfYAkRgUtELJZlXTmaEZEEBl 1FN84xkGxuflshkWYQctrDHIN6j7aIDRnYqAaanIpkimh0p/kvq6ySxj9kH+CKYdI3Kc yww97j+xwyDz/YHs2knni6olFsA1k16o4uvAaxX/55aCny6vbkmViy4g0LujJh3mQud+ 0mFg== X-Received: by 10.194.77.38 with SMTP id p6mr8176125wjw.50.1417617549713; Wed, 03 Dec 2014 06:39:09 -0800 (PST) Received: from [192.168.1.37] (136.Red-81-39-109.dynamicIP.rima-tde.net. [81.39.109.136]) by mx.google.com with ESMTPSA id gs9sm36537819wjc.47.2014.12.03.06.39.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 06:39:08 -0800 (PST) Message-ID: <547F208E.6000000@gmail.com> Date: Wed, 03 Dec 2014 15:39:10 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brandon Williams , Oleg Moskalenko References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B8E7@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B9B5@xmb-rcd-x10.cisco.com> <547E2069.4050307@gmail.com> <547E6022.5030101@akamai.com> <547ED5B3.7070102@gmail.com> <547F1C55.4040208@akamai.com> In-Reply-To: <547F1C55.4040208@akamai.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/AKREVpJpspgjSbLYSdlbLhLMRSo Cc: Jonathan Lennox , "tram@ietf.org" , "\[ACME\] Victor Pascual Avila" , "Tirumaleswar Reddy \(tireddy\)" , "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Simon Perreault Subject: Re: [tram] TURN over WebSocket 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, 03 Dec 2014 14:39:13 -0000 Maybe then is me the one I am missing something, can you explain how is ALPN meant to solve the problem if TURNS over 443 is blocked by the proxy? Best regards Sergio On 03/12/2014 15:21, Brandon Williams wrote: > What am I missing? Why would ALPN require changing the wifi network? I > can accept that it may be necessary, but in the absence of someone > explaining why the wifi network needs to care, it really doesn't make > sense to me. > > --Brandon > > On 12/03/2014 04:24 AM, Oleg Moskalenko wrote: >> That is a good point. A solution must not require changing every wifi >> network in the world. A "pure" ALPN solution is a great way to kill the >> whole WebRTC idea. >> >> On Wed, Dec 3, 2014 at 1:19 AM, Sergio Garcia Murillo >> > > wrote: >> >> Am I supposed to change every hotel, cafe or airport wifi in the >> world in order to make it work? That's what I mean. >> >> Don't take me wrong, ALPN seems a good solution, as good as ipv6 is >> for removing NAT, but it is something out my control to have it >> deployed worldwide, so I can't rely on it as a solution. From a >> webrtc point of view we only control the client and the turn server, >> everything in between should be considered hostile. >> >> Best regards >> Sergio >> >> >> On 03/12/2014 1:58, Brandon Williams wrote: >> >> What part of ALPN is not under your control? If you're doing >> WSS, then you've already got TLS in the picture, so ALPN and WSS >> seem to both solve the server-side multiplexing problem from the >> original problem statement. What part of the problem statement >> does WSS solve that ALPN does not? >> >> If you're concerned about unencrypted TURN multiplexing with >> unencrypted HTTP on port 80, then I can see WS solving a problem >> that ALPN can't solve. >> >> --Brandon >> >> On 12/02/2014 03:26 PM, Sergio Garcia Murillo wrote: >> >> We control the client and the server, and you are asking me >> to wait >> until what is not in our control is changed. Obviously, not >> working for me >> >> BTW, I am talking about real life experiences, when WSS >> works and TURNS >> over 443 doesn't. >> >> Best regards >> Sergio >> >> On 02/12/2014 20:44, Tirumaleswar Reddy (tireddy) wrote: >> >> >> why will it not work when ALPN is used ? >> >> -Tiru >> >> *From:*Sergio Garcia Murillo >> [mailto:sergio.garcia.murillo@__gmail.com >> ] ? >> >> *Sent:* Wednesday, December 03, 2014 12:52 AM >> *To:* Tirumaleswar Reddy (tireddy) >> *Cc:* Jonathan Lennox; [ACME] Victor Pascual Avila; >> Simon Perreault; >> tram@ietf.org ; >> draft-chenxin-behave-turn-__websocket@tools.ietf.org >> >> *Subject:* RE: [tram] TURN over WebSocket >> >> >> El 02/12/2014 20:04, "Tirumaleswar Reddy (tireddy)" >> >> >> >> escribió: >> > >> > From: Simon Perreault [mailto:sperreault@jive.com >> >> > >] >> > Sent: Tuesday, December 02, 2014 10:19 PM >> > >> > To: Tirumaleswar Reddy (tireddy) >> > Cc: Jonathan Lennox; Sergio Garcia Murillo; Victor >> Pascual Avila; >> draft-chenxin-behave-turn-__websocket@tools.ietf.org >> >> > >__; >> tram@ietf.org >> > >> > Subject: Re: [tram] TURN over WebSocket >> > >> > >> > >> > >> > >> > On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar Reddy >> (tireddy) >> >> >> >> wrote: >> > >> > Transparent proxies like firewalls keep getting >> upgraded frequently >> to handle new applications, threats etc. If firewall has >> a feature to >> block WebRTC traffic then by sending traffic over >> WebSocket will not >> solve the problem. >> > >> > >> > >> > (As a participant...) >> > >> > >> > This has also been discussed before. >> TURN-over-WebSockets is not a >> way for applications to circumvent policy. >> > >> > >> > >> > The problem is there are networks that are set up so >> that "the web" >> is open, through a transparent proxy. WebRTC is part of >> "the web". >> Making TURN fit the mould of "the web" is is not >> circumventing policy, >> it's making WebRTC work. You should not need to >> update your >> proxy/firewall config for WebRTC to just work if "the >> web" already >> does work. >> > >> > >> > >> > [TR] Okay, so looks like the problem can also be >> solved by running >> TURN over 443 similar to proposals in DPRIVE WG to run >> DNS over 443. >> > >> > >> >> Good try! Unlucky enough, doesn't work. >> >> Best regards >> Sergio >> >> >> >> >> _________________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/__listinfo/tram >> >> >> > From nobody Wed Dec 3 06:46:12 2014 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 218C91A1AD0 for ; Wed, 3 Dec 2014 06:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 DU6XeYKjF7CI for ; Wed, 3 Dec 2014 06:46:09 -0800 (PST) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C0401A011D for ; Wed, 3 Dec 2014 06:46:09 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id b13so20024827wgh.17 for ; Wed, 03 Dec 2014 06:46:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=/HefvIMXcnlfxOOwXxUUtoe4RfCm8LLBcznLllKsiog=; b=kcP/M5cp9ZXZgZQgGWM59plVDbO0Ea4jmvBYVB5B8Am/7DIj3oUM1D82NFfKam+XQr Jc8o0NlBK1f2hwOP8ylnc67Tgo+Jvcc5GG+8d5mt5coEVn3xLUw5m5YE7mrQFsGJ+gPY 26NuKUMqc0ba4ZwHzSYhv0Z8jRP8b4WPpideORGqfFOsYvlcLShiCzTS0ZMhDd/eZ6QR JDZPGZYifFVoJ9+nrZpCFH8vUdrTaK0bMODGYPTXOnSBVewiYC+HbnZM+KQTcYG3zBAp 9VkvYp6f6gmb4HRqirKXn+C4tToU5K4XBw8u7OY1rPq7fIlQRF5cG4tM17+QFbP9ulcX Xq1A== X-Received: by 10.180.85.6 with SMTP id d6mr102721812wiz.82.1417617968186; Wed, 03 Dec 2014 06:46:08 -0800 (PST) Received: from [192.168.1.37] (136.Red-81-39-109.dynamicIP.rima-tde.net. [81.39.109.136]) by mx.google.com with ESMTPSA id qg11sm30551789wic.17.2014.12.03.06.46.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 06:46:07 -0800 (PST) Message-ID: <547F2231.6030900@gmail.com> Date: Wed, 03 Dec 2014 15:46:09 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Hutton, Andrew" , "Tirumaleswar Reddy (tireddy)" , Brandon Williams References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B8E7@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B9B5@xmb-rcd-x10.cisco.com> <547E2069.4050307@gmail.com> <547E6022.5030101@akamai.com> <547ED5B3.7070102@gmail.com> <913383AAA69FF945B8F946018B75898A2837D203@xmb-rcd-x10.cisco.com> <547EF260.3050103@gmail.com> <913383AAA69FF945B8F946018B75898A2837D346@xmb-rcd-x10.cisco.com> <547EFA5A.4050500@gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF1E620267@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E620267@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/O9hz7wh2I6FoUQL92ueITlgo34U Cc: "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Jonathan Lennox , "\[ACME\] Victor Pascual Avila" , "tram@ietf.org" , Simon Perreault Subject: Re: [tram] TURN over WebSocket 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, 03 Dec 2014 14:46:11 -0000 On 03/12/2014 14:58, Hutton, Andrew wrote: > On: 03 December 2014 11:56 Sergio Garcia Murillo Wrote: >> To: Tirumaleswar Reddy (tireddy); Brandon Williams >> Cc: draft-chenxin-behave-turn-websocket@tools.ietf.org; Jonathan >> Lennox; [ACME] Victor Pascual Avila; tram@ietf.org; Simon Perreault >> Subject: Re: [tram] TURN over WebSocket >> >> On 03/12/2014 12:46, Tirumaleswar Reddy (tireddy) wrote: >>>> -----Original Message----- >>>> From: Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com] >>>> Sent: Wednesday, December 03, 2014 4:52 PM >>>> To: Tirumaleswar Reddy (tireddy); Brandon Williams >>>> Cc: draft-chenxin-behave-turn-websocket@tools.ietf.org; Jonathan >> Lennox; >>>> [ACME] Victor Pascual Avila; tram@ietf.org; Simon Perreault >>>> Subject: Re: [tram] TURN over WebSocket >>>> >>>> I will ask it otherwise. >>>> >>>> I am in a hotel that allows http/https/wss/wss but turns on 443 >> doesn't >>>> work. How is ALPN supposed to help in that scenario ? >>> How will the hotel firewall identify that it's TURN traffic sent over >> 443 ? >> >> Ask the hotel wifi administrators... ;) >> >> I don't know how it works (DPI most probably) but the fact is that I >> have found this kind of scenarios in real life. >> > If it is DPI detecting that the traffic looks like media then who is to say that the DPI will not block the media when it is going over a websockets connection. > > Again, I am not saying this is a bad idea I just think we have to understand the problem very clearly. Completely fair. I would love to provide more info, but unfortunately this kind of stuff doesn't happen on a controlled environment. I have got reports which show no relay candidates/reflexive candidates gathered and WSS signaling happening without issues. There have been quite a lot of similar reports going on the mailing lists for quite some time. Best regards Sergio From nobody Wed Dec 3 07:57:32 2014 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 5F55C1A1B3F for ; Wed, 3 Dec 2014 07:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xp339w6yi4G for ; Wed, 3 Dec 2014 07:57:25 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 19C4F1A1B7E for ; Wed, 3 Dec 2014 07:57:25 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4C82B28545; Wed, 3 Dec 2014 15:57:24 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 3307328542; Wed, 3 Dec 2014 15:57:24 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id E1AFB2071; Wed, 3 Dec 2014 15:57:23 +0000 (GMT) Message-ID: <547F32E3.1000708@akamai.com> Date: Wed, 03 Dec 2014 10:57:23 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Sergio Garcia Murillo , Oleg Moskalenko References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B8E7@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B9B5@xmb-rcd-x10.cisco.com> <547E2069.4050307@gmail.com> <547E6022.5030101@akamai.com> <547ED5B3.7070102@gmail.com> <547F1C55.4040208@akamai.com> <547F208E.6000000@gmail.com> In-Reply-To: <547F208E.6000000@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/vCc75jVlGEqHWgIJb2p2LzVy5nw Cc: Jonathan Lennox , "tram@ietf.org" , "\[ACME\] Victor Pascual Avila" , "Tirumaleswar Reddy \(tireddy\)" , "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Simon Perreault Subject: Re: [tram] TURN over WebSocket 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, 03 Dec 2014 15:57:31 -0000 The only thing that makes sense to me to explain the problem you describe is that the proxy is splitting the TLS session so that it can view the data flow. If such a proxy only supports HTTP (and by extension Websockets) for the data flow, then it would make sense that TURNS over 443 does not work. The piece I'm missing though is how the proxy could be splitting the TLS session in this way without you knowing, unless the client is accepting a certificate signed by someone else's CA. Nevertheless, if TLS splitting is what's happening and the proxy is rejecting data flows that do not look like HTTP, I can understand how WSS might resolve the problem under conditions where TURNS with ALPN might not. That having been said, if I'm correct about the source of the problem, I'm conflicted about taking up work intended to make a proxy like this function for WebRTC. If TLS is being used solely for the purpose of firewall traversal, then it's OK to split the session. But what if that isn't the case? There are significant security implications associated with helping such a system to function transparently. I personally would rather see my WebRTC sessions fail than accept decryption by an unknown MITM. Of course, it might be the case that something else is happening here and there is no decryption happening on the proxy, which returns me to the point that Andrew made ... I think we need to better understand the nature of the problem in order to decide whether it makes sense to adopt the draft and add a milestone. --Brandon On 12/03/2014 09:39 AM, Sergio Garcia Murillo wrote: > Maybe then is me the one I am missing something, can you explain how is > ALPN meant to solve the problem if TURNS over 443 is blocked by the proxy? > > Best regards > Sergio > On 03/12/2014 15:21, Brandon Williams wrote: >> What am I missing? Why would ALPN require changing the wifi network? I >> can accept that it may be necessary, but in the absence of someone >> explaining why the wifi network needs to care, it really doesn't make >> sense to me. >> >> --Brandon >> >> On 12/03/2014 04:24 AM, Oleg Moskalenko wrote: >>> That is a good point. A solution must not require changing every wifi >>> network in the world. A "pure" ALPN solution is a great way to kill the >>> whole WebRTC idea. >>> >>> On Wed, Dec 3, 2014 at 1:19 AM, Sergio Garcia Murillo >>> >> > wrote: >>> >>> Am I supposed to change every hotel, cafe or airport wifi in the >>> world in order to make it work? That's what I mean. >>> >>> Don't take me wrong, ALPN seems a good solution, as good as ipv6 is >>> for removing NAT, but it is something out my control to have it >>> deployed worldwide, so I can't rely on it as a solution. From a >>> webrtc point of view we only control the client and the turn server, >>> everything in between should be considered hostile. >>> >>> Best regards >>> Sergio >>> >>> >>> On 03/12/2014 1:58, Brandon Williams wrote: >>> >>> What part of ALPN is not under your control? If you're doing >>> WSS, then you've already got TLS in the picture, so ALPN and WSS >>> seem to both solve the server-side multiplexing problem from the >>> original problem statement. What part of the problem statement >>> does WSS solve that ALPN does not? >>> >>> If you're concerned about unencrypted TURN multiplexing with >>> unencrypted HTTP on port 80, then I can see WS solving a problem >>> that ALPN can't solve. >>> >>> --Brandon >>> >>> On 12/02/2014 03:26 PM, Sergio Garcia Murillo wrote: >>> >>> We control the client and the server, and you are asking me >>> to wait >>> until what is not in our control is changed. Obviously, not >>> working for me >>> >>> BTW, I am talking about real life experiences, when WSS >>> works and TURNS >>> over 443 doesn't. >>> >>> Best regards >>> Sergio >>> >>> On 02/12/2014 20:44, Tirumaleswar Reddy (tireddy) wrote: >>> >>> >>> why will it not work when ALPN is used ? >>> >>> -Tiru >>> >>> *From:*Sergio Garcia Murillo >>> [mailto:sergio.garcia.murillo@__gmail.com >>> ] ? >>> >>> *Sent:* Wednesday, December 03, 2014 12:52 AM >>> *To:* Tirumaleswar Reddy (tireddy) >>> *Cc:* Jonathan Lennox; [ACME] Victor Pascual Avila; >>> Simon Perreault; >>> tram@ietf.org ; >>> draft-chenxin-behave-turn-__websocket@tools.ietf.org >>> >>> *Subject:* RE: [tram] TURN over WebSocket >>> >>> >>> El 02/12/2014 20:04, "Tirumaleswar Reddy (tireddy)" >>> >>> >> >>> escribió: >>> > >>> > From: Simon Perreault [mailto:sperreault@jive.com >>> >>> >> >] >>> > Sent: Tuesday, December 02, 2014 10:19 PM >>> > >>> > To: Tirumaleswar Reddy (tireddy) >>> > Cc: Jonathan Lennox; Sergio Garcia Murillo; Victor >>> Pascual Avila; >>> draft-chenxin-behave-turn-__websocket@tools.ietf.org >>> >>> >> >__; >>> tram@ietf.org >>> > >>> > Subject: Re: [tram] TURN over WebSocket >>> > >>> > >>> > >>> > >>> > >>> > On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar Reddy >>> (tireddy) >>> >>> >> >>> wrote: >>> > >>> > Transparent proxies like firewalls keep getting >>> upgraded frequently >>> to handle new applications, threats etc. If firewall has >>> a feature to >>> block WebRTC traffic then by sending traffic over >>> WebSocket will not >>> solve the problem. >>> > >>> > >>> > >>> > (As a participant...) >>> > >>> > >>> > This has also been discussed before. >>> TURN-over-WebSockets is not a >>> way for applications to circumvent policy. >>> > >>> > >>> > >>> > The problem is there are networks that are set up so >>> that "the web" >>> is open, through a transparent proxy. WebRTC is part of >>> "the web". >>> Making TURN fit the mould of "the web" is is not >>> circumventing policy, >>> it's making WebRTC work. You should not need to >>> update your >>> proxy/firewall config for WebRTC to just work if "the >>> web" already >>> does work. >>> > >>> > >>> > >>> > [TR] Okay, so looks like the problem can also be >>> solved by running >>> TURN over 443 similar to proposals in DPRIVE WG to run >>> DNS over 443. >>> > >>> > >>> >>> Good try! Unlucky enough, doesn't work. >>> >>> Best regards >>> Sergio >>> >>> >>> >>> >>> _________________________________________________ >>> tram mailing list >>> tram@ietf.org >>> https://www.ietf.org/mailman/__listinfo/tram >>> >>> >>> >> > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Wed Dec 3 12:32:08 2014 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 27EA21ABC0F for ; Wed, 3 Dec 2014 12:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 8tbCu5Ve52mG for ; Wed, 3 Dec 2014 12:30:22 -0800 (PST) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6824F1AC3BF for ; Wed, 3 Dec 2014 12:30:22 -0800 (PST) Received: by mail-oi0-f49.google.com with SMTP id i138so11150789oig.8 for ; Wed, 03 Dec 2014 12:30:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uqHklMr3e/twiq+hB+4f5ATCyBWwCQ9A6fR5Kl0zr24=; b=koKZm4CC3DYVL+GTHr3syTBBNZu70nKfHI4jkEA/QMcznOEL/Teyym7SlOdTHjJYDq 0PmnfgMvwNWPI0UVpovaBYFpE8g6gUun8KtfkU+V7WTDEnHdOkOxOuGtc1A0SZLUpni9 jmwKH4PIkutZb4M+oryobDXzwZc/hzHG39J3Zi4u5Kw1ssD4wlI+BJ5gxPLoX5UhTeRP 6zc1n8lgNQpuMLFE4ONCTcvtY98imjzoJvG3VG27gXlo0Ovl5zmO9RzEUIxJpTfe54Ye 0Opk5wDZwbiHqGyvlHKWor0j6X3b61/rzKtCTxNdL4yfnsxALEZwqxumXN4qCbRCclHY 2aZQ== MIME-Version: 1.0 X-Received: by 10.60.149.195 with SMTP id uc3mr4463432oeb.14.1417638621685; Wed, 03 Dec 2014 12:30:21 -0800 (PST) Received: by 10.76.152.105 with HTTP; Wed, 3 Dec 2014 12:30:21 -0800 (PST) In-Reply-To: <547F32E3.1000708@akamai.com> References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B8E7@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B9B5@xmb-rcd-x10.cisco.com> <547E2069.4050307@gmail.com> <547E6022.5030101@akamai.com> <547ED5B3.7070102@gmail.com> <547F1C55.4040208@akamai.com> <547F208E.6000000@gmail.com> <547F32E3.1000708@akamai.com> Date: Wed, 3 Dec 2014 13:30:21 -0700 Message-ID: From: toadzky To: Brandon Williams Content-Type: multipart/alternative; boundary=047d7b417ccf772dad050955b643 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/iBOJEPHCBe7CnWcrxxhZkZ0Wen0 Cc: Jonathan Lennox , Oleg Moskalenko , "tram@ietf.org" , "\[ACME\] Victor Pascual Avila" , Sergio Garcia Murillo , "Tirumaleswar Reddy \(tireddy\)" , "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Simon Perreault Subject: Re: [tram] TURN over WebSocket 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, 03 Dec 2014 20:30:35 -0000 X-List-Received-Date: Wed, 03 Dec 2014 20:30:35 -0000 --047d7b417ccf772dad050955b643 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As a developer, I would much prefer to do this kind of thing over WSS. Websockets allow the application to control processing on the packets, rather than relying on a framework to do. As far as I can tell, nothing really supports ALPN at all. If I wanted to write a proxy in Java that only listened on 80 and 443, to do ALPN, Jersey (or whichever framework I choose) would need to support ALPN and allow me to register different handlers for different types. That would be fine if it was a network library (like Netty), but it's an HTTP framework that would be dealing with other TCP protocols. On top of that, the websocket solution can be supported quickly and easily with existing frameworks and infrastructure - no waiting for someone else to decide to finally support ALPN. David On Wed, Dec 3, 2014 at 8:57 AM, Brandon Williams < brandon.williams@akamai.com> wrote: > The only thing that makes sense to me to explain the problem you describe > is that the proxy is splitting the TLS session so that it can view the da= ta > flow. If such a proxy only supports HTTP (and by extension Websockets) fo= r > the data flow, then it would make sense that TURNS over 443 does not work= . > The piece I'm missing though is how the proxy could be splitting the TLS > session in this way without you knowing, unless the client is accepting a > certificate signed by someone else's CA. Nevertheless, if TLS splitting i= s > what's happening and the proxy is rejecting data flows that do not look > like HTTP, I can understand how WSS might resolve the problem under > conditions where TURNS with ALPN might not. > > That having been said, if I'm correct about the source of the problem, I'= m > conflicted about taking up work intended to make a proxy like this functi= on > for WebRTC. If TLS is being used solely for the purpose of firewall > traversal, then it's OK to split the session. But what if that isn't the > case? There are significant security implications associated with helping > such a system to function transparently. I personally would rather see my > WebRTC sessions fail than accept decryption by an unknown MITM. > > Of course, it might be the case that something else is happening here and > there is no decryption happening on the proxy, which returns me to the > point that Andrew made ... I think we need to better understand the natur= e > of the problem in order to decide whether it makes sense to adopt the dra= ft > and add a milestone. > > --Brandon > > > On 12/03/2014 09:39 AM, Sergio Garcia Murillo wrote: > >> Maybe then is me the one I am missing something, can you explain how is >> ALPN meant to solve the problem if TURNS over 443 is blocked by the prox= y? >> >> Best regards >> Sergio >> On 03/12/2014 15:21, Brandon Williams wrote: >> >>> What am I missing? Why would ALPN require changing the wifi network? I >>> can accept that it may be necessary, but in the absence of someone >>> explaining why the wifi network needs to care, it really doesn't make >>> sense to me. >>> >>> --Brandon >>> >>> On 12/03/2014 04:24 AM, Oleg Moskalenko wrote: >>> >>>> That is a good point. A solution must not require changing every wifi >>>> network in the world. A "pure" ALPN solution is a great way to kill t= he >>>> whole WebRTC idea. >>>> >>>> On Wed, Dec 3, 2014 at 1:19 AM, Sergio Garcia Murillo >>>> >>> > wrote: >>>> >>>> Am I supposed to change every hotel, cafe or airport wifi in the >>>> world in order to make it work? That's what I mean. >>>> >>>> Don't take me wrong, ALPN seems a good solution, as good as ipv6 = is >>>> for removing NAT, but it is something out my control to have it >>>> deployed worldwide, so I can't rely on it as a solution. From a >>>> webrtc point of view we only control the client and the turn >>>> server, >>>> everything in between should be considered hostile. >>>> >>>> Best regards >>>> Sergio >>>> >>>> >>>> On 03/12/2014 1:58, Brandon Williams wrote: >>>> >>>> What part of ALPN is not under your control? If you're doing >>>> WSS, then you've already got TLS in the picture, so ALPN and >>>> WSS >>>> seem to both solve the server-side multiplexing problem from >>>> the >>>> original problem statement. What part of the problem statemen= t >>>> does WSS solve that ALPN does not? >>>> >>>> If you're concerned about unencrypted TURN multiplexing with >>>> unencrypted HTTP on port 80, then I can see WS solving a >>>> problem >>>> that ALPN can't solve. >>>> >>>> --Brandon >>>> >>>> On 12/02/2014 03:26 PM, Sergio Garcia Murillo wrote: >>>> >>>> We control the client and the server, and you are asking = me >>>> to wait >>>> until what is not in our control is changed. Obviously, n= ot >>>> working for me >>>> >>>> BTW, I am talking about real life experiences, when WSS >>>> works and TURNS >>>> over 443 doesn't. >>>> >>>> Best regards >>>> Sergio >>>> >>>> On 02/12/2014 20:44, Tirumaleswar Reddy (tireddy) wrote: >>>> >>>> >>>> why will it not work when ALPN is used ? >>>> >>>> -Tiru >>>> >>>> *From:*Sergio Garcia Murillo >>>> [mailto:sergio.garcia.murillo@__gmail.com >>>> ] ? >>>> >>>> *Sent:* Wednesday, December 03, 2014 12:52 AM >>>> *To:* Tirumaleswar Reddy (tireddy) >>>> *Cc:* Jonathan Lennox; [ACME] Victor Pascual Avila; >>>> Simon Perreault; >>>> tram@ietf.org ; >>>> draft-chenxin-behave-turn-__websocket@tools.ietf.org >>>> >>>> *Subject:* RE: [tram] TURN over WebSocket >>>> >>>> >>>> El 02/12/2014 20:04, "Tirumaleswar Reddy (tireddy)" >>>> >>>> >= > >>>> escribi=C3=B3: >>>> > >>>> > From: Simon Perreault [mailto:sperreault@jive.com >>>> >>>> >>> >] >>>> > Sent: Tuesday, December 02, 2014 10:19 PM >>>> > >>>> > To: Tirumaleswar Reddy (tireddy) >>>> > Cc: Jonathan Lennox; Sergio Garcia Murillo; Victor >>>> Pascual Avila; >>>> draft-chenxin-behave-turn-__websocket@tools.ietf.org >>>> >>>> >>> >__; >>>> tram@ietf.org >>>> > >>>> > Subject: Re: [tram] TURN over WebSocket >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar Reddy >>>> (tireddy) >>>> >>>> >= > >>>> wrote: >>>> > >>>> > Transparent proxies like firewalls keep getting >>>> upgraded frequently >>>> to handle new applications, threats etc. If firewall >>>> has >>>> a feature to >>>> block WebRTC traffic then by sending traffic over >>>> WebSocket will not >>>> solve the problem. >>>> > >>>> > >>>> > >>>> > (As a participant...) >>>> > >>>> > >>>> > This has also been discussed before. >>>> TURN-over-WebSockets is not a >>>> way for applications to circumvent policy. >>>> > >>>> > >>>> > >>>> > The problem is there are networks that are set up = so >>>> that "the web" >>>> is open, through a transparent proxy. WebRTC is part = of >>>> "the web". >>>> Making TURN fit the mould of "the web" is is not >>>> circumventing policy, >>>> it's making WebRTC work. You should not need to >>>> update your >>>> proxy/firewall config for WebRTC to just work if "the >>>> web" already >>>> does work. >>>> > >>>> > >>>> > >>>> > [TR] Okay, so looks like the problem can also be >>>> solved by running >>>> TURN over 443 similar to proposals in DPRIVE WG to ru= n >>>> DNS over 443. >>>> > >>>> > >>>> >>>> Good try! Unlucky enough, doesn't work. >>>> >>>> Best regards >>>> Sergio >>>> >>>> >>>> >>>> >>>> _________________________________________________ >>>> tram mailing list >>>> tram@ietf.org >>>> https://www.ietf.org/mailman/__listinfo/tram >>>> >>>> >>>> >>>> >>> >> > -- > Brandon Williams; Senior Principal Software Engineer > Emerging Products Engineering; Akamai Technologies Inc. > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --047d7b417ccf772dad050955b643 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As a developer, I would much prefer to do this kind of thi= ng over WSS. Websockets allow the application to control processing on the = packets, rather than relying on a framework to do. As far as I can tell, no= thing really supports ALPN at all. If I wanted to write a proxy in Java tha= t only listened on 80 and 443, to do ALPN, Jersey (or whichever framework I= choose) would need to support ALPN and allow me to register different hand= lers for different types. That would be fine if it was a network library (l= ike Netty), but it's an HTTP framework that would be dealing with other= TCP protocols. On top of that, the websocket solution can be supported qui= ckly and easily with existing frameworks and infrastructure - no waiting fo= r someone else to decide to finally support ALPN.

David<= /div>

On Wed= , Dec 3, 2014 at 8:57 AM, Brandon Williams <brandon.williams@aka= mai.com> wrote:
The only th= ing that makes sense to me to explain the problem you describe is that the = proxy is splitting the TLS session so that it can view the data flow. If su= ch a proxy only supports HTTP (and by extension Websockets) for the data fl= ow, then it would make sense that TURNS over 443 does not work. The piece I= 'm missing though is how the proxy could be splitting the TLS session i= n this way without you knowing, unless the client is accepting a certificat= e signed by someone else's CA. Nevertheless, if TLS splitting is what&#= 39;s happening and the proxy is rejecting data flows that do not look like = HTTP, I can understand how WSS might resolve the problem under conditions w= here TURNS with ALPN might not.

That having been said, if I'm correct about the source of the problem, = I'm conflicted about taking up work intended to make a proxy like this = function for WebRTC. If TLS is being used solely for the purpose of firewal= l traversal, then it's OK to split the session. But what if that isn= 9;t the case? There are significant security implications associated with h= elping such a system to function transparently. I personally would rather s= ee my WebRTC sessions fail than accept decryption by an unknown MITM.

Of course, it might be the case that something else is happening here and t= here is no decryption happening on the proxy, which returns me to the point= that Andrew made ... I think we need to better understand the nature of th= e problem in order to decide whether it makes sense to adopt the draft and = add a milestone.

--Brandon


On 12/03/2014 09:39 AM, Sergio Garcia Murillo wrote:
Maybe then is me the one I am missing something, can you explain how is
ALPN meant to solve the problem if TURNS over 443 is blocked by the proxy?<= br>
Best regards
Sergio
On 03/12/2014 15:21, Brandon Williams wrote:
What am I missing? Why would ALPN require changing the wifi network? I
can accept that it may be necessary, but in the absence of someone
explaining why the wifi network needs to care, it really doesn't make sense to me.

--Brandon

On 12/03/2014 04:24 AM, Oleg Moskalenko wrote:
That is a good point. A solution must not require changing every wifi
network in the world. A "pure" ALPN=C2=A0 solution is a great way= to kill the
whole WebRTC idea.

On Wed, Dec 3, 2014 at 1:19 AM, Sergio Garcia Murillo
<se= rgio.garcia.murillo@gmail.com
<mailto:sergio.garcia.murillo@gmail.com>> wrote:

=C2=A0 =C2=A0 =C2=A0Am I supposed to change every hotel, cafe or airport wi= fi in the
=C2=A0 =C2=A0 =C2=A0world in order to make it work? That's what I mean.=

=C2=A0 =C2=A0 =C2=A0Don't take me wrong, ALPN seems a good solution, as= good as ipv6 is
=C2=A0 =C2=A0 =C2=A0for removing NAT, but it is something out my control to= have it
=C2=A0 =C2=A0 =C2=A0deployed worldwide, so I can't rely on it as a solu= tion. From a
=C2=A0 =C2=A0 =C2=A0webrtc point of view we only control the client and the= turn server,
=C2=A0 =C2=A0 =C2=A0everything in between should be considered hostile.

=C2=A0 =C2=A0 =C2=A0Best regards
=C2=A0 =C2=A0 =C2=A0Sergio


=C2=A0 =C2=A0 =C2=A0On 03/12/2014 1:58, Brandon Williams wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0What part of ALPN is not under your contr= ol? If you're doing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0WSS, then you've already got TLS in t= he picture, so ALPN and WSS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0seem to both solve the server-side multip= lexing problem from the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0original problem statement. What part of = the problem statement
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0does WSS solve that ALPN does not?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If you're concerned about unencrypted= TURN multiplexing with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0unencrypted HTTP on port 80, then I can s= ee WS solving a problem
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that ALPN can't solve.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--Brandon

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 12/02/2014 03:26 PM, Sergio Garcia Mur= illo wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0We control the client and t= he server, and you are asking me
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to wait
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0until what is not in our co= ntrol is changed. Obviously, not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0working for me

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BTW, I am talking about rea= l life experiences, when WSS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0works and TURNS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0over 443 doesn't.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Best regards
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sergio

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 02/12/2014 20:44, Tiruma= leswar Reddy (tireddy) wrote:


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0why will it n= ot work when ALPN is used ?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-Tiru

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*From:*Sergio= Garcia Murillo
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[mailto:sergio.garcia.murill= o@__gmail.com=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:sergio.g= arcia.murillo@gmail.com>] ?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*Sent:* Wedne= sday, December 03, 2014 12:52 AM
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*To:* Tirumal= eswar Reddy (tireddy)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*Cc:* Jonatha= n Lennox; [ACME] Victor Pascual Avila;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Simon Perreau= lt;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tram@ietf.org <mailto:tram@ietf.org>;
draft-chenxin-behave-turn-__websocket@tools.ietf.org<= /a>
<mailto:draft-chenxin-behave-turn-websocket@tools.ie= tf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*Subject:* RE= : [tram] TURN over WebSocket


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0El 02/12/2014= 20:04, "Tirumaleswar Reddy (tireddy)"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<tireddy@cisco.com <m= ailto:tireddy@cisco.= com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:tireddy@cisco.com = <mailto:tireddy@c= isco.com>>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0escribi=C3=B3= :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > From: S= imon Perreault [mailto:sperreault@jive.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:sperreault@jive.com<= /a>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:sperreault@jive.com<= /a>
<mailto:sperrea= ult@jive.com>>]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Sent: T= uesday, December 02, 2014 10:19 PM
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > To: Tir= umaleswar Reddy (tireddy)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Cc: Jon= athan Lennox; Sergio Garcia Murillo; Victor
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pascual Avila= ;
draft-chenxin-behave-turn-__websocket@tools.ietf.org<= /a>
<mailto:draft-chenxin-behave-turn-websocket@tools.ie= tf.org>
<mailto:draft-chenxin-behave-__turn-websocket@tool= s.ietf.org
<mailto:draft-chenxin-behave-turn-websocket@tools.ie= tf.org>>__;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tram@ietf.org <mailto:tram@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:tram@ietf.org <mail= to:tram@ietf.org>= >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Subject= : Re: [tram] TURN over WebSocket
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > On Tue,= Dec 2, 2014 at 9:34 AM, Tirumaleswar Reddy
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(tireddy)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<tireddy@cisco.com <m= ailto:tireddy@cisco.= com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:tireddy@cisco.com = <mailto:tireddy@c= isco.com>>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Transpa= rent proxies like firewalls keep getting
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0upgraded freq= uently
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to handle new= applications, threats etc. If firewall has
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a feature to<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0block WebRTC = traffic then by sending traffic over
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0WebSocket wil= l not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0solve the pro= blem.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > (As a p= articipant...)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > This ha= s also been discussed before.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TURN-over-Web= Sockets is not a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0way for appli= cations to circumvent policy.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > The pro= blem is there are networks that are set up so
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that "th= e web"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is open, thro= ugh a transparent proxy. WebRTC is part of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"the web= ".
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Making TURN f= it the mould of "the web" is is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0circumventing= policy,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0it's maki= ng WebRTC work. You should not need to
update your
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proxy/firewal= l config for WebRTC to just work if "the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0web" alr= eady
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0does work. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > [TR] Ok= ay, so looks like the problem can also be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0solved by run= ning
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TURN over 443= similar to proposals in DPRIVE WG to run
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DNS over 443.=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Good try! Unl= ucky enough, doesn't work.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Best regards<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sergio




=C2=A0 =C2=A0 =C2=A0________________________________________________= _
=C2=A0 =C2=A0 =C2=A0tram mailing list
=C2=A0 =C2=A0 =C2=A0tram= @ietf.org <mailto:tram@ietf.org>
=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/__listinfo/tram=
=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/listinfo/tram= >





--
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--047d7b417ccf772dad050955b643-- From nobody Wed Dec 3 12:53:31 2014 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 9939C1AC3ED for ; Wed, 3 Dec 2014 12:53:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 Bi7O_iYVcwHz for ; Wed, 3 Dec 2014 12:53:26 -0800 (PST) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 583A11AC3E3 for ; Wed, 3 Dec 2014 12:53:19 -0800 (PST) Received: by mail-oi0-f49.google.com with SMTP id i138so11407313oig.22 for ; Wed, 03 Dec 2014 12:53:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ARNa+Semi9Ase85fGhYH/dppdnLqem7YS5Uu730VXqA=; b=VXN6E9K8gXBWo1Q7+5HNuEmyeKjSRLZC1qXkAhtxAA3m1eRkQsFhT0Xzq4YL/+67Yt +g4v2S3vLgL7QU1mUlwjtPD3B7vEGVXhglYQvT4LCMSAOv0nmTSqKAJtxb/GzoTNus25 iLqDdIhGuJQDzGKYA5l45hvUrQebOoy1KZKIMY+y7RI2hSuCfFY1E6K1VxPJH7Yg6jny 5sjvybm9TCwWNnyfzKmaMPOzv5FtX7qR+/YyI3HOjCoUBgZ4ca2dcYS9NQ2sWn/8PKtP rx/mZ7OTTsmpbnW/DD+1XRQc6Gp6XebIQeVvWi/WjPxn9Z9XDD3eaVWkwBp/nrMDVD1y QMaA== MIME-Version: 1.0 X-Received: by 10.182.20.76 with SMTP id l12mr4435187obe.63.1417639998697; Wed, 03 Dec 2014 12:53:18 -0800 (PST) Received: by 10.76.152.105 with HTTP; Wed, 3 Dec 2014 12:53:18 -0800 (PST) Date: Wed, 3 Dec 2014 13:53:18 -0700 Message-ID: From: toadzky To: "tram@ietf.org" Content-Type: multipart/alternative; boundary=001a113336b88ab8b305095608e1 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/UW3ASLqqP4LLrBMZRts8IewQfdg Subject: [tram] Review of draft-chenxin-behave-turn-websocket-01 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, 03 Dec 2014 20:53:28 -0000 --001a113336b88ab8b305095608e1 Content-Type: text/plain; charset=UTF-8 Major =========== None Minor =========== None Nits =========== - Spelling error in Section 1: "...this solution could also be easyly implemented..." Solution: s/easyly/easily/ - In the Informative References, 'I-D.petithuguenin-behave-turn-uris' has been published as RFC 7065. The references throughout the draft should probably be updated to reflect this. - Spelling error in Section 7: s/analisys/analysis/ --001a113336b88ab8b305095608e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Major
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
None

Minor
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
None

Nits
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
- Spelling error in Section 1:=C2=A0&= quot;...this solution could also be easyly implemented..."
S= olution: s/easyly/easily/

- In the Informative Ref= erences, 'I-D.petithuguenin-behave-turn-uris' has been published as= RFC 7065. The references throughout the draft should probably be updated t= o reflect this.

- Spelling error in Section 7: s/<= span style=3D"color:rgb(0,0,0);font-size:1em">analisys/analysis/


--001a113336b88ab8b305095608e1-- From nobody Thu Dec 4 01:40:06 2014 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 C1E0A1A0120 for ; Thu, 4 Dec 2014 01:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 0brVt6C_V_Qz for ; Thu, 4 Dec 2014 01:40:00 -0800 (PST) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 408DA1A0113 for ; Thu, 4 Dec 2014 01:40:00 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id a1so22065831wgh.25 for ; Thu, 04 Dec 2014 01:39:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=GH+5hdTywM3Nn0dKXw+Cs7RWdieUnmKg5uDLmlTmqrY=; b=dyiDzCPHRLha/8NEeLgQHn2oi7WEzrutCaBahlYOYL/GujwXhxTX2NgXWKzC3kjgUR RbD2LgzTGwZeE6VIVObmoEyV71vSi3kr3KlVLCpwzO0I33Sxu8WQoHOsVeZ0h4wzKgiW RpGcI/uefQpC6PDVbhh2U2eGqhIuGVTe45oQXkBWbj1WdZKmwmgb8Ka/cJPzhXop2AMQ VF3amoQkFlRUU9F6WyguVOqPdDq5+lmZRJ9XWDfx/HO+t/SZf/gKaO2KmvheNUMKt0LU DU7uyudQb2JulH/zDWyQH/9yGBPY4/UQg9Ib7FsDqkrq6PBctYifqeRv7vQatk/y1FQl QYfA== X-Received: by 10.194.3.45 with SMTP id 13mr13766351wjz.47.1417685999025; Thu, 04 Dec 2014 01:39:59 -0800 (PST) Received: from [192.168.1.37] (136.Red-81-39-109.dynamicIP.rima-tde.net. [81.39.109.136]) by mx.google.com with ESMTPSA id wb9sm26333249wic.20.2014.12.04.01.39.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Dec 2014 01:39:58 -0800 (PST) Message-ID: <54802BF1.6020504@gmail.com> Date: Thu, 04 Dec 2014 10:40:01 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "tram@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/k8mPGjUwnHr7Sif7B2zusSBTUwA Subject: [tram] TURN over websockets (recap) 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, 04 Dec 2014 09:40:04 -0000 Hi guys, Trying to move forward on this topic. The concerns so far with this draft have been around if it provides better connectivity than TURN over TLS on port 443 and/or if ALPN could provide better support in that case. On the other side, there has been other voices stating their willingless to use it, and even preferring it to the other counter parts (TURN over TCP/TLS) because they were easiest to implement on web environments. In my opinion, having alternative options for TURN is a good thing, as provides more choices according to each one own scenarios, and even if it is proven that TURN over WS provides sames connectivity levels that TURN over TLS on port 443 that should not be a reason for blocking the draft. (Note that that doesn't mean that it should be automatically endorsed by webrtc, in which this aspect should be taken into consideration). What is the other people opinion? Is there any other kind of concern (security for example) regarding this draft that should be taken into consideration? Best regards Sergio From nobody Fri Dec 5 09:28:34 2014 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 548851AD47A for ; Fri, 5 Dec 2014 09:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BctS1YowFV9Y for ; Fri, 5 Dec 2014 09:28:30 -0800 (PST) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 98DA21AD477 for ; Fri, 5 Dec 2014 09:28:30 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id BBB8B1EB843B; Fri, 5 Dec 2014 18:28:29 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.125]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Fri, 5 Dec 2014 18:28:29 +0100 From: "Hutton, Andrew" To: Sergio Garcia Murillo , "tram@ietf.org" Thread-Topic: [tram] TURN over websockets (recap) Thread-Index: AQHQD6ZMdzoA/E5gPk2XH/PgruWtjJyBQSGQ Date: Fri, 5 Dec 2014 17:28:28 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E62549C@MCHP04MSX.global-ad.net> References: <54802BF1.6020504@gmail.com> In-Reply-To: <54802BF1.6020504@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/lJlt1ONwzKKzRhRnEgBpjjGWy4Q Subject: Re: [tram] TURN over websockets (recap) 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: Fri, 05 Dec 2014 17:28:32 -0000 If people have a requirement for TURN over websockets then I can see no rea= son to prevent them creating a draft specifying how this works. However I got the impression that those that stated they wanted this did so= in the context of WebRTC and if that is their motivation then they will ha= ve to persuade the RTCWEB WG that it is needed. Regards Andy > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Sergio Garcia > Murillo > Sent: 04 December 2014 09:40 > To: tram@ietf.org > Subject: [tram] TURN over websockets (recap) >=20 > Hi guys, >=20 > Trying to move forward on this topic. >=20 > The concerns so far with this draft have been around if it provides > better connectivity than TURN over TLS on port 443 and/or if ALPN could > provide better support in that case. On the other side, there has been > other voices stating their willingless to use it, and even preferring > it > to the other counter parts (TURN over TCP/TLS) because they were > easiest > to implement on web environments. >=20 > In my opinion, having alternative options for TURN is a good thing, as > provides more choices according to each one own scenarios, and even if > it is proven that TURN over WS provides sames connectivity levels that > TURN over TLS on port 443 that should not be a reason for blocking the > draft. (Note that that doesn't mean that it should be automatically > endorsed by webrtc, in which this aspect should be taken into > consideration). >=20 > What is the other people opinion? Is there any other kind of concern > (security for example) regarding this draft that should be taken into > consideration? >=20 > Best regards > Sergio >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Fri Dec 5 11:25:23 2014 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 E3E751AD612 for ; Fri, 5 Dec 2014 11:25:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 VyuOji5Hz0cz for ; Fri, 5 Dec 2014 11:25:19 -0800 (PST) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55AF81AD611 for ; Fri, 5 Dec 2014 11:25:19 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id hz20so1185058lab.20 for ; Fri, 05 Dec 2014 11:25:18 -0800 (PST) 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=bqn3OmYuztxHtGYsO0qyPqyTtNEtlvQGvwit0b2Wf/E=; b=HCwbKwbxFWJ1g6s2zfGQqnUkd5sHBxh1n25WSfDfhuiiBw8X8FafYQwhJ4/LyTORb8 eRJ0BcrY7EqQDMNn0jPZYdq/5fMPkr4CFTJbZgWZLytEUH85SXtYkYwyjpPevaDD1rSY jOIflkVqFEvqWB0256PB8ITjtj91dX14kB0wgYJdjwfVH0i8oui5EYDO9x+6fGquHexu YI9aXWDP3FmRS+2HimHThrZJH76yn5V0F7fpMuOzgKl0nIH6u+MT3A9wbaD0nboCzzp9 XSTxoc2EesvKEHJ926+ETglXLSo7vyGW6PxC3+g5a4eJTkenHv0uNdYfRH7J4I/vqnD4 g79w== X-Gm-Message-State: ALoCoQldKY2grq0okqIODWZafTCZR6r35mm36jGTQ7z02WHEenGnXxv6lh+tqHy1Yz3vqKYcJhgI MIME-Version: 1.0 X-Received: by 10.112.56.134 with SMTP id a6mr4437937lbq.25.1417807517905; Fri, 05 Dec 2014 11:25:17 -0800 (PST) Received: by 10.25.84.145 with HTTP; Fri, 5 Dec 2014 11:25:17 -0800 (PST) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E62549C@MCHP04MSX.global-ad.net> References: <54802BF1.6020504@gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF1E62549C@MCHP04MSX.global-ad.net> Date: Fri, 5 Dec 2014 12:25:17 -0700 Message-ID: From: Simon Perreault To: "Hutton, Andrew" Content-Type: multipart/alternative; boundary=001a1133a876770bdf05097d093a Archived-At: http://mailarchive.ietf.org/arch/msg/tram/vQEbH5UflVFsbacYC2tSLCdfu-s Cc: Sergio Garcia Murillo , "tram@ietf.org" Subject: Re: [tram] TURN over websockets (recap) 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: Fri, 05 Dec 2014 19:25:21 -0000 --001a1133a876770bdf05097d093a Content-Type: text/plain; charset=UTF-8 On Fri, Dec 5, 2014 at 10:28 AM, Hutton, Andrew wrote: > If people have a requirement for TURN over websockets then I can see no > reason to prevent them creating a draft specifying how this works. > > However I got the impression that those that stated they wanted this did > so in the context of WebRTC and if that is their motivation then they will > have to persuade the RTCWEB WG that it is needed. > Well, there are two distinct issues here: 1. Whether or not to specify TURN-over-WebSockets in a working group. 2. Whether or not to add TURN-over-WebSockets to the set of WebRTC requirements. 1 is up to TRAM. 2 is up to RTCWEB. I'll also add that 1 and 2 are orthogonal. So in the context of this discussion, please focus on 1 and leave 2 to RTCWEB. Thanks, Simon --001a1133a876770bdf05097d093a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, Dec 5, 2014 at 10:28 AM, Hutton, Andrew <andrew.hutton@unify= .com> wrote:
If people have a requirement for= TURN over websockets then I can see no reason to prevent them creating a d= raft specifying how this works.

However I got the impression that those that stated they wanted this did so= in the context of WebRTC and if that is their motivation then they will ha= ve to persuade the RTCWEB WG that it is needed.
Well, there are two distinct issues here:
=
1. Whether or not to specify TURN-over= -WebSockets in a working group.
2. Whether = or not to add TURN-over-WebSockets to the set of WebRTC requirements.
=

1 is up to = TRAM. 2 is up to RTCWEB.

I'll also add that 1 and 2 are orthogonal. So in the= context of this discussion, please focus on 1 and leave 2 to RTCWEB.
=

Thanks,
Simon
--001a1133a876770bdf05097d093a-- From nobody Fri Dec 5 11:38:39 2014 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 63C021AD64A for ; Fri, 5 Dec 2014 11:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 QLPl64YOsQz3 for ; Fri, 5 Dec 2014 11:38:35 -0800 (PST) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 786161AD649 for ; Fri, 5 Dec 2014 11:38:35 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id l18so1718801wgh.26 for ; Fri, 05 Dec 2014 11:38:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=TSMjmfLIAL7qsZbKAaVGp4XL42wPzn8SS0DKqCRwDoo=; b=BMowkjefCFoPdm9+BtQNL6XFAmZfUdGwmoX6JON89wVf04E3vhiLyT3LEQUIJAvi/w padrlfBrOVw4V6Xp+vAhi/UKEQdDzwMq/T9dKXYEV+tq5f/7zb0SgKtuRKEAR5uwFFzr Duru/Ff0rRL2K2xwxDR8sub/JP/cB53ROLgJ6rdvnku0WZ9lwkShmsqeAijUHuB84ZIc znRoh6dM+Inj4D4slhUDiYvWwZ3wwG8YAudvoQ1ieKCk5u7Pvw6p6iQSaAfnyvEzzLbN GpUjeHRnljEiirJRy+FFTI/T1TsOXS7Ae76dr+qB88UmsCPzxilDhd1Il8nWjkYywF5y 6YlQ== X-Received: by 10.180.221.201 with SMTP id qg9mr6558382wic.29.1417808314298; Fri, 05 Dec 2014 11:38:34 -0800 (PST) Received: from [192.168.0.193] ([95.61.111.78]) by mx.google.com with ESMTPSA id ce1sm46059458wjc.2.2014.12.05.11.38.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Dec 2014 11:38:33 -0800 (PST) Message-ID: <548209BD.8040704@gmail.com> Date: Fri, 05 Dec 2014 20:38:37 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Hutton, Andrew" , "tram@ietf.org" References: <54802BF1.6020504@gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF1E62549C@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E62549C@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Yc3-IVoep_a9ygelmO4TPUBea78 Subject: Re: [tram] TURN over websockets (recap) 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: Fri, 05 Dec 2014 19:38:37 -0000 Completely agree, one battle at a time.. :) On the mean time I will try to get more info about the scenarios we have outlined here. Best regards Sergio On 05/12/2014 18:28, Hutton, Andrew wrote: > If people have a requirement for TURN over websockets then I can see no reason to prevent them creating a draft specifying how this works. > > However I got the impression that those that stated they wanted this did so in the context of WebRTC and if that is their motivation then they will have to persuade the RTCWEB WG that it is needed. > > Regards > Andy > > > > >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Sergio Garcia >> Murillo >> Sent: 04 December 2014 09:40 >> To: tram@ietf.org >> Subject: [tram] TURN over websockets (recap) >> >> Hi guys, >> >> Trying to move forward on this topic. >> >> The concerns so far with this draft have been around if it provides >> better connectivity than TURN over TLS on port 443 and/or if ALPN could >> provide better support in that case. On the other side, there has been >> other voices stating their willingless to use it, and even preferring >> it >> to the other counter parts (TURN over TCP/TLS) because they were >> easiest >> to implement on web environments. >> >> In my opinion, having alternative options for TURN is a good thing, as >> provides more choices according to each one own scenarios, and even if >> it is proven that TURN over WS provides sames connectivity levels that >> TURN over TLS on port 443 that should not be a reason for blocking the >> draft. (Note that that doesn't mean that it should be automatically >> endorsed by webrtc, in which this aspect should be taken into >> consideration). >> >> What is the other people opinion? Is there any other kind of concern >> (security for example) regarding this draft that should be taken into >> consideration? >> >> Best regards >> Sergio >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram From nobody Mon Dec 8 09:33:58 2014 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 700AB1A1AAE; Mon, 8 Dec 2014 09:33:56 -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] 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 9kDZu1Sz0M4r; Mon, 8 Dec 2014 09:33:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5141A1B76; Mon, 8 Dec 2014 09:33:52 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141208173352.21096.99911.idtracker@ietfa.amsl.com> Date: Mon, 08 Dec 2014 09:33:52 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/VcxIVWv_UiYxEmvFQF1RXJgRYbQ Cc: tram mailing list , tram chair , RFC Editor Subject: [tram] Document Action: 'Application Layer Protocol Negotiation (ALPN) Labels for Session Traversal Utilities for NAT (STUN) Usages' to Informational RFC (draft-ietf-tram-alpn-08.txt) 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: Mon, 08 Dec 2014 17:33:56 -0000 The IESG has approved the following document: - 'Application Layer Protocol Negotiation (ALPN) Labels for Session Traversal Utilities for NAT (STUN) Usages' (draft-ietf-tram-alpn-08.txt) as Informational RFC This document is the product of the TURN Revised and Modernized Working Group. The IESG contact persons are Spencer Dawkins and Martin Stiemerling. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-tram-alpn/ Technical Summary This document defines two APLN labels for two usages of STUN over (D)TLS: NAT discovery and TURN. Working Group Summary The draft was initially thought to be a "slam dunk" but the working group ended up arguing over the granularity of ALPN labels: did we need just one label for all of STUN or one label for each STUN usage? Once the WG selected the second option, it argued over the necessity of a generic "STUN" label for future and unknown usages, rejecting that idea in the end. Many TRAM regulars participated in the discussion. Martin Thompson in particular provided much (D)TLS and ALPN expertise. The consensus is solid and represents the whole working group. A discussion during Last Call resulted in the deletion of some non-normative text describing possible use cases. Document Quality No specific implementation was mentioned on the list, but this shepherd expects that WebRTC stacks and TURN servers will implement this draft quickly. Personnel The document shepherd is Simon Perreault The responsible Area Director is Spencer Dawkins The IANA designated expert reviewer for Application-Layer Protocol Negotiation (ALPN) Protocol IDs is Joe Salowey From nobody Wed Dec 10 04:05:30 2014 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 30F3D1A1F02 for ; Wed, 3 Dec 2014 12:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 T_FZSg4BHgBU for ; Wed, 3 Dec 2014 12:36:56 -0800 (PST) Received: from smtpcmd01217.aruba.it (smtpcmd01217.aruba.it [62.149.158.217]) by ietfa.amsl.com (Postfix) with ESMTP id AD1071A1B94 for ; Wed, 3 Dec 2014 12:36:55 -0800 (PST) Received: from lminiero ([95.235.34.214]) by smtpcmd01.ad.aruba.it with bizsmtp id P8ce1p00H4dCTyP018ceoi; Wed, 03 Dec 2014 21:36:53 +0100 Date: Wed, 3 Dec 2014 21:36:37 +0100 From: Lorenzo Miniero To: toadzky Message-ID: <20141203213637.2fc801ea@lminiero> In-Reply-To: References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B8E7@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B9B5@xmb-rcd-x10.cisco.com> <547E2069.4050307@gmail.com> <547E6022.5030101@akamai.com> <547ED5B3.7070102@gmail.com> <547F1C55.4040208@akamai.com> <547F208E.6000000@gmail.com> <547F32E3.1000708@akamai.com> Organization: Meetecho X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tram/xQifVgeTa7OH9KZgXPMvn7HU-VE X-Mailman-Approved-At: Wed, 10 Dec 2014 04:05:29 -0800 Cc: Jonathan Lennox , Oleg Moskalenko , "tram@ietf.org" , Brandon Williams , "\[ACME\] Victor Pascual Avila" , Sergio Garcia Murillo , "Tirumaleswar Reddy \(tireddy\)" , "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Simon Perreault Subject: Re: [tram] TURN over WebSocket 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, 03 Dec 2014 20:36:59 -0000 Not to mention the fact that even with plain WS instead of WSS you could transport TURNS and keep it secure. Lorenzo =20 On Wed, 3 Dec 2014 13:30:21 -0700 toadzky wrote: > As a developer, I would much prefer to do this kind of thing over WSS. > Websockets allow the application to control processing on the packets, > rather than relying on a framework to do. As far as I can tell, > nothing really supports ALPN at all. If I wanted to write a proxy in > Java that only listened on 80 and 443, to do ALPN, Jersey (or > whichever framework I choose) would need to support ALPN and allow me > to register different handlers for different types. That would be > fine if it was a network library (like Netty), but it's an HTTP > framework that would be dealing with other TCP protocols. On top of > that, the websocket solution can be supported quickly and easily with > existing frameworks and infrastructure - no waiting for someone else > to decide to finally support ALPN. >=20 > David >=20 > On Wed, Dec 3, 2014 at 8:57 AM, Brandon Williams < > brandon.williams@akamai.com> wrote: >=20 > > The only thing that makes sense to me to explain the problem you > > describe is that the proxy is splitting the TLS session so that it > > can view the data flow. If such a proxy only supports HTTP (and by > > extension Websockets) for the data flow, then it would make sense > > that TURNS over 443 does not work. The piece I'm missing though is > > how the proxy could be splitting the TLS session in this way > > without you knowing, unless the client is accepting a certificate > > signed by someone else's CA. Nevertheless, if TLS splitting is > > what's happening and the proxy is rejecting data flows that do not > > look like HTTP, I can understand how WSS might resolve the problem > > under conditions where TURNS with ALPN might not. > > > > That having been said, if I'm correct about the source of the > > problem, I'm conflicted about taking up work intended to make a > > proxy like this function for WebRTC. If TLS is being used solely > > for the purpose of firewall traversal, then it's OK to split the > > session. But what if that isn't the case? There are significant > > security implications associated with helping such a system to > > function transparently. I personally would rather see my WebRTC > > sessions fail than accept decryption by an unknown MITM. > > > > Of course, it might be the case that something else is happening > > here and there is no decryption happening on the proxy, which > > returns me to the point that Andrew made ... I think we need to > > better understand the nature of the problem in order to decide > > whether it makes sense to adopt the draft and add a milestone. > > > > --Brandon > > > > > > On 12/03/2014 09:39 AM, Sergio Garcia Murillo wrote: > > > >> Maybe then is me the one I am missing something, can you explain > >> how is ALPN meant to solve the problem if TURNS over 443 is > >> blocked by the proxy? > >> > >> Best regards > >> Sergio > >> On 03/12/2014 15:21, Brandon Williams wrote: > >> > >>> What am I missing? Why would ALPN require changing the wifi > >>> network? I can accept that it may be necessary, but in the > >>> absence of someone explaining why the wifi network needs to care, > >>> it really doesn't make sense to me. > >>> > >>> --Brandon > >>> > >>> On 12/03/2014 04:24 AM, Oleg Moskalenko wrote: > >>> > >>>> That is a good point. A solution must not require changing every > >>>> wifi network in the world. A "pure" ALPN solution is a great > >>>> way to kill the whole WebRTC idea. > >>>> > >>>> On Wed, Dec 3, 2014 at 1:19 AM, Sergio Garcia Murillo > >>>> >>>> > wrote: > >>>> > >>>> Am I supposed to change every hotel, cafe or airport wifi > >>>> in the world in order to make it work? That's what I mean. > >>>> > >>>> Don't take me wrong, ALPN seems a good solution, as good as > >>>> ipv6 is for removing NAT, but it is something out my control to > >>>> have it deployed worldwide, so I can't rely on it as a solution. > >>>> From a webrtc point of view we only control the client and the > >>>> turn server, > >>>> everything in between should be considered hostile. > >>>> > >>>> Best regards > >>>> Sergio > >>>> > >>>> > >>>> On 03/12/2014 1:58, Brandon Williams wrote: > >>>> > >>>> What part of ALPN is not under your control? If you're > >>>> doing WSS, then you've already got TLS in the picture, so ALPN > >>>> and WSS > >>>> seem to both solve the server-side multiplexing problem > >>>> from the > >>>> original problem statement. What part of the problem > >>>> statement does WSS solve that ALPN does not? > >>>> > >>>> If you're concerned about unencrypted TURN multiplexing > >>>> with unencrypted HTTP on port 80, then I can see WS solving a > >>>> problem > >>>> that ALPN can't solve. > >>>> > >>>> --Brandon > >>>> > >>>> On 12/02/2014 03:26 PM, Sergio Garcia Murillo wrote: > >>>> > >>>> We control the client and the server, and you are > >>>> asking me to wait > >>>> until what is not in our control is changed. > >>>> Obviously, not working for me > >>>> > >>>> BTW, I am talking about real life experiences, when > >>>> WSS works and TURNS > >>>> over 443 doesn't. > >>>> > >>>> Best regards > >>>> Sergio > >>>> > >>>> On 02/12/2014 20:44, Tirumaleswar Reddy (tireddy) > >>>> wrote: > >>>> > >>>> > >>>> why will it not work when ALPN is used ? > >>>> > >>>> -Tiru > >>>> > >>>> *From:*Sergio Garcia Murillo > >>>> [mailto:sergio.garcia.murillo@__gmail.com > >>>> ] ? > >>>> > >>>> *Sent:* Wednesday, December 03, 2014 12:52 AM > >>>> *To:* Tirumaleswar Reddy (tireddy) > >>>> *Cc:* Jonathan Lennox; [ACME] Victor Pascual > >>>> Avila; Simon Perreault; > >>>> tram@ietf.org ; > >>>> draft-chenxin-behave-turn-__websocket@tools.ietf.org > >>>> > >>>> *Subject:* RE: [tram] TURN over WebSocket > >>>> > >>>> > >>>> El 02/12/2014 20:04, "Tirumaleswar Reddy > >>>> (tireddy)" > >>>> >>>> >> escribi=C3=B3: > >>>> > > >>>> > From: Simon Perreault > >>>> > [mailto:sperreault@jive.com > >>>> > >>>> >>>> >] > >>>> > Sent: Tuesday, December 02, 2014 10:19 PM > >>>> > > >>>> > To: Tirumaleswar Reddy (tireddy) > >>>> > Cc: Jonathan Lennox; Sergio Garcia Murillo; > >>>> > Victor > >>>> Pascual Avila; > >>>> draft-chenxin-behave-turn-__websocket@tools.ietf.org > >>>> > >>>> >>>> >__; > >>>> tram@ietf.org > >>>> > > >>>> > Subject: Re: [tram] TURN over WebSocket > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar > >>>> > Reddy > >>>> (tireddy) > >>>> > >>>> >>>> >> wrote: > >>>> > > >>>> > Transparent proxies like firewalls keep > >>>> > getting > >>>> upgraded frequently > >>>> to handle new applications, threats etc. If > >>>> firewall has > >>>> a feature to > >>>> block WebRTC traffic then by sending traffic > >>>> over WebSocket will not > >>>> solve the problem. > >>>> > > >>>> > > >>>> > > >>>> > (As a participant...) > >>>> > > >>>> > > >>>> > This has also been discussed before. > >>>> TURN-over-WebSockets is not a > >>>> way for applications to circumvent policy. > >>>> > > >>>> > > >>>> > > >>>> > The problem is there are networks that are > >>>> > set up so > >>>> that "the web" > >>>> is open, through a transparent proxy. WebRTC is > >>>> part of "the web". > >>>> Making TURN fit the mould of "the web" is is not > >>>> circumventing policy, > >>>> it's making WebRTC work. You should not need to > >>>> update your > >>>> proxy/firewall config for WebRTC to just work > >>>> if "the web" already > >>>> does work. > >>>> > > >>>> > > >>>> > > >>>> > [TR] Okay, so looks like the problem can > >>>> > also be > >>>> solved by running > >>>> TURN over 443 similar to proposals in DPRIVE WG > >>>> to run DNS over 443. > >>>> > > >>>> > > >>>> > >>>> Good try! Unlucky enough, doesn't work. > >>>> > >>>> Best regards > >>>> Sergio > >>>> > >>>> > >>>> > >>>> > >>>> _________________________________________________ > >>>> tram mailing list > >>>> tram@ietf.org > >>>> https://www.ietf.org/mailman/__listinfo/tram > >>>> > >>>> > >>>> > >>>> > >>> > >> > > -- > > Brandon Williams; Senior Principal Software Engineer > > Emerging Products Engineering; Akamai Technologies Inc. > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram > > From nobody Fri Dec 12 06:40:10 2014 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 E1A6A1A8A62 for ; Thu, 11 Dec 2014 11:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.012 X-Spam-Level: X-Spam-Status: No, score=0.012 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 54T29vDIsaAs for ; Thu, 11 Dec 2014 11:47:03 -0800 (PST) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A42EF1A8890 for ; Thu, 11 Dec 2014 11:47:02 -0800 (PST) Received: by mail-vc0-f181.google.com with SMTP id le20so2828205vcb.26 for ; Thu, 11 Dec 2014 11:47:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8zsTU2B+3bdHv8tO78s9davlfyrnB90otIBrPOIBqj8=; b=S4GlXnEGChpSNFvTbXU7uzRjGd6v3+vpeYtHnlJ/x46b/0wgQCorquZ4ic03yZrroG hunn+8ahvyKNHAftK1vCuClG4RPyOuZWHeINmoXclscqFWo0XVPC4Dcgx69kz/hZDtnl Z1k8EJPTbkUsC1a7xXBsG7Wm7hnvnpC/LHgM62L0Yq9PQPM9hYE54NGNIWmIw2UDM7+I zRQY4mF/6/ft6Sdf+FfrDlRvN1riGurpfWSGUPEtkvNS6X59tO84u0QTi6JzDLUj9lsJ xmnZz3nWBeQ8AneCQ4u8Lc6Vklw+RROpaHjHlYVD1+fvyYSYMyhWf3vEoyNNVSQ7s3kY VSxg== 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:from:date :message-id:subject:to:cc:content-type; bh=8zsTU2B+3bdHv8tO78s9davlfyrnB90otIBrPOIBqj8=; b=PT0+de1M3C2tonuLB0Js8bGyzuvqwDUbLnAM133c+gmpJgblEUudfva//QksbmSnAq BNN1E8QGyhmqu0Z/SBHuLI5fFId8pmMBLnz+2fJPcq1JNuTDsjjeu9bAHPGKb4m/f42f ktEtUp+g0/PCCV7DIRUhhM5UmxScRbynR62AHxCkC5FnuzGfkh4zbr/z2z/AYoTSgkBK F/ggM//oN+jLzIgXJki3eXjOLhD2YUPYjyn+EDrxn4A80eRea9dkIVC23Jl7/HxSVRzv SlrTNh/eXwocPymzf9PbiqHJQNHkTQpfc+SRi7kQTuKdPzPGLL/W8fubF1H8liT2fcxv krJA== X-Gm-Message-State: ALoCoQlwMfgs3hZbuDGtaNRJak5ffKv/Mb7wONi+M3ZLRsfxYAzed5Kzox1/OqIi01Pkk8VerVCF X-Received: by 10.52.170.211 with SMTP id ao19mr7091698vdc.58.1418327221626; Thu, 11 Dec 2014 11:47:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.10.229 with HTTP; Thu, 11 Dec 2014 11:46:41 -0800 (PST) In-Reply-To: <20141203213637.2fc801ea@lminiero> References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B8E7@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B9B5@xmb-rcd-x10.cisco.com> <547E2069.4050307@gmail.com> <547E6022.5030101@akamai.com> <547ED5B3.7070102@gmail.com> <547F1C55.4040208@akamai.com> <547F208E.6000000@gmail.com> <547F32E3.1000708@akamai.com> <20141203213637.2fc801ea@lminiero> From: Justin Uberti Date: Thu, 11 Dec 2014 11:46:41 -0800 Message-ID: To: Lorenzo Miniero Content-Type: multipart/alternative; boundary=047d7b86f58a38891c0509f60aba Archived-At: http://mailarchive.ietf.org/arch/msg/tram/NRaaZIsq92DkyXY4dZYyd0x2bUU X-Mailman-Approved-At: Fri, 12 Dec 2014 06:40:09 -0800 Cc: toadzky , Jonathan Lennox , Oleg Moskalenko , "tram@ietf.org" , Brandon Williams , Sergio Garcia Murillo , "\[ACME\] Victor Pascual Avila" , "Tirumaleswar Reddy \(tireddy\)" , "draft-chenxin-behave-turn-websocket@tools.ietf.org" , Simon Perreault Subject: Re: [tram] TURN over WebSocket 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 Dec 2014 19:47:06 -0000 --047d7b86f58a38891c0509f60aba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable So I see 3 arguments being made here: 1) WSS allows the app and TURN server to be the same entity. 2) TURN/WSS works where TURN/TLS doesn't, because DPI. 3) TURN/WS works where TURN/TLS doesn't, because DPI. #2 seems very hard to believe; both of these things will try to establish a TLS connection and then run WS or TURN over top. It's not clear to me that DPI will be able to reliably ID TURN packets versus TURN/WS packets when they are encrypted. (Clearly if the DPI is able to intercept the TLS, it's a different story.) #3 implies that HTTPS and WSS doesn't work, so not sure how useful that is. As Brandon says, I agree we need to understand the problem better before deciding whether this has value. On Wed, Dec 3, 2014 at 12:36 PM, Lorenzo Miniero wrote: > Not to mention the fact that even with plain WS instead of WSS you could > transport TURNS and keep it secure. > > Lorenzo > > > > On Wed, 3 Dec 2014 13:30:21 -0700 > toadzky wrote: > > > As a developer, I would much prefer to do this kind of thing over WSS. > > Websockets allow the application to control processing on the packets, > > rather than relying on a framework to do. As far as I can tell, > > nothing really supports ALPN at all. If I wanted to write a proxy in > > Java that only listened on 80 and 443, to do ALPN, Jersey (or > > whichever framework I choose) would need to support ALPN and allow me > > to register different handlers for different types. That would be > > fine if it was a network library (like Netty), but it's an HTTP > > framework that would be dealing with other TCP protocols. On top of > > that, the websocket solution can be supported quickly and easily with > > existing frameworks and infrastructure - no waiting for someone else > > to decide to finally support ALPN. > > > > David > > > > On Wed, Dec 3, 2014 at 8:57 AM, Brandon Williams < > > brandon.williams@akamai.com> wrote: > > > > > The only thing that makes sense to me to explain the problem you > > > describe is that the proxy is splitting the TLS session so that it > > > can view the data flow. If such a proxy only supports HTTP (and by > > > extension Websockets) for the data flow, then it would make sense > > > that TURNS over 443 does not work. The piece I'm missing though is > > > how the proxy could be splitting the TLS session in this way > > > without you knowing, unless the client is accepting a certificate > > > signed by someone else's CA. Nevertheless, if TLS splitting is > > > what's happening and the proxy is rejecting data flows that do not > > > look like HTTP, I can understand how WSS might resolve the problem > > > under conditions where TURNS with ALPN might not. > > > > > > That having been said, if I'm correct about the source of the > > > problem, I'm conflicted about taking up work intended to make a > > > proxy like this function for WebRTC. If TLS is being used solely > > > for the purpose of firewall traversal, then it's OK to split the > > > session. But what if that isn't the case? There are significant > > > security implications associated with helping such a system to > > > function transparently. I personally would rather see my WebRTC > > > sessions fail than accept decryption by an unknown MITM. > > > > > > Of course, it might be the case that something else is happening > > > here and there is no decryption happening on the proxy, which > > > returns me to the point that Andrew made ... I think we need to > > > better understand the nature of the problem in order to decide > > > whether it makes sense to adopt the draft and add a milestone. > > > > > > --Brandon > > > > > > > > > On 12/03/2014 09:39 AM, Sergio Garcia Murillo wrote: > > > > > >> Maybe then is me the one I am missing something, can you explain > > >> how is ALPN meant to solve the problem if TURNS over 443 is > > >> blocked by the proxy? > > >> > > >> Best regards > > >> Sergio > > >> On 03/12/2014 15:21, Brandon Williams wrote: > > >> > > >>> What am I missing? Why would ALPN require changing the wifi > > >>> network? I can accept that it may be necessary, but in the > > >>> absence of someone explaining why the wifi network needs to care, > > >>> it really doesn't make sense to me. > > >>> > > >>> --Brandon > > >>> > > >>> On 12/03/2014 04:24 AM, Oleg Moskalenko wrote: > > >>> > > >>>> That is a good point. A solution must not require changing every > > >>>> wifi network in the world. A "pure" ALPN solution is a great > > >>>> way to kill the whole WebRTC idea. > > >>>> > > >>>> On Wed, Dec 3, 2014 at 1:19 AM, Sergio Garcia Murillo > > >>>> > >>>> > wrote: > > >>>> > > >>>> Am I supposed to change every hotel, cafe or airport wifi > > >>>> in the world in order to make it work? That's what I mean. > > >>>> > > >>>> Don't take me wrong, ALPN seems a good solution, as good as > > >>>> ipv6 is for removing NAT, but it is something out my control to > > >>>> have it deployed worldwide, so I can't rely on it as a solution. > > >>>> From a webrtc point of view we only control the client and the > > >>>> turn server, > > >>>> everything in between should be considered hostile. > > >>>> > > >>>> Best regards > > >>>> Sergio > > >>>> > > >>>> > > >>>> On 03/12/2014 1:58, Brandon Williams wrote: > > >>>> > > >>>> What part of ALPN is not under your control? If you're > > >>>> doing WSS, then you've already got TLS in the picture, so ALPN > > >>>> and WSS > > >>>> seem to both solve the server-side multiplexing problem > > >>>> from the > > >>>> original problem statement. What part of the problem > > >>>> statement does WSS solve that ALPN does not? > > >>>> > > >>>> If you're concerned about unencrypted TURN multiplexing > > >>>> with unencrypted HTTP on port 80, then I can see WS solving a > > >>>> problem > > >>>> that ALPN can't solve. > > >>>> > > >>>> --Brandon > > >>>> > > >>>> On 12/02/2014 03:26 PM, Sergio Garcia Murillo wrote: > > >>>> > > >>>> We control the client and the server, and you are > > >>>> asking me to wait > > >>>> until what is not in our control is changed. > > >>>> Obviously, not working for me > > >>>> > > >>>> BTW, I am talking about real life experiences, when > > >>>> WSS works and TURNS > > >>>> over 443 doesn't. > > >>>> > > >>>> Best regards > > >>>> Sergio > > >>>> > > >>>> On 02/12/2014 20:44, Tirumaleswar Reddy (tireddy) > > >>>> wrote: > > >>>> > > >>>> > > >>>> why will it not work when ALPN is used ? > > >>>> > > >>>> -Tiru > > >>>> > > >>>> *From:*Sergio Garcia Murillo > > >>>> [mailto:sergio.garcia.murillo@__gmail.com > > >>>> ] ? > > >>>> > > >>>> *Sent:* Wednesday, December 03, 2014 12:52 AM > > >>>> *To:* Tirumaleswar Reddy (tireddy) > > >>>> *Cc:* Jonathan Lennox; [ACME] Victor Pascual > > >>>> Avila; Simon Perreault; > > >>>> tram@ietf.org ; > > >>>> draft-chenxin-behave-turn-__websocket@tools.ietf.org > > >>>> > > >>>> *Subject:* RE: [tram] TURN over WebSocket > > >>>> > > >>>> > > >>>> El 02/12/2014 20:04, "Tirumaleswar Reddy > > >>>> (tireddy)" > > >>>> > >>>> >> escribi=C3=B3: > > >>>> > > > >>>> > From: Simon Perreault > > >>>> > [mailto:sperreault@jive.com > > >>>> > > >>>> > >>>> >] > > >>>> > Sent: Tuesday, December 02, 2014 10:19 PM > > >>>> > > > >>>> > To: Tirumaleswar Reddy (tireddy) > > >>>> > Cc: Jonathan Lennox; Sergio Garcia Murillo; > > >>>> > Victor > > >>>> Pascual Avila; > > >>>> draft-chenxin-behave-turn-__websocket@tools.ietf.org > > >>>> > > >>>> > >>>> >__; > > >>>> tram@ietf.org > > >>>> > > > >>>> > Subject: Re: [tram] TURN over WebSocket > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar > > >>>> > Reddy > > >>>> (tireddy) > > >>>> > > >>>> > >>>> >> wrote: > > >>>> > > > >>>> > Transparent proxies like firewalls keep > > >>>> > getting > > >>>> upgraded frequently > > >>>> to handle new applications, threats etc. If > > >>>> firewall has > > >>>> a feature to > > >>>> block WebRTC traffic then by sending traffic > > >>>> over WebSocket will not > > >>>> solve the problem. > > >>>> > > > >>>> > > > >>>> > > > >>>> > (As a participant...) > > >>>> > > > >>>> > > > >>>> > This has also been discussed before. > > >>>> TURN-over-WebSockets is not a > > >>>> way for applications to circumvent policy. > > >>>> > > > >>>> > > > >>>> > > > >>>> > The problem is there are networks that are > > >>>> > set up so > > >>>> that "the web" > > >>>> is open, through a transparent proxy. WebRTC is > > >>>> part of "the web". > > >>>> Making TURN fit the mould of "the web" is is not > > >>>> circumventing policy, > > >>>> it's making WebRTC work. You should not need to > > >>>> update your > > >>>> proxy/firewall config for WebRTC to just work > > >>>> if "the web" already > > >>>> does work. > > >>>> > > > >>>> > > > >>>> > > > >>>> > [TR] Okay, so looks like the problem can > > >>>> > also be > > >>>> solved by running > > >>>> TURN over 443 similar to proposals in DPRIVE WG > > >>>> to run DNS over 443. > > >>>> > > > >>>> > > > >>>> > > >>>> Good try! Unlucky enough, doesn't work. > > >>>> > > >>>> Best regards > > >>>> Sergio > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> _________________________________________________ > > >>>> tram mailing list > > >>>> tram@ietf.org > > >>>> https://www.ietf.org/mailman/__listinfo/tram > > >>>> > > >>>> > > >>>> > > >>>> > > >>> > > >> > > > -- > > > Brandon Williams; Senior Principal Software Engineer > > > Emerging Products Engineering; Akamai Technologies Inc. > > > > > > _______________________________________________ > > > 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 > --047d7b86f58a38891c0509f60aba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So I see 3 arguments being made here:
1) WSS allows th= e app and TURN server to be the same entity.
2) TURN/WSS works wh= ere TURN/TLS doesn't, because DPI.
3) TURN/WS works where TUR= N/TLS doesn't, because DPI.

#2 seems very hard= to believe; both of these things will try to establish a TLS connection an= d then run WS or TURN over top. It's not clear to me that DPI will be a= ble to reliably ID TURN packets versus TURN/WS packets when they are encryp= ted. (Clearly if the DPI is able to intercept the TLS, it's a different= story.)
#3 implies that HTTPS and WSS doesn't work, so not s= ure how useful that is.

As Brandon says, I agree w= e need to understand the problem better before deciding whether this has va= lue.


On Wed, Dec 3, 2014 at 12:36 PM, Lorenzo Miniero <lorenzo= @meetecho.com> wrote:
Not t= o mention the fact that even with plain WS instead of WSS you could
transport TURNS and keep it secure.

Lorenzo



On Wed, 3 Dec 2014 13:30:21 -0700
toadzky <toadzky@gmail.com> = wrote:

> As a developer, I would much prefer to do this kind of thing over WSS.=
> Websockets allow the application to control processing on the packets,=
> rather than relying on a framework to do. As far as I can tell,
> nothing really supports ALPN at all. If I wanted to write a proxy in > Java that only listened on 80 and 443, to do ALPN, Jersey (or
> whichever framework I choose) would need to support ALPN and allow me<= br> > to register different handlers for different types. That would be
> fine if it was a network library (like Netty), but it's an HTTP > framework that would be dealing with other TCP protocols. On top of > that, the websocket solution can be supported quickly and easily with<= br> > existing frameworks and infrastructure - no waiting for someone else > to decide to finally support ALPN.
>
> David
>
> On Wed, Dec 3, 2014 at 8:57 AM, Brandon Williams <
> brandon.williams@akamai= .com> wrote:
>
> > The only thing that makes sense to me to explain the problem you<= br> > > describe is that the proxy is splitting the TLS session so that i= t
> > can view the data flow. If such a proxy only supports HTTP (and b= y
> > extension Websockets) for the data flow, then it would make sense=
> > that TURNS over 443 does not work. The piece I'm missing thou= gh is
> > how the proxy could be splitting the TLS session in this way
> > without you knowing, unless the client is accepting a certificate=
> > signed by someone else's CA. Nevertheless, if TLS splitting i= s
> > what's happening and the proxy is rejecting data flows that d= o not
> > look like HTTP, I can understand how WSS might resolve the proble= m
> > under conditions where TURNS with ALPN might not.
> >
> > That having been said, if I'm correct about the source of the=
> > problem, I'm conflicted about taking up work intended to make= a
> > proxy like this function for WebRTC. If TLS is being used solely<= br> > > for the purpose of firewall traversal, then it's OK to split = the
> > session. But what if that isn't the case? There are significa= nt
> > security implications associated with helping such a system to > > function transparently. I personally would rather see my WebRTC > > sessions fail than accept decryption by an unknown MITM.
> >
> > Of course, it might be the case that something else is happening<= br> > > here and there is no decryption happening on the proxy, which
> > returns me to the point that Andrew made ... I think we need to > > better understand the nature of the problem in order to decide > > whether it makes sense to adopt the draft and add a milestone. > >
> > --Brandon
> >
> >
> > On 12/03/2014 09:39 AM, Sergio Garcia Murillo wrote:
> >
> >> Maybe then is me the one I am missing something, can you expl= ain
> >> how is ALPN meant to solve the problem if TURNS over 443 is > >> blocked by the proxy?
> >>
> >> Best regards
> >> Sergio
> >> On 03/12/2014 15:21, Brandon Williams wrote:
> >>
> >>> What am I missing? Why would ALPN require changing the wi= fi
> >>> network? I can accept that it may be necessary, but in th= e
> >>> absence of someone explaining why the wifi network needs = to care,
> >>> it really doesn't make sense to me.
> >>>
> >>> --Brandon
> >>>
> >>> On 12/03/2014 04:24 AM, Oleg Moskalenko wrote:
> >>>
> >>>> That is a good point. A solution must not require cha= nging every
> >>>> wifi network in the world. A "pure" ALPN=C2= =A0 solution is a great
> >>>> way to kill the whole WebRTC idea.
> >>>>
> >>>> On Wed, Dec 3, 2014 at 1:19 AM, Sergio Garcia Murillo=
> >>>> <sergio.garcia.murillo@gmail.com
> >>>> <mailto:sergio.garcia.murillo@gmail.com>> wrote:
> >>>>
> >>>>=C2=A0 =C2=A0 =C2=A0 Am I supposed to change every hot= el, cafe or airport wifi
> >>>> in the world in order to make it work? That's wha= t I mean.
> >>>>
> >>>>=C2=A0 =C2=A0 =C2=A0 Don't take me wrong, ALPN see= ms a good solution, as good as
> >>>> ipv6 is for removing NAT, but it is something out my = control to
> >>>> have it deployed worldwide, so I can't rely on it= as a solution.
> >>>> From a webrtc point of view we only control the clien= t and the
> >>>> turn server,
> >>>>=C2=A0 =C2=A0 =C2=A0 everything in between should be c= onsidered hostile.
> >>>>
> >>>>=C2=A0 =C2=A0 =C2=A0 Best regards
> >>>>=C2=A0 =C2=A0 =C2=A0 Sergio
> >>>>
> >>>>
> >>>>=C2=A0 =C2=A0 =C2=A0 On 03/12/2014 1:58, Brandon Willi= ams wrote:
> >>>>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 What part of ALPN i= s not under your control? If you're
> >>>> doing WSS, then you've already got TLS in the pic= ture, so ALPN
> >>>> and WSS
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 seem to both solve = the server-side multiplexing problem
> >>>> from the
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 original problem st= atement. What part of the problem
> >>>> statement does WSS solve that ALPN does not?
> >>>>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If you're conce= rned about unencrypted TURN multiplexing
> >>>> with unencrypted HTTP on port 80, then I can see WS s= olving a
> >>>> problem
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that ALPN can't= solve.
> >>>>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --Brandon
> >>>>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On 12/02/2014 03:26= PM, Sergio Garcia Murillo wrote:
> >>>>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 We co= ntrol the client and the server, and you are
> >>>> asking me to wait
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 until= what is not in our control is changed.
> >>>> Obviously, not working for me
> >>>>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BTW, = I am talking about real life experiences, when
> >>>> WSS works and TURNS
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 over = 443 doesn't.
> >>>>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Best = regards
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Sergi= o
> >>>>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On 02= /12/2014 20:44, Tirumaleswar Reddy (tireddy)
> >>>> wrote:
> >>>>
> >>>>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 why will it not work when ALPN is used ?
> >>>>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 -Tiru
> >>>>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 *From:*Sergio Garcia Murillo
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 [mailto:sergio.garcia.= murillo@__gmail.com<= br> > >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 <mailto:se= rgio.garcia.murillo@gmail.com>] ?
> >>>>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 *Sent:* Wednesday, December 03, 2014 12:52 AM
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 *To:* Tirumaleswar Reddy (tireddy)
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 *Cc:* Jonathan Lennox; [ACME] Victor Pascual
> >>>> Avila; Simon Perreault;
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 tram@ietf.org <mailto:tram@ietf.org>;
> >>>> draft-chenxin-behave-turn-__websocket@tools.ietf.org=
> >>>> <mailto:draft-chenxin-behave-turn-websocket@tools.ietf.= org>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 *Subject:* RE: [tram] TURN over WebSocket
> >>>>
> >>>>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 El 02/12/2014 20:04, "Tirumaleswar Reddy
> >>>> (tireddy)" <tireddy@cisco.com <mailto:t= ireddy@cisco.com>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 <mailto:tireddy@cisco.co= m
> >>>> <mailto:tired= dy@cisco.com>>> escribi=C3=B3:
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0> From: Simon Perreault
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0> [mailto:sperre= ault@jive.com
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 <mailto:sperreault@jiv= e.com>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 <mailto:sperreault@jiv= e.com
> >>>> <mailto:spe= rreault@jive.com>>]
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0> Sent: Tuesday, December 02, 2014 10:19 PM
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0> To: Tirumaleswar Reddy (tireddy)
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0> Cc: Jonathan Lennox; Sergio Garcia Murillo;
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0> Victor
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Pascual Avila;
> >>>> draft-chenxin-behave-turn-__websocket@tools.ietf.org=
> >>>> <mailto:draft-chenxin-behave-turn-websocket@tools.ietf.= org>
> >>>> <mailto:draft-chenxin-behave-__turn-websocket@tools.i= etf.org
> >>>> <mailto:draft-chenxin-behave-turn-websocket@tools.ietf.= org>>__;
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 tram@ietf.org <mailto:tram@ietf.org>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 <mailto:tram@ietf.org &l= t;mailto:tram@ietf.org>>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0> Subject: Re: [tram] TURN over WebSocket
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0> On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0> Reddy
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 (tireddy)
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 <tireddy@cisco.com &= lt;mailto:tireddy@cisco.com> > >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 <mailto:tireddy@cisco.co= m
> >>>> <mailto:tired= dy@cisco.com>>> wrote:
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0> Transparent proxies like firewalls keep
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0> getting
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 upgraded frequently
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 to handle new applications, threats etc. If
> >>>> firewall has
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 a feature to
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 block WebRTC traffic then by sending traffic
> >>>> over WebSocket will not
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 solve the problem.
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0> (As a participant...)
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0> This has also been discussed before.
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 TURN-over-WebSockets is not a
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 way for applications to circumvent policy.
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0> The problem is there are networks that are
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0> set up so
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 that "the web"
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 is open, through a transparent proxy. WebRTC is
> >>>> part of "the web".
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Making TURN fit the mould of "the web" is is not
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 circumventing policy,
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 it's making WebRTC work. You should not need to
> >>>> update your
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 proxy/firewall config for WebRTC to just work
> >>>> if "the web" already
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 does work.
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0> [TR] Okay, so looks like the problem can
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0> also be
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 solved by running
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 TURN over 443 similar to proposals in DPRIVE WG
> >>>> to run DNS over 443.
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0>
> >>>>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Good try! Unlucky enough, doesn't work.
> >>>>
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Best regards
> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Sergio
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>=C2=A0 =C2=A0 =C2=A0 _________________________________= ________________
> >>>>=C2=A0 =C2=A0 =C2=A0 tram mailing list
> >>>>=C2=A0 =C2=A0 =C2=A0 = tram@ietf.org <mailto:tram@ietf.org= >
> >>>>=C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/__li= stinfo/tram
> >>>>=C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailman/li= stinfo/tram>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> > --
> > Brandon Williams; Senior Principal Software Engineer
> > Emerging Products Engineering; Akamai Technologies Inc.
> >
> > _______________________________________________
> > tram mailing list
> > tram@ietf.org
> > https://www.ietf.org/mailman/listinfo/tram
> >

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--047d7b86f58a38891c0509f60aba-- From nobody Fri Dec 12 06:42:14 2014 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 A36A81A8968 for ; Fri, 12 Dec 2014 06:42:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.801 X-Spam-Level: X-Spam-Status: No, score=-102.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 j7RjpZ0e4Gpb for ; Fri, 12 Dec 2014 06:42:10 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C66251A8700 for ; Fri, 12 Dec 2014 06:42:09 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-8b-548afebf7911 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 7C.24.04231.FBEFA845; Fri, 12 Dec 2014 15:42:08 +0100 (CET) Received: from [131.160.126.11] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.23) with Microsoft SMTP Server id 14.3.195.1; Fri, 12 Dec 2014 15:42:07 +0100 Message-ID: <548AFEBF.6080702@ericsson.com> Date: Fri, 12 Dec 2014 16:42:07 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "tram@ietf.org" References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B8E7@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B9B5@xmb-rcd-x10.cisco.com> <547E2069.4050307@gmail.com> <547E6022.5030101@akamai.com> <547ED5B3.7070102@gmail.com> <547F1C55.4040208@akamai.com> <547F208E.6000000@gmail.com> <547F32E3.1000708@akamai.com> <20141203213637.2fc801ea@lminiero> In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3RvfAv64Qg+VL2Cw+rL3A5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujIO7F7AUrCmruHLlO3sD42PfLkZODgkBE4l5m+cwQ9hiEhfu rWfrYuTiEBI4wijxZMYORpCEkMAaRokVJyO7GDk4eAW0JQ7ulAUJswioSqx7t5oVxGYTsJDY cus+C4gtKhAlcXTJVXYQm1dAUOLkzCdgcREBZYmJJ56D7RIWUJdoPLkIatchdomlT++AJTgF AiWeNcxjArGZBQwkjiyawwphy0s0b53NDHGPtsTyZy0sExgFZiHZMQtJyywkLQsYmVcxihan FhfnphsZ66UWZSYXF+fn6eWllmxiBIbgwS2/dXcwrn7teIhRgINRiYe3YFJXiBBrYllxZe4h RmkOFiVx3kXn5gULCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYLQ2zL9/+JZsiv27xSeEL10J TfFgTlINr5h72llyxp1re0M0znoG9kl73NmgtsjH27nhSJjFsSluMw9vUHGK8A6sNqzKFdvU /4/ZuPq89Ud5v9neBw+8m7HX6GGp08/oU1u4jJ2v3NrhsqVVTCiIe/lu3yrrre0NJU69t9vj rp6YzbrfYceOt0osxRmJhlrMRcWJAEBVyk4iAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/tram/eIo_450nbq0b0kMrZeDk2v50Sfs Subject: Re: [tram] TURN over WebSocket 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: Fri, 12 Dec 2014 14:42:13 -0000 Please, keep the cc: list short so that your messages are not held for manual moderation. Cheers, Gonzalo On 11/12/2014 9:46 PM, Justin Uberti wrote: > So I see 3 arguments being made here: > 1) WSS allows the app and TURN server to be the same entity. > 2) TURN/WSS works where TURN/TLS doesn't, because DPI. > 3) TURN/WS works where TURN/TLS doesn't, because DPI. > > #2 seems very hard to believe; both of these things will try to > establish a TLS connection and then run WS or TURN over top. It's not > clear to me that DPI will be able to reliably ID TURN packets versus > TURN/WS packets when they are encrypted. (Clearly if the DPI is able to > intercept the TLS, it's a different story.) > #3 implies that HTTPS and WSS doesn't work, so not sure how useful that is. > > As Brandon says, I agree we need to understand the problem better before > deciding whether this has value. > > > On Wed, Dec 3, 2014 at 12:36 PM, Lorenzo Miniero > wrote: > > Not to mention the fact that even with plain WS instead of WSS you could > transport TURNS and keep it secure. > > Lorenzo > > > > On Wed, 3 Dec 2014 13:30:21 -0700 > toadzky > wrote: > > > As a developer, I would much prefer to do this kind of thing over WSS. > > Websockets allow the application to control processing on the packets, > > rather than relying on a framework to do. As far as I can tell, > > nothing really supports ALPN at all. If I wanted to write a proxy in > > Java that only listened on 80 and 443, to do ALPN, Jersey (or > > whichever framework I choose) would need to support ALPN and allow me > > to register different handlers for different types. That would be > > fine if it was a network library (like Netty), but it's an HTTP > > framework that would be dealing with other TCP protocols. On top of > > that, the websocket solution can be supported quickly and easily with > > existing frameworks and infrastructure - no waiting for someone else > > to decide to finally support ALPN. > > > > David > > > > On Wed, Dec 3, 2014 at 8:57 AM, Brandon Williams < > > brandon.williams@akamai.com > > wrote: > > > > > The only thing that makes sense to me to explain the problem you > > > describe is that the proxy is splitting the TLS session so that it > > > can view the data flow. If such a proxy only supports HTTP (and by > > > extension Websockets) for the data flow, then it would make sense > > > that TURNS over 443 does not work. The piece I'm missing though is > > > how the proxy could be splitting the TLS session in this way > > > without you knowing, unless the client is accepting a certificate > > > signed by someone else's CA. Nevertheless, if TLS splitting is > > > what's happening and the proxy is rejecting data flows that do not > > > look like HTTP, I can understand how WSS might resolve the problem > > > under conditions where TURNS with ALPN might not. > > > > > > That having been said, if I'm correct about the source of the > > > problem, I'm conflicted about taking up work intended to make a > > > proxy like this function for WebRTC. If TLS is being used solely > > > for the purpose of firewall traversal, then it's OK to split the > > > session. But what if that isn't the case? There are significant > > > security implications associated with helping such a system to > > > function transparently. I personally would rather see my WebRTC > > > sessions fail than accept decryption by an unknown MITM. > > > > > > Of course, it might be the case that something else is happening > > > here and there is no decryption happening on the proxy, which > > > returns me to the point that Andrew made ... I think we need to > > > better understand the nature of the problem in order to decide > > > whether it makes sense to adopt the draft and add a milestone. > > > > > > --Brandon > > > > > > > > > On 12/03/2014 09:39 AM, Sergio Garcia Murillo wrote: > > > > > >> Maybe then is me the one I am missing something, can you explain > > >> how is ALPN meant to solve the problem if TURNS over 443 is > > >> blocked by the proxy? > > >> > > >> Best regards > > >> Sergio > > >> On 03/12/2014 15:21, Brandon Williams wrote: > > >> > > >>> What am I missing? Why would ALPN require changing the wifi > > >>> network? I can accept that it may be necessary, but in the > > >>> absence of someone explaining why the wifi network needs to care, > > >>> it really doesn't make sense to me. > > >>> > > >>> --Brandon > > >>> > > >>> On 12/03/2014 04:24 AM, Oleg Moskalenko wrote: > > >>> > > >>>> That is a good point. A solution must not require changing every > > >>>> wifi network in the world. A "pure" ALPN solution is a great > > >>>> way to kill the whole WebRTC idea. > > >>>> > > >>>> On Wed, Dec 3, 2014 at 1:19 AM, Sergio Garcia Murillo > > >>>> > > >>>> >> wrote: > > >>>> > > >>>> Am I supposed to change every hotel, cafe or airport wifi > > >>>> in the world in order to make it work? That's what I mean. > > >>>> > > >>>> Don't take me wrong, ALPN seems a good solution, as good as > > >>>> ipv6 is for removing NAT, but it is something out my control to > > >>>> have it deployed worldwide, so I can't rely on it as a solution. > > >>>> From a webrtc point of view we only control the client and the > > >>>> turn server, > > >>>> everything in between should be considered hostile. > > >>>> > > >>>> Best regards > > >>>> Sergio > > >>>> > > >>>> > > >>>> On 03/12/2014 1:58, Brandon Williams wrote: > > >>>> > > >>>> What part of ALPN is not under your control? If you're > > >>>> doing WSS, then you've already got TLS in the picture, so ALPN > > >>>> and WSS > > >>>> seem to both solve the server-side multiplexing problem > > >>>> from the > > >>>> original problem statement. What part of the problem > > >>>> statement does WSS solve that ALPN does not? > > >>>> > > >>>> If you're concerned about unencrypted TURN multiplexing > > >>>> with unencrypted HTTP on port 80, then I can see WS solving a > > >>>> problem > > >>>> that ALPN can't solve. > > >>>> > > >>>> --Brandon > > >>>> > > >>>> On 12/02/2014 03:26 PM, Sergio Garcia Murillo wrote: > > >>>> > > >>>> We control the client and the server, and you are > > >>>> asking me to wait > > >>>> until what is not in our control is changed. > > >>>> Obviously, not working for me > > >>>> > > >>>> BTW, I am talking about real life experiences, when > > >>>> WSS works and TURNS > > >>>> over 443 doesn't. > > >>>> > > >>>> Best regards > > >>>> Sergio > > >>>> > > >>>> On 02/12/2014 20:44, Tirumaleswar Reddy (tireddy) > > >>>> wrote: > > >>>> > > >>>> > > >>>> why will it not work when ALPN is used ? > > >>>> > > >>>> -Tiru > > >>>> > > >>>> *From:*Sergio Garcia Murillo > > >>>> [mailto:sergio.garcia.murillo@ > __gmail.com > > >>>> >] ? > > >>>> > > >>>> *Sent:* Wednesday, December 03, 2014 12:52 AM > > >>>> *To:* Tirumaleswar Reddy (tireddy) > > >>>> *Cc:* Jonathan Lennox; [ACME] Victor Pascual > > >>>> Avila; Simon Perreault; > > >>>> tram@ietf.org > >; > > >>>> draft-chenxin-behave-turn-__websocket@tools.ietf.org > > > >>>> > > > >>>> *Subject:* RE: [tram] TURN over WebSocket > > >>>> > > >>>> > > >>>> El 02/12/2014 20:04, "Tirumaleswar Reddy > > >>>> (tireddy)" > > > > >>>> > > >>>> >>> escribi: > > >>>> > > > >>>> > From: Simon Perreault > > >>>> > [mailto:sperreault@jive.com > > > >>>> > > > >>>> > > >>>> >>] > > >>>> > Sent: Tuesday, December 02, 2014 10:19 PM > > >>>> > > > >>>> > To: Tirumaleswar Reddy (tireddy) > > >>>> > Cc: Jonathan Lennox; Sergio Garcia Murillo; > > >>>> > Victor > > >>>> Pascual Avila; > > >>>> draft-chenxin-behave-turn-__websocket@tools.ietf.org > > > >>>> > > > >>>> > > >>>> >>__; > > >>>> tram@ietf.org > > > > >>>> > >> > > >>>> > Subject: Re: [tram] TURN over WebSocket > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar > > >>>> > Reddy > > >>>> (tireddy) > > >>>> > > > >>>> > > >>>> >>> wrote: > > >>>> > > > >>>> > Transparent proxies like firewalls keep > > >>>> > getting > > >>>> upgraded frequently > > >>>> to handle new applications, threats etc. If > > >>>> firewall has > > >>>> a feature to > > >>>> block WebRTC traffic then by sending traffic > > >>>> over WebSocket will not > > >>>> solve the problem. > > >>>> > > > >>>> > > > >>>> > > > >>>> > (As a participant...) > > >>>> > > > >>>> > > > >>>> > This has also been discussed before. > > >>>> TURN-over-WebSockets is not a > > >>>> way for applications to circumvent policy. > > >>>> > > > >>>> > > > >>>> > > > >>>> > The problem is there are networks that are > > >>>> > set up so > > >>>> that "the web" > > >>>> is open, through a transparent proxy. WebRTC is > > >>>> part of "the web". > > >>>> Making TURN fit the mould of "the web" is is not > > >>>> circumventing policy, > > >>>> it's making WebRTC work. You should not need to > > >>>> update your > > >>>> proxy/firewall config for WebRTC to just work > > >>>> if "the web" already > > >>>> does work. > > >>>> > > > >>>> > > > >>>> > > > >>>> > [TR] Okay, so looks like the problem can > > >>>> > also be > > >>>> solved by running > > >>>> TURN over 443 similar to proposals in DPRIVE WG > > >>>> to run DNS over 443. > > >>>> > > > >>>> > > > >>>> > > >>>> Good try! Unlucky enough, doesn't work. > > >>>> > > >>>> Best regards > > >>>> Sergio > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> _________________________________________________ > > >>>> tram mailing list > > >>>> tram@ietf.org > > > > >>>> https://www.ietf.org/mailman/__listinfo/tram > > >>>> > > >>>> > > >>>> > > >>>> > > >>> > > >> > > > -- > > > Brandon Williams; Senior Principal Software Engineer > > > Emerging Products Engineering; Akamai Technologies Inc. > > > > > > _______________________________________________ > > > 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 > > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > From nobody Sun Dec 14 22:37:10 2014 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 297531A1A04; Sun, 14 Dec 2014 22:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 2T9On1lN2py1; Sun, 14 Dec 2014 22:37:07 -0800 (PST) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 585F61A0271; Sun, 14 Dec 2014 22:37:07 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id l18so13811226wgh.2 for ; Sun, 14 Dec 2014 22:37:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ohwo06I5b67wSfq+/+MgUhEmX28Ul8ZFBDMj29BSGqI=; b=wpDsEMnPnoBoqlnvvFhmhYWMnNJJ89yIYBvO7l9jdodAwR8cNL+Zs9/Oskd8p+TIqd mqXYRJy9dRxW4oqVbCZuKonBWeo0nW9ZQ0zhAYd9tMXql5tL2hdnyvAGqO8qgXws+P6m 2TG57Skt4XROl7+YT96oRGCIRE4hEdiwL4oYeXjbW7srzqJam3diGGquC+x8efZRJarD 4KKAWwt/csZAzq3a3ztaY1oVnh4NSHJaIYC4IUmFd746+qgkjn56Gn5p0sBtb+Gh4l5s dZNuB7XNe10r3c2qmC51bOTrXWHnhMDrPfqMKJScPfvve7baXGopYesZOSWAaRwLhQ64 db1Q== MIME-Version: 1.0 X-Received: by 10.194.80.68 with SMTP id p4mr12960439wjx.108.1418625426066; Sun, 14 Dec 2014 22:37:06 -0800 (PST) Received: by 10.194.238.132 with HTTP; Sun, 14 Dec 2014 22:37:06 -0800 (PST) In-Reply-To: <20141208173352.21096.99911.idtracker@ietfa.amsl.com> References: <20141208173352.21096.99911.idtracker@ietfa.amsl.com> Date: Sun, 14 Dec 2014 22:37:06 -0800 Message-ID: From: Oleg Moskalenko To: The IESG Content-Type: multipart/alternative; boundary=047d7bb04f9e971644050a3b7817 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/X5EZjLQx_prtNKm2jcJmlBjYP4c Cc: tram chair , tram mailing list , IETF-Announce , RFC Editor Subject: Re: [tram] Document Action: 'Application Layer Protocol Negotiation (ALPN) Labels for Session Traversal Utilities for NAT (STUN) Usages' to Informational RFC (draft-ietf-tram-alpn-08.txt) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 06:37:09 -0000 --047d7bb04f9e971644050a3b7817 Content-Type: text/plain; charset=UTF-8 The ALPN specs are implemented in the coturn-4.3.2.2 release: https://code.google.com/p/coturn/wiki/Downloads Oleg On Mon, Dec 8, 2014 at 9:33 AM, The IESG wrote: > > The IESG has approved the following document: > - 'Application Layer Protocol Negotiation (ALPN) Labels for Session > Traversal Utilities for NAT (STUN) Usages' > (draft-ietf-tram-alpn-08.txt) as Informational RFC > > This document is the product of the TURN Revised and Modernized Working > Group. > > The IESG contact persons are Spencer Dawkins and Martin Stiemerling. > > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-tram-alpn/ > > > > > Technical Summary > > This document defines two APLN labels for two usages of STUN over (D)TLS: > NAT > discovery and TURN. > > Working Group Summary > > The draft was initially thought to be a "slam dunk" but the working group > ended > up arguing over the granularity of ALPN labels: did we need just one label > for > all of STUN or one label for each STUN usage? Once the WG selected the > second > option, it argued over the necessity of a generic "STUN" label for future > and > unknown usages, rejecting that idea in the end. > > Many TRAM regulars participated in the discussion. Martin Thompson in > particular > provided much (D)TLS and ALPN expertise. The consensus is solid and > represents > the whole working group. > > A discussion during Last Call resulted in the deletion of some > non-normative text > describing possible use cases. > > Document Quality > > No specific implementation was mentioned on the list, but this shepherd > expects > that WebRTC stacks and TURN servers will implement this draft quickly. > > Personnel > > The document shepherd is Simon Perreault > The responsible Area Director is Spencer Dawkins > The IANA designated expert reviewer for > Application-Layer Protocol Negotiation (ALPN) Protocol IDs is Joe > Salowey > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --047d7bb04f9e971644050a3b7817 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The ALPN specs are implemented in the coturn-4.3.2.2 = release:

https://code.google.com/p/coturn/wiki/Downloads

Oleg
<= br>

On Mon, = Dec 8, 2014 at 9:33 AM, The IESG <iesg-secretary@ietf.org> wrote:
The IESG has approved the followi= ng document:
- 'Application Layer Protocol Negotiation (ALPN) Labels for Session
=C2=A0 =C2=A0Traversal Utilities for NAT (STUN) Usages'
=C2=A0 (draft-ietf-tram-alpn-08.txt) as Informational RFC

This document is the product of the TURN Revised and Modernized Working
Group.

The IESG contact persons are Spencer Dawkins and Martin Stiemerling.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-tram-alpn/




Technical Summary

This document defines two APLN labels for two usages of STUN over (D)TLS: N= AT
discovery and TURN.

Working Group Summary

The draft was initially thought to be a "slam dunk" but the worki= ng group ended
up arguing over the granularity of ALPN labels: did we need just one label = for
all of STUN or one label for each STUN usage? Once the WG selected the seco= nd
option, it argued over the necessity of a generic "STUN" label fo= r future and
unknown usages, rejecting that idea in the end.

Many TRAM regulars participated in the discussion. Martin Thompson in parti= cular
provided much (D)TLS and ALPN expertise. The consensus is solid and represe= nts
the whole working group.

A discussion during Last Call resulted in the deletion of some non-normativ= e text
describing possible use cases.

Document Quality

No specific implementation was mentioned on the list, but this shepherd exp= ects
that WebRTC stacks and TURN servers will implement this draft quickly.

Personnel

The document shepherd is Simon Perreault <sperreault@jive.com>
The responsible Area Director is Spencer Dawkins
The IANA designated expert reviewer for
=C2=A0 =C2=A0 Application-Layer Protocol Negotiation (ALPN) Protocol IDs is= Joe Salowey

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram
--047d7bb04f9e971644050a3b7817-- From nobody Sun Dec 14 22:40:56 2014 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 1F4371A1A00 for ; Sun, 14 Dec 2014 22:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 UAsbq-EcYBh8 for ; Sun, 14 Dec 2014 22:40:52 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 277D21A1A07 for ; Sun, 14 Dec 2014 22:40:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6695; q=dns/txt; s=iport; t=1418625652; x=1419835252; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MUlKLySNLutJdc+87uKmaXlkFWgc6rNRh8xbSatavDw=; b=kwg/LEQVqsQ9vCg5fGy2yNt3fIoyMRJKj3UQW1Eg9Hs9kzws9uAEtBCe rdGTvmkPU2va6JCghkfi5VSrRSsXAxdKMEZ+cYe9gxolMtH3DsIHGs2m/ EEAigjdYUkxr+EJMu56QAd418jX+FAc+iW7CxqS7N6qLkQ4MxBcfgkWC8 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtAFAN6BjlStJA2F/2dsb2JhbABagwZSWLY/jH08gV8BCYVyAoEUFgEBAQEBfYQNAQEEAQEBaAMLEAIBCA4tBAchBgsUEQIEDgWIGAMRDct6DYVNAQEBAQEBAQEBAQEBAQEBAQEBAQEBF41KgURgBAeDFoETBYQmAolagz6DboFDgTuKK4VRIoIwgTxugQOBQAEBAQ X-IronPort-AV: E=Sophos;i="5.07,578,1413244800"; d="scan'208,217";a="380394551" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-3.cisco.com with ESMTP; 15 Dec 2014 06:40:49 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id sBF6eneJ006036 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Dec 2014 06:40:49 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.111]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Mon, 15 Dec 2014 00:40:49 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: Oleg Moskalenko Thread-Topic: [tram] Document Action: 'Application Layer Protocol Negotiation (ALPN) Labels for Session Traversal Utilities for NAT (STUN) Usages' to Informational RFC (draft-ietf-tram-alpn-08.txt) Thread-Index: AQHQGDGPznxoBJ+Ak0CILOYgeMtl0ZyQM7wS Date: Mon, 15 Dec 2014 06:40:48 +0000 Message-ID: <1C99A443-EC23-43CC-A645-E14B2752F4A3@cisco.com> References: <20141208173352.21096.99911.idtracker@ietfa.amsl.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_1C99A443EC2343CCA645E14B2752F4A3ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/aOyOaHtRbzvDtxiG_ArHG5f0Xac Cc: tram mailing list , tram chair Subject: Re: [tram] Document Action: 'Application Layer Protocol Negotiation (ALPN) Labels for Session Traversal Utilities for NAT (STUN) Usages' to Informational RFC (draft-ietf-tram-alpn-08.txt) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 06:40:54 -0000 --_000_1C99A443EC2343CCA645E14B2752F4A3ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Excellent! Thanks, Oleg! Regards, Gonzalo On Dec 15, 2014, at 2:37 PM, Oleg Moskalenko > wrote: The ALPN specs are implemented in the coturn-4.3.2.2 release: https://code.google.com/p/coturn/wiki/Downloads Oleg On Mon, Dec 8, 2014 at 9:33 AM, The IESG > wrote: The IESG has approved the following document: - 'Application Layer Protocol Negotiation (ALPN) Labels for Session Traversal Utilities for NAT (STUN) Usages' (draft-ietf-tram-alpn-08.txt) as Informational RFC This document is the product of the TURN Revised and Modernized Working Group. The IESG contact persons are Spencer Dawkins and Martin Stiemerling. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-tram-alpn/ Technical Summary This document defines two APLN labels for two usages of STUN over (D)TLS: N= AT discovery and TURN. Working Group Summary The draft was initially thought to be a "slam dunk" but the working group e= nded up arguing over the granularity of ALPN labels: did we need just one label = for all of STUN or one label for each STUN usage? Once the WG selected the seco= nd option, it argued over the necessity of a generic "STUN" label for future a= nd unknown usages, rejecting that idea in the end. Many TRAM regulars participated in the discussion. Martin Thompson in parti= cular provided much (D)TLS and ALPN expertise. The consensus is solid and represe= nts the whole working group. A discussion during Last Call resulted in the deletion of some non-normativ= e text describing possible use cases. Document Quality No specific implementation was mentioned on the list, but this shepherd exp= ects that WebRTC stacks and TURN servers will implement this draft quickly. Personnel The document shepherd is Simon Perreault > The responsible Area Director is Spencer Dawkins The IANA designated expert reviewer for Application-Layer Protocol Negotiation (ALPN) Protocol IDs is Joe Salow= ey _______________________________________________ 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 --_000_1C99A443EC2343CCA645E14B2752F4A3ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Excellent!  Thanks, Oleg!

Regards,

Gonzalo



On Dec 15, 2014, at 2:37 PM, Oleg Moskalenko <mom040267@gmail.com> wrote:

The ALPN specs are implemented in the coturn-4.3.2.2 release:

https://code.go= ogle.com/p/coturn/wiki/Downloads

Oleg


On Mon, Dec 8, 2014 at 9:33 AM, The IESG <iesg-secre= tary@ietf.org> wrote:
The IESG has approved the following document:
- 'Application Layer Protocol Negotiation (ALPN) Labels for Session
   Traversal Utilities for NAT (STUN) Usages'
  (draft-ietf-tram-alpn-08.txt) as Informational RFC

This document is the product of the TURN Revised and Modernized Working
Group.

The IESG contact persons are Spencer Dawkins and Martin Stiemerling.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-tram-alpn/




Technical Summary

This document defines two APLN labels for two usages of STUN over (D)TLS: N= AT
discovery and TURN.

Working Group Summary

The draft was initially thought to be a "slam dunk" but the worki= ng group ended
up arguing over the granularity of ALPN labels: did we need just one label = for
all of STUN or one label for each STUN usage? Once the WG selected the seco= nd
option, it argued over the necessity of a generic "STUN" label fo= r future and
unknown usages, rejecting that idea in the end.

Many TRAM regulars participated in the discussion. Martin Thompson in parti= cular
provided much (D)TLS and ALPN expertise. The consensus is solid and represe= nts
the whole working group.

A discussion during Last Call resulted in the deletion of some non-normativ= e text
describing possible use cases.

Document Quality

No specific implementation was mentioned on the list, but this shepherd exp= ects
that WebRTC stacks and TURN servers will implement this draft quickly.

Personnel

The document shepherd is Simon Perreault <sperreault@jive.com>
The responsible Area Director is Spencer Dawkins
The IANA designated expert reviewer for
    Application-Layer Protocol Negotiation (ALPN) Protocol IDs is= Joe Salowey

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram
_______________________________________________
tram mailing list
tram@ietf.org
https://www.ie= tf.org/mailman/listinfo/tram
--_000_1C99A443EC2343CCA645E14B2752F4A3ciscocom_-- From nobody Thu Dec 18 02:23:57 2014 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 06E911A6F9E for ; Thu, 18 Dec 2014 02:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 Gi1zvvT-oQ1a for ; Thu, 18 Dec 2014 02:23:48 -0800 (PST) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 911941A0235 for ; Thu, 18 Dec 2014 02:23:47 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id r20so1265687wiv.2 for ; Thu, 18 Dec 2014 02:23:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=Iw1UopUEPHQ8ESms6GbV6eT5RbB5boWOAurtxAzYrUA=; b=axMthN8i2jXYEtRBtZkMeWkXOsDQpVLkqc8whnkTBOpGnVgHkRV4jA07/XXLvERaK4 yqA6Yhvogmz25VW98EyoSunObAIoaek0vj6BEVXB9F1qnfXMy+p3zA7xJxhMOU2mO3Z3 7jITVj1jWopse+fNxLFsRiPRv5YuWD8TPKpiJsCXUvYuDhlVUgkthHjz7f282B7YeOJb 1Qb+jSLNRXkDhVy6PLDvEwdgwzaMF4H67vMxputy60O/Z/TuRXw+N+K1aygr03JNOC5e 8BPDfgc+FJ4XaYCdfvnTg6l1cd6Pn4aTA10ZPG6w36cWL428OVynosYSsGR/tie9JVb6 x1tA== X-Received: by 10.180.76.201 with SMTP id m9mr22689301wiw.52.1418898226364; Thu, 18 Dec 2014 02:23:46 -0800 (PST) Received: from [192.168.1.37] (136.Red-81-39-109.dynamicIP.rima-tde.net. [81.39.109.136]) by mx.google.com with ESMTPSA id dp8sm24150511wib.20.2014.12.18.02.23.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Dec 2014 02:23:45 -0800 (PST) Message-ID: <5492AB2A.5050105@gmail.com> Date: Thu, 18 Dec 2014 11:23:38 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Justin Uberti References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B8E7@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B9B5@xmb-rcd-x10.cisco.com> <547E2069.4050307@gmail.com> <547E6022.5030101@akamai.com> <547ED5B3.7070102@gmail.com> <547F1C55.4040208@akamai.com> <547F208E.6000000@gmail.com> <547F32E3.1000708@akamai.com> <20141203213637.2fc801ea@lminiero> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000503040204050609040504" Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ldB7xg-MwaXrB0lqSS96pQdLoCM Cc: "draft-chenxin-behave-turn-websocket@tools.ietf.org" , "tram@ietf.org" Subject: Re: [tram] TURN over WebSocket 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 Dec 2014 10:23:54 -0000 This is a multi-part message in MIME format. --------------000503040204050609040504 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sorry for the late reply, busy week.. :) Regarding #2 and #3, I agree that it needs to be look further. Anyway, as I said in a previous email, it should not be a show stopper for working on the draft on the TRAM group, even if they are not clarified and we can state that TURN over WS provides same connectivity level than TURN over TLS + HTTP CONNECT. Also, regarding 1, I have been thinking about it and it is not only about easing the deployment in some constrained scenarios. It would provide a much better integration with Web usage than normal TURN. For example in our service, we have a couple balanced nginx servers acting ssl terminator ands reverse proxy for http and ws. So adding TURNS over WS to our deployment would be kind of trivial and would allow us to keep all our urls under the same domain. (I think that the extra delay of having a new intermediary proxy would be neglectable). So we could have: https://www.xxxxx.xx/rest https://www.xxxxx.xx/html wss://www.xxxxx.xx/sip wss://www.xxxxx.xx/turn Theres huge is a side benefit for that, as all of them shares same domain, we can share cookies with authentication tokens and the other HTTP headers (like Origin) between the different websockets (sip/turn) and rest apis. Note that we had to add an HTTP REST API to the TURN server for short time credentials and load balancing and add origin header to STUN/TURN messages, to be able to do what is natively supported by websockets. Best regards Sergio On 11/12/2014 20:46, Justin Uberti wrote: > So I see 3 arguments being made here: > 1) WSS allows the app and TURN server to be the same entity. > 2) TURN/WSS works where TURN/TLS doesn't, because DPI. > 3) TURN/WS works where TURN/TLS doesn't, because DPI. > > #2 seems very hard to believe; both of these things will try to > establish a TLS connection and then run WS or TURN over top. It's not > clear to me that DPI will be able to reliably ID TURN packets versus > TURN/WS packets when they are encrypted. (Clearly if the DPI is able > to intercept the TLS, it's a different story.) > #3 implies that HTTPS and WSS doesn't work, so not sure how useful > that is. > > As Brandon says, I agree we need to understand the problem better > before deciding whether this has value. > > > On Wed, Dec 3, 2014 at 12:36 PM, Lorenzo Miniero > wrote: > > Not to mention the fact that even with plain WS instead of WSS you > could > transport TURNS and keep it secure. > > Lorenzo > > > > On Wed, 3 Dec 2014 13:30:21 -0700 > toadzky > wrote: > > > As a developer, I would much prefer to do this kind of thing > over WSS. > > Websockets allow the application to control processing on the > packets, > > rather than relying on a framework to do. As far as I can tell, > > nothing really supports ALPN at all. If I wanted to write a proxy in > > Java that only listened on 80 and 443, to do ALPN, Jersey (or > > whichever framework I choose) would need to support ALPN and > allow me > > to register different handlers for different types. That would be > > fine if it was a network library (like Netty), but it's an HTTP > > framework that would be dealing with other TCP protocols. On top of > > that, the websocket solution can be supported quickly and easily > with > > existing frameworks and infrastructure - no waiting for someone else > > to decide to finally support ALPN. > > > > David > > > > On Wed, Dec 3, 2014 at 8:57 AM, Brandon Williams < > > brandon.williams@akamai.com > > wrote: > > > > > The only thing that makes sense to me to explain the problem you > > > describe is that the proxy is splitting the TLS session so that it > > > can view the data flow. If such a proxy only supports HTTP (and by > > > extension Websockets) for the data flow, then it would make sense > > > that TURNS over 443 does not work. The piece I'm missing though is > > > how the proxy could be splitting the TLS session in this way > > > without you knowing, unless the client is accepting a certificate > > > signed by someone else's CA. Nevertheless, if TLS splitting is > > > what's happening and the proxy is rejecting data flows that do not > > > look like HTTP, I can understand how WSS might resolve the problem > > > under conditions where TURNS with ALPN might not. > > > > > > That having been said, if I'm correct about the source of the > > > problem, I'm conflicted about taking up work intended to make a > > > proxy like this function for WebRTC. If TLS is being used solely > > > for the purpose of firewall traversal, then it's OK to split the > > > session. But what if that isn't the case? There are significant > > > security implications associated with helping such a system to > > > function transparently. I personally would rather see my WebRTC > > > sessions fail than accept decryption by an unknown MITM. > > > > > > Of course, it might be the case that something else is happening > > > here and there is no decryption happening on the proxy, which > > > returns me to the point that Andrew made ... I think we need to > > > better understand the nature of the problem in order to decide > > > whether it makes sense to adopt the draft and add a milestone. > > > > > > --Brandon > > > > > > > > > On 12/03/2014 09:39 AM, Sergio Garcia Murillo wrote: > > > > > >> Maybe then is me the one I am missing something, can you explain > > >> how is ALPN meant to solve the problem if TURNS over 443 is > > >> blocked by the proxy? > > >> > > >> Best regards > > >> Sergio > > >> On 03/12/2014 15:21, Brandon Williams wrote: > > >> > > >>> What am I missing? Why would ALPN require changing the wifi > > >>> network? I can accept that it may be necessary, but in the > > >>> absence of someone explaining why the wifi network needs to > care, > > >>> it really doesn't make sense to me. > > >>> > > >>> --Brandon > > >>> > > >>> On 12/03/2014 04:24 AM, Oleg Moskalenko wrote: > > >>> > > >>>> That is a good point. A solution must not require changing > every > > >>>> wifi network in the world. A "pure" ALPN solution is a great > > >>>> way to kill the whole WebRTC idea. > > >>>> > > >>>> On Wed, Dec 3, 2014 at 1:19 AM, Sergio Garcia Murillo > > >>>> > > >>>> >> wrote: > > >>>> > > >>>> Am I supposed to change every hotel, cafe or airport wifi > > >>>> in the world in order to make it work? That's what I mean. > > >>>> > > >>>> Don't take me wrong, ALPN seems a good solution, as > good as > > >>>> ipv6 is for removing NAT, but it is something out my control to > > >>>> have it deployed worldwide, so I can't rely on it as a > solution. > > >>>> From a webrtc point of view we only control the client and the > > >>>> turn server, > > >>>> everything in between should be considered hostile. > > >>>> > > >>>> Best regards > > >>>> Sergio > > >>>> > > >>>> > > >>>> On 03/12/2014 1:58, Brandon Williams wrote: > > >>>> > > >>>> What part of ALPN is not under your control? If you're > > >>>> doing WSS, then you've already got TLS in the picture, so ALPN > > >>>> and WSS > > >>>> seem to both solve the server-side multiplexing > problem > > >>>> from the > > >>>> original problem statement. What part of the problem > > >>>> statement does WSS solve that ALPN does not? > > >>>> > > >>>> If you're concerned about unencrypted TURN > multiplexing > > >>>> with unencrypted HTTP on port 80, then I can see WS solving a > > >>>> problem > > >>>> that ALPN can't solve. > > >>>> > > >>>> --Brandon > > >>>> > > >>>> On 12/02/2014 03:26 PM, Sergio Garcia Murillo wrote: > > >>>> > > >>>> We control the client and the server, and you are > > >>>> asking me to wait > > >>>> until what is not in our control is changed. > > >>>> Obviously, not working for me > > >>>> > > >>>> BTW, I am talking about real life experiences, > when > > >>>> WSS works and TURNS > > >>>> over 443 doesn't. > > >>>> > > >>>> Best regards > > >>>> Sergio > > >>>> > > >>>> On 02/12/2014 20:44, Tirumaleswar Reddy (tireddy) > > >>>> wrote: > > >>>> > > >>>> > > >>>> why will it not work when ALPN is used ? > > >>>> > > >>>> -Tiru > > >>>> > > >>>> *From:*Sergio Garcia Murillo > > >>>> [mailto:sergio.garcia.murillo@ > __gmail.com > > >>>> >] ? > > >>>> > > >>>> *Sent:* Wednesday, December 03, 2014 12:52 AM > > >>>> *To:* Tirumaleswar Reddy (tireddy) > > >>>> *Cc:* Jonathan Lennox; [ACME] Victor Pascual > > >>>> Avila; Simon Perreault; > > >>>> tram@ietf.org >; > > >>>> draft-chenxin-behave-turn-__websocket@tools.ietf.org > > > >>>> > > > >>>> *Subject:* RE: [tram] TURN over WebSocket > > >>>> > > >>>> > > >>>> El 02/12/2014 20:04, "Tirumaleswar Reddy > > >>>> (tireddy)" > > > > >>>> > > >>>> >>> > escribió: > > >>>> > > > >>>> > From: Simon Perreault > > >>>> > [mailto:sperreault@jive.com > > > >>>> > > > >>>> > > >>>> >>] > > >>>> > Sent: Tuesday, December 02, 2014 10:19 PM > > >>>> > > > >>>> > To: Tirumaleswar Reddy (tireddy) > > >>>> > Cc: Jonathan Lennox; Sergio Garcia Murillo; > > >>>> > Victor > > >>>> Pascual Avila; > > >>>> draft-chenxin-behave-turn-__websocket@tools.ietf.org > > > >>>> > > > >>>> > > > >>>> >>__; > > >>>> tram@ietf.org > > > >>>> >> > > >>>> > Subject: Re: [tram] TURN over WebSocket > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > On Tue, Dec 2, 2014 at 9:34 AM, > Tirumaleswar > > >>>> > Reddy > > >>>> (tireddy) > > >>>> > > > >>>> > > >>>> >>> wrote: > > >>>> > > > >>>> > Transparent proxies like firewalls keep > > >>>> > getting > > >>>> upgraded frequently > > >>>> to handle new applications, threats etc. If > > >>>> firewall has > > >>>> a feature to > > >>>> block WebRTC traffic then by sending traffic > > >>>> over WebSocket will not > > >>>> solve the problem. > > >>>> > > > >>>> > > > >>>> > > > >>>> > (As a participant...) > > >>>> > > > >>>> > > > >>>> > This has also been discussed before. > > >>>> TURN-over-WebSockets is not a > > >>>> way for applications to circumvent policy. > > >>>> > > > >>>> > > > >>>> > > > >>>> > The problem is there are networks that are > > >>>> > set up so > > >>>> that "the web" > > >>>> is open, through a transparent proxy. > WebRTC is > > >>>> part of "the web". > > >>>> Making TURN fit the mould of "the web" is > is not > > >>>> circumventing policy, > > >>>> it's making WebRTC work. You should not > need to > > >>>> update your > > >>>> proxy/firewall config for WebRTC to just work > > >>>> if "the web" already > > >>>> does work. > > >>>> > > > >>>> > > > >>>> > > > >>>> > [TR] Okay, so looks like the problem can > > >>>> > also be > > >>>> solved by running > > >>>> TURN over 443 similar to proposals in > DPRIVE WG > > >>>> to run DNS over 443. > > >>>> > > > >>>> > > > >>>> > > >>>> Good try! Unlucky enough, doesn't work. > > >>>> > > >>>> Best regards > > >>>> Sergio > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> _________________________________________________ > > >>>> tram mailing list > > >>>> tram@ietf.org > > > >>>> https://www.ietf.org/mailman/__listinfo/tram > > >>>> > > >>>> > > >>>> > > >>>> > > >>> > > >> > > > -- > > > Brandon Williams; Senior Principal Software Engineer > > > Emerging Products Engineering; Akamai Technologies Inc. > > > > > > _______________________________________________ > > > 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 > > --------------000503040204050609040504 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Sorry for the late reply, busy week.. :)

Regarding #2 and #3, I agree that it needs to be look further.

Anyway, as I said in a previous email, it should not be a show stopper for working on the draft on the TRAM group, even if they are not clarified and we can state that TURN over WS provides same connectivity level than TURN over TLS + HTTP CONNECT.

Also, regarding 1, I have been thinking about it and it is not only about easing the deployment in some constrained scenarios. It would provide a much better integration with Web usage than normal TURN.

For example in our service, we have a couple balanced nginx servers acting ssl terminator ands reverse proxy for http and ws. So adding TURNS over WS to our deployment would be kind of trivial and would allow us to keep all our urls under the same domain. (I think that the extra delay of having a new intermediary proxy would be neglectable). So we could have:

https://www.xxxxx.xx/rest
https://www.xxxxx.xx/html
wss://www.xxxxx.xx/sip
wss://www.xxxxx.xx/turn

Theres huge is a side benefit for that, as all of them shares same domain, we can share cookies with authentication tokens and the other HTTP headers (like Origin) between the different websockets (sip/turn) and rest apis. Note that we had to add an HTTP REST API to the TURN server for short time credentials and load balancing and add origin header to STUN/TURN messages, to be able to do what is natively supported by websockets.

Best regards
Sergio
On 11/12/2014 20:46, Justin Uberti wrote:
So I see 3 arguments being made here:
1) WSS allows the app and TURN server to be the same entity.
2) TURN/WSS works where TURN/TLS doesn't, because DPI.
3) TURN/WS works where TURN/TLS doesn't, because DPI.

#2 seems very hard to believe; both of these things will try to establish a TLS connection and then run WS or TURN over top. It's not clear to me that DPI will be able to reliably ID TURN packets versus TURN/WS packets when they are encrypted. (Clearly if the DPI is able to intercept the TLS, it's a different story.)
#3 implies that HTTPS and WSS doesn't work, so not sure how useful that is.

As Brandon says, I agree we need to understand the problem better before deciding whether this has value.


On Wed, Dec 3, 2014 at 12:36 PM, Lorenzo Miniero <lorenzo@meetecho.com> wrote:
Not to mention the fact that even with plain WS instead of WSS you could
transport TURNS and keep it secure.

Lorenzo



On Wed, 3 Dec 2014 13:30:21 -0700
toadzky <toadzky@gmail.com> wrote:

> As a developer, I would much prefer to do this kind of thing over WSS.
> Websockets allow the application to control processing on the packets,
> rather than relying on a framework to do. As far as I can tell,
> nothing really supports ALPN at all. If I wanted to write a proxy in
> Java that only listened on 80 and 443, to do ALPN, Jersey (or
> whichever framework I choose) would need to support ALPN and allow me
> to register different handlers for different types. That would be
> fine if it was a network library (like Netty), but it's an HTTP
> framework that would be dealing with other TCP protocols. On top of
> that, the websocket solution can be supported quickly and easily with
> existing frameworks and infrastructure - no waiting for someone else
> to decide to finally support ALPN.
>
> David
>
> On Wed, Dec 3, 2014 at 8:57 AM, Brandon Williams <
> brandon.williams@akamai.com> wrote:
>
> > The only thing that makes sense to me to explain the problem you
> > describe is that the proxy is splitting the TLS session so that it
> > can view the data flow. If such a proxy only supports HTTP (and by
> > extension Websockets) for the data flow, then it would make sense
> > that TURNS over 443 does not work. The piece I'm missing though is
> > how the proxy could be splitting the TLS session in this way
> > without you knowing, unless the client is accepting a certificate
> > signed by someone else's CA. Nevertheless, if TLS splitting is
> > what's happening and the proxy is rejecting data flows that do not
> > look like HTTP, I can understand how WSS might resolve the problem
> > under conditions where TURNS with ALPN might not.
> >
> > That having been said, if I'm correct about the source of the
> > problem, I'm conflicted about taking up work intended to make a
> > proxy like this function for WebRTC. If TLS is being used solely
> > for the purpose of firewall traversal, then it's OK to split the
> > session. But what if that isn't the case? There are significant
> > security implications associated with helping such a system to
> > function transparently. I personally would rather see my WebRTC
> > sessions fail than accept decryption by an unknown MITM.
> >
> > Of course, it might be the case that something else is happening
> > here and there is no decryption happening on the proxy, which
> > returns me to the point that Andrew made ... I think we need to
> > better understand the nature of the problem in order to decide
> > whether it makes sense to adopt the draft and add a milestone.
> >
> > --Brandon
> >
> >
> > On 12/03/2014 09:39 AM, Sergio Garcia Murillo wrote:
> >
> >> Maybe then is me the one I am missing something, can you explain
> >> how is ALPN meant to solve the problem if TURNS over 443 is
> >> blocked by the proxy?
> >>
> >> Best regards
> >> Sergio
> >> On 03/12/2014 15:21, Brandon Williams wrote:
> >>
> >>> What am I missing? Why would ALPN require changing the wifi
> >>> network? I can accept that it may be necessary, but in the
> >>> absence of someone explaining why the wifi network needs to care,
> >>> it really doesn't make sense to me.
> >>>
> >>> --Brandon
> >>>
> >>> On 12/03/2014 04:24 AM, Oleg Moskalenko wrote:
> >>>
> >>>> That is a good point. A solution must not require changing every
> >>>> wifi network in the world. A "pure" ALPN  solution is a great
> >>>> way to kill the whole WebRTC idea.
> >>>>
> >>>> On Wed, Dec 3, 2014 at 1:19 AM, Sergio Garcia Murillo
> >>>> <sergio.garcia.murillo@gmail.com
> >>>> <mailto:sergio.garcia.murillo@gmail.com>> wrote:
> >>>>
> >>>>      Am I supposed to change every hotel, cafe or airport wifi
> >>>> in the world in order to make it work? That's what I mean.
> >>>>
> >>>>      Don't take me wrong, ALPN seems a good solution, as good as
> >>>> ipv6 is for removing NAT, but it is something out my control to
> >>>> have it deployed worldwide, so I can't rely on it as a solution.
> >>>> From a webrtc point of view we only control the client and the
> >>>> turn server,
> >>>>      everything in between should be considered hostile.
> >>>>
> >>>>      Best regards
> >>>>      Sergio
> >>>>
> >>>>
> >>>>      On 03/12/2014 1:58, Brandon Williams wrote:
> >>>>
> >>>>          What part of ALPN is not under your control? If you're
> >>>> doing WSS, then you've already got TLS in the picture, so ALPN
> >>>> and WSS
> >>>>          seem to both solve the server-side multiplexing problem
> >>>> from the
> >>>>          original problem statement. What part of the problem
> >>>> statement does WSS solve that ALPN does not?
> >>>>
> >>>>          If you're concerned about unencrypted TURN multiplexing
> >>>> with unencrypted HTTP on port 80, then I can see WS solving a
> >>>> problem
> >>>>          that ALPN can't solve.
> >>>>
> >>>>          --Brandon
> >>>>
> >>>>          On 12/02/2014 03:26 PM, Sergio Garcia Murillo wrote:
> >>>>
> >>>>              We control the client and the server, and you are
> >>>> asking me to wait
> >>>>              until what is not in our control is changed.
> >>>> Obviously, not working for me
> >>>>
> >>>>              BTW, I am talking about real life experiences, when
> >>>> WSS works and TURNS
> >>>>              over 443 doesn't.
> >>>>
> >>>>              Best regards
> >>>>              Sergio
> >>>>
> >>>>              On 02/12/2014 20:44, Tirumaleswar Reddy (tireddy)
> >>>> wrote:
> >>>>
> >>>>
> >>>>                  why will it not work when ALPN is used ?
> >>>>
> >>>>                  -Tiru
> >>>>
> >>>>                  *From:*Sergio Garcia Murillo
> >>>>                  [mailto:sergio.garcia.murillo@__gmail.com
> >>>>                  <mailto:sergio.garcia.murillo@gmail.com>] ?
> >>>>
> >>>>                  *Sent:* Wednesday, December 03, 2014 12:52 AM
> >>>>                  *To:* Tirumaleswar Reddy (tireddy)
> >>>>                  *Cc:* Jonathan Lennox; [ACME] Victor Pascual
> >>>> Avila; Simon Perreault;
> >>>>                  tram@ietf.org <mailto:tram@ietf.org>;
> >>>> draft-chenxin-behave-turn-__websocket@tools.ietf.org
> >>>> <mailto:draft-chenxin-behave-turn-websocket@tools.ietf.org>
> >>>>                  *Subject:* RE: [tram] TURN over WebSocket
> >>>>
> >>>>
> >>>>                  El 02/12/2014 20:04, "Tirumaleswar Reddy
> >>>> (tireddy)" <tireddy@cisco.com <mailto:tireddy@cisco.com>
> >>>>                  <mailto:tireddy@cisco.com
> >>>> <mailto:tireddy@cisco.com>>> escribió:
> >>>>                   >
> >>>>                   > From: Simon Perreault
> >>>>                   > [mailto:sperreault@jive.com
> >>>>                  <mailto:sperreault@jive.com>
> >>>>                  <mailto:sperreault@jive.com
> >>>> <mailto:sperreault@jive.com>>]
> >>>>                   > Sent: Tuesday, December 02, 2014 10:19 PM
> >>>>                   >
> >>>>                   > To: Tirumaleswar Reddy (tireddy)
> >>>>                   > Cc: Jonathan Lennox; Sergio Garcia Murillo;
> >>>>                   > Victor
> >>>>                  Pascual Avila;
> >>>> draft-chenxin-behave-turn-__websocket@tools.ietf.org
> >>>> <mailto:draft-chenxin-behave-turn-websocket@tools.ietf.org>
> >>>> <mailto:draft-chenxin-behave-__turn-websocket@tools.ietf.org
> >>>> <mailto:draft-chenxin-behave-turn-websocket@tools.ietf.org>>__;
> >>>>                  tram@ietf.org <mailto:tram@ietf.org>
> >>>>                  <mailto:tram@ietf.org <mailto:tram@ietf.org>>
> >>>>                   > Subject: Re: [tram] TURN over WebSocket
> >>>>                   >
> >>>>                   >
> >>>>                   >
> >>>>                   >
> >>>>                   >
> >>>>                   > On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar
> >>>>                   > Reddy
> >>>>                  (tireddy)
> >>>>                  <tireddy@cisco.com <mailto:tireddy@cisco.com>
> >>>>                  <mailto:tireddy@cisco.com
> >>>> <mailto:tireddy@cisco.com>>> wrote:
> >>>>                   >
> >>>>                   > Transparent proxies like firewalls keep
> >>>>                   > getting
> >>>>                  upgraded frequently
> >>>>                  to handle new applications, threats etc. If
> >>>> firewall has
> >>>>                  a feature to
> >>>>                  block WebRTC traffic then by sending traffic
> >>>> over WebSocket will not
> >>>>                  solve the problem.
> >>>>                   >
> >>>>                   >
> >>>>                   >
> >>>>                   > (As a participant...)
> >>>>                   >
> >>>>                   >
> >>>>                   > This has also been discussed before.
> >>>>                  TURN-over-WebSockets is not a
> >>>>                  way for applications to circumvent policy.
> >>>>                   >
> >>>>                   >
> >>>>                   >
> >>>>                   > The problem is there are networks that are
> >>>>                   > set up so
> >>>>                  that "the web"
> >>>>                  is open, through a transparent proxy. WebRTC is
> >>>> part of "the web".
> >>>>                  Making TURN fit the mould of "the web" is is not
> >>>>                  circumventing policy,
> >>>>                  it's making WebRTC work. You should not need to
> >>>> update your
> >>>>                  proxy/firewall config for WebRTC to just work
> >>>> if "the web" already
> >>>>                  does work.
> >>>>                   >
> >>>>                   >
> >>>>                   >
> >>>>                   > [TR] Okay, so looks like the problem can
> >>>>                   > also be
> >>>>                  solved by running
> >>>>                  TURN over 443 similar to proposals in DPRIVE WG
> >>>> to run DNS over 443.
> >>>>                   >
> >>>>                   >
> >>>>
> >>>>                  Good try! Unlucky enough, doesn't work.
> >>>>
> >>>>                  Best regards
> >>>>                  Sergio
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>      _________________________________________________
> >>>>      tram mailing list
> >>>>      tram@ietf.org <mailto:tram@ietf.org>
> >>>>      https://www.ietf.org/mailman/__listinfo/tram
> >>>>      <https://www.ietf.org/mailman/listinfo/tram>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> > --
> > Brandon Williams; Senior Principal Software Engineer
> > Emerging Products Engineering; Akamai Technologies Inc.
> >
> > _______________________________________________
> > 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


--------------000503040204050609040504-- From nobody Thu Dec 18 06:59:30 2014 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 AA9C01A00FE for ; Thu, 18 Dec 2014 06:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-uslXfWEBx8 for ; Thu, 18 Dec 2014 06:59:14 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 7A82C1A8A4F for ; Thu, 18 Dec 2014 06:59:14 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 95DFA47631; Thu, 18 Dec 2014 14:59:13 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 84CBC4762E; Thu, 18 Dec 2014 14:59:13 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 6999F202D; Thu, 18 Dec 2014 14:59:13 +0000 (GMT) Message-ID: <5492EBC1.8080107@akamai.com> Date: Thu, 18 Dec 2014 09:59:13 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "tram@ietf.org" References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B8E7@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2837B9B5@xmb-rcd-x10.cisco.com> <547E2069.4050307@gmail.com> <547E6022.5030101@akamai.com> <547ED5B3.7070102@gmail.com> <547F1C55.4040208@akamai.com> <547F208E.6000000@gmail.com> <547F32E3.1000708@akamai.com> <20141203213637.2fc801ea@lminiero> <5492AB2A.5050105@gmail.com > In-Reply-To: <5492AB2A.5050105@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/pY4MhFU0aMFwcnPxu-21N8hp6Ic Cc: "draft-chenxin-behave-turn-websocket@tools.ietf.org" Subject: Re: [tram] TURN over WebSocket 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 Dec 2014 14:59:28 -0000 In my opinion, for the working group to adopt a draft that broadens the range of TURN transport options, there should be a solid justification for doing so based on a use case that cannot be satisfied with the transport options that are already defined. I don't think that ease of implementation in a specific context provides a solid enough justification on its own. Although it might improve things for a closed system where both the client and the server are under common control, it potentially makes things harder for those of us who control only one side or the other, increasing the number of transports we must support in order to ensure compatibility. Basically what I'm saying is that I do think a compelling use case that cannot be satisfied by existing RFCs and/or drafts is required in order for the draft to be adopted by the working group. At the moment, I think this should remain a discussion on the list, and I would also encourage you to ask for some presentation time at the in-person meeting in Dallas. --Brandon On 12/18/2014 05:23 AM, Sergio Garcia Murillo wrote: > Sorry for the late reply, busy week.. :) > > Regarding #2 and #3, I agree that it needs to be look further. > > Anyway, as I said in a previous email, it should not be a show stopper > for working on the draft on the TRAM group, even if they are not > clarified and we can state that TURN over WS provides same connectivity > level than TURN over TLS + HTTP CONNECT. > > Also, regarding 1, I have been thinking about it and it is not only > about easing the deployment in some constrained scenarios. It would > provide a much better integration with Web usage than normal TURN. > > For example in our service, we have a couple balanced nginx servers > acting ssl terminator ands reverse proxy for http and ws. So adding > TURNS over WS to our deployment would be kind of trivial and would allow > us to keep all our urls under the same domain. (I think that the extra > delay of having a new intermediary proxy would be neglectable). So we > could have: > > https://www.xxxxx.xx/rest > https://www.xxxxx.xx/html > wss://www.xxxxx.xx/sip > wss://www.xxxxx.xx/turn > > Theres huge is a side benefit for that, as all of them shares same > domain, we can share cookies with authentication tokens and the other > HTTP headers (like Origin) between the different websockets (sip/turn) > and rest apis. Note that we had to add an HTTP REST API to the TURN > server for short time credentials and load balancing and add origin > header to STUN/TURN messages, to be able to do what is natively > supported by websockets. > > Best regards > Sergio > On 11/12/2014 20:46, Justin Uberti wrote: >> So I see 3 arguments being made here: >> 1) WSS allows the app and TURN server to be the same entity. >> 2) TURN/WSS works where TURN/TLS doesn't, because DPI. >> 3) TURN/WS works where TURN/TLS doesn't, because DPI. >> >> #2 seems very hard to believe; both of these things will try to >> establish a TLS connection and then run WS or TURN over top. It's not >> clear to me that DPI will be able to reliably ID TURN packets versus >> TURN/WS packets when they are encrypted. (Clearly if the DPI is able >> to intercept the TLS, it's a different story.) >> #3 implies that HTTPS and WSS doesn't work, so not sure how useful >> that is. >> >> As Brandon says, I agree we need to understand the problem better >> before deciding whether this has value. >> >> >> On Wed, Dec 3, 2014 at 12:36 PM, Lorenzo Miniero > > wrote: >> >> Not to mention the fact that even with plain WS instead of WSS you >> could >> transport TURNS and keep it secure. >> >> Lorenzo >> >> >> >> On Wed, 3 Dec 2014 13:30:21 -0700 >> toadzky > wrote: >> >> > As a developer, I would much prefer to do this kind of thing >> over WSS. >> > Websockets allow the application to control processing on the >> packets, >> > rather than relying on a framework to do. As far as I can tell, >> > nothing really supports ALPN at all. If I wanted to write a proxy in >> > Java that only listened on 80 and 443, to do ALPN, Jersey (or >> > whichever framework I choose) would need to support ALPN and >> allow me >> > to register different handlers for different types. That would be >> > fine if it was a network library (like Netty), but it's an HTTP >> > framework that would be dealing with other TCP protocols. On top of >> > that, the websocket solution can be supported quickly and easily >> with >> > existing frameworks and infrastructure - no waiting for someone else >> > to decide to finally support ALPN. >> > >> > David >> > >> > On Wed, Dec 3, 2014 at 8:57 AM, Brandon Williams < >> > brandon.williams@akamai.com >> > wrote: >> > >> > > The only thing that makes sense to me to explain the problem you >> > > describe is that the proxy is splitting the TLS session so that it >> > > can view the data flow. If such a proxy only supports HTTP (and by >> > > extension Websockets) for the data flow, then it would make sense >> > > that TURNS over 443 does not work. The piece I'm missing though is >> > > how the proxy could be splitting the TLS session in this way >> > > without you knowing, unless the client is accepting a certificate >> > > signed by someone else's CA. Nevertheless, if TLS splitting is >> > > what's happening and the proxy is rejecting data flows that do not >> > > look like HTTP, I can understand how WSS might resolve the problem >> > > under conditions where TURNS with ALPN might not. >> > > >> > > That having been said, if I'm correct about the source of the >> > > problem, I'm conflicted about taking up work intended to make a >> > > proxy like this function for WebRTC. If TLS is being used solely >> > > for the purpose of firewall traversal, then it's OK to split the >> > > session. But what if that isn't the case? There are significant >> > > security implications associated with helping such a system to >> > > function transparently. I personally would rather see my WebRTC >> > > sessions fail than accept decryption by an unknown MITM. >> > > >> > > Of course, it might be the case that something else is happening >> > > here and there is no decryption happening on the proxy, which >> > > returns me to the point that Andrew made ... I think we need to >> > > better understand the nature of the problem in order to decide >> > > whether it makes sense to adopt the draft and add a milestone. >> > > >> > > --Brandon >> > > >> > > >> > > On 12/03/2014 09:39 AM, Sergio Garcia Murillo wrote: >> > > >> > >> Maybe then is me the one I am missing something, can you explain >> > >> how is ALPN meant to solve the problem if TURNS over 443 is >> > >> blocked by the proxy? >> > >> >> > >> Best regards >> > >> Sergio >> > >> On 03/12/2014 15:21, Brandon Williams wrote: >> > >> >> > >>> What am I missing? Why would ALPN require changing the wifi >> > >>> network? I can accept that it may be necessary, but in the >> > >>> absence of someone explaining why the wifi network needs to >> care, >> > >>> it really doesn't make sense to me. >> > >>> >> > >>> --Brandon >> > >>> >> > >>> On 12/03/2014 04:24 AM, Oleg Moskalenko wrote: >> > >>> >> > >>>> That is a good point. A solution must not require changing >> every >> > >>>> wifi network in the world. A "pure" ALPN solution is a great >> > >>>> way to kill the whole WebRTC idea. >> > >>>> >> > >>>> On Wed, Dec 3, 2014 at 1:19 AM, Sergio Garcia Murillo >> > >>>> > >> > >>>> > >> wrote: >> > >>>> >> > >>>> Am I supposed to change every hotel, cafe or airport wifi >> > >>>> in the world in order to make it work? That's what I mean. >> > >>>> >> > >>>> Don't take me wrong, ALPN seems a good solution, as >> good as >> > >>>> ipv6 is for removing NAT, but it is something out my control to >> > >>>> have it deployed worldwide, so I can't rely on it as a >> solution. >> > >>>> From a webrtc point of view we only control the client and the >> > >>>> turn server, >> > >>>> everything in between should be considered hostile. >> > >>>> >> > >>>> Best regards >> > >>>> Sergio >> > >>>> >> > >>>> >> > >>>> On 03/12/2014 1:58, Brandon Williams wrote: >> > >>>> >> > >>>> What part of ALPN is not under your control? If you're >> > >>>> doing WSS, then you've already got TLS in the picture, so ALPN >> > >>>> and WSS >> > >>>> seem to both solve the server-side multiplexing >> problem >> > >>>> from the >> > >>>> original problem statement. What part of the problem >> > >>>> statement does WSS solve that ALPN does not? >> > >>>> >> > >>>> If you're concerned about unencrypted TURN >> multiplexing >> > >>>> with unencrypted HTTP on port 80, then I can see WS solving a >> > >>>> problem >> > >>>> that ALPN can't solve. >> > >>>> >> > >>>> --Brandon >> > >>>> >> > >>>> On 12/02/2014 03:26 PM, Sergio Garcia Murillo wrote: >> > >>>> >> > >>>> We control the client and the server, and you are >> > >>>> asking me to wait >> > >>>> until what is not in our control is changed. >> > >>>> Obviously, not working for me >> > >>>> >> > >>>> BTW, I am talking about real life experiences, >> when >> > >>>> WSS works and TURNS >> > >>>> over 443 doesn't. >> > >>>> >> > >>>> Best regards >> > >>>> Sergio >> > >>>> >> > >>>> On 02/12/2014 20:44, Tirumaleswar Reddy (tireddy) >> > >>>> wrote: >> > >>>> >> > >>>> >> > >>>> why will it not work when ALPN is used ? >> > >>>> >> > >>>> -Tiru >> > >>>> >> > >>>> *From:*Sergio Garcia Murillo >> > >>>> [mailto:sergio.garcia.murillo@ >> __gmail.com >> > >>>> > >] ? >> > >>>> >> > >>>> *Sent:* Wednesday, December 03, 2014 12:52 AM >> > >>>> *To:* Tirumaleswar Reddy (tireddy) >> > >>>> *Cc:* Jonathan Lennox; [ACME] Victor Pascual >> > >>>> Avila; Simon Perreault; >> > >>>> tram@ietf.org > >; >> > >>>> draft-chenxin-behave-turn-__websocket@tools.ietf.org >> >> > >>>> > > >> > >>>> *Subject:* RE: [tram] TURN over WebSocket >> > >>>> >> > >>>> >> > >>>> El 02/12/2014 20:04, "Tirumaleswar Reddy >> > >>>> (tireddy)" >> > >> > >>>> > >> > >>>> >>> >> escribió: >> > >>>> > >> > >>>> > From: Simon Perreault >> > >>>> > [mailto:sperreault@jive.com >> >> > >>>> > > >> > >>>> > >> > >>>> >>] >> > >>>> > Sent: Tuesday, December 02, 2014 10:19 PM >> > >>>> > >> > >>>> > To: Tirumaleswar Reddy (tireddy) >> > >>>> > Cc: Jonathan Lennox; Sergio Garcia Murillo; >> > >>>> > Victor >> > >>>> Pascual Avila; >> > >>>> draft-chenxin-behave-turn-__websocket@tools.ietf.org >> >> > >>>> > > >> > >>>> >> > >> > >>>> > >>__; >> > >>>> tram@ietf.org > > >> > >>>> > >> >> > >>>> > Subject: Re: [tram] TURN over WebSocket >> > >>>> > >> > >>>> > >> > >>>> > >> > >>>> > >> > >>>> > >> > >>>> > On Tue, Dec 2, 2014 at 9:34 AM, >> Tirumaleswar >> > >>>> > Reddy >> > >>>> (tireddy) >> > >>>> > > > >> > >>>> > >> > >>>> >>> wrote: >> > >>>> > >> > >>>> > Transparent proxies like firewalls keep >> > >>>> > getting >> > >>>> upgraded frequently >> > >>>> to handle new applications, threats etc. If >> > >>>> firewall has >> > >>>> a feature to >> > >>>> block WebRTC traffic then by sending traffic >> > >>>> over WebSocket will not >> > >>>> solve the problem. >> > >>>> > >> > >>>> > >> > >>>> > >> > >>>> > (As a participant...) >> > >>>> > >> > >>>> > >> > >>>> > This has also been discussed before. >> > >>>> TURN-over-WebSockets is not a >> > >>>> way for applications to circumvent policy. >> > >>>> > >> > >>>> > >> > >>>> > >> > >>>> > The problem is there are networks that are >> > >>>> > set up so >> > >>>> that "the web" >> > >>>> is open, through a transparent proxy. >> WebRTC is >> > >>>> part of "the web". >> > >>>> Making TURN fit the mould of "the web" is >> is not >> > >>>> circumventing policy, >> > >>>> it's making WebRTC work. You should not >> need to >> > >>>> update your >> > >>>> proxy/firewall config for WebRTC to just work >> > >>>> if "the web" already >> > >>>> does work. >> > >>>> > >> > >>>> > >> > >>>> > >> > >>>> > [TR] Okay, so looks like the problem can >> > >>>> > also be >> > >>>> solved by running >> > >>>> TURN over 443 similar to proposals in >> DPRIVE WG >> > >>>> to run DNS over 443. >> > >>>> > >> > >>>> > >> > >>>> >> > >>>> Good try! Unlucky enough, doesn't work. >> > >>>> >> > >>>> Best regards >> > >>>> Sergio >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> _________________________________________________ >> > >>>> tram mailing list >> > >>>> tram@ietf.org > > >> > >>>> https://www.ietf.org/mailman/__listinfo/tram >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>> >> > >> >> > > -- >> > > Brandon Williams; Senior Principal Software Engineer >> > > Emerging Products Engineering; Akamai Technologies Inc. >> > > >> > > _______________________________________________ >> > > 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; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Thu Dec 18 11:12:23 2014 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 6DE331A6F58 for ; Thu, 18 Dec 2014 11:12:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 TLFpoO-4aSQd for ; Thu, 18 Dec 2014 11:12:19 -0800 (PST) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2477B1A1B57 for ; Thu, 18 Dec 2014 11:12:19 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id z12so1512701lbi.18 for ; Thu, 18 Dec 2014 11:12:17 -0800 (PST) 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:content-type; bh=rD4P2SUbBVhCrghj2L+XHKAaUY9EbRNOZhQvarUiTfI=; b=YDAktqVD8B2uXlM+z1l2Wpy4uNNVYANQ/PNwtMpIS1bQYb6WCoHduj+oH7EYgEjEVO fMHX4C0kEevMEliZy4y+VFZOoPQIWvI8lc3DyvQ4FpF6W1bqkhc1jOPhATURMpnOpeMn c/t1c19pYt4iwGyUjm2qanYM2yH1uYR+EXW1e/nrbRMh0Z7tIjrF71BeGcJUE/wQV2if 7sRP+amq+oYiNrwUMGQ4pmcIHBR2/+Mu891DAaFircQ2gVbxIqiDVEhcNfGnrdOgNR9U 7GrpeqomuVzmtOChi3yJLVy/bmQ2st0h+qEju/YYnIkekUeeIuK3ioo+cAvgy/9z+5EG a+Ag== X-Gm-Message-State: ALoCoQkTLeqIdtFE6OjE/l9M3ajOTmyewDze4gwRGEyCty3gmZHgD6ZN5tHIHbSrrIYMO5Ejbjl6 MIME-Version: 1.0 X-Received: by 10.152.29.129 with SMTP id k1mr3988201lah.10.1418929937479; Thu, 18 Dec 2014 11:12:17 -0800 (PST) Received: by 10.25.84.145 with HTTP; Thu, 18 Dec 2014 11:12:17 -0800 (PST) In-Reply-To: References: Date: Thu, 18 Dec 2014 14:12:17 -0500 Message-ID: From: Simon Perreault To: "tram@ietf.org" Content-Type: multipart/alternative; boundary=089e0160b7dae28f44050a825e9e Archived-At: http://mailarchive.ietf.org/arch/msg/tram/b0PloKDuyz7b8x8PmZu4Du2ylAE Subject: Re: [tram] TURN over WebSocket 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 Dec 2014 19:12:21 -0000 --089e0160b7dae28f44050a825e9e Content-Type: text/plain; charset=UTF-8 Ok here's our recap of the discussion, as chairs: - Nobody disagrees about the technical merit of TURN over WebSockets (ToWS). That is, nobody said it won't work, it will break stuff, or won't actually solve the problem. - There is disagreement about what the problem actually is, and whether we really do need ToWS in the context of WebRTC. - Nevertheless, there is an important number of TRAMsters that appear to be interested in working on ToWS. So, unless somebody makes a compelling argument against enabling that group of interested people to work on ToWS within TRAM, we will propose a new milestone for this work, and adopt draft-chenxin-behave-turn-websocket as WG document. Simon & Gonzalo On Mon, Dec 1, 2014 at 4:10 AM, Victor Pascual Avila < victor.pascual.avila@gmail.com> wrote: > > Hi, > > last year we put together this I-D: > https://tools.ietf.org/html/draft-chenxin-behave-turn-websocket-01 > > We have recently received some emails indicating there's interest in > reviving this work. > > Use case: only traffic on ports 80 and 443 are allowed and the > need/requirement to run both HTTPS and TURN servers on port 443, on > the same IP address. > > Shall we create a new milestone for this? > > Cheers, > -Victor > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --089e0160b7dae28f44050a825e9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ok here's our recap of = the discussion, as chairs:

- Nobody disagrees about the technical merit of= TURN over WebSockets (ToWS). That is, nobody said it won't work, it wi= ll break stuff, or won't actually solve the problem.

- There is disagre= ement about what the problem actually is, and whether we really do need ToW= S in the context of WebRTC.

- Nevertheless, there is an important number of= TRAMsters that appear to be interested in working on ToWS.

So, unless some= body makes a compelling argument against enabling that group of interested = people to work on ToWS within TRAM, we will propose a new milestone for thi= s work, and adopt=C2=A0draft-chenxin-behave-turn-websocket as WG document.<= /div>

= Simon & Gonzalo


On Mon, Dec 1, 2014 at 4:10= AM, Victor Pascual Avila <victor.pascual.avila@gmail.com= > wrote:
Hi,

last year we put together this I-D:
https://tools.ietf.org/html/draft-chenxin-behave-turn= -websocket-01

We have recently received some emails indicating there's interest in reviving this work.

Use case: only traffic on ports 80 and 443 are allowed and the
need/requirement to run both HTTPS and TURN servers on port 443, on
the same IP address.

Shall we create a new milestone for this?

Cheers,
-Victor

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram
--089e0160b7dae28f44050a825e9e-- From nobody Thu Dec 18 11:21:15 2014 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 A5C371A9232 for ; Thu, 18 Dec 2014 11:21:13 -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] 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 iJH-CJnz1akJ for ; Thu, 18 Dec 2014 11:21:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E096C1A9240 for ; Thu, 18 Dec 2014 11:21:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.8.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141218192108.30639.99950.idtracker@ietfa.amsl.com> Date: Thu, 18 Dec 2014 11:21:08 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/tram/cZM-lmY_mU3B6-KBgn6XgOiN4aQ Subject: [tram] Milestones changed for tram WG 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: Thu, 18 Dec 2014 19:21:13 -0000 URL: http://datatracker.ietf.org/wg/tram/charter/ From nobody Thu Dec 18 13:11:49 2014 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 2F4CF1A702E for ; Thu, 18 Dec 2014 13:11:48 -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] 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 bXPt38m9L_QV for ; Thu, 18 Dec 2014 13:11:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C09F1A7D81 for ; Thu, 18 Dec 2014 13:11:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.8.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141218211131.17897.88761.idtracker@ietfa.amsl.com> Date: Thu, 18 Dec 2014 13:11:31 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/tram/8qpFNsoSMM4As31N4x4-E41HXaM Subject: [tram] Milestones changed for tram WG 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: Thu, 18 Dec 2014 21:11:48 -0000 Changed milestone "Send new TURN-over-WebSockets transport mechanism to IESG for publication as Proposed Standard", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/tram/charter/ From nobody Thu Dec 18 18:00:30 2014 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 1578C1A00AE for ; Thu, 18 Dec 2014 18:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 t_fEiy3BppKd for ; Thu, 18 Dec 2014 18:00:27 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E90DD1A9082 for ; Thu, 18 Dec 2014 18:00:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11564; q=dns/txt; s=iport; t=1418954427; x=1420164027; h=from:to:subject:date:message-id:mime-version; bh=8LUwaqJKURt5zIMgnT40FY3fALEtIjqOhGgj/HRl4XU=; b=IKZHSbZxN2p0OxXkcVtuVELA4Egv3v2mV3PmuBJp5Rjc+B4MEbnnwkmF 0DcJwZ3qSAWt2U5xsNW1jD5oHEc7sGIxYLTJRKQTevKo044MvVDPBXZNC L7mp0WoDTsdWioCe6Ci6WRtE8wEVp9QgiBFkEg0llJnUPHoO+rjRTsaL7 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcGAAiGk1StJV2a/2dsb2JhbABbgkNDUlgEgwLAd4IbAQmFcgIcgQUWAQEBAQF9hAwBAQEEAQEBIApBHQEIDgMEAQELHQMCBB8GCxQJCQEEARIIiBADEQ25JpBVDYVPAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSNSoF3FhcKgmkugRMFjgqDPoNujTOFUyKDbG8BgUR+AQEB X-IronPort-AV: E=Sophos;i="5.07,604,1413244800"; d="scan'208,217";a="106787579" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP; 19 Dec 2014 02:00:26 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sBJ20PEI018733 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Dec 2014 02:00:26 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.58]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Thu, 18 Dec 2014 20:00:25 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault , "tram@ietf.org" Thread-Topic: [tram] TURN over WebSocket Thread-Index: AdAbL4uONqgEUX3YTaWhynK8u8UwQQ== Date: Fri, 19 Dec 2014 02:00:24 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A35521BDA@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.32.109] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A35521BDAxmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/lIMCqlB6rEIErNXBm2vulTO_TQw Subject: Re: [tram] TURN over WebSocket 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: Fri, 19 Dec 2014 02:00:29 -0000 --_000_913383AAA69FF945B8F946018B75898A35521BDAxmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgdGhlcmUgaXMgYSBwcm9ibGVtIHdpdGggVFVSTiB0aGVuIEkgZ3Vlc3MgaXQgY291bGQgYWxz byBiZSBhIHByb2JsZW0gd2l0aCBETlMgKEROUy1vdmVyLVRMUy1vdmVyLVRDUCB0byBzb2x2ZSBw cml2YWN5IHByb2JsZW0pIG9yIHNvbWUgb3RoZXIgcHJvdG9jb2wuIFdlIG1heSB3YW50IHRvIGRp c2N1c3MgaG93IHRoaXMgcHJvYmxlbSBpbXBhY3RzIGFueSBwcm90b2NvbCB0aGF0IHBsYW5zIHRv IHVzZSBUTFMgb24gcG9ydCA0NDMsIHdoeSB0aGlzIHByb2JsZW0gY2Fubm90IGJlIGFkZHJlc3Nl ZCBieSBleGlzdGluZyBtZWNoYW5pc21zIGFuZCBzaG91bGQgb3RoZXIgcHJvdG9jb2xzIGFsc28g dXNlIFdlYnNvY2tldHMuDQoNCi1UaXJ1DQoNCkZyb206IHRyYW0gW21haWx0bzp0cmFtLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTaW1vbiBQZXJyZWF1bHQNClNlbnQ6IEZyaWRheSwg RGVjZW1iZXIgMTksIDIwMTQgMTI6NDIgQU0NClRvOiB0cmFtQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW3RyYW1dIFRVUk4gb3ZlciBXZWJTb2NrZXQNCg0KT2sgaGVyZSdzIG91ciByZWNhcCBvZiB0 aGUgZGlzY3Vzc2lvbiwgYXMgY2hhaXJzOg0KDQotIE5vYm9keSBkaXNhZ3JlZXMgYWJvdXQgdGhl IHRlY2huaWNhbCBtZXJpdCBvZiBUVVJOIG92ZXIgV2ViU29ja2V0cyAoVG9XUykuIFRoYXQgaXMs IG5vYm9keSBzYWlkIGl0IHdvbid0IHdvcmssIGl0IHdpbGwgYnJlYWsgc3R1ZmYsIG9yIHdvbid0 IGFjdHVhbGx5IHNvbHZlIHRoZSBwcm9ibGVtLg0KDQotIFRoZXJlIGlzIGRpc2FncmVlbWVudCBh Ym91dCB3aGF0IHRoZSBwcm9ibGVtIGFjdHVhbGx5IGlzLCBhbmQgd2hldGhlciB3ZSByZWFsbHkg ZG8gbmVlZCBUb1dTIGluIHRoZSBjb250ZXh0IG9mIFdlYlJUQy4NCg0KLSBOZXZlcnRoZWxlc3Ms IHRoZXJlIGlzIGFuIGltcG9ydGFudCBudW1iZXIgb2YgVFJBTXN0ZXJzIHRoYXQgYXBwZWFyIHRv IGJlIGludGVyZXN0ZWQgaW4gd29ya2luZyBvbiBUb1dTLg0KDQpTbywgdW5sZXNzIHNvbWVib2R5 IG1ha2VzIGEgY29tcGVsbGluZyBhcmd1bWVudCBhZ2FpbnN0IGVuYWJsaW5nIHRoYXQgZ3JvdXAg b2YgaW50ZXJlc3RlZCBwZW9wbGUgdG8gd29yayBvbiBUb1dTIHdpdGhpbiBUUkFNLCB3ZSB3aWxs IHByb3Bvc2UgYSBuZXcgbWlsZXN0b25lIGZvciB0aGlzIHdvcmssIGFuZCBhZG9wdCBkcmFmdC1j aGVueGluLWJlaGF2ZS10dXJuLXdlYnNvY2tldCBhcyBXRyBkb2N1bWVudC4NCg0KU2ltb24gJiBH b256YWxvDQoNCg0KT24gTW9uLCBEZWMgMSwgMjAxNCBhdCA0OjEwIEFNLCBWaWN0b3IgUGFzY3Vh bCBBdmlsYSA8dmljdG9yLnBhc2N1YWwuYXZpbGFAZ21haWwuY29tPG1haWx0bzp2aWN0b3IucGFz Y3VhbC5hdmlsYUBnbWFpbC5jb20+PiB3cm90ZToNCkhpLA0KDQpsYXN0IHllYXIgd2UgcHV0IHRv Z2V0aGVyIHRoaXMgSS1EOg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNoZW54 aW4tYmVoYXZlLXR1cm4td2Vic29ja2V0LTAxDQoNCldlIGhhdmUgcmVjZW50bHkgcmVjZWl2ZWQg c29tZSBlbWFpbHMgaW5kaWNhdGluZyB0aGVyZSdzIGludGVyZXN0IGluDQpyZXZpdmluZyB0aGlz IHdvcmsuDQoNClVzZSBjYXNlOiBvbmx5IHRyYWZmaWMgb24gcG9ydHMgODAgYW5kIDQ0MyBhcmUg YWxsb3dlZCBhbmQgdGhlDQpuZWVkL3JlcXVpcmVtZW50IHRvIHJ1biBib3RoIEhUVFBTIGFuZCBU VVJOIHNlcnZlcnMgb24gcG9ydCA0NDMsIG9uDQp0aGUgc2FtZSBJUCBhZGRyZXNzLg0KDQpTaGFs bCB3ZSBjcmVhdGUgYSBuZXcgbWlsZXN0b25lIGZvciB0aGlzPw0KDQpDaGVlcnMsDQotVmljdG9y DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp0cmFt IG1haWxpbmcgbGlzdA0KdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0K --_000_913383AAA69FF945B8F946018B75898A35521BDAxmbrcdx10ciscoc_ 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 LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgdGhlcmUgaXMgYSBwcm9ibGVtIHdpdGggVFVSTiB0 aGVuIEkgZ3Vlc3MgaXQgY291bGQgYWxzbyBiZSBhIHByb2JsZW0gd2l0aCBETlMgKEROUy1vdmVy LVRMUy1vdmVyLVRDUCB0byBzb2x2ZSBwcml2YWN5IHByb2JsZW0pIG9yIHNvbWUgb3RoZXIgcHJv dG9jb2wuIFdlDQogbWF5IHdhbnQgdG8gZGlzY3VzcyBob3cgdGhpcyBwcm9ibGVtIGltcGFjdHMg YW55IHByb3RvY29sIHRoYXQgcGxhbnMgdG8gdXNlIFRMUyBvbiBwb3J0IDQ0Mywgd2h5IHRoaXMg cHJvYmxlbSBjYW5ub3QgYmUgYWRkcmVzc2VkIGJ5IGV4aXN0aW5nIG1lY2hhbmlzbXMgYW5kIHNo b3VsZCBvdGhlciBwcm90b2NvbHMgYWxzbyB1c2UgV2Vic29ja2V0cy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1UaXJ1 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHRyYW0gW21haWx0 bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlNpbW9uIFBlcnJl YXVsdDxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIERlY2VtYmVyIDE5LCAyMDE0IDEyOjQyIEFN PGJyPg0KPGI+VG86PC9iPiB0cmFtQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb dHJhbV0gVFVSTiBvdmVyIFdlYlNvY2tldDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+T2sg aGVyZSdzIG91ciByZWNhcCBvZiB0aGUgZGlzY3Vzc2lvbiwgYXMgY2hhaXJzOjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPi0g Tm9ib2R5IGRpc2FncmVlcyBhYm91dCB0aGUgdGVjaG5pY2FsIG1lcml0IG9mIFRVUk4gb3ZlciBX ZWJTb2NrZXRzIChUb1dTKS4gVGhhdCBpcywgbm9ib2R5IHNhaWQgaXQgd29uJ3Qgd29yaywgaXQg d2lsbCBicmVhayBzdHVmZiwgb3Igd29uJ3QgYWN0dWFsbHkgc29sdmUgdGhlIHByb2JsZW0uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij4tIFRoZXJlIGlzIGRpc2FncmVlbWVudCBhYm91dCB3aGF0IHRoZSBwcm9i bGVtIGFjdHVhbGx5IGlzLCBhbmQgd2hldGhlciB3ZSByZWFsbHkgZG8gbmVlZCBUb1dTIGluIHRo ZSBjb250ZXh0IG9mIFdlYlJUQy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPi0gTmV2ZXJ0aGVsZXNzLCB0aGVy ZSBpcyBhbiBpbXBvcnRhbnQgbnVtYmVyIG9mIFRSQU1zdGVycyB0aGF0IGFwcGVhciB0byBiZSBp bnRlcmVzdGVkIGluIHdvcmtpbmcgb24gVG9XUy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlNvLCB1bmxlc3Mg c29tZWJvZHkgbWFrZXMgYSBjb21wZWxsaW5nIGFyZ3VtZW50IGFnYWluc3QgZW5hYmxpbmcgdGhh dCBncm91cCBvZiBpbnRlcmVzdGVkIHBlb3BsZSB0byB3b3JrIG9uIFRvV1Mgd2l0aGluIFRSQU0s IHdlIHdpbGwgcHJvcG9zZSBhIG5ldyBtaWxlc3RvbmUgZm9yIHRoaXMgd29yaywgYW5kIGFkb3B0 Jm5ic3A7ZHJhZnQtY2hlbnhpbi1iZWhhdmUtdHVybi13ZWJzb2NrZXQNCiBhcyBXRyBkb2N1bWVu dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPlNpbW9uICZhbXA7IEdvbnphbG88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBEZWMgMSwgMjAxNCBhdCA0OjEwIEFNLCBWaWN0b3Ig UGFzY3VhbCBBdmlsYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZpY3Rvci5wYXNjdWFsLmF2aWxhQGdt YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZpY3Rvci5wYXNjdWFsLmF2aWxhQGdtYWlsLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPGJy Pg0KPGJyPg0KbGFzdCB5ZWFyIHdlIHB1dCB0b2dldGhlciB0aGlzIEktRDo8YnI+DQo8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hlbnhpbi1iZWhhdmUtdHVybi13 ZWJzb2NrZXQtMDEiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtY2hlbnhpbi1iZWhhdmUtdHVybi13ZWJzb2NrZXQtMDE8L2E+PGJyPg0KPGJyPg0KV2Ug aGF2ZSByZWNlbnRseSByZWNlaXZlZCBzb21lIGVtYWlscyBpbmRpY2F0aW5nIHRoZXJlJ3MgaW50 ZXJlc3QgaW48YnI+DQpyZXZpdmluZyB0aGlzIHdvcmsuPGJyPg0KPGJyPg0KVXNlIGNhc2U6IG9u bHkgdHJhZmZpYyBvbiBwb3J0cyA4MCBhbmQgNDQzIGFyZSBhbGxvd2VkIGFuZCB0aGU8YnI+DQpu ZWVkL3JlcXVpcmVtZW50IHRvIHJ1biBib3RoIEhUVFBTIGFuZCBUVVJOIHNlcnZlcnMgb24gcG9y dCA0NDMsIG9uPGJyPg0KdGhlIHNhbWUgSVAgYWRkcmVzcy48YnI+DQo8YnI+DQpTaGFsbCB3ZSBj cmVhdGUgYSBuZXcgbWlsZXN0b25lIGZvciB0aGlzPzxicj4NCjxicj4NCkNoZWVycyw8YnI+DQot VmljdG9yPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQp0cmFtIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzp0cmFt QGlldGYub3JnIj50cmFtQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_913383AAA69FF945B8F946018B75898A35521BDAxmbrcdx10ciscoc_-- From nobody Tue Dec 23 06:54:08 2014 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 5097A1ACF1A; Tue, 23 Dec 2014 06:54:06 -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] 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 DkZ9qp715JaW; Tue, 23 Dec 2014 06:54:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C681ACEF4; Tue, 23 Dec 2014 06:54:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141223145405.31591.72067.idtracker@ietfa.amsl.com> Date: Tue, 23 Dec 2014 06:54:05 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/bJDJwVdMKUEKTB2ZS_EnAKuTXAU Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-stun-origin-04.txt 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: Tue, 23 Dec 2014 14:54:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TURN Revised and Modernized Working Group of the IETF. Title : An Origin Attribute for the STUN Protocol Authors : Alan Johnston Justin Uberti John Yoakum Kundan Singh Filename : draft-ietf-tram-stun-origin-04.txt Pages : 12 Date : 2014-12-23 Abstract: STUN, or Session Traversal Utilities for NAT, is a protocol used to assist other protocols traverse Network Address Translators or NATs. STUN, and STUN extensions such as TURN, or Traversal Using Relays around NAT, and ICE, Interactive Communications Establishment, have been around for many years but with WebRTC, Web Real-Time Communications, STUN and related extensions are about to see major deployments and implementation due to these protocols being implemented in browsers. This specification defines an ORIGIN attribute for STUN that can be used in similar ways to the HTTP header field of the same name. WebRTC browsers utilizing STUN and TURN would include this attribute which would provide servers with additional information about the STUN and TURN requests they receive. This specification defines the usage of the STUN ORIGIN attribute for web and SIP contexts. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-stun-origin/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tram-stun-origin-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stun-origin-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 23 07:29:29 2014 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 465F41ACF1A for ; Tue, 23 Dec 2014 07:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 MCtEXwBuL2lW for ; Tue, 23 Dec 2014 07:29:26 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 997F71A8F50 for ; Tue, 23 Dec 2014 07:29:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2718; q=dns/txt; s=iport; t=1419348566; x=1420558166; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=4mvDEWCjO4LI8pupibjDVD4BzQ5qtn+bybQXBiZk0ec=; b=Hi2iW+Hda4ClckOdfahAHkv32R1gryDXYorK+Mjy4OBufMYensLCpH4U p/GsbH+qPPj8+K7FWXVxPjMNIa1fd9c9kH0eh3VM+bvYCdPX+09P69QC3 IlkWOZQ9ZVK1londpamxSQ/bseL+eGA+8oTTHRaSFRswfXNY+TQuMmmsj U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkFAFqJmVStJA2J/2dsb2JhbABbgwZSWASDAMEXgieFbgIcexYBAQEBAX2EDAEBAQQjEUMOBAIBCBEEAQEDAgYdAwICAjAUAQYBAQUDAgQTCAGIIw24S5VyAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhjiA4BoJiLoETBY4Ugz+GQTCCNY1cIoNubwGBRH4BAQE X-IronPort-AV: E=Sophos;i="5.07,632,1413244800"; d="scan'208";a="107884306" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-6.cisco.com with ESMTP; 23 Dec 2014 15:29:25 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sBNFTPNd026853 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 23 Dec 2014 15:29:25 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.58]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Tue, 23 Dec 2014 09:29:25 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" Thread-Topic: New Version Notification for draft-reddy-tram-stun-path-data-00.txt Thread-Index: AQHQHsIV3VuulXGCB0OqNizGsEVDB5ydRr7Q Date: Tue, 23 Dec 2014 15:29:25 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A35523A3E@xmb-rcd-x10.cisco.com> References: <20141223150647.4003.56437.idtracker@ietfa.amsl.com> In-Reply-To: <20141223150647.4003.56437.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.53.201] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Qp6kYhPt2Apg8VQQxpEZ8eGfuyE Subject: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 15:29:28 -0000 VGhpcyBkcmFmdCBkZXNjcmliZXMgYSBtZWNoYW5pc20gZm9yIGFuIGVuZHBvaW50IHRvIGRpc2Nv dmVyIHRoZSBwYXRoIGNoYXJhY3RlcmlzdGljcyB1c2luZyBTVFVOLg0KQ29tbWVudHMgYW5kIHN1 Z2dlc3Rpb25zIGFyZSB3ZWxjb21lLg0KDQotVGlydQ0KIA0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAyMywgMjAxNCA4OjM3IFBN DQpUbzogVmFydW4gU2luZ2g7IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk7IERhbiBXaW5n IChkd2luZyk7IFZhcnVuIFNpbmdoOyBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpOyBQYWwg TWFydGluc2VuIChwYWxtYXJ0aSk7IERhbiBXaW5nIChkd2luZyk7IFBhbCBNYXJ0aW5zZW4gKHBh bG1hcnRpKQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1yZWRk eS10cmFtLXN0dW4tcGF0aC1kYXRhLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBk cmFmdC1yZWRkeS10cmFtLXN0dW4tcGF0aC1kYXRhLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1 bGx5IHN1Ym1pdHRlZCBieSBUaXJ1bWFsZXN3YXIgUmVkZHkgYW5kIHBvc3RlZCB0byB0aGUgSUVU RiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtcmVkZHktdHJhbS1zdHVuLXBhdGgtZGF0YQ0K UmV2aXNpb246CTAwDQpUaXRsZToJCURpc2NvdmVyeSBvZiBwYXRoIGNoYXJhY3RlcmlzdGljcyB1 c2luZyBTVFVODQpEb2N1bWVudCBkYXRlOgkyMDE0LTEyLTIzDQpHcm91cDoJCUluZGl2aWR1YWwg U3VibWlzc2lvbg0KUGFnZXM6CQk5DQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcmVkZHktdHJhbS1zdHVuLXBhdGgtZGF0YS0wMC50eHQN ClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1y ZWRkeS10cmFtLXN0dW4tcGF0aC1kYXRhLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXJlZGR5LXRyYW0tc3R1bi1wYXRoLWRhdGEtMDANCg0KDQpBYnN0 cmFjdDoNCiAgIEEgaG9zdCB3aXRoIG11bHRpcGxlIGludGVyZmFjZXMgbmVlZHMgdG8gY2hvb3Nl IHRoZSBiZXN0IGludGVyZmFjZQ0KICAgZm9yIGNvbW11bmljYXRpb24uICBPZnRlbnRpbWVzLCB0 aGlzIGRlY2lzaW9uIGlzIGJhc2VkIG9uIGEgc3RhdGljDQogICBjb25maWd1cmF0aW9uIGFuZCBk b2VzIG5vdCBjb25zaWRlciB0aGUgcGF0aCBjaGFyYWN0ZXJpc3RpY3MsIHdoaWNoDQogICBtYXkg YWZmZWN0IHRoZSB1c2VyIGV4cGVyaWVuY2UuDQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVz IGEgbWVjaGFuaXNtIGZvciBhbiBlbmRwb2ludCB0byBkaXNjb3ZlciB0aGUNCiAgIHBhdGggY2hh cmFjdGVyaXN0aWNzIHVzaW5nIFNlc3Npb24gVHJhdmVyc2FsIFV0aWxpdGllcyBmb3IgTkFUIChT VFVOKQ0KICAgbWVzc2FnZXMuICBUaGUgbWVhc3VyZW1lbnQgaW5mb3JtYXRpb24gY2FuIHRoZW4g YmUgdXNlZCB0byBpbmZsdWVuY2UNCiAgIHRoZSBlbmRwb2ludCdzIEludGVyYWN0aXZlIENvbm5l Y3Rpdml0eSBFc3RhYmxpc2htZW50IChJQ0UpIGNhbmRpZGF0ZQ0KICAgcGFpciBzZWxlY3Rpb24g YWxnb3JpdGhtLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUg dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3Vi bWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxl IGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Tue Dec 23 07:35:38 2014 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 CD5961ACF56 for ; Tue, 23 Dec 2014 07:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 xJZms3ZMxA5A for ; Tue, 23 Dec 2014 07:35:34 -0800 (PST) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 906951ACF54 for ; Tue, 23 Dec 2014 07:35:33 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id pn19so5726682lab.37 for ; Tue, 23 Dec 2014 07:35:32 -0800 (PST) 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=gC53R5o1dZrau+waL3XwwAyeN6uYoiIyZdroRUu/IA0=; b=VLnROiiM814/m3P2MeP0NW3Ej+O1PGzy0PwdT6rvrvEfTqMD/F/1xKXsglPlAdz9qz s00CNaTXhiVgv1kk8F18KwZ0LiMjL2SnaS8Xq+krPBUdXfINV+wmHaKeAQaBSXjFvMpT 5/FSqggayjZKSAD0hb8V6xKALIhZdEUILXnWHvjcnwlUtt7us2cPXvmrUHy7rdcuPMj4 EqdXS6swBQeK0KwmTVmGiPR4CGAAER3wL2g4v7enX2Dkt8urPp31FhvYNEcWgU8alYFg GgGVqUvJzJBSyHwnS8bUqnS6I5z6VM3rd7nWlVb27RTPoDJcVWlGGjVU8ao3cySnAM1m e4JQ== X-Gm-Message-State: ALoCoQm91gRZ2hO1Q1S0lsfLYrzWKGt18nT68bPcxWEf2RFxrsCGIPDKpSakALTkT4Nl5HPI7lBS MIME-Version: 1.0 X-Received: by 10.112.168.164 with SMTP id zx4mr28748286lbb.28.1419348930214; Tue, 23 Dec 2014 07:35:30 -0800 (PST) Received: by 10.25.84.145 with HTTP; Tue, 23 Dec 2014 07:35:30 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A35523A3E@xmb-rcd-x10.cisco.com> References: <20141223150647.4003.56437.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35523A3E@xmb-rcd-x10.cisco.com> Date: Tue, 23 Dec 2014 10:35:30 -0500 Message-ID: From: Simon Perreault To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=001a11c23564cc5dc9050ae3ec08 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/jOCDEGnOMNHX7JYIOQ50-xvsSCE Cc: "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 15:35:37 -0000 --001a11c23564cc5dc9050ae3ec08 Content-Type: text/plain; charset=UTF-8 Cool. One thing caught my eye: To resolve the issue of identical request and response packets in a STUN transaction, this document changes that retransmission behavior for idempotent packets. Is this actually true? I didn't find any such change. Simon On Tue, Dec 23, 2014 at 10:29 AM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > > This draft describes a mechanism for an endpoint to discover the path > characteristics using STUN. > Comments and suggestions are welcome. > > -Tiru > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, December 23, 2014 8:37 PM > To: Varun Singh; Tirumaleswar Reddy (tireddy); Dan Wing (dwing); Varun > Singh; Tirumaleswar Reddy (tireddy); Pal Martinsen (palmarti); Dan Wing > (dwing); Pal Martinsen (palmarti) > Subject: New Version Notification for > draft-reddy-tram-stun-path-data-00.txt > > > A new version of I-D, draft-reddy-tram-stun-path-data-00.txt > has been successfully submitted by Tirumaleswar Reddy and posted to the > IETF repository. > > Name: draft-reddy-tram-stun-path-data > Revision: 00 > Title: Discovery of path characteristics using STUN > Document date: 2014-12-23 > Group: Individual Submission > Pages: 9 > URL: > http://www.ietf.org/internet-drafts/draft-reddy-tram-stun-path-data-00.txt > Status: > https://datatracker.ietf.org/doc/draft-reddy-tram-stun-path-data/ > Htmlized: > http://tools.ietf.org/html/draft-reddy-tram-stun-path-data-00 > > > Abstract: > A host with multiple interfaces needs to choose the best interface > for communication. Oftentimes, this decision is based on a static > configuration and does not consider the path characteristics, which > may affect the user experience. > > This document describes a mechanism for an endpoint to discover the > path characteristics using Session Traversal Utilities for NAT (STUN) > messages. The measurement information can then be used to influence > the endpoint's Interactive Connectivity Establishment (ICE) candidate > pair selection algorithm. > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --001a11c23564cc5dc9050ae3ec08 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Cool.

One thing caught my eye:

   To resolve the issue of
   identical request and response packets in a STUN transaction, this
   document changes that retransmission behavior for idempotent packets.

Is this actually true? I didn't find any su=
ch change.

Simon

On Tue, Dec 23, 2014 at 10:29 AM, Tirumaleswar Reddy (tir= eddy) <tireddy@cisco.com> wrote:
This draft describes a mechanism for an endpoint to discover the path ch= aracteristics using STUN.
Comments and suggestions are welcome.

-Tiru

-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Tuesday, December 23, 2014 8:37 PM
To: Varun Singh; Tirumaleswar Reddy (tireddy); Dan Wing (dwing); Varun Sing= h; Tirumaleswar Reddy (tireddy); Pal Martinsen (palmarti); Dan Wing (dwing)= ; Pal Martinsen (palmarti)
Subject: New Version Notification for draft-reddy-tram-stun-path-data-00.tx= t


A new version of I-D, draft-reddy-tram-stun-path-data-00.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the IET= F repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-reddy-tram-stun-path-da= ta
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Discovery of path characteristics = using STUN
Document date:=C2=A0 2014-12-23
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 9
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/internet-drafts/draft-reddy-tram-stun-path-data-00.txt=
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datat= racker.ietf.org/doc/draft-reddy-tram-stun-path-data/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/= html/draft-reddy-tram-stun-path-data-00


Abstract:
=C2=A0 =C2=A0A host with multiple interfaces needs to choose the best inter= face
=C2=A0 =C2=A0for communication.=C2=A0 Oftentimes, this decision is based on= a static
=C2=A0 =C2=A0configuration and does not consider the path characteristics, = which
=C2=A0 =C2=A0may affect the user experience.

=C2=A0 =C2=A0This document describes a mechanism for an endpoint to discove= r the
=C2=A0 =C2=A0path characteristics using Session Traversal Utilities for NAT= (STUN)
=C2=A0 =C2=A0messages.=C2=A0 The measurement information can then be used t= o influence
=C2=A0 =C2=A0the endpoint's Interactive Connectivity Establishment (ICE= ) candidate
=C2=A0 =C2=A0pair selection algorithm.




Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram
--001a11c23564cc5dc9050ae3ec08-- From nobody Tue Dec 23 07:58:21 2014 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 C08931ACF88 for ; Tue, 23 Dec 2014 07:58:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.831 X-Spam-Level: X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, 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 i4goBjYm8qlm for ; Tue, 23 Dec 2014 07:58:14 -0800 (PST) Received: from server209.appriver.com (server209c.appriver.com [8.31.233.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8ADC1ACF91 for ; Tue, 23 Dec 2014 07:58:08 -0800 (PST) X-Note-AR-ScanTimeLocal: 12/23/2014 10:58:06 AM X-Policy: vidyo.com - vidyo.com X-Policy: vidyo.com - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: SecureTide Build: 11/21/2014 10:58:18 PM UTC X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-196/SG:2 12/23/2014 10:57:11 AM X-GBUdb-Analysis: 0, 67.231.149.202, Ugly c=0.675238 p=-0.700428 Source Normal X-Signature-Violations: 0-0-0-3622-c X-Note-419: 15.6815 ms. Fail:0 Chk:1328 of 1328 total X-Note: SCH-CT/SI:0-1328/SG:1 12/23/2014 10:57:51 AM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL->UNITED STATES-> X-Note-Sending-IP: 67.231.149.202 X-Note-Reverse-DNS: mx0a-00198e01.pphosted.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G251 G252 G253 G254 G258 G259 G371 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [67.231.149.202] (HELO mx0a-00198e01.pphosted.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTP id 180890067; Tue, 23 Dec 2014 10:58:06 -0500 Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.14.7/8.14.7) with SMTP id sBNFuDBr016456; Tue, 23 Dec 2014 10:58:06 -0500 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 1rdthes40n-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 23 Dec 2014 10:58:06 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Tue, 23 Dec 2014 09:58:05 -0600 From: Jonathan Lennox To: "Tirumaleswar Reddy (tireddy)" Thread-Topic: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt Thread-Index: AQHQHsIV3VuulXGCB0OqNizGsEVDB5ydRr7QgAByywA= Date: Tue, 23 Dec 2014 15:58:05 +0000 Message-ID: <1A180643-8AEA-4258-ACFE-9E46B5F0F969@vidyo.com> References: <20141223150647.4003.56437.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35523A3E@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A35523A3E@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2014-12-23_05:2014-12-23,2014-12-23,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1412230159 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ifQ6WpQsWgv4w5kelBrYHO0uQ4c Cc: "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 15:58:20 -0000 On Dec 23, 2014, at 10:29 AM, Tirumaleswar Reddy (tireddy) wrote: > This draft describes a mechanism for an endpoint to discover the path cha= racteristics using STUN. > Comments and suggestions are welcome. One other path characteristic that it would be useful to be able to learn i= s Path MTU. The natural way to do this would be to support the ICE attribute PADDING (0= x0026) (from RFC 5780) in the ICE connectivity/consent STUN usages, though = for backward compatibility we may need to resurrect the optional flavor of = PADDING (0x8026) from draft-ietf-behave-nat-behavior-discovery-00. This doesn=92t necessarily need to be specified in this same draft, of cour= se, but it seems related.= From nobody Tue Dec 23 08:11:50 2014 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 464D31A90FC for ; Tue, 23 Dec 2014 08:11:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 6mnkmOhQJJLU for ; Tue, 23 Dec 2014 08:11:31 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EA361A90FD for ; Tue, 23 Dec 2014 08:11:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1011; q=dns/txt; s=iport; t=1419351072; x=1420560672; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=qU4v2DFG8r57rM522fnt80V8k91CVrwV4Lnn/vwPs0A=; b=Wop3dYV6ciTqA09Lg/DZm0jizBms8rkgeOmIBqsASWjEVYt3ZMGsO1aM g2FCIRjeVCRucy0JvhnZSytSUJgAOzxu1Rho67SGcOP32UTeMw5FZ/uNL iD5w3VSed7IjNN7HsFnYiE+3muDtrdJ6mB8hIeBI2UXMcaoGiQWqZE3pR M=; X-IronPort-AV: E=Sophos;i="5.07,632,1413244800"; d="scan'208";a="382221568" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-6.cisco.com with ESMTP; 23 Dec 2014 16:11:12 +0000 Received: from [10.24.100.77] ([10.24.100.77]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id sBNGB9PT003683 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Dec 2014 16:11:11 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: <1A180643-8AEA-4258-ACFE-9E46B5F0F969@vidyo.com> Date: Tue, 23 Dec 2014 08:11:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <868A4DD6-060C-4FBD-A114-F794A4B34C00@cisco.com> References: <20141223150647.4003.56437.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35523A3E@xmb-rcd-x10.cisco.com> <1A180643-8AEA-4258-ACFE-9E46B5F0F969@vidyo.com> To: Jonathan Lennox X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tram/TKRdl0NMIED-PJy9rs6BTkJI_TM Cc: "tram@ietf.org" , Tirumaleswar Reddy Subject: Re: [tram] New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 16:11:42 -0000 On Dec 23, 2014, at 7:58 AM, Jonathan Lennox wrote: >=20 > On Dec 23, 2014, at 10:29 AM, Tirumaleswar Reddy (tireddy) = wrote: >=20 >> This draft describes a mechanism for an endpoint to discover the path = characteristics using STUN. >> Comments and suggestions are welcome. >=20 > One other path characteristic that it would be useful to be able to = learn is Path MTU. >=20 > The natural way to do this would be to support the ICE attribute = PADDING (0x0026) (from RFC 5780) in the ICE connectivity/consent STUN = usages, though for backward compatibility we may need to resurrect the = optional flavor of PADDING (0x8026) from = draft-ietf-behave-nat-behavior-discovery-00. >=20 > This doesn=92t necessarily need to be specified in this same draft, of = course, but it seems related. Yes, we should determine the path's MTU. Marc wrote = http://tools.ietf.org/html/draft-petithuguenin-behave-stun-pmtud but it = expired in 2009. -d From nobody Tue Dec 23 08:13:33 2014 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 8D96B1A911B for ; Tue, 23 Dec 2014 08:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.21 X-Spam-Level: X-Spam-Status: No, score=-14.21 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, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 raNQY6xQG4aQ for ; Tue, 23 Dec 2014 08:13:27 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19A3E1A90FE for ; Tue, 23 Dec 2014 08:13:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8914; q=dns/txt; s=iport; t=1419351184; x=1420560784; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=vtaHFqFuer87HGDhnf2EM5zMRUeU/tjLOx3fjQ1kxFA=; b=WoVOloDzzg7A6Yqh0GkFcyhqCzmXOBcBhxlTRvksoeiogdV98cKkmmwO vx3SFMTfF+ozFY+hopKSviLHGUOC0CtyE1OQfm0rf/YiC4AHi5DWz8sGa cqCME304JaqRBchoav6FILIOAdeg3HTF384UbY1iBU7uV07890tyKdZ9z M=; X-IronPort-AV: E=Sophos;i="5.07,632,1413244800"; d="scan'208,217";a="379090043" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-1.cisco.com with ESMTP; 23 Dec 2014 16:13:03 +0000 Received: from [10.24.100.77] ([10.24.100.77]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sBNGD1OK003678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Dec 2014 16:13:02 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_E2A7247D-D7D4-414B-B922-B1DFBC5A8F4F" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: Date: Tue, 23 Dec 2014 08:13:01 -0800 Message-Id: References: <20141223150647.4003.56437.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35523A3E@xmb-rcd-x10.cisco.com> To: Simon Perreault X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tram/yzN5ia4mOR8ftegFcCNd8rfgG_c Cc: "tram@ietf.org" , Tirumaleswar Reddy Subject: Re: [tram] New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 16:13:31 -0000 --Apple-Mail=_E2A7247D-D7D4-414B-B922-B1DFBC5A8F4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 23, 2014, at 7:35 AM, Simon Perreault = wrote: > Cool. >=20 > One thing caught my eye: >=20 > To resolve the issue of > identical request and response packets in a STUN transaction, this > document changes that retransmission behavior for idempotent = packets. >=20 > Is this actually true? I didn't find any such change. I agree it is not well described or separated from the rest of the text, = but what we want to do is described in 3.0: If a client wishes to determine the path characteristics, it inserts the PATH-CHARACTERISTIC attribute in a STUN request. In the PATH- CHARACTERISTIC attribute client sends the number of times the STUN request is retransmitted with the same Transaction ID. =20 -d >=20 > Simon >=20 > On Tue, Dec 23, 2014 at 10:29 AM, Tirumaleswar Reddy (tireddy) = wrote: > This draft describes a mechanism for an endpoint to discover the path = characteristics using STUN. > Comments and suggestions are welcome. >=20 > -Tiru >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, December 23, 2014 8:37 PM > To: Varun Singh; Tirumaleswar Reddy (tireddy); Dan Wing (dwing); Varun = Singh; Tirumaleswar Reddy (tireddy); Pal Martinsen (palmarti); Dan Wing = (dwing); Pal Martinsen (palmarti) > Subject: New Version Notification for = draft-reddy-tram-stun-path-data-00.txt >=20 >=20 > A new version of I-D, draft-reddy-tram-stun-path-data-00.txt > has been successfully submitted by Tirumaleswar Reddy and posted to = the IETF repository. >=20 > Name: draft-reddy-tram-stun-path-data > Revision: 00 > Title: Discovery of path characteristics using STUN > Document date: 2014-12-23 > Group: Individual Submission > Pages: 9 > URL: = http://www.ietf.org/internet-drafts/draft-reddy-tram-stun-path-data-00.txt= > Status: = https://datatracker.ietf.org/doc/draft-reddy-tram-stun-path-data/ > Htmlized: = http://tools.ietf.org/html/draft-reddy-tram-stun-path-data-00 >=20 >=20 > Abstract: > A host with multiple interfaces needs to choose the best interface > for communication. Oftentimes, this decision is based on a static > configuration and does not consider the path characteristics, which > may affect the user experience. >=20 > This document describes a mechanism for an endpoint to discover the > path characteristics using Session Traversal Utilities for NAT = (STUN) > messages. The measurement information can then be used to = influence > the endpoint's Interactive Connectivity Establishment (ICE) = candidate > pair selection algorithm. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > 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 --Apple-Mail=_E2A7247D-D7D4-414B-B922-B1DFBC5A8F4F Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Dec 23, 2014, at 7:35 AM, Simon Perreault <sperreault@jive.com> wrote:

Cool.

One thing caught my eye:

   To resolve the issue of
   identical request and response packets in a STUN transaction, this
   document changes that retransmission behavior for idempotent packets.

Is this actually true? I didn't find any such change.

I agree it is not well described or separated from the rest of the text, but what we want to do is described in 3.0:

   If a client wishes to determine the path characteristics, it inserts
   the PATH-CHARACTERISTIC attribute in a STUN request.  In the PATH-
   CHARACTERISTIC attribute client sends the number of times the STUN
   request is retransmitted with the same Transaction ID.

-d


Simon

On Tue, Dec 23, 2014 at 10:29 AM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:
This draft describes a mechanism for an endpoint to discover the path characteristics using STUN.
Comments and suggestions are welcome.

-Tiru

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Tuesday, December 23, 2014 8:37 PM
To: Varun Singh; Tirumaleswar Reddy (tireddy); Dan Wing (dwing); Varun Singh; Tirumaleswar Reddy (tireddy); Pal Martinsen (palmarti); Dan Wing (dwing); Pal Martinsen (palmarti)
Subject: New Version Notification for draft-reddy-tram-stun-path-data-00.txt


A new version of I-D, draft-reddy-tram-stun-path-data-00.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the IETF repository.

Name:           draft-reddy-tram-stun-path-data
Revision:       00
Title:          Discovery of path characteristics using STUN
Document date:  2014-12-23
Group:          Individual Submission
Pages:          9
URL:            http://www.ietf.org/internet-drafts/draft-reddy-tram-stun-path-data-00.txt
Status:         https://datatracker.ietf.org/doc/draft-reddy-tram-stun-path-data/
Htmlized:       http://tools.ietf.org/html/draft-reddy-tram-stun-path-data-00


Abstract:
   A host with multiple interfaces needs to choose the best interface
   for communication.  Oftentimes, this decision is based on a static
   configuration and does not consider the path characteristics, which
   may affect the user experience.

   This document describes a mechanism for an endpoint to discover the
   path characteristics using Session Traversal Utilities for NAT (STUN)
   messages.  The measurement information can then be used to influence
   the endpoint's Interactive Connectivity Establishment (ICE) candidate
   pair selection algorithm.




Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
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

--Apple-Mail=_E2A7247D-D7D4-414B-B922-B1DFBC5A8F4F-- From nobody Tue Dec 23 09:55:28 2014 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 C677B1A1A75 for ; Tue, 23 Dec 2014 09:55:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 sRgfAHnuFhzH for ; Tue, 23 Dec 2014 09:55:24 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DF611A1A66 for ; Tue, 23 Dec 2014 09:55:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17726; q=dns/txt; s=iport; t=1419357324; x=1420566924; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nbFU91BYmhnGxUO0Bxjh4a5KelvQ5BtEQP7Dx+Npnf0=; b=GDmS7TP6AIVVulCqvbe+wKv2wGoX9MuCAi/MjVyII87f0nwsSKPDTWvT pXSrO3RPlB3UbvVm9x42Nqe2F0fRGDWmaIshhXI/CZTYP7kojUSzC/rZ2 NNpgmi3Q5OCLQYpMTN+PMiSlAYLvQTHbpCWTgmyCtmkEff9mPuZrKCuug Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0FAFmrmVStJV2T/2dsb2JhbABbgkNDUlgEgwDBGDyBXwELhW4CHH0WAQEBAQF9hAwBAQEEAQEBIApBCQIMBAIBCA4DBAEBCx0DAgICJQsUCAEIAgQOBQgBiCMNuEeVewEBAQEBAQEBAQEBAQEBAQEBAQEBARePQQ8eBAYBBgOCXy6BEwWMPYFXgz+GQTCCNY1cIoIygTxvAYFEfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,633,1413244800"; d="scan'208,217";a="379117510" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-1.cisco.com with ESMTP; 23 Dec 2014 17:55:23 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id sBNHtNbE011797 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Dec 2014 17:55:23 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.58]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Tue, 23 Dec 2014 11:55:23 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault Thread-Topic: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt Thread-Index: AQHQHsIV3VuulXGCB0OqNizGsEVDB5ydRr7QgABsfQD//8HYkA== Date: Tue, 23 Dec 2014 17:55:22 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A35523C04@xmb-rcd-x10.cisco.com> References: <20141223150647.4003.56437.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35523A3E@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.53.201] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A35523C04xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/_x9x5oZTe0FeLU9jADyx0v--n_Q Cc: "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 17:55:27 -0000 --_000_913383AAA69FF945B8F946018B75898A35523C04xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogU2ltb24gUGVycmVhdWx0IFttYWlsdG86c3BlcnJlYXVsdEBqaXZlLmNvbV0NClNlbnQ6 IFR1ZXNkYXksIERlY2VtYmVyIDIzLCAyMDE0IDk6MDYgUE0NClRvOiBUaXJ1bWFsZXN3YXIgUmVk ZHkgKHRpcmVkZHkpDQpDYzogdHJhbUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt0cmFtXSBGVzog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1yZWRkeS10cmFtLXN0dW4tcGF0aC1k YXRhLTAwLnR4dA0KDQpDb29sLg0KDQpPbmUgdGhpbmcgY2F1Z2h0IG15IGV5ZToNCg0KDQogICBU byByZXNvbHZlIHRoZSBpc3N1ZSBvZg0KDQogICBpZGVudGljYWwgcmVxdWVzdCBhbmQgcmVzcG9u c2UgcGFja2V0cyBpbiBhIFNUVU4gdHJhbnNhY3Rpb24sIHRoaXMNCg0KICAgZG9jdW1lbnQgY2hh bmdlcyB0aGF0IHJldHJhbnNtaXNzaW9uIGJlaGF2aW9yIGZvciBpZGVtcG90ZW50IHBhY2tldHMu DQoNCg0KSXMgdGhpcyBhY3R1YWxseSB0cnVlPyBJIGRpZG4ndCBmaW5kIGFueSBzdWNoIGNoYW5n ZS4NCg0KSXQgaXMgZXhwbGFpbmVkIGluIHNlY3Rpb24gMy4xDQoNCjxzbmlwPg0KICAgVGhpcyBz cGVjaWZpY2F0aW9uIHVwZGF0ZXMgb25lIHRoZSBTVFVOIG1lc3NhZ2Ugc3RydWN0dXJpbmcgcnVs ZXMNCiAgIGV4cGxhaW5lZCBpbiBTZWN0aW9uIDYgb2YgW1JGQzUzODldIHRoYXQgcmVzZW5kcyBv ZiB0aGUgc2FtZSByZXF1ZXN0DQogICByZXVzZSB0aGUgc2FtZSB0cmFuc2FjdGlvbiBJRCBhbmQg YXJlIGJpdC13aXNlIGlkZW50aWNhbCB0byB0aGUNCiAgIHByZXZpb3VzIHJlcXVlc3QuICBUaGUg UmVUcmFuc0NudCBpbiB0aGUgUEFUSC1DSEFSQUNURVJJU1RJQw0KICAgYXR0cmlidXRlIHdpbGwg YmUgaW5jcmVtZW50ZWQgYnkgMSBmb3IgZXZlcnkgcmUtdHJhbnNtaXNzaW9uIGFuZCB0aGUNCiAg IHJlLXRyYW5zbWl0dGVkIFNUVU4gcmVxdWVzdCBNVVNUIGJlIGJpdC13aXNlIGlkZW50aWNhbCB0 byB0aGUNCiAgIHByZXZpb3VzIHJlcXVlc3QgZXhjZXB0IGZvciB0aGUgUmVUcmFuc0NudCB2YWx1 ZS4NCjwvc25pcD4NCg0KLVRpcnUNCg0KU2ltb24NCg0KT24gVHVlLCBEZWMgMjMsIDIwMTQgYXQg MTA6MjkgQU0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgPHRpcmVkZHlAY2lzY28uY29t PG1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbT4+IHdyb3RlOg0KVGhpcyBkcmFmdCBkZXNjcmliZXMg YSBtZWNoYW5pc20gZm9yIGFuIGVuZHBvaW50IHRvIGRpc2NvdmVyIHRoZSBwYXRoIGNoYXJhY3Rl cmlzdGljcyB1c2luZyBTVFVOLg0KQ29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21l Lg0KDQotVGlydQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IFttYWlsdG86 aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+ XQ0KU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMjMsIDIwMTQgODozNyBQTQ0KVG86IFZhcnVuIFNp bmdoOyBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpOyBEYW4gV2luZyAoZHdpbmcpOyBWYXJ1 biBTaW5naDsgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsgUGFsIE1hcnRpbnNlbiAocGFs bWFydGkpOyBEYW4gV2luZyAoZHdpbmcpOyBQYWwgTWFydGluc2VuIChwYWxtYXJ0aSkNClN1Ympl Y3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcmVkZHktdHJhbS1zdHVuLXBh dGgtZGF0YS0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtcmVkZHktdHJh bS1zdHVuLXBhdGgtZGF0YS0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg YnkgVGlydW1hbGVzd2FyIFJlZGR5IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4N Cg0KTmFtZTogICAgICAgICAgIGRyYWZ0LXJlZGR5LXRyYW0tc3R1bi1wYXRoLWRhdGENClJldmlz aW9uOiAgICAgICAwMA0KVGl0bGU6ICAgICAgICAgIERpc2NvdmVyeSBvZiBwYXRoIGNoYXJhY3Rl cmlzdGljcyB1c2luZyBTVFVODQpEb2N1bWVudCBkYXRlOiAgMjAxNC0xMi0yMw0KR3JvdXA6ICAg ICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6ICAgICAgICAgIDkNClVSTDogICAg ICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1yZWRkeS10 cmFtLXN0dW4tcGF0aC1kYXRhLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJlZGR5LXRyYW0tc3R1bi1wYXRoLWRhdGEvDQpIdG1s aXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmVkZHktdHJhbS1z dHVuLXBhdGgtZGF0YS0wMA0KDQoNCkFic3RyYWN0Og0KICAgQSBob3N0IHdpdGggbXVsdGlwbGUg aW50ZXJmYWNlcyBuZWVkcyB0byBjaG9vc2UgdGhlIGJlc3QgaW50ZXJmYWNlDQogICBmb3IgY29t bXVuaWNhdGlvbi4gIE9mdGVudGltZXMsIHRoaXMgZGVjaXNpb24gaXMgYmFzZWQgb24gYSBzdGF0 aWMNCiAgIGNvbmZpZ3VyYXRpb24gYW5kIGRvZXMgbm90IGNvbnNpZGVyIHRoZSBwYXRoIGNoYXJh Y3RlcmlzdGljcywgd2hpY2gNCiAgIG1heSBhZmZlY3QgdGhlIHVzZXIgZXhwZXJpZW5jZS4NCg0K ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBtZWNoYW5pc20gZm9yIGFuIGVuZHBvaW50IHRv IGRpc2NvdmVyIHRoZQ0KICAgcGF0aCBjaGFyYWN0ZXJpc3RpY3MgdXNpbmcgU2Vzc2lvbiBUcmF2 ZXJzYWwgVXRpbGl0aWVzIGZvciBOQVQgKFNUVU4pDQogICBtZXNzYWdlcy4gIFRoZSBtZWFzdXJl bWVudCBpbmZvcm1hdGlvbiBjYW4gdGhlbiBiZSB1c2VkIHRvIGluZmx1ZW5jZQ0KICAgdGhlIGVu ZHBvaW50J3MgSW50ZXJhY3RpdmUgQ29ubmVjdGl2aXR5IEVzdGFibGlzaG1lbnQgKElDRSkgY2Fu ZGlkYXRlDQogICBwYWlyIHNlbGVjdGlvbiBhbGdvcml0aG0uDQoNCg0KDQoNClBsZWFzZSBub3Rl IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1 Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0KDQpUaGUgSUVURiBT ZWNyZXRhcmlhdA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KdHJhbSBtYWlsaW5nIGxpc3QNCnRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg== --_000_913383AAA69FF945B8F946018B75898A35523C04xmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7 DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBTaW1vbiBQZXJyZWF1bHQgW21haWx0bzpzcGVycmVhdWx0QGppdmUuY29t XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIERlY2VtYmVyIDIzLCAyMDE0IDk6MDYgUE08 YnI+DQo8Yj5Ubzo8L2I+IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk8YnI+DQo8Yj5DYzo8 L2I+IHRyYW1AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0cmFtXSBGVzogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1yZWRkeS10cmFtLXN0dW4tcGF0aC1kYXRh LTAwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Db29sLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T25lIHRoaW5nIGNhdWdodCBteSBleWU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyBUbyByZXNvbHZlIHRoZSBpc3N1ZSBvZjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 IGlkZW50aWNhbCByZXF1ZXN0IGFuZCByZXNwb25zZSBwYWNrZXRzIGluIGEgU1RVTiB0cmFuc2Fj dGlvbiwgdGhpczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGRvY3VtZW50IGNoYW5nZXMg dGhhdCByZXRyYW5zbWlzc2lvbiBiZWhhdmlvciBmb3IgaWRlbXBvdGVudCBwYWNrZXRzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JcyB0aGlzIGFjdHVhbGx5IHRydWU/IEkgZGlkbid0IGZpbmQgYW55IHN1Y2ggY2hh bmdlLjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkl0IGlzIGV4cGxhaW5l ZCBpbiBzZWN0aW9uIDMuMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmx0O3NuaXAmZ3Q7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBUaGlzIHNw ZWNpZmljYXRpb24gdXBkYXRlcyBvbmUgdGhlIFNUVU4gbWVzc2FnZSBzdHJ1Y3R1cmluZyBydWxl czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsgZXhwbGFpbmVkIGluIFNlY3Rpb24gNiBvZiBbUkZDNTM4OV0gdGhhdCByZXNl bmRzIG9mIHRoZSBzYW1lIHJlcXVlc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHJldXNlIHRoZSBzYW1lIHRyYW5zYWN0 aW9uIElEIGFuZCBhcmUgYml0LXdpc2UgaWRlbnRpY2FsIHRvIHRoZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgcHJldmlv dXMgcmVxdWVzdC4mbmJzcDsgVGhlIFJlVHJhbnNDbnQgaW4gdGhlIFBBVEgtQ0hBUkFDVEVSSVNU SUM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7IGF0dHJpYnV0ZSB3aWxsIGJlIGluY3JlbWVudGVkIGJ5IDEgZm9yIGV2ZXJ5 IHJlLXRyYW5zbWlzc2lvbiBhbmQgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyByZS10cmFuc21pdHRlZCBTVFVOIHJl cXVlc3QgTVVTVCBiZSBiaXQtd2lzZSBpZGVudGljYWwgdG8gdGhlPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBwcmV2aW91 cyByZXF1ZXN0IGV4Y2VwdCBmb3IgdGhlIFJlVHJhbnNDbnQgdmFsdWUuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZsdDsvc25pcCZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPi1UaXJ1PC9zcGFuPjxicj4NCjxicj4NClNpbW9uPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgRGVjIDIzLCAyMDE0 IGF0IDEwOjI5IEFNLCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpICZsdDs8YSBocmVmPSJt YWlsdG86dGlyZWRkeUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj50aXJlZGR5QGNpc2NvLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhp cyBkcmFmdCBkZXNjcmliZXMgYSBtZWNoYW5pc20gZm9yIGFuIGVuZHBvaW50IHRvIGRpc2NvdmVy IHRoZSBwYXRoIGNoYXJhY3RlcmlzdGljcyB1c2luZyBTVFVOLjxicj4NCkNvbW1lbnRzIGFuZCBz dWdnZXN0aW9ucyBhcmUgd2VsY29tZS48YnI+DQo8YnI+DQotVGlydTxicj4NCjxicj4NCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogPGEgaHJlZj0ibWFpbHRvOmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiBbbWFpbHRvOjxh IGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZzwvYT5dPGJyPg0KU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMjMsIDIwMTQgODozNyBQ TTxicj4NClRvOiBWYXJ1biBTaW5naDsgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsgRGFu IFdpbmcgKGR3aW5nKTsgVmFydW4gU2luZ2g7IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk7 IFBhbCBNYXJ0aW5zZW4gKHBhbG1hcnRpKTsgRGFuIFdpbmcgKGR3aW5nKTsgUGFsIE1hcnRpbnNl biAocGFsbWFydGkpPGJyPg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1yZWRkeS10cmFtLXN0dW4tcGF0aC1kYXRhLTAwLnR4dDxicj4NCjxicj4NCjxicj4NCkEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1yZWRkeS10cmFtLXN0dW4tcGF0aC1kYXRhLTAwLnR4 dDxicj4NCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVGlydW1hbGVzd2FyIFJl ZGR5IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpOYW1lOiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZHJhZnQtcmVkZHktdHJhbS1z dHVuLXBhdGgtZGF0YTxicj4NClJldmlzaW9uOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzAw PGJyPg0KVGl0bGU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBEaXNjb3Zlcnkg b2YgcGF0aCBjaGFyYWN0ZXJpc3RpY3MgdXNpbmcgU1RVTjxicj4NCkRvY3VtZW50IGRhdGU6Jm5i c3A7IDIwMTQtMTItMjM8YnI+DQpHcm91cDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IEluZGl2aWR1YWwgU3VibWlzc2lvbjxicj4NClBhZ2VzOiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgOTxicj4NClVSTDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1yZWRkeS10cmFtLXN0dW4tcGF0aC1kYXRhLTAwLnR4dCIgdGFyZ2V0PSJfYmxhbmsiPg0K aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcmVkZHktdHJhbS1zdHVu LXBhdGgtZGF0YS0wMC50eHQ8L2E+PGJyPg0KU3RhdHVzOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1yZWRkeS10cmFtLXN0dW4tcGF0aC1kYXRhLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJlZGR5LXRyYW0tc3R1bi1wYXRoLWRhdGEvPC9h Pjxicj4NCkh0bWxpemVkOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJlZGR5LXRyYW0tc3R1bi1wYXRoLWRhdGEtMDAi IHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yZWRkeS10 cmFtLXN0dW4tcGF0aC1kYXRhLTAwPC9hPjxicj4NCjxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4N CiZuYnNwOyAmbmJzcDtBIGhvc3Qgd2l0aCBtdWx0aXBsZSBpbnRlcmZhY2VzIG5lZWRzIHRvIGNo b29zZSB0aGUgYmVzdCBpbnRlcmZhY2U8YnI+DQombmJzcDsgJm5ic3A7Zm9yIGNvbW11bmljYXRp b24uJm5ic3A7IE9mdGVudGltZXMsIHRoaXMgZGVjaXNpb24gaXMgYmFzZWQgb24gYSBzdGF0aWM8 YnI+DQombmJzcDsgJm5ic3A7Y29uZmlndXJhdGlvbiBhbmQgZG9lcyBub3QgY29uc2lkZXIgdGhl IHBhdGggY2hhcmFjdGVyaXN0aWNzLCB3aGljaDxicj4NCiZuYnNwOyAmbmJzcDttYXkgYWZmZWN0 IHRoZSB1c2VyIGV4cGVyaWVuY2UuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1l bnQgZGVzY3JpYmVzIGEgbWVjaGFuaXNtIGZvciBhbiBlbmRwb2ludCB0byBkaXNjb3ZlciB0aGU8 YnI+DQombmJzcDsgJm5ic3A7cGF0aCBjaGFyYWN0ZXJpc3RpY3MgdXNpbmcgU2Vzc2lvbiBUcmF2 ZXJzYWwgVXRpbGl0aWVzIGZvciBOQVQgKFNUVU4pPGJyPg0KJm5ic3A7ICZuYnNwO21lc3NhZ2Vz LiZuYnNwOyBUaGUgbWVhc3VyZW1lbnQgaW5mb3JtYXRpb24gY2FuIHRoZW4gYmUgdXNlZCB0byBp bmZsdWVuY2U8YnI+DQombmJzcDsgJm5ic3A7dGhlIGVuZHBvaW50J3MgSW50ZXJhY3RpdmUgQ29u bmVjdGl2aXR5IEVzdGFibGlzaG1lbnQgKElDRSkgY2FuZGlkYXRlPGJyPg0KJm5ic3A7ICZuYnNw O3BhaXIgc2VsZWN0aW9uIGFsZ29yaXRobS48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpQ bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg dGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFy ZSBhdmFpbGFibGUgYXQNCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPnRvb2xzLmlldGYub3JnPC9hPi48YnI+DQo8YnI+DQpUaGUgSUVURiBTZWNyZXRhcmlh dDxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KdHJhbSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRm Lm9yZyI+dHJhbUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW08L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_913383AAA69FF945B8F946018B75898A35523C04xmbrcdx10ciscoc_-- From nobody Tue Dec 23 09:57:48 2014 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 37EE51A1A8F for ; Tue, 23 Dec 2014 09:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 UR1UlDIYIvRg for ; Tue, 23 Dec 2014 09:57:44 -0800 (PST) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF48B1A1A75 for ; Tue, 23 Dec 2014 09:57:43 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id s18so5929981lam.30 for ; Tue, 23 Dec 2014 09:57:42 -0800 (PST) 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=WXAbM4A3iCo7Ww6Om8k6VxnZa5rd5Pe6TMaTOj14zF8=; b=izPPpMWfjvBUyuSL5oL1kMHzIoaYM6N5TuN12w8JGcl8EBRiUVRnli7tYwAPboWsWY jqO3Uy9cHp2zcN+rpcRTS4H3BIINjL0KsmdU+Gj4DXseDOzO6T2c/LBPeDUjlBRy4Fi3 RgwiDkcp8zxSx5LOLj07Q7ZndGCOU12EI8weTDYkC/Amrzk5ylUI1cPvpRHIb7/yi5EX PM/yTbSpFMipboflZD/UOEqRz5Kio3zOi1+UGxX0VaTmep459cgAMaOPw+r2UrBd5egv 42xkV3RqXIJ7ZYZdGXpV/6D3WjWdxdn2Fj4UqK7T1KtIGwc0uJS4CHshCUMtMOdlnGJG ef8A== X-Gm-Message-State: ALoCoQk2p+se6gKw9Bp0xOYImmuA6S+dtHY4w21srDZ/yejLV148/Pf5+BvGkMQXb1GbVHnPW7gB MIME-Version: 1.0 X-Received: by 10.152.164.133 with SMTP id yq5mr25464027lab.38.1419357461985; Tue, 23 Dec 2014 09:57:41 -0800 (PST) Received: by 10.25.84.145 with HTTP; Tue, 23 Dec 2014 09:57:41 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A35523C04@xmb-rcd-x10.cisco.com> References: <20141223150647.4003.56437.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35523A3E@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A35523C04@xmb-rcd-x10.cisco.com> Date: Tue, 23 Dec 2014 12:57:41 -0500 Message-ID: From: Simon Perreault To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=001a1133a84e54ce09050ae5e9b5 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/H3tQQq6WBf1Uj88UHEDbo8f0Oi0 Cc: "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 17:57:46 -0000 --001a1133a84e54ce09050ae5e9b5 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 23, 2014 at 12:55 PM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > > One thing caught my eye: > > > > To resolve the issue of > > identical request and response packets in a STUN transaction, this > > document changes that retransmission behavior for idempotent packets. > > > > Is this actually true? I didn't find any such change. > > > > It is explained in section 3.1 > > > > > > This specification updates one the STUN message structuring rules > > explained in Section 6 of [RFC5389] that resends of the same request > > reuse the same transaction ID and are bit-wise identical to the > > previous request. The ReTransCnt in the PATH-CHARACTERISTIC > > attribute will be incremented by 1 for every re-transmission and the > > re-transmitted STUN request MUST be bit-wise identical to the > > previous request except for the ReTransCnt value. > > > Ok, but the "for idempotent packets" part is missing. To be clear: is there any difference in behaviour for Binding vs Allocate requests? Simon --001a1133a84e54ce09050ae5e9b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Dec 23, 2014 at 12:55 PM, Tirumaleswar Reddy (tireddy) <tireddy@ci= sco.com> wrote:

One thing caught my eye:

=C2=A0

=C2=A0=C2=A0 To resolve t=
he issue of
=C2=A0=C2=A0 identical re=
quest and response packets in a STUN transaction, this=

=C2=A0=C2=A0 document cha=
nges that retransmission behavior for idempotent packets.
=C2=A0

Is this actually true? I didn't find any such ch= ange.

=C2=A0

It is explained in= section 3.1

=C2=A0

<snip>

=C2=A0=C2=A0 This specification updates one the STUN messa= ge structuring rules

=C2=A0=C2=A0 explained in Section 6 of [RFC5389] that rese= nds of the same request

=C2=A0=C2=A0 reuse the same transaction ID and are bit-wis= e identical to the

=C2=A0=C2=A0 previous request.=C2=A0 The ReTransCnt in the= PATH-CHARACTERISTIC

=C2=A0=C2=A0 attribute will be incremented by 1 for every = re-transmission and the

=C2=A0=C2=A0 re-transmitted STUN request MUST be bit-wise = identical to the

=C2=A0=C2=A0 previous request except for the ReTransCnt va= lue.

</snip>

<= /div>

Ok, but the "for idempotent packets" = part is missing. To be clear: is there any difference in behaviour for Bind= ing vs Allocate requests?

Simon
--001a1133a84e54ce09050ae5e9b5-- From nobody Tue Dec 23 11:34:26 2014 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 598421A1AE1 for ; Tue, 23 Dec 2014 11:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Voix_Zzuza-r for ; Tue, 23 Dec 2014 11:34:23 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 3E66B1A1AE3 for ; Tue, 23 Dec 2014 11:26:52 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 2188347608 for ; Tue, 23 Dec 2014 19:26:51 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id F38CC47606 for ; Tue, 23 Dec 2014 19:26:50 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id EF872202D for ; Tue, 23 Dec 2014 19:26:50 +0000 (GMT) Message-ID: <5499C1FA.90300@akamai.com> Date: Tue, 23 Dec 2014 14:26:50 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: tram@ietf.org References: <20141223150647.4003.56437.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35523A3E@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A35523C04@xmb-rcd-x10.cisco.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/9bsOGIwPCOBpG7YWzs_Z_CREC-0 Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 19:34:25 -0000 On 12/23/2014 12:57 PM, Simon Perreault wrote: > > Ok, but the "for idempotent packets" part is missing. To be clear: is > there any difference in behaviour for Binding vs Allocate requests? > > Simon I agree that the draft needs a bit of clarification about usage. I think the authors intend the new attribute to be used primarily (exclusively?) in the STUN Binding messages used for ICE connectivity checks. That way, it ends up representing the characteristics for end-to-end connectivity, not just the "first mile" into the relay. That said, the draft doesn't explicitly call this out, so confirmation on intent from the authors would be good. --Brandon -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Tue Dec 23 17:33:23 2014 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 10FE21A8831 for ; Tue, 23 Dec 2014 17:33:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 E7CBUXKZzskZ for ; Tue, 23 Dec 2014 17:33:19 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A88741A882B for ; Tue, 23 Dec 2014 17:33:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14526; q=dns/txt; s=iport; t=1419384800; x=1420594400; h=from:to:cc:subject:date:message-id:mime-version; bh=jGJh+MzD0+wfhcPHpU4RxKYHqaOsBRthMvR7v0vHHhI=; b=C2nLVGgxNZedwz3aqcYKwkXrMGOIsfXpCA2MIJzTTyK+Dx9eCFCRgy36 9ESOMnAJXKJ6NN7CLDGtxAzh6qRQxt/EJX6Bn2IunQxMia8RANyRKDCTy Eceu44He9keW5+rixT7Qj5VQCGwu03y983Syd67mVj3zq9ZfZRBuOiXQr U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As0HADIXmlStJV2d/2dsb2JhbABRCoJDQ1JYBIMAwTuIFwIceRYBAQEBAX2EDAEBAQQjCkoCEgEIDgMEAQELHQMCBDAUCAEJAQQOBQiIJLVzlWYBAQEBAQEBAQEBAQEBAQEBAQEBAQEXjxYrFhsGB4JiLoETBY4VmkMigjKBPG+BRX4BAQE X-IronPort-AV: E=Sophos;i="5.07,635,1413244800"; d="scan'208,217";a="379205991" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 24 Dec 2014 01:33:20 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id sBO1XIsE029162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Dec 2014 01:33:18 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.58]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Tue, 23 Dec 2014 19:33:18 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault Thread-Topic: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt Thread-Index: AdAfGZHaNI38FKcSSlqQtC7gm6obbw== Date: Wed, 24 Dec 2014 01:33:18 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A35523D08@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.41.162] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A35523D08xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/pJ0MtAEj9nXgEsXCp14IBd3-JAY Cc: "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 01:33:22 -0000 --_000_913383AAA69FF945B8F946018B75898A35523D08xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW5saW5lIFtUUl0NCg0KRnJvbTogU2ltb24gUGVycmVhdWx0IFttYWlsdG86c3BlcnJlYXVsdEBq aXZlLmNvbV0NClNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDIzLCAyMDE0IDExOjI4IFBNDQpUbzog VGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KQ0KQ2M6IHRyYW1AaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbdHJhbV0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcmVkZHkt dHJhbS1zdHVuLXBhdGgtZGF0YS0wMC50eHQNCg0KDQpPbiBUdWUsIERlYyAyMywgMjAxNCBhdCAx Mjo1NSBQTSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSA8dGlyZWRkeUBjaXNjby5jb208 bWFpbHRvOnRpcmVkZHlAY2lzY28uY29tPj4gd3JvdGU6DQpPbmUgdGhpbmcgY2F1Z2h0IG15IGV5 ZToNCg0KDQogICBUbyByZXNvbHZlIHRoZSBpc3N1ZSBvZg0KDQogICBpZGVudGljYWwgcmVxdWVz dCBhbmQgcmVzcG9uc2UgcGFja2V0cyBpbiBhIFNUVU4gdHJhbnNhY3Rpb24sIHRoaXMNCg0KICAg ZG9jdW1lbnQgY2hhbmdlcyB0aGF0IHJldHJhbnNtaXNzaW9uIGJlaGF2aW9yIGZvciBpZGVtcG90 ZW50IHBhY2tldHMuDQoNCg0KSXMgdGhpcyBhY3R1YWxseSB0cnVlPyBJIGRpZG4ndCBmaW5kIGFu eSBzdWNoIGNoYW5nZS4NCg0KSXQgaXMgZXhwbGFpbmVkIGluIHNlY3Rpb24gMy4xDQoNCjxzbmlw Pg0KICAgVGhpcyBzcGVjaWZpY2F0aW9uIHVwZGF0ZXMgb25lIHRoZSBTVFVOIG1lc3NhZ2Ugc3Ry dWN0dXJpbmcgcnVsZXMNCiAgIGV4cGxhaW5lZCBpbiBTZWN0aW9uIDYgb2YgW1JGQzUzODldIHRo YXQgcmVzZW5kcyBvZiB0aGUgc2FtZSByZXF1ZXN0DQogICByZXVzZSB0aGUgc2FtZSB0cmFuc2Fj dGlvbiBJRCBhbmQgYXJlIGJpdC13aXNlIGlkZW50aWNhbCB0byB0aGUNCiAgIHByZXZpb3VzIHJl cXVlc3QuICBUaGUgUmVUcmFuc0NudCBpbiB0aGUgUEFUSC1DSEFSQUNURVJJU1RJQw0KICAgYXR0 cmlidXRlIHdpbGwgYmUgaW5jcmVtZW50ZWQgYnkgMSBmb3IgZXZlcnkgcmUtdHJhbnNtaXNzaW9u IGFuZCB0aGUNCiAgIHJlLXRyYW5zbWl0dGVkIFNUVU4gcmVxdWVzdCBNVVNUIGJlIGJpdC13aXNl IGlkZW50aWNhbCB0byB0aGUNCiAgIHByZXZpb3VzIHJlcXVlc3QgZXhjZXB0IGZvciB0aGUgUmVU cmFuc0NudCB2YWx1ZS4NCjwvc25pcD4NCg0KT2ssIGJ1dCB0aGUgImZvciBpZGVtcG90ZW50IHBh Y2tldHMiIHBhcnQgaXMgbWlzc2luZy4NCg0KW1RSXSBZZXMsIHVwZGF0ZWQgZHJhZnQuDQoNClRv IGJlIGNsZWFyOiBpcyB0aGVyZSBhbnkgZGlmZmVyZW5jZSBpbiBiZWhhdmlvciBmb3IgQmluZGlu ZyB2cyBBbGxvY2F0ZSByZXF1ZXN0cyA/DQoNCltUUl0gTm8uIFRVUk4gc2VydmVyIGFzIHVzdWFs IHJlbWVtYmVycyB0aGUgdHJhbnNhY3Rpb24gSUQgdG8gZGVhbCB3aXRoIHJldHJhbnNtaXNzaW9u IG9mIEFsbG9jYXRlIHJlcXVlc3RzLCBzbyBpdCBjYW4gaWRlbnRpZnkgdGhhdCBBbGxvY2F0ZSBy ZXF1ZXN0IGlzIHJldHJhbnNtaXR0ZWQgd2l0aCBvbmx5IGNoYW5nZSBpbiB0aGUgUmVUcmFuc0Nu dCB2YWx1ZS4NCg0KLVRpcnUNCg0KU2ltb24NCg== --_000_913383AAA69FF945B8F946018B75898A35523D08xmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7 DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J bmxpbmUgW1RSXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBT aW1vbiBQZXJyZWF1bHQgW21haWx0bzpzcGVycmVhdWx0QGppdmUuY29tXQ0KPGJyPg0KPGI+U2Vu dDo8L2I+IFR1ZXNkYXksIERlY2VtYmVyIDIzLCAyMDE0IDExOjI4IFBNPGJyPg0KPGI+VG86PC9i PiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpPGJyPg0KPGI+Q2M6PC9iPiB0cmFtQGlldGYu b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHJhbV0gRlc6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtcmVkZHktdHJhbS1zdHVuLXBhdGgtZGF0YS0wMC50eHQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwg RGVjIDIzLCAyMDE0IGF0IDEyOjU1IFBNLCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpICZs dDs8YSBocmVmPSJtYWlsdG86dGlyZWRkeUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj50aXJl ZGR5QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+T25lIHRoaW5nIGNhdWdodCBteSBleWU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFRvIHJlc29sdmUgdGhlIGlzc3VlIG9mPC9zcGFuPjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsgaWRlbnRpY2FsIHJlcXVlc3QgYW5kIHJlc3BvbnNlIHBhY2tl dHMgaW4gYSBTVFVOIHRyYW5zYWN0aW9uLCB0aGlzPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsgZG9jdW1lbnQgY2hhbmdlcyB0aGF0IHJldHJhbnNtaXNzaW9uIGJlaGF2aW9yIGZvciBpZGVt cG90ZW50IHBhY2tldHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SXMgdGhpcyBhY3R1YWxseSB0cnVlPyBJIGRp ZG4ndCBmaW5kIGFueSBzdWNoIGNoYW5nZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkl0IGlzIGV4cGxhaW5lZCBpbiBzZWN0 aW9uIDMuMTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZsdDtzbmlwJmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBUaGlzIHNwZWNp ZmljYXRpb24gdXBkYXRlcyBvbmUgdGhlIFNUVU4gbWVzc2FnZSBzdHJ1Y3R1cmluZyBydWxlczwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyBleHBsYWluZWQgaW4gU2VjdGlvbiA2IG9mIFtSRkM1Mzg5XSB0aGF0IHJlc2Vu ZHMgb2YgdGhlIHNhbWUgcmVxdWVzdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyByZXVzZSB0aGUgc2FtZSB0cmFuc2Fj dGlvbiBJRCBhbmQgYXJlIGJpdC13aXNlIGlkZW50aWNhbCB0byB0aGU8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgcHJl dmlvdXMgcmVxdWVzdC4mbmJzcDsgVGhlIFJlVHJhbnNDbnQgaW4gdGhlIFBBVEgtQ0hBUkFDVEVS SVNUSUM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsgYXR0cmlidXRlIHdpbGwgYmUgaW5jcmVtZW50ZWQgYnkgMSBmb3Ig ZXZlcnkgcmUtdHJhbnNtaXNzaW9uIGFuZCB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgcmUtdHJhbnNtaXR0ZWQg U1RVTiByZXF1ZXN0IE1VU1QgYmUgYml0LXdpc2UgaWRlbnRpY2FsIHRvIHRoZTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyBwcmV2aW91cyByZXF1ZXN0IGV4Y2VwdCBmb3IgdGhlIFJlVHJhbnNDbnQgdmFsdWUuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmx0Oy9zbmlwJmd0Ozwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpPaywgYnV0 IHRoZSAmcXVvdDtmb3IgaWRlbXBvdGVudCBwYWNrZXRzJnF1b3Q7IHBhcnQgaXMgbWlzc2luZy4g PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bVFJdIFllcywgdXBkYXRl ZCBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG8gYmUgY2xlYXI6IGlzIHRoZXJlIGFu eSBkaWZmZXJlbmNlIGluIGJlaGF2aW9yIGZvciBCaW5kaW5nIHZzIEFsbG9jYXRlIHJlcXVlc3Rz PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPg0KPC9zcGFuPj88bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1RSXSBOby4gVFVSTiBz ZXJ2ZXIgYXMgdXN1YWwgcmVtZW1iZXJzIHRoZSB0cmFuc2FjdGlvbiBJRCB0byBkZWFsIHdpdGgg cmV0cmFuc21pc3Npb24gb2YgQWxsb2NhdGUgcmVxdWVzdHMsIHNvIGl0IGNhbiBpZGVudGlmeSB0 aGF0IEFsbG9jYXRlIHJlcXVlc3QgaXMgcmV0cmFuc21pdHRlZA0KIHdpdGggb25seSBjaGFuZ2Ug aW4gdGhlIFJlVHJhbnNDbnQgdmFsdWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tVGlydTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2ltb248bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_913383AAA69FF945B8F946018B75898A35523D08xmbrcdx10ciscoc_-- From nobody Tue Dec 23 18:41:17 2014 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 7A6381A8931 for ; Tue, 23 Dec 2014 18:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 ynq1H_YEs74d for ; Tue, 23 Dec 2014 18:41:15 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEDA51A88CF for ; Tue, 23 Dec 2014 18:41:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1904; q=dns/txt; s=iport; t=1419388875; x=1420598475; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=vEfczSTv/dXSW4RoHdFsmNzhig7wtYGE89Y1RnxCyvA=; b=lNvpVmmZABp8Jd/OvZE8iUt12A5GW73MstWiZFOcpyBQ7bWVrE9cYfzZ p0TAt5h3sKDGLf7Ybg2ySre9ZIjX/FJUFmMTvQkjng85NgY0HgE8Z+G9v ZmGWUgz7Io/1D8Z23EKY0uKnfCMP5yRknvSnXMKcL5WS1zzpbfFez62pF s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFAFUnmlStJV2d/2dsb2JhbABbgwZSWATEQIIbDIVwAoEXFgEBAQEBfYQMAQEBBAEBATc0CQ4GAQgRBAEBAQoUCS4LFAgBCQEEARIIiCQNy0gBAQEBAQEBAQEBAQEBAQEBAQEBAQETBI9BPoMQgRMBBI4Vgz+XBCKCMoE8bwGBRH4BAQE X-IronPort-AV: E=Sophos;i="5.07,636,1413244800"; d="scan'208";a="108042048" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP; 24 Dec 2014 02:41:14 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id sBO2fEU9028262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Dec 2014 02:41:14 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.58]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Tue, 23 Dec 2014 20:41:14 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , "tram@ietf.org" Thread-Topic: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt Thread-Index: AdAfIxHruJ39yLOxRJ+/MfQ0DrXuiA== Date: Wed, 24 Dec 2014 02:41:13 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A35523D5C@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.41.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/FFOK0aayVQ1AJqBmkVKIrbJV7jU Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 02:41:16 -0000 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams > Sent: Wednesday, December 24, 2014 12:57 AM > To: tram@ietf.org > Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-stu= n- > path-data-00.txt >=20 >=20 > On 12/23/2014 12:57 PM, Simon Perreault wrote: > > > > Ok, but the "for idempotent packets" part is missing. To be clear: is > > there any difference in behaviour for Binding vs Allocate requests? > > > > Simon >=20 > I agree that the draft needs a bit of clarification about usage. >=20 > I think the authors intend the new attribute to be used primarily > (exclusively?) in the STUN Binding messages used for ICE connectivity > checks. That way, it ends up representing the characteristics for > end-to-end connectivity, not just the "first mile" into the relay. That > said, the draft doesn't explicitly call this out, so confirmation on > intent from the authors would be good. Yes, the primary use case for PATH-CHARACTERISTICS is to use in ICE connect= ivity checks. The other use case that needs further discussion is: When an = endpoint discovers multiple TURN servers then this new attribute can be us= ed with Allocate requests to determine the priority amongst the relayed can= didates (https://tools.ietf.org/html/draft-patil-tram-turn-serv-selection-0= 0#section-3.3). But as you mentioned it does not represent end-to-end chara= cteristics and ICE connectivity checks with PATH-CHARACTERISTICS would help= to choose a TURN server that provides better path characteristics.=20 -Tiru >=20 > --Brandon >=20 > -- > Brandon Williams; Senior Principal Software Engineer > Emerging Products Engineering; Akamai Technologies Inc. >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Tue Dec 23 22:37:34 2014 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 2E79C1ACD3B for ; Tue, 23 Dec 2014 22:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4UGqsv_qva9 for ; Tue, 23 Dec 2014 22:37:26 -0800 (PST) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id E010C1ACD3A for ; Tue, 23 Dec 2014 22:37:25 -0800 (PST) Received: from ctbriwangaij (unknown [219.142.69.76]) by app1 (Coremail) with SMTP id Z0GX06ArQQHQSppULWwVAA==.7634S4; Wed, 24 Dec 2014 13:10:57 +0800 (CST) From: "Aijun Wang" To: "'Tirumaleswar Reddy \(tireddy\)'" , References: <20141223150647.4003.56437.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35523A3E@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A35523A3E@xmb-rcd-x10.cisco.com> Date: Wed, 24 Dec 2014 14:36:50 +0800 Message-ID: <003301d01f44$086ad280$19407780$@org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHQHsIV3VuulXGCB0OqNizGsEVDB5ydRr7QgAEB6VA= Content-Language: zh-cn X-CM-TRANSID: Z0GX06ArQQHQSppULWwVAA==.7634S4 X-Coremail-Antispam: 1U3129KBjvJXoWxWF1DKFW5JFWrCFy7Gw1xZrb_yoW5XF18pa yxXrWfWry8Jwn7A3s7J3W8J3W5ZFWkZ3y7AF15Kr1kCay5JFy0qFW5KayrAa4jgr98Aws7 Zr4I9r15Zasa9rJanT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjBvb7 Iv0xC_Jr1l5I8CrVACY4xI64kE6c02F40Ex7xfM7kC6x804xWl14x267AKxVW8JVW5JwAF xVCF77xC6IxKo4kEV4yl1I0EscIYIxCEI4klw4CSwwAv7VCjz48v1sIEY20_GF1lx4CE17 CEb7AF67AKxVWUXVWUAjIFyTuYvjfUF38nUUUUU Archived-At: http://mailarchive.ietf.org/arch/msg/tram/6-L5oAcikLzDeDRFf9vkkY9teOQ Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 06:37:30 -0000 Hi, Reddy: I doubt the feasibility of this probe process. For UE that has multiple interfaces, the OS of the UE will automatically choose only one default interface for communicating. According to this draft, the ICE agent within the UE will try every possible interface to send the STUN packet? This will make the connection time between two endpoints unacceptable. Best Regards. -----Original Message----- From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy (tireddy) Sent: Tuesday, December 23, 2014 11:29 PM To: tram@ietf.org Subject: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt This draft describes a mechanism for an endpoint to discover the path characteristics using STUN. Comments and suggestions are welcome. -Tiru -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Tuesday, December 23, 2014 8:37 PM To: Varun Singh; Tirumaleswar Reddy (tireddy); Dan Wing (dwing); Varun Singh; Tirumaleswar Reddy (tireddy); Pal Martinsen (palmarti); Dan Wing (dwing); Pal Martinsen (palmarti) Subject: New Version Notification for draft-reddy-tram-stun-path-data-00.txt A new version of I-D, draft-reddy-tram-stun-path-data-00.txt has been successfully submitted by Tirumaleswar Reddy and posted to the IETF repository. Name: draft-reddy-tram-stun-path-data Revision: 00 Title: Discovery of path characteristics using STUN Document date: 2014-12-23 Group: Individual Submission Pages: 9 URL: http://www.ietf.org/internet-drafts/draft-reddy-tram-stun-path-data-00.txt Status: https://datatracker.ietf.org/doc/draft-reddy-tram-stun-path-data/ Htmlized: http://tools.ietf.org/html/draft-reddy-tram-stun-path-data-00 Abstract: A host with multiple interfaces needs to choose the best interface for communication. Oftentimes, this decision is based on a static configuration and does not consider the path characteristics, which may affect the user experience. This document describes a mechanism for an endpoint to discover the path characteristics using Session Traversal Utilities for NAT (STUN) messages. The measurement information can then be used to influence the endpoint's Interactive Connectivity Establishment (ICE) candidate pair selection algorithm. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram From nobody Wed Dec 24 02:02:57 2014 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 1D2541AD023 for ; Wed, 24 Dec 2014 02:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 mem23aLkkTJw for ; Wed, 24 Dec 2014 02:02:49 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EC811ACDAA for ; Wed, 24 Dec 2014 02:02:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3701; q=dns/txt; s=iport; t=1419415369; x=1420624969; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=86r05a1TyzhxyfOdVODj5WimLIkqwry3zavCMhXHroE=; b=nAvDV7cw4lUDHYT2O7xXaY1CQaV4+eIgDKsKPk6Z3bwhRdu5Dbi1CMJe P+9yNdbjAWoRj/heuHNx9MCP+nJjexA9UgPJ8dTNsNxK762vFjo8ZLt9z 2sjrZ48GA/w3txLK7bEfkKsIGfvKTxTb5D5IZrL9FoP6SaTfn8k5oOfz2 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFALKOmlStJV2c/2dsb2JhbABbgwZSWATEM4IbDIVwAoERFgEBAQEBfYQMAQEBAwEBAQE3NAkHBwQCAQgRBAEBCxQJBycLFAgBCAIEARIIAYgbCA3LTwEBAQEBAQEBAQEBAQEBAQEBAQEBARePQTgGgxCBEwWOFYM/hkEwgjWNXiKCMoE8bwGBRH4BAQE X-IronPort-AV: E=Sophos;i="5.07,637,1413244800"; d="scan'208";a="379282214" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 24 Dec 2014 10:02:48 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id sBOA2mSx026302 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Dec 2014 10:02:48 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.58]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Wed, 24 Dec 2014 04:02:48 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Aijun Wang , "tram@ietf.org" Thread-Topic: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt Thread-Index: AQHQHsIV3VuulXGCB0OqNizGsEVDB5ydRr7QgAEB6VCAAB+0UA== Date: Wed, 24 Dec 2014 10:02:47 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A35523F70@xmb-rcd-x10.cisco.com> References: <20141223150647.4003.56437.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35523A3E@xmb-rcd-x10.cisco.com> <003301d01f44$086ad280$19407780$@org.cn> In-Reply-To: <003301d01f44$086ad280$19407780$@org.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.18.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/pUmdq6UYXFYWFrvaFYZKCW4RxGE Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 10:02:51 -0000 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Aijun Wang > Sent: Wednesday, December 24, 2014 12:07 PM > To: Tirumaleswar Reddy (tireddy); tram@ietf.org > Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-stu= n- > path-data-00.txt >=20 > Hi, Reddy: >=20 > I doubt the feasibility of this probe process. For UE that has multiple > interfaces, the OS of the UE will automatically choose only one default > interface for communicating.=20 No, MPTCP on mobile devices already uses multiple interfaces (for example A= pple uses MPTCP for Siri). MPRTP (draft-ietf-avtcore-mprtp-00) also uses m= ultiple interfaces. > According to this draft, the ICE agent within the > UE will try every possible interface to send the STUN packet?=20 > This will make > the connection time between two endpoints unacceptable. The new attribute can be added to the STUN binding request/response used fo= r ICE connectivity checks and does not introduce any additional messages. -Tiru >=20 > Best Regards. >=20 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Tirumaleswar > Reddy > (tireddy) > Sent: Tuesday, December 23, 2014 11:29 PM > To: tram@ietf.org > Subject: [tram] FW: New Version Notification for draft-reddy-tram-stun-pa= th- > data-00.txt >=20 > This draft describes a mechanism for an endpoint to discover the path > characteristics using STUN. > Comments and suggestions are welcome. >=20 > -Tiru >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, December 23, 2014 8:37 PM > To: Varun Singh; Tirumaleswar Reddy (tireddy); Dan Wing (dwing); Varun > Singh; Tirumaleswar Reddy (tireddy); Pal Martinsen (palmarti); Dan Wing > (dwing); Pal Martinsen (palmarti) > Subject: New Version Notification for draft-reddy-tram-stun-path-data-00.= txt >=20 >=20 > A new version of I-D, draft-reddy-tram-stun-path-data-00.txt > has been successfully submitted by Tirumaleswar Reddy and posted to the > IETF > repository. >=20 > Name: draft-reddy-tram-stun-path-data > Revision: 00 > Title: Discovery of path characteristics using STUN > Document date: 2014-12-23 > Group: Individual Submission > Pages: 9 > URL: > http://www.ietf.org/internet-drafts/draft-reddy-tram-stun-path-data-00.tx= t > Status: > https://datatracker.ietf.org/doc/draft-reddy-tram-stun-path-data/ > Htmlized: > http://tools.ietf.org/html/draft-reddy-tram-stun-path-data-00 >=20 >=20 > Abstract: > A host with multiple interfaces needs to choose the best interface > for communication. Oftentimes, this decision is based on a static > configuration and does not consider the path characteristics, which > may affect the user experience. >=20 > This document describes a mechanism for an endpoint to discover the > path characteristics using Session Traversal Utilities for NAT (STUN) > messages. The measurement information can then be used to influence > the endpoint's Interactive Connectivity Establishment (ICE) candidate > pair selection algorithm. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram >=20 >=20 >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Thu Dec 25 08:36:41 2014 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 D8D591A87F0 for ; Thu, 25 Dec 2014 08:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.563 X-Spam-Level: X-Spam-Status: No, score=-0.563 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, T_RP_MATCHES_RCVD=-0.01] 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 qR8ft8C5AzEB for ; Thu, 25 Dec 2014 08:36:36 -0800 (PST) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id CE45D1A87A8 for ; Thu, 25 Dec 2014 08:36:35 -0800 (PST) Received: from ctbriwangaij (unknown [114.248.172.19]) by app1 (Coremail) with SMTP id Z0GX06CbMgCqKJxUZ3UVAA==.63009S4; Thu, 25 Dec 2014 23:09:51 +0800 (CST) From: "Aijun Wang" To: "'Tirumaleswar Reddy \(tireddy\)'" , References: <20141223150647.4003.56437.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35523A3E@xmb-rcd-x10.cisco.com> <003301d01f44$086ad280$19407780$@org.cn> <913383AAA69FF945B8F946018B75898A35523F70@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A35523F70@xmb-rcd-x10.cisco.com> Date: Fri, 26 Dec 2014 00:36:03 +0800 Message-ID: <005c01d02060$e81da2f0$b858e8d0$@org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHQHsIV3VuulXGCB0OqNizGsEVDB5ydRr7QgAEB6VCAAB+0UIACFSZg Content-Language: zh-cn X-CM-TRANSID: Z0GX06CbMgCqKJxUZ3UVAA==.63009S4 X-Coremail-Antispam: 1U3129KBjvJXoWxCw4DWr4ruFyxXr47WrWUtwb_yoW7JF1Dpa y7tay3GrWkJwnrAwnrtw10kF1jv395ArW7AF15tr1kCa98tFy0qrW5tw4rZasrWrn8Jwsr Zr47ur1Uu3ZxurJanT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjBvb7 Iv0xC_Jr1l5I8CrVACY4xI64kE6c02F40Ex7xfM7kC6x804xWl14x267AKxVW8JVW5JwAF xVCF77xC6IxKo4kEV4yl1I0EscIYIxCEI4klw4CSwwAv7VCjz48v1sIEY20_GF1lx4CE17 CEb7AF67AKxVWUXVWUAjIFyTuYvjfUF38nUUUUU Archived-At: http://mailarchive.ietf.org/arch/msg/tram/IuKc5I3z6jEydLsX9lrJxKTPxRw Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 16:36:40 -0000 Hi, Reddy Please see the reply inline below. > -----Original Message----- > From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > Sent: Wednesday, December 24, 2014 6:03 PM > To: Aijun Wang; tram@ietf.org > Subject: RE: [tram] FW: New Version Notification for > draft-reddy-tram-stun-path-data-00.txt > > > -----Original Message----- > > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Aijun Wang > > Sent: Wednesday, December 24, 2014 12:07 PM > > To: Tirumaleswar Reddy (tireddy); tram@ietf.org > > Subject: Re: [tram] FW: New Version Notification for > > draft-reddy-tram-stun- path-data-00.txt > > > > Hi, Reddy: > > > > I doubt the feasibility of this probe process. For UE that has > > multiple interfaces, the OS of the UE will automatically choose only > > one default interface for communicating. > > No, MPTCP on mobile devices already uses multiple interfaces (for example > Apple uses MPTCP for Siri). MPRTP (draft-ietf-avtcore-mprtp-00) also uses > multiple interfaces. > The purpose of MPTCP and MPRTP is just contrary to your proposal. They just want to utilize all the available paths for TCP or RTP chunk data transport, but this draft just wants to select one best pair? On the other hand, there is also other factor needed to be considered for selecting the underlying network, for example the prices of different connection. I think the users themselves should decide which one and how many interfaces can be used for data transfer, not one of the application on their devices. > > According to this draft, the ICE agent within the UE will try every > > possible interface to send the STUN packet? > > This will make > > the connection time between two endpoints unacceptable. > > The new attribute can be added to the STUN binding request/response used for > ICE connectivity checks and does not introduce any additional messages. > The checking results can't be kept consistency all the time. How about the selected interface become congested when it begins to transfer the chunk data? From this point, the MPTCP and MPRTP may be more reasonable solution. It can balance between different links/interfaces, not just select only one that looks like idle. > -Tiru > > > > > Best Regards. > > > > -----Original Message----- > > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Tirumaleswar > > Reddy > > (tireddy) > > Sent: Tuesday, December 23, 2014 11:29 PM > > To: tram@ietf.org > > Subject: [tram] FW: New Version Notification for > > draft-reddy-tram-stun-path- data-00.txt > > > > This draft describes a mechanism for an endpoint to discover the path > > characteristics using STUN. > > Comments and suggestions are welcome. > > > > -Tiru > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Tuesday, December 23, 2014 8:37 PM > > To: Varun Singh; Tirumaleswar Reddy (tireddy); Dan Wing (dwing); Varun > > Singh; Tirumaleswar Reddy (tireddy); Pal Martinsen (palmarti); Dan > > Wing (dwing); Pal Martinsen (palmarti) > > Subject: New Version Notification for > > draft-reddy-tram-stun-path-data-00.txt > > > > > > A new version of I-D, draft-reddy-tram-stun-path-data-00.txt > > has been successfully submitted by Tirumaleswar Reddy and posted to > > the IETF repository. > > > > Name: draft-reddy-tram-stun-path-data > > Revision: 00 > > Title: Discovery of path characteristics using STUN > > Document date: 2014-12-23 > > Group: Individual Submission > > Pages: 9 > > URL: > > http://www.ietf.org/internet-drafts/draft-reddy-tram-stun-path-data-00 > > .txt > > Status: > > https://datatracker.ietf.org/doc/draft-reddy-tram-stun-path-data/ > > Htmlized: > > http://tools.ietf.org/html/draft-reddy-tram-stun-path-data-00 > > > > > > Abstract: > > A host with multiple interfaces needs to choose the best interface > > for communication. Oftentimes, this decision is based on a static > > configuration and does not consider the path characteristics, which > > may affect the user experience. > > > > This document describes a mechanism for an endpoint to discover the > > path characteristics using Session Traversal Utilities for NAT (STUN) > > messages. The measurement information can then be used to > influence > > the endpoint's Interactive Connectivity Establishment (ICE) candidate > > pair selection algorithm. > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > _______________________________________________ > > 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 Fri Dec 26 03:46:41 2014 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 242B21A6FA6 for ; Fri, 26 Dec 2014 03:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.588 X-Spam-Level: X-Spam-Status: No, score=-1.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=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 7HxgaTdhszUq for ; Fri, 26 Dec 2014 03:46:34 -0800 (PST) Received: from tsinghua.org.cn (mail.alumail.com [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id 337F11A6FA3 for ; Fri, 26 Dec 2014 03:46:32 -0800 (PST) Received: from ctbriwangaij (unknown [123.120.47.191]) by app1 (Coremail) with SMTP id Z0GX06BLZwEcNp1ULPoqAA==.32145S4; Fri, 26 Dec 2014 18:19:31 +0800 (CST) From: "Aijun Wang" To: "'Varun Singh'" References: <20141223150647.4003.56437.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35523A3E@xmb-rcd-x10.cisco.com> <003301d01f44$086ad280$19407780$@org.cn> <913383AAA69FF945B8F946018B75898A35523F70@xmb-rcd-x10.cisco.com> <005c01d02060$e81da2f0$b858e8d0$@org.cn> In-Reply-To: Date: Fri, 26 Dec 2014 19:45:54 +0800 Message-ID: <000901d02101$8ab0a260$a011e720$@org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01D02144.98D3E260" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdAgfsXJzpxITKbuQwusSauXvMe8qAAf3XiA Content-Language: zh-cn X-CM-TRANSID: Z0GX06BLZwEcNp1ULPoqAA==.32145S4 X-Coremail-Antispam: 1U3129KBjvJXoWxtw4fWFy8Zr4UCF1kCw1rWFg_yoW3JF43pa y7tFW5KrWkJwnrAwnrt3W8KFyUZrZ5ArW7Ar1rtr1vka98JFy0qrWrKw4rZFZrurn8Jwnr Zr47ur1UZ3ZxZrJanT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjQlb7 Iv0xC_Jr1l5I8CrVAYj202j2C_Gr0_Xr1l5I8CrVAqjxCE14ACF2xKxwAqx4xG64kEw2xG 04xIwI0_Jr0_Gr1l5I8CrVCF0I0E4I0vr24lb4IE77IF4wAFF20E14v26r4j6ryUM7C26x Cjj4IEI4klw4CSwwAFxVCaYxvI4VCIwcAKzIAtMcIj6x8ErcxFaVAv8VW8AwC2zVAF1VAY 17CE14v26r1Y6r170xZFpf9x0JURE__UUUUU= Archived-At: http://mailarchive.ietf.org/arch/msg/tram/kZFG8EKRDBJE1872-V5Xm9bB6Xc Cc: tram@ietf.org, "'Tirumaleswar Reddy \(tireddy\)'" Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Dec 2014 11:46:40 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000A_01D02144.98D3E260 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, Varun, =20 ICE defines three types candidates: HOST CANDIDATE, REFELXTIVE = CANDIDATE, RELAY CANDIDATE. For UE that has multiple interfaces(for = examples m interfaces), it will have 3*m CANDIDATE. If we uses the = mechanism that described in this draft to select the best local = interface, the UE must try all of these interfaces to send the STUN = request message. Correspondingly, the communication pair will try = [3*m]*[3*m] times connectivity check to find the path that has best = characteristics? =20 This will certainly make the connection process unacceptable. To solve = such problem, we should prefer the process that described in the = RFC5245(https://datatracker.ietf.org/doc/rfc5245/), section 4.1.2. = =E2=80=9CPrioritizing Candidates=E2=80=9D first, then do the ICE = connectivity check in sequence. The prioritizing algorithm should = consider several factors, such as the security, prices, power = consumption etc. =20 =20 The path characteristic, such as loss, RTT, jitter can also be = considered, but this information should be acquired via other out-band = method, not the in-band solution that described in this draft. =20 Best Regards. =20 Aijun Wang. =20 From: Varun Singh [mailto:vsingh.ietf@gmail.com]=20 Sent: Friday, December 26, 2014 5:35 AM To: Aijun Wang Cc: Tirumaleswar Reddy (tireddy); tram@ietf.org Subject: Re: [tram] FW: New Version Notification for = draft-reddy-tram-stun-path-data-00.txt =20 Hi Aijun, Comments inline. =20 Cheers, Varun.=20 On Thursday, December 25, 2014, Aijun Wang = wrote: Hi, Reddy Please see the reply inline below. > -----Original Message----- > From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com = ] > Sent: Wednesday, December 24, 2014 6:03 PM > To: Aijun Wang; tram@ietf.org =20 > Subject: RE: [tram] FW: New Version Notification for > draft-reddy-tram-stun-path-data-00.txt > > > -----Original Message----- > > From: tram [mailto:tram-bounces@ietf.org ] On Behalf = Of Aijun Wang > > Sent: Wednesday, December 24, 2014 12:07 PM > > To: Tirumaleswar Reddy (tireddy); tram@ietf.org =20 > > Subject: Re: [tram] FW: New Version Notification for > > draft-reddy-tram-stun- path-data-00.txt > > > > Hi, Reddy: > > > > I doubt the feasibility of this probe process. For UE that has > > multiple interfaces, the OS of the UE will automatically choose only > > one default interface for communicating. > > No, MPTCP on mobile devices already uses multiple interfaces (for = example > Apple uses MPTCP for Siri). MPRTP (draft-ietf-avtcore-mprtp-00) also = uses > multiple interfaces. > The purpose of MPTCP and MPRTP is just contrary to your proposal. They = just want to utilize all the available paths for TCP or RTP chunk data = transport, but this draft just wants to select one best pair? On the other hand, = there =20 IMO the draft exposes two transport characteristics: RTT measurement, = and loss (upstream and downstream path). While there may be additional = metrics like jitter, power consumption, and as you point out money. =20 is also other factor needed to be considered for selecting the = underlying network, for example the prices of different connection. I think the = users themselves should decide which one and how many interfaces can be used = for data transfer, not one of the application on their devices. The users typically choose interfaces (allowing access to the 3G/LTE at = the system level, but this can easily be exposed at the app level), = which then becomes a system policy. And this mechanism can still work by = skipping the candidate gathering phase for interfaces i.e., not allowed = access by user/system settings. =20 > > According to this draft, the ICE agent within the UE will try every > > possible interface to send the STUN packet? > > This will make > > the connection time between two endpoints unacceptable. > > The new attribute can be added to the STUN binding request/response = used for > ICE connectivity checks and does not introduce any additional = messages. > The checking results can't be kept consistency all the time. How about = the selected interface become congested when it begins to transfer the chunk data? From this point, the MPTCP and MPRTP may be more reasonable = solution. It can balance between different links/interfaces, not just select only = one that looks like idle. =20 The metrics gathered from the connectivity checks should be fed upwards = into the rmcat or towards the congestion control, which can make the = appropriate decision.=20 =20 > -Tiru > > > > > Best Regards. > > > > -----Original Message----- > > From: tram [mailto:tram-bounces@ietf.org ] On Behalf = Of Tirumaleswar > > Reddy > > (tireddy) > > Sent: Tuesday, December 23, 2014 11:29 PM > > To: tram@ietf.org =20 > > Subject: [tram] FW: New Version Notification for > > draft-reddy-tram-stun-path- data-00.txt > > > > This draft describes a mechanism for an endpoint to discover the = path > > characteristics using STUN. > > Comments and suggestions are welcome. > > > > -Tiru > > > > -----Original Message----- > > From: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org ] > > Sent: Tuesday, December 23, 2014 8:37 PM > > To: Varun Singh; Tirumaleswar Reddy (tireddy); Dan Wing (dwing); = Varun > > Singh; Tirumaleswar Reddy (tireddy); Pal Martinsen (palmarti); Dan > > Wing (dwing); Pal Martinsen (palmarti) > > Subject: New Version Notification for > > draft-reddy-tram-stun-path-data-00.txt > > > > > > A new version of I-D, draft-reddy-tram-stun-path-data-00.txt > > has been successfully submitted by Tirumaleswar Reddy and posted to > > the IETF repository. > > > > Name: draft-reddy-tram-stun-path-data > > Revision: 00 > > Title: Discovery of path characteristics using STUN > > Document date: 2014-12-23 > > Group: Individual Submission > > Pages: 9 > > URL: > > = http://www.ietf.org/internet-drafts/draft-reddy-tram-stun-path-data-00 > > .txt > > Status: > > https://datatracker.ietf.org/doc/draft-reddy-tram-stun-path-data/ > > Htmlized: > > http://tools.ietf.org/html/draft-reddy-tram-stun-path-data-00 > > > > > > Abstract: > > A host with multiple interfaces needs to choose the best = interface > > for communication. Oftentimes, this decision is based on a = static > > configuration and does not consider the path characteristics, = which > > may affect the user experience. > > > > This document describes a mechanism for an endpoint to discover = the > > path characteristics using Session Traversal Utilities for NAT = (STUN) > > messages. The measurement information can then be used to > influence > > the endpoint's Interactive Connectivity Establishment (ICE) = candidate > > pair selection algorithm. > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org =20 > > https://www.ietf.org/mailman/listinfo/tram > > > > > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org =20 > > https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org =20 https://www.ietf.org/mailman/listinfo/tram --=20 http://www.netlab.tkk.fi/~varun/ ------=_NextPart_000_000A_01D02144.98D3E260 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi, Varun,

 

ICE defines three types candidates: HOST CANDIDATE, REFELXTIVE = CANDIDATE, RELAY CANDIDATE.=C2=A0 For UE that has multiple = interfaces(for examples m interfaces), it will have 3*m CANDIDATE. If we = uses the mechanism that described in this draft to select the best local = interface, the UE must try all of these interfaces to send the STUN = request message. Correspondingly, the communication pair will try = =C2=A0[3*m]*[3*m] times connectivity check to find the path that has = best characteristics?

 

This will certainly make the connection process unacceptable. To = solve such problem, we should prefer the process that described in the = RFC5245(https://datatracker.ie= tf.org/doc/rfc5245/), =C2=A0section 4.1.2.=C2=A0 = =E2=80=9CPrioritizing Candidates=E2=80=9D first, then do the ICE = connectivity check in sequence. The prioritizing algorithm should = consider several factors, such as the security, prices, power = consumption etc. =C2=A0

 

The path characteristic, such as loss, RTT, jitter can also be = considered, but this information should be acquired via other out-band = method, not the in-band solution that described in this = draft.

 

Best Regards.

 

Aijun Wang.

 

From:= Varun = Singh [mailto:vsingh.ietf@gmail.com]
Sent: Friday, December = 26, 2014 5:35 AM
To: Aijun Wang
Cc: Tirumaleswar = Reddy (tireddy); tram@ietf.org
Subject: Re: [tram] FW: New = Version Notification for = draft-reddy-tram-stun-path-data-00.txt

<= p class=3DMsoNormal> 

Hi Aijun,

Comments = inline.

 

Cheers,

Varun. 

On Thursday, = December 25, 2014, Aijun Wang <wangaijun@tsinghua.org.cn&g= t; wrote:

Hi, Reddy

Please see the reply inline = below.

> -----Original Message-----
> From: Tirumaleswar = Reddy (tireddy) [mailto:tireddy@cisco.com]
> Sent: Wednesday, = December 24, 2014 6:03 PM
> To: Aijun Wang; tram@ietf.org
> Subject: RE: [tram] FW: = New Version Notification for
> = draft-reddy-tram-stun-path-data-00.txt
>
> > = -----Original Message-----
> > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Aijun = Wang
> > Sent: Wednesday, December 24, 2014 12:07 PM
> = > To: Tirumaleswar Reddy (tireddy); tram@ietf.org
> > Subject: Re: [tram] = FW: New Version Notification for
> > draft-reddy-tram-stun- = path-data-00.txt
> >
> > Hi, Reddy:
> = >
> > I doubt the feasibility of this probe process. For UE = that has
> > multiple interfaces, the OS of the UE will = automatically choose only
> > one default interface for = communicating.
>
> No, MPTCP on mobile devices already uses = multiple interfaces (for example
> Apple uses MPTCP for = Siri).  MPRTP (draft-ietf-avtcore-mprtp-00) also uses
> = multiple interfaces.
>


The purpose of MPTCP and MPRTP = is just contrary to your proposal. They just
want to utilize all the = available paths for TCP or RTP chunk data transport,
but this draft = just wants to select one best pair? On the other hand, = there

 

IMO the draft exposes two transport = characteristics: RTT measurement, and loss (upstream and downstream = path). While there may be additional metrics like jitter, power = consumption, and as you point out = money.

 

is also other factor = needed to be considered for selecting the underlying
network, for = example the prices of different connection. I think the = users
themselves should decide which one and how many interfaces can = be used for
data transfer, not one of the application on their = devices.

The users typically choose = interfaces (allowing access to the 3G/LTE at the system level, but = this can easily be exposed at the app level), which then becomes a = system policy. And this mechanism can still work by skipping = the candidate gathering phase for interfaces i.e., not = allowed access by user/system = settings.

 

> > According to = this draft, the ICE agent within the UE will try every
> > = possible interface to send the STUN packet?
> > This will = make
> > the connection time between two endpoints = unacceptable.
>
> The new attribute can be added to the STUN = binding request/response used
for
> ICE connectivity checks and = does not introduce any additional messages.
>
The checking = results can't be kept consistency all the time. How about = the
selected interface become congested when it begins to transfer = the chunk
data? From this point, the MPTCP and MPRTP may be more = reasonable solution.
It can balance between different = links/interfaces, not just select only one
that looks like = idle.

 

The metrics gathered from the = connectivity checks should be fed upwards into the rmcat or towards the = congestion control, which can make the appropriate = decision. 

 

> -Tiru
>
> >
> > Best = Regards.
> >
> > -----Original Message-----
> = > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of = Tirumaleswar
> > Reddy
> > (tireddy)
> > = Sent: Tuesday, December 23, 2014 11:29 PM
> > To: tram@ietf.org
> > Subject: [tram] FW: = New Version Notification for
> > draft-reddy-tram-stun-path- = data-00.txt
> >
> > This draft describes a mechanism = for an endpoint to discover the path
> > characteristics using = STUN.
> > Comments and suggestions are welcome.
> = >
> > -Tiru
> >
> > -----Original = Message-----
> > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > Sent: = Tuesday, December 23, 2014 8:37 PM
> > To: Varun Singh; = Tirumaleswar Reddy (tireddy); Dan Wing (dwing); Varun
> > = Singh; Tirumaleswar Reddy (tireddy); Pal Martinsen (palmarti); = Dan
> > Wing (dwing); Pal Martinsen (palmarti)
> > = Subject: New Version Notification for
> > = draft-reddy-tram-stun-path-data-00.txt
> >
> >
> = > A new version of I-D, = draft-reddy-tram-stun-path-data-00.txt
> > has been = successfully submitted by Tirumaleswar Reddy and posted to
> > = the IETF repository.
> >
> > Name:      =         =  draft-reddy-tram-stun-path-data
> > Revision:  =  00
> > Title:            =   Discovery of path characteristics using STUN
> > = Document date:      2014-12-23
> > Group:  =             Individual Submission
> = > Pages:              9
> = > URL:
> > http://www.ietf.org/internet-drafts/draft-reddy-tram-st= un-path-data-00
> > .txt
> > Status:
> > = https://datatracker.ietf.org/doc/draft-reddy-tram-stun-= path-data/
> > Htmlized:
> > http://tools.ietf.org/html/draft-reddy-tram-stun-path-d= ata-00
> >
> >
> > Abstract:
> = >    A host with multiple interfaces needs to choose the = best interface
> >    for communication.  = Oftentimes, this decision is based on a static
> >    = configuration and does not consider the path characteristics, = which
> >    may affect the user experience.
> = >
> >    This document describes a mechanism for = an endpoint to discover the
> >    path = characteristics using Session Traversal Utilities for NAT (STUN)
> = >    messages.  The measurement information can then = be used to
> influence
> >    the endpoint's = Interactive Connectivity Establishment (ICE) candidate
> = >    pair selection algorithm.
> >
> = >
> >
> >
> >
> > Please note = that it may take a couple of minutes from the time of
> > = submission until the htmlized version and diff are available at
tools.ietf.org.
> >
> > The IETF = Secretariat
> >
> > = _______________________________________________
> > 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

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



--
http://www.netlab.tkk.fi/~varun/<= /p>

------=_NextPart_000_000A_01D02144.98D3E260-- From nobody Sat Dec 27 06:33:08 2014 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 01CEF1ACD9C for ; Wed, 24 Dec 2014 05:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 73DhL9GIvVg2 for ; Wed, 24 Dec 2014 05:16:51 -0800 (PST) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 337761A038D for ; Wed, 24 Dec 2014 05:16:51 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id pn19so7012252lab.37 for ; Wed, 24 Dec 2014 05:16:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ekCAUCIc4z7aUagCOYea5k+AzmCPrb7SQT+gn6cVE5Y=; b=G23ep1YBI3p6IE9n8ml3i50JbKSErSE9Q6vc3SsaDS/P6JZtDBadifWRQu9J5wPELP gjhx0DzT9+ZKEif4EuTwaSUcXpkhhuJqv2cQdgL/XzVWOjeOneRxfH4ieghfmq2WpMR4 m97GSJJLVys/zhBJqjMDt6sBpBF5JM1vviBDXa6THhon4wRqrPShy/g/wwl7VlkPp8Js ZFZhYmrb2XIisw6Dq4U1T/csOHsUYY+097m9R+U2fnC+aLogt8ScdNlM4hc9DjUwZHik F6wS3y5eJjfBKwOI4eP3B3nuIgeb+ZVF2ORNX1DShGIM8qV4vVtn5n15Plt8tF9eI3lG Ybuw== MIME-Version: 1.0 X-Received: by 10.152.27.8 with SMTP id p8mr34352252lag.69.1419427009705; Wed, 24 Dec 2014 05:16:49 -0800 (PST) Received: by 10.112.25.5 with HTTP; Wed, 24 Dec 2014 05:16:49 -0800 (PST) In-Reply-To: <003301d01f44$086ad280$19407780$@org.cn> References: <20141223150647.4003.56437.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35523A3E@xmb-rcd-x10.cisco.com> <003301d01f44$086ad280$19407780$@org.cn> Date: Wed, 24 Dec 2014 15:16:49 +0200 Message-ID: From: Varun Singh To: Aijun Wang Content-Type: multipart/alternative; boundary=089e0160bdb2b2bbb0050af61ac5 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/FjVROTiCc9nL-4opZDz1_posss8 X-Mailman-Approved-At: Sat, 27 Dec 2014 06:33:07 -0800 Cc: "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 13:16:54 -0000 --089e0160bdb2b2bbb0050af61ac5 Content-Type: text/plain; charset=UTF-8 Hi, If we follow through with the proposal on continuous nomination, we should be able to pick better candidate pairs (based on loss, RTT) as and when they appear. However, we won't know the available capacity until we send media packets on it, but that is the job for the RTP congestion control to figure out anyway. Cheers, Varun. On Wednesday, December 24, 2014, Aijun Wang wrote: > Hi, Reddy: > > I doubt the feasibility of this probe process. For UE that has multiple > interfaces, the OS of the UE will automatically choose only one default > interface for communicating. According to this draft, the ICE agent within > the UE will try every possible interface to send the STUN packet? This will > make the connection time between two endpoints unacceptable. > > Best Regards. > > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org ] On Behalf Of > Tirumaleswar Reddy > (tireddy) > Sent: Tuesday, December 23, 2014 11:29 PM > To: tram@ietf.org > Subject: [tram] FW: New Version Notification for > draft-reddy-tram-stun-path-data-00.txt > > This draft describes a mechanism for an endpoint to discover the path > characteristics using STUN. > Comments and suggestions are welcome. > > -Tiru > > -----Original Message----- > From: internet-drafts@ietf.org [mailto: > internet-drafts@ietf.org ] > Sent: Tuesday, December 23, 2014 8:37 PM > To: Varun Singh; Tirumaleswar Reddy (tireddy); Dan Wing (dwing); Varun > Singh; Tirumaleswar Reddy (tireddy); Pal Martinsen (palmarti); Dan Wing > (dwing); Pal Martinsen (palmarti) > Subject: New Version Notification for > draft-reddy-tram-stun-path-data-00.txt > > > A new version of I-D, draft-reddy-tram-stun-path-data-00.txt > has been successfully submitted by Tirumaleswar Reddy and posted to the > IETF > repository. > > Name: draft-reddy-tram-stun-path-data > Revision: 00 > Title: Discovery of path characteristics using STUN > Document date: 2014-12-23 > Group: Individual Submission > Pages: 9 > URL: > http://www.ietf.org/internet-drafts/draft-reddy-tram-stun-path-data-00.txt > Status: > https://datatracker.ietf.org/doc/draft-reddy-tram-stun-path-data/ > Htmlized: > http://tools.ietf.org/html/draft-reddy-tram-stun-path-data-00 > > > Abstract: > A host with multiple interfaces needs to choose the best interface > for communication. Oftentimes, this decision is based on a static > configuration and does not consider the path characteristics, which > may affect the user experience. > > This document describes a mechanism for an endpoint to discover the > path characteristics using Session Traversal Utilities for NAT (STUN) > messages. The measurement information can then be used to influence > the endpoint's Interactive Connectivity Establishment (ICE) candidate > pair selection algorithm. > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > 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 > -- http://www.netlab.tkk.fi/~varun/ --089e0160bdb2b2bbb0050af61ac5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,

If we follow through with the proposal on continuous= =C2=A0nomination, we should be able to pick better candidate pairs (based o= n loss, RTT)=C2=A0as and when they appear. However, we won't know the a= vailable=C2=A0capacity until we send media packets on it, but that is=C2=A0= the job for the=C2=A0RTP=C2=A0congestion control to figure out anyway.=C2= =A0

Cheers,
Varun.=C2=A0

On Wedne= sday, December 24, 2014, Aijun Wang <wangaijun@tsinghua.org.cn> wrote:
Hi, Reddy:

I doubt the feasibility of this probe process. For UE that has multiple
interfaces, the OS of the UE will automatically choose only one default
interface for communicating. According to this draft, the ICE agent within<= br> the UE will try every possible interface to send the STUN packet? This will=
make the connection time between two endpoints unacceptable.

Best Regards.

-----Original Message-----
From: tram [mailto:tram-bounces@ietf.org] On Behal= f Of Tirumaleswar Reddy
(tireddy)
Sent: Tuesday, December 23, 2014 11:29 PM
To: tram@ietf.org
Subject: [tram] FW: New Version Notification for
draft-reddy-tram-stun-path-data-00.txt

This draft describes a mechanism for an endpoint to discover the path
characteristics using STUN.
Comments and suggestions are welcome.

-Tiru

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Tuesday, December 23, 2014 8:37 PM
To: Varun Singh; Tirumaleswar Reddy (tireddy); Dan Wing (dwing); Varun
Singh; Tirumaleswar Reddy (tireddy); Pal Martinsen (palmarti); Dan Wing
(dwing); Pal Martinsen (palmarti)
Subject: New Version Notification for draft-reddy-tram-stun-path-data-00.tx= t


A new version of I-D, draft-reddy-tram-stun-path-data-00.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the IET= F
repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-reddy-tram-stun-path-da= ta
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Discovery of path characteristics = using STUN
Document date:=C2=A0 2014-12-23
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 9
URL:
http://www.ietf.org/internet-drafts/draft-red= dy-tram-stun-path-data-00.txt
Status:
https://datatracker.ietf.org/doc/draft-reddy-tram-stun= -path-data/
Htmlized:
http://tools.ietf.org/html/draft-reddy-tram-stun-path-data= -00


Abstract:
=C2=A0 =C2=A0A host with multiple interfaces needs to choose the best inter= face
=C2=A0 =C2=A0for communication.=C2=A0 Oftentimes, this decision is based on= a static
=C2=A0 =C2=A0configuration and does not consider the path characteristics, = which
=C2=A0 =C2=A0may affect the user experience.

=C2=A0 =C2=A0This document describes a mechanism for an endpoint to discove= r the
=C2=A0 =C2=A0path characteristics using Session Traversal Utilities for NAT= (STUN)
=C2=A0 =C2=A0messages.=C2=A0 The measurement information can then be used t= o influence
=C2=A0 =C2=A0the endpoint's Interactive Connectivity Establishment (ICE= ) candidate
=C2=A0 =C2=A0pair selection algorithm.





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram



_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


--
http://www.netlab.tkk.fi/~varun/
--089e0160bdb2b2bbb0050af61ac5-- From nobody Sat Dec 27 06:33:09 2014 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 663AD1A1A9F for ; Thu, 25 Dec 2014 13:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 yKo5-64qpE5o for ; Thu, 25 Dec 2014 13:34:53 -0800 (PST) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DE711A1A9C for ; Thu, 25 Dec 2014 13:34:52 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id gm9so8055559lab.40 for ; Thu, 25 Dec 2014 13:34:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bUvSTtPO0xE6PW3mun0xQc98Hszej/zYmhsmEpkgLI4=; b=UiA33Pd8RPrd230Y71Bv3DWy/AUDGmbJ/sY+JRTcBlqSOjaJ4vSpRNUWEGAHwDNTj2 58VCdFMSV1W5nhqkaWNXtJT1zaBGQs1R5RpZYxu1luo60OWR48xh+8K5MhrpCKxl2zQG +UsuXSGJanEbzFOSwpJkl+oPeqXobWSGrseC+35UqMnxKOc2SVRCrnKG47iN26DYX5e3 icievEiRmnWnoGrubN4hkyqLxe0KfwECrY49dSFpQKFLn+MGd69h5O6Eg39zZiyLspHv qp0WC41sL8+r99npZPL58AE4vHzkj7JaZGKRNRwSgeevAogyRiU9u/BylDJOGmzE2TFJ G87w== MIME-Version: 1.0 X-Received: by 10.112.159.129 with SMTP id xc1mr40729089lbb.24.1419543290702; Thu, 25 Dec 2014 13:34:50 -0800 (PST) Received: by 10.112.25.5 with HTTP; Thu, 25 Dec 2014 13:34:50 -0800 (PST) In-Reply-To: <005c01d02060$e81da2f0$b858e8d0$@org.cn> References: <20141223150647.4003.56437.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35523A3E@xmb-rcd-x10.cisco.com> <003301d01f44$086ad280$19407780$@org.cn> <913383AAA69FF945B8F946018B75898A35523F70@xmb-rcd-x10.cisco.com> <005c01d02060$e81da2f0$b858e8d0$@org.cn> Date: Thu, 25 Dec 2014 23:34:50 +0200 Message-ID: From: Varun Singh To: Aijun Wang Content-Type: multipart/alternative; boundary=001a11c313ac95f2cc050b112d63 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/_GyW7uIS2RnSTqCOc2_sA_HM5mw X-Mailman-Approved-At: Sat, 27 Dec 2014 06:33:07 -0800 Cc: "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 21:34:56 -0000 --001a11c313ac95f2cc050b112d63 Content-Type: text/plain; charset=UTF-8 Hi Aijun, Comments inline. Cheers, Varun. On Thursday, December 25, 2014, Aijun Wang wrote: > Hi, Reddy > > Please see the reply inline below. > > > -----Original Message----- > > From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com > ] > > Sent: Wednesday, December 24, 2014 6:03 PM > > To: Aijun Wang; tram@ietf.org > > Subject: RE: [tram] FW: New Version Notification for > > draft-reddy-tram-stun-path-data-00.txt > > > > > -----Original Message----- > > > From: tram [mailto:tram-bounces@ietf.org ] On Behalf Of > Aijun Wang > > > Sent: Wednesday, December 24, 2014 12:07 PM > > > To: Tirumaleswar Reddy (tireddy); tram@ietf.org > > > Subject: Re: [tram] FW: New Version Notification for > > > draft-reddy-tram-stun- path-data-00.txt > > > > > > Hi, Reddy: > > > > > > I doubt the feasibility of this probe process. For UE that has > > > multiple interfaces, the OS of the UE will automatically choose only > > > one default interface for communicating. > > > > No, MPTCP on mobile devices already uses multiple interfaces (for example > > Apple uses MPTCP for Siri). MPRTP (draft-ietf-avtcore-mprtp-00) also > uses > > multiple interfaces. > > > > > The purpose of MPTCP and MPRTP is just contrary to your proposal. They just > want to utilize all the available paths for TCP or RTP chunk data > transport, > but this draft just wants to select one best pair? On the other hand, there IMO the draft exposes two transport characteristics: RTT measurement, and loss (upstream and downstream path). While there may be additional metrics like jitter, power consumption, and as you point out money. > is also other factor needed to be considered for selecting the underlying > network, for example the prices of different connection. I think the users > themselves should decide which one and how many interfaces can be used for > data transfer, not one of the application on their devices. > > The users typically choose interfaces (allowing access to the 3G/LTE at the system level, but this can easily be exposed at the app level), which then becomes a system policy. And this mechanism can still work by skipping the candidate gathering phase for interfaces i.e., not allowed access by user/system settings. > > > According to this draft, the ICE agent within the UE will try every > > > possible interface to send the STUN packet? > > > This will make > > > the connection time between two endpoints unacceptable. > > > > The new attribute can be added to the STUN binding request/response used > for > > ICE connectivity checks and does not introduce any additional messages. > > > The checking results can't be kept consistency all the time. How about the > selected interface become congested when it begins to transfer the chunk > data? From this point, the MPTCP and MPRTP may be more reasonable solution. > It can balance between different links/interfaces, not just select only one > that looks like idle. > > The metrics gathered from the connectivity checks should be fed upwards into the rmcat or towards the congestion control, which can make the appropriate decision. > > -Tiru > > > > > > > > Best Regards. > > > > > > -----Original Message----- > > > From: tram [mailto:tram-bounces@ietf.org ] On Behalf Of > Tirumaleswar > > > Reddy > > > (tireddy) > > > Sent: Tuesday, December 23, 2014 11:29 PM > > > To: tram@ietf.org > > > Subject: [tram] FW: New Version Notification for > > > draft-reddy-tram-stun-path- data-00.txt > > > > > > This draft describes a mechanism for an endpoint to discover the path > > > characteristics using STUN. > > > Comments and suggestions are welcome. > > > > > > -Tiru > > > > > > -----Original Message----- > > > From: internet-drafts@ietf.org [mailto: > internet-drafts@ietf.org ] > > > Sent: Tuesday, December 23, 2014 8:37 PM > > > To: Varun Singh; Tirumaleswar Reddy (tireddy); Dan Wing (dwing); Varun > > > Singh; Tirumaleswar Reddy (tireddy); Pal Martinsen (palmarti); Dan > > > Wing (dwing); Pal Martinsen (palmarti) > > > Subject: New Version Notification for > > > draft-reddy-tram-stun-path-data-00.txt > > > > > > > > > A new version of I-D, draft-reddy-tram-stun-path-data-00.txt > > > has been successfully submitted by Tirumaleswar Reddy and posted to > > > the IETF repository. > > > > > > Name: draft-reddy-tram-stun-path-data > > > Revision: 00 > > > Title: Discovery of path characteristics using STUN > > > Document date: 2014-12-23 > > > Group: Individual Submission > > > Pages: 9 > > > URL: > > > http://www.ietf.org/internet-drafts/draft-reddy-tram-stun-path-data-00 > > > .txt > > > Status: > > > https://datatracker.ietf.org/doc/draft-reddy-tram-stun-path-data/ > > > Htmlized: > > > http://tools.ietf.org/html/draft-reddy-tram-stun-path-data-00 > > > > > > > > > Abstract: > > > A host with multiple interfaces needs to choose the best interface > > > for communication. Oftentimes, this decision is based on a static > > > configuration and does not consider the path characteristics, which > > > may affect the user experience. > > > > > > This document describes a mechanism for an endpoint to discover the > > > path characteristics using Session Traversal Utilities for NAT > (STUN) > > > messages. The measurement information can then be used to > > influence > > > the endpoint's Interactive Connectivity Establishment (ICE) > candidate > > > pair selection algorithm. > > > > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > > > The IETF Secretariat > > > > > > _______________________________________________ > > > 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 > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > -- http://www.netlab.tkk.fi/~varun/ --001a11c313ac95f2cc050b112d63 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Aijun,

Comments inline.

Cheers,
Varu= n.=C2=A0

On Thursday, December 25, 2014, Aijun Wang <wangaijun@tsinghua.org.cn> wrote:
Hi, Reddy

Please see the reply inline below.

> -----Original Message-----
> From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@ci= sco.com]
> Sent: Wednesday, December 24, 2014 6:03 PM
> To: Aijun Wang; tram@ietf.org
> Subject: RE: [tram] FW: New Version Notification for
> draft-reddy-tram-stun-path-data-00.txt
>
> > -----Original Message-----
> > From: tram [mailto:tram-bounces@ietf.org= ] On Behalf Of Aijun Wang
> > Sent: Wednesday, December 24, 2014 12:07 PM
> > To: Tirumaleswar Reddy (tireddy); tram@ietf.org<= br> > > Subject: Re: [tram] FW: New Version Notification for
> > draft-reddy-tram-stun- path-data-00.txt
> >
> > Hi, Reddy:
> >
> > I doubt the feasibility of this probe process. For UE that has > > multiple interfaces, the OS of the UE will automatically choose o= nly
> > one default interface for communicating.
>
> No, MPTCP on mobile devices already uses multiple interfaces (for exam= ple
> Apple uses MPTCP for Siri).=C2=A0 MPRTP (draft-ietf-avtcore-mprtp-00) = also uses
> multiple interfaces.
>


The purpose of MPTCP and MPRTP is just contrary to your proposal. They just=
want to utilize all the available paths for TCP or RTP chunk data transport= ,
but this draft just wants to select one best pair? On the other hand, there=

IMO the draft exposes two transport charac= teristics: RTT measurement, and loss (upstream and downstream path). While = there may be additional metrics like jitter, power consumption,=C2=A0and as= you point out money.
=C2=A0
is also other factor needed to be considered for selecting the underlying network, for example the prices of different connection. I think the users<= br> themselves should decide which one and how many interfaces can be used for<= br> data transfer, not one of the application on their devices.

The users typically choose interfaces (allowing acces= s to the=C2=A03G/LTE at the system level, but this can easily be exposed at= the app level), which then becomes=C2=A0a system policy. And this mechanis= m can still work by skipping the=C2=A0candidate gathering phase=C2=A0for in= terfaces i.e.,=C2=A0not allowed access by user/system settings.
= =C2=A0
> > According to this draft, the ICE agent within the UE will try eve= ry
> > possible interface to send the STUN packet?
> > This will make
> > the connection time between two endpoints unacceptable.
>
> The new attribute can be added to the STUN binding request/response us= ed
for
> ICE connectivity checks and does not introduce any additional messages= .
>
The checking results can't be kept consistency all the time. How about = the
selected interface become congested when it begins to transfer the chunk data? From this point, the MPTCP and MPRTP may be more reasonable solution.=
It can balance between different links/interfaces, not just select only one=
that looks like idle.


The metrics gathered from the connectivity = checks should be fed upwards into the rmcat or towards the congestion contr= ol, which can make the appropriate decision.=C2=A0
=C2=A0
> -Tiru
>
> >
> > Best Regards.
> >
> > -----Original Message-----
> > From: tram [mailto:tram-bounces@ietf.org= ] On Behalf Of Tirumaleswar
> > Reddy
> > (tireddy)
> > Sent: Tuesday, December 23, 2014 11:29 PM
> > To: tram@ietf.org
> > Subject: [tram] FW: New Version Notification for
> > draft-reddy-tram-stun-path- data-00.txt
> >
> > This draft describes a mechanism for an endpoint to discover the = path
> > characteristics using STUN.
> > Comments and suggestions are welcome.
> >
> > -Tiru
> >
> > -----Original Message-----
> > From: internet-drafts@ietf.org [mailt= o:internet-drafts@ietf.org]
> > Sent: Tuesday, December 23, 2014 8:37 PM
> > To: Varun Singh; Tirumaleswar Reddy (tireddy); Dan Wing (dwing); = Varun
> > Singh; Tirumaleswar Reddy (tireddy); Pal Martinsen (palmarti); Da= n
> > Wing (dwing); Pal Martinsen (palmarti)
> > Subject: New Version Notification for
> > draft-reddy-tram-stun-path-data-00.txt
> >
> >
> > A new version of I-D, draft-reddy-tram-stun-path-data-00.txt
> > has been successfully submitted by Tirumaleswar Reddy and posted = to
> > the IETF repository.
> >
> > Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft= -reddy-tram-stun-path-data
> > Revision:=C2=A0 =C2=A000
> > Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Discovery = of path characteristics using STUN
> > Document date:=C2=A0 =C2=A0 =C2=A0 2014-12-23
> > Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual= Submission
> > Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 9
> > URL:
> > http://www.ietf.org/internet-drafts/dra= ft-reddy-tram-stun-path-data-00
> > .txt
> > Status:
> > https://datatracker.ietf.org/doc/draft-reddy= -tram-stun-path-data/
> > Htmlized:
> > http://tools.ietf.org/html/draft-reddy-tram-stun= -path-data-00
> >
> >
> > Abstract:
> >=C2=A0 =C2=A0 A host with multiple interfaces needs to choose the = best interface
> >=C2=A0 =C2=A0 for communication.=C2=A0 Oftentimes, this decision i= s based on a static
> >=C2=A0 =C2=A0 configuration and does not consider the path charact= eristics, which
> >=C2=A0 =C2=A0 may affect the user experience.
> >
> >=C2=A0 =C2=A0 This document describes a mechanism for an endpoint = to discover the
> >=C2=A0 =C2=A0 path characteristics using Session Traversal Utiliti= es for NAT (STUN)
> >=C2=A0 =C2=A0 messages.=C2=A0 The measurement information can then= be used to
> influence
> >=C2=A0 =C2=A0 the endpoint's Interactive Connectivity Establis= hment (ICE) candidate
> >=C2=A0 =C2=A0 pair selection algorithm.
> >
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of=
> > submission until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >
> > _______________________________________________
> > 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



_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


--
http://www.netlab.tkk.fi/~varun/
--001a11c313ac95f2cc050b112d63-- From nobody Sat Dec 27 06:33:11 2014 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 A0ECF1A912B for ; Fri, 26 Dec 2014 10:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 MxsQtqFpNBPp for ; Fri, 26 Dec 2014 10:29:56 -0800 (PST) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C42541A9123 for ; Fri, 26 Dec 2014 10:29:55 -0800 (PST) Received: by mail-la0-f48.google.com with SMTP id gf13so8833764lab.7 for ; Fri, 26 Dec 2014 10:29:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=+nfizA0IwBWGxrH4kW3ybLDyB533RaiEYP3att0JBH8=; b=DM9PCa3IhVtvKY7ZrM/SflWzmZuoxIjNXdM0Bp/FttUPc2jogIdy3R+Brjz+ijClbl 7ELU0aXba2Ujkb/o33ocie0q911Rm40SBTJ/6CX2FOZGmPg1VP/f/p7mgPM57KgTcZAn OAY9WRrWOTuSgAbx93KsW9/TCX7dci+IvBhewVQh9YZLofDp16LfRTzsPHVAc7VHL7jX UHXY0/wkOIZLFcG2SZwMQ9208YaGtuoGurAnwM+y8Wu60Qkl5FCHyeX8mD57M6u5Hb/a Fmb/Ta5doB3sZ5Nic1PwTyqY+38e7KzvGAcy193QtrPKUj9KWRVAZ/0D9Tjg4BH8G5U0 ecsw== X-Received: by 10.112.169.67 with SMTP id ac3mr44716336lbc.83.1419618594236; Fri, 26 Dec 2014 10:29:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.25.5 with HTTP; Fri, 26 Dec 2014 10:29:33 -0800 (PST) In-Reply-To: <000901d02101$8ab0a260$a011e720$@org.cn> References: <20141223150647.4003.56437.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35523A3E@xmb-rcd-x10.cisco.com> <003301d01f44$086ad280$19407780$@org.cn> <913383AAA69FF945B8F946018B75898A35523F70@xmb-rcd-x10.cisco.com> <005c01d02060$e81da2f0$b858e8d0$@org.cn> <000901d02101$8ab0a260$a011e720$@org.cn> From: Varun Singh Date: Fri, 26 Dec 2014 20:29:33 +0200 Message-ID: To: Aijun Wang Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tram/22yDXv7O4C3Ir_puro7M_U2xmNg X-Mailman-Approved-At: Sat, 27 Dec 2014 06:33:07 -0800 Cc: "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Dec 2014 18:29:58 -0000 Hi Aijun, Responses inline. On Fri, Dec 26, 2014 at 1:45 PM, Aijun Wang wro= te: > Hi, Varun, > > > > ICE defines three types candidates: HOST CANDIDATE, REFELXTIVE CANDIDATE, > RELAY CANDIDATE. For UE that has multiple interfaces(for examples m > interfaces), it will have 3*m CANDIDATE. If we uses the mechanism that > described in this draft to select the best local interface, the UE must t= ry > all of these interfaces to send the STUN request message. Correspondingly= , > the communication pair will try [3*m]*[3*m] times connectivity check to > find the path that has best characteristics? > IMO, the endpoint would have to check the gathered interfaces any way. RFC5= 245 describes two mechanisms: Aggressive and Regular nomination to finally pick= the candidate pair to send media (Section 8.1.1.x). This draft proposes that the endpoint could use the candidate pair with better path characteristics instead of picking the highest priority pair. > > > This will certainly make the connection process unacceptable. To solve su= ch > problem, we should prefer the process that described in the > RFC5245(https://datatracker.ietf.org/doc/rfc5245/), section 4.1.2. > =E2=80=9CPrioritizing Candidates=E2=80=9D first, then do the ICE connecti= vity check in > sequence. The prioritizing algorithm should consider several factors, suc= h > as the security, prices, power consumption etc. > I may be wrong, but the co-authors should correct me: AFAIU the proposal do= es not change the order or the testing the list of candidates, but the outcome of the testing. i.e., once the candidates have been ordered and tested, the endpoi= nt can use the candidate pair with better path characteristics even though it = has a lower priority compared to the other successful candidates. Further, this should be information > > > The path characteristic, such as loss, RTT, jitter can also be considered= , > but this information should be acquired via other out-band method, not th= e > in-band solution that described in this draft. Sure, out-of-band mechanisms can be used as well. However, the endpoints ar= e anyway performing connectivity checks, it provides a perfect opportunity to= get some measurements before sending any media packets on those paths. Further, the STUN packets are good enough for performing RTT measurements as they are sent out at regular intervals. > > > > Best Regards. > > > > Aijun Wang. > > > > From: Varun Singh [mailto:vsingh.ietf@gmail.com] > Sent: Friday, December 26, 2014 5:35 AM > To: Aijun Wang > Cc: Tirumaleswar Reddy (tireddy); tram@ietf.org > > > Subject: Re: [tram] FW: New Version Notification for > draft-reddy-tram-stun-path-data-00.txt > > > > Hi Aijun, > > Comments inline. > > > > Cheers, > > Varun. > > On Thursday, December 25, 2014, Aijun Wang > wrote: > > Hi, Reddy > > Please see the reply inline below. > >> -----Original Message----- >> From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] >> Sent: Wednesday, December 24, 2014 6:03 PM >> To: Aijun Wang; tram@ietf.org >> Subject: RE: [tram] FW: New Version Notification for >> draft-reddy-tram-stun-path-data-00.txt >> >> > -----Original Message----- >> > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Aijun Wang >> > Sent: Wednesday, December 24, 2014 12:07 PM >> > To: Tirumaleswar Reddy (tireddy); tram@ietf.org >> > Subject: Re: [tram] FW: New Version Notification for >> > draft-reddy-tram-stun- path-data-00.txt >> > >> > Hi, Reddy: >> > >> > I doubt the feasibility of this probe process. For UE that has >> > multiple interfaces, the OS of the UE will automatically choose only >> > one default interface for communicating. >> >> No, MPTCP on mobile devices already uses multiple interfaces (for exampl= e >> Apple uses MPTCP for Siri). MPRTP (draft-ietf-avtcore-mprtp-00) also us= es >> multiple interfaces. >> > > > The purpose of MPTCP and MPRTP is just contrary to your proposal. They ju= st > want to utilize all the available paths for TCP or RTP chunk data transpo= rt, > but this draft just wants to select one best pair? On the other hand, the= re > > > > IMO the draft exposes two transport characteristics: RTT measurement, and > loss (upstream and downstream path). While there may be additional metric= s > like jitter, power consumption, and as you point out money. > > > > is also other factor needed to be considered for selecting the underlying > network, for example the prices of different connection. I think the user= s > themselves should decide which one and how many interfaces can be used fo= r > data transfer, not one of the application on their devices. > > The users typically choose interfaces (allowing access to the 3G/LTE at t= he > system level, but this can easily be exposed at the app level), which the= n > becomes a system policy. And this mechanism can still work by skipping th= e > candidate gathering phase for interfaces i.e., not allowed access by > user/system settings. > > > >> > According to this draft, the ICE agent within the UE will try every >> > possible interface to send the STUN packet? >> > This will make >> > the connection time between two endpoints unacceptable. >> >> The new attribute can be added to the STUN binding request/response used > for >> ICE connectivity checks and does not introduce any additional messages. >> > The checking results can't be kept consistency all the time. How about th= e > selected interface become congested when it begins to transfer the chunk > data? From this point, the MPTCP and MPRTP may be more reasonable solutio= n. > It can balance between different links/interfaces, not just select only o= ne > that looks like idle. > > > > The metrics gathered from the connectivity checks should be fed upwards i= nto > the rmcat or towards the congestion control, which can make the appropria= te > decision. > > > >> -Tiru >> >> > >> > Best Regards. >> > >> > -----Original Message----- >> > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Tirumaleswar >> > Reddy >> > (tireddy) >> > Sent: Tuesday, December 23, 2014 11:29 PM >> > To: tram@ietf.org >> > Subject: [tram] FW: New Version Notification for >> > draft-reddy-tram-stun-path- data-00.txt >> > >> > This draft describes a mechanism for an endpoint to discover the path >> > characteristics using STUN. >> > Comments and suggestions are welcome. >> > >> > -Tiru >> > >> > -----Original Message----- >> > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> > Sent: Tuesday, December 23, 2014 8:37 PM >> > To: Varun Singh; Tirumaleswar Reddy (tireddy); Dan Wing (dwing); Varun >> > Singh; Tirumaleswar Reddy (tireddy); Pal Martinsen (palmarti); Dan >> > Wing (dwing); Pal Martinsen (palmarti) >> > Subject: New Version Notification for >> > draft-reddy-tram-stun-path-data-00.txt >> > >> > >> > A new version of I-D, draft-reddy-tram-stun-path-data-00.txt >> > has been successfully submitted by Tirumaleswar Reddy and posted to >> > the IETF repository. >> > >> > Name: draft-reddy-tram-stun-path-data >> > Revision: 00 >> > Title: Discovery of path characteristics using STUN >> > Document date: 2014-12-23 >> > Group: Individual Submission >> > Pages: 9 >> > URL: >> > http://www.ietf.org/internet-drafts/draft-reddy-tram-stun-path-data-00 >> > .txt >> > Status: >> > https://datatracker.ietf.org/doc/draft-reddy-tram-stun-path-data/ >> > Htmlized: >> > http://tools.ietf.org/html/draft-reddy-tram-stun-path-data-00 >> > >> > >> > Abstract: >> > A host with multiple interfaces needs to choose the best interface >> > for communication. Oftentimes, this decision is based on a static >> > configuration and does not consider the path characteristics, which >> > may affect the user experience. >> > >> > This document describes a mechanism for an endpoint to discover the >> > path characteristics using Session Traversal Utilities for NAT (STU= N) >> > messages. The measurement information can then be used to >> influence >> > the endpoint's Interactive Connectivity Establishment (ICE) candida= te >> > pair selection algorithm. >> > >> > >> > >> > >> > >> > Please note that it may take a couple of minutes from the time of >> > submission until the htmlized version and diff are available at > tools.ietf.org. >> > >> > The IETF Secretariat >> > >> > _______________________________________________ >> > 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 > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > > -- > http://www.netlab.tkk.fi/~varun/ --=20 http://www.netlab.tkk.fi/~varun/ From nobody Mon Dec 29 06:48:12 2014 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 C05531A3BA3 for ; Mon, 29 Dec 2014 06:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ATyGIxCZmSy0 for ; Mon, 29 Dec 2014 06:48:09 -0800 (PST) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 548381A3B9B for ; Mon, 29 Dec 2014 06:48:09 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id p9so10835338lbv.7 for ; Mon, 29 Dec 2014 06:48:07 -0800 (PST) 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=eumLj8JjvyS4B1D4pLtl2pE73l3c1fEOFkxUuSgkvvg=; b=MDhKrEYdlw0YzXYS36sCNnTZLYakiy9A+27rmxNRGskn5hrCCl3EVoB7M8g5GHUdac jNhRNf/IiOsKPLgJ1438G+TMlgIP35hBg7QthxbnAWIUMq4g8YBtOf9gT2y/z5uWQ/aM WIF1y/cEcH6/pj+Lz8O+B5uTpL5HEvoJ0OLNH+3eE85FhUkM22uYOAePpzEbbxWlVusL GV3n+8YCv3g46AsfhPKK9fRQ2E8fx2MiLEE+6wUG3QpPiEWckN5bOVolzdH78YhLnqaj o8IV1Bj2gmuBHg5SqjlnKDh0rh81g0lhdRhek48V8H7+BQs0RnP4a6dj/dI3Chn3L4p3 E86g== X-Gm-Message-State: ALoCoQkVYgSGHj+MilBgP+Vb4oHBFMMkctWCNLFw1RkVzYFFLiX2A6Qso4ukYZgWbiDzQlbqNJ+t MIME-Version: 1.0 X-Received: by 10.112.55.101 with SMTP id r5mr39493302lbp.98.1419864487731; Mon, 29 Dec 2014 06:48:07 -0800 (PST) Received: by 10.25.84.145 with HTTP; Mon, 29 Dec 2014 06:48:07 -0800 (PST) In-Reply-To: <000901d02101$8ab0a260$a011e720$@org.cn> References: <20141223150647.4003.56437.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35523A3E@xmb-rcd-x10.cisco.com> <003301d01f44$086ad280$19407780$@org.cn> <913383AAA69FF945B8F946018B75898A35523F70@xmb-rcd-x10.cisco.com> <005c01d02060$e81da2f0$b858e8d0$@org.cn> <000901d02101$8ab0a260$a011e720$@org.cn> Date: Mon, 29 Dec 2014 09:48:07 -0500 Message-ID: From: Simon Perreault To: Aijun Wang Content-Type: multipart/alternative; boundary=001a1133d0b86bbf90050b5bf617 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/mTVBIrJfG6HGCYtQ2XZB2Z9IsOg Cc: "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" , Varun Singh Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 14:48:10 -0000 --001a1133d0b86bbf90050b5bf617 Content-Type: text/plain; charset=UTF-8 On Fri, Dec 26, 2014 at 6:45 AM, Aijun Wang wrote: > > ICE defines three types candidates: HOST CANDIDATE, REFELXTIVE CANDIDATE, > RELAY CANDIDATE. For UE that has multiple interfaces(for examples m > interfaces), it will have 3*m CANDIDATE. If we uses the mechanism that > described in this draft to select the best local interface, the UE must try > all of these interfaces to send the STUN request message. Correspondingly, > the communication pair will try [3*m]*[3*m] times connectivity check to > find the path that has best characteristics? > > > > This will certainly make the connection process unacceptable. > The ICE process is already how you describe (except there's usually only 1 relayed candidate per address family). That's why e.g., trickle ICE was created: to speed things up. This draft doesn't change the number of messages or candidates, so I view this line of argument as applying to ICE in general, and therefore irrelevant to this draft. Simon --001a1133d0b86bbf90050b5bf617 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, Dec 26, 2014 at 6:45 AM, Aijun Wang <wangaijun@tsinghua.= org.cn> wrote:

ICE defines three types ca= ndidates: HOST CANDIDATE, REFELXTIVE CANDIDATE, RELAY CANDIDATE.=C2=A0 For = UE that has multiple interfaces(for examples m interfaces), it will have 3*= m CANDIDATE. If we uses the mechanism that described in this draft to selec= t the best local interface, the UE must try all of these interfaces to send= the STUN request message. Correspondingly, the communication pair will try= =C2=A0[3*m]*[3*m] times connectivity check to find the path that has best = characteristics?

=C2=A0

This will certainly ma= ke the connection process unacceptable.


Th= e ICE process is already how you describe (except there's usually only = 1 relayed candidate per address family). That's why e.g., trickle ICE w= as created: to speed things up.

<= div class=3D"gmail_extra">This draft doesn't change the number of messa= ges or candidates, so I view this line of argument as applying to ICE in ge= neral, and therefore irrelevant to this draft.

Simon
--001a1133d0b86bbf90050b5bf617-- From nobody Mon Dec 29 06:51:32 2014 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 1F48F1A6EDE for ; Mon, 29 Dec 2014 06:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 M1QwCJ1oji5E for ; Mon, 29 Dec 2014 06:51:28 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41FF01A6ED9 for ; Mon, 29 Dec 2014 06:51:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14234; q=dns/txt; s=iport; t=1419864688; x=1421074288; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=QBjdnLhlmy8m6NUcSfZbWWIHi8sO8UtGXmwUxFwA7LE=; b=SwwcxAP1sawiLbWOOkykIi2aFbuHTIj8jfj8tSf+LMGioUmRlySRtKZu zas3BAbjT3YivhfdFeAO3hiO21/Cpydywk5DpZl5OGCcAidhIy4JtBOQE hfbX+b9mj3rkknmsbkZFkyDAkfrqViS9UNYMIJrlTwWhoyWWhxWtU7bOZ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksFAPRpoVStJV2Y/2dsb2JhbABcFoJwUlgEgwHBR4IbCoVzAhxxFgEBAQEBfYQMAQEBAwEBAQELFRExCQkCBQcGAQgOAwQBAQECAgYdAwIEHwYLFAEHAQkBBAEJBAUIARKHfQMJCA2uNo9kDYUJAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiGyDQIFcHRYbDYJiLoETBY4Vgz+Bf4FxglEwgjWIBwOCG4M5IoIygTxvgUV+AQEB X-IronPort-AV: E=Sophos;i="5.07,659,1413244800"; d="scan'208";a="108999387" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-3.cisco.com with ESMTP; 29 Dec 2014 14:51:27 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sBTEpQYF031552 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Dec 2014 14:51:26 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.58]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Mon, 29 Dec 2014 08:51:26 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Varun Singh , Aijun Wang Thread-Topic: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt Thread-Index: AdAjdry5gd8ZnQtkQa+oHEpYeRu26w== Date: Mon, 29 Dec 2014 14:51:26 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A35525139@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.71.222] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/tMiWG94o6gu9PffqToD_qGaWUPE Cc: "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 14:51:31 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBWYXJ1biBTaW5naCBbbWFpbHRv OnZzaW5naC5pZXRmQGdtYWlsLmNvbV0NCj4gU2VudDogU2F0dXJkYXksIERlY2VtYmVyIDI3LCAy MDE0IDEyOjAwIEFNDQo+IFRvOiBBaWp1biBXYW5nDQo+IENjOiBUaXJ1bWFsZXN3YXIgUmVkZHkg KHRpcmVkZHkpOyB0cmFtQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdHJhbV0gRlc6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcmVkZHktdHJhbS1zdHVuLQ0KPiBwYXRoLWRh dGEtMDAudHh0DQo+IA0KPiBIaSBBaWp1biwNCj4gDQo+IFJlc3BvbnNlcyBpbmxpbmUuDQo+IA0K PiBPbiBGcmksIERlYyAyNiwgMjAxNCBhdCAxOjQ1IFBNLCBBaWp1biBXYW5nIDx3YW5nYWlqdW5A dHNpbmdodWEub3JnLmNuPg0KPiB3cm90ZToNCj4gPiBIaSwgVmFydW4sDQo+ID4NCj4gPg0KPiA+ DQo+ID4gSUNFIGRlZmluZXMgdGhyZWUgdHlwZXMgY2FuZGlkYXRlczogSE9TVCBDQU5ESURBVEUs IFJFRkVMWFRJVkUNCj4gPiBDQU5ESURBVEUsIFJFTEFZIENBTkRJREFURS4gIEZvciBVRSB0aGF0 IGhhcyBtdWx0aXBsZSBpbnRlcmZhY2VzKGZvcg0KPiA+IGV4YW1wbGVzIG0gaW50ZXJmYWNlcyks IGl0IHdpbGwgaGF2ZSAzKm0gQ0FORElEQVRFLiBJZiB3ZSB1c2VzIHRoZQ0KPiA+IG1lY2hhbmlz bSB0aGF0IGRlc2NyaWJlZCBpbiB0aGlzIGRyYWZ0IHRvIHNlbGVjdCB0aGUgYmVzdCBsb2NhbA0K PiA+IGludGVyZmFjZSwgdGhlIFVFIG11c3QgdHJ5IGFsbCBvZiB0aGVzZSBpbnRlcmZhY2VzIHRv IHNlbmQgdGhlIFNUVU4NCj4gPiByZXF1ZXN0IG1lc3NhZ2UuIENvcnJlc3BvbmRpbmdseSwgdGhl IGNvbW11bmljYXRpb24gcGFpciB3aWxsIHRyeQ0KPiA+IFszKm1dKlszKm1dIHRpbWVzIGNvbm5l Y3Rpdml0eSBjaGVjayB0byBmaW5kIHRoZSBwYXRoIHRoYXQgaGFzIGJlc3QNCj4gY2hhcmFjdGVy aXN0aWNzPw0KPiA+DQo+IA0KPiBJTU8sIHRoZSBlbmRwb2ludCB3b3VsZCBoYXZlIHRvIGNoZWNr IHRoZSBnYXRoZXJlZCBpbnRlcmZhY2VzIGFueSB3YXkuDQo+IFJGQzUyNDUgZGVzY3JpYmVzIHR3 byBtZWNoYW5pc21zOiBBZ2dyZXNzaXZlIGFuZCBSZWd1bGFyIG5vbWluYXRpb24gdG8NCj4gZmlu YWxseSBwaWNrIHRoZSBjYW5kaWRhdGUgcGFpciB0byBzZW5kIG1lZGlhIChTZWN0aW9uIDguMS4x LngpLg0KPiANCj4gVGhpcyBkcmFmdCBwcm9wb3NlcyB0aGF0IHRoZSBlbmRwb2ludCBjb3VsZCB1 c2UgdGhlIGNhbmRpZGF0ZSBwYWlyIHdpdGgNCj4gYmV0dGVyIHBhdGggY2hhcmFjdGVyaXN0aWNz IGluc3RlYWQgb2YgcGlja2luZyB0aGUgaGlnaGVzdCBwcmlvcml0eSBwYWlyLg0KPiANCj4gPg0K PiA+DQo+ID4gVGhpcyB3aWxsIGNlcnRhaW5seSBtYWtlIHRoZSBjb25uZWN0aW9uIHByb2Nlc3Mg dW5hY2NlcHRhYmxlLiBUbyBzb2x2ZQ0KPiA+IHN1Y2ggcHJvYmxlbSwgd2Ugc2hvdWxkIHByZWZl ciB0aGUgcHJvY2VzcyB0aGF0IGRlc2NyaWJlZCBpbiB0aGUNCj4gPiBSRkM1MjQ1KGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3JmYzUyNDUvKSwgIHNlY3Rpb24gNC4xLjIuDQo+ID4g 4oCcUHJpb3JpdGl6aW5nIENhbmRpZGF0ZXPigJ0gZmlyc3QsIHRoZW4gZG8gdGhlIElDRSBjb25u ZWN0aXZpdHkgY2hlY2sgaW4NCj4gPiBzZXF1ZW5jZS4gVGhlIHByaW9yaXRpemluZyBhbGdvcml0 aG0gc2hvdWxkIGNvbnNpZGVyIHNldmVyYWwgZmFjdG9ycywNCj4gPiBzdWNoIGFzIHRoZSBzZWN1 cml0eSwgcHJpY2VzLCBwb3dlciBjb25zdW1wdGlvbiBldGMuDQo+ID4NCj4gDQo+IEkgbWF5IGJl IHdyb25nLCBidXQgdGhlIGNvLWF1dGhvcnMgc2hvdWxkIGNvcnJlY3QgbWU6IEFGQUlVIHRoZSBw cm9wb3NhbA0KPiBkb2VzIG5vdCBjaGFuZ2UgdGhlIG9yZGVyIG9yIHRoZSB0ZXN0aW5nIHRoZSBs aXN0IG9mIGNhbmRpZGF0ZXMsIGJ1dCB0aGUNCj4gb3V0Y29tZSBvZiB0aGUgdGVzdGluZy4gaS5l Liwgb25jZSB0aGUgY2FuZGlkYXRlcyBoYXZlIGJlZW4gb3JkZXJlZCBhbmQNCj4gdGVzdGVkLCB0 aGUgZW5kcG9pbnQgY2FuIHVzZSB0aGUgY2FuZGlkYXRlIHBhaXIgd2l0aCBiZXR0ZXIgcGF0aA0K PiBjaGFyYWN0ZXJpc3RpY3MgZXZlbiB0aG91Z2ggaXQgaGFzIGEgbG93ZXIgcHJpb3JpdHkgY29t cGFyZWQgdG8gdGhlIG90aGVyDQo+IHN1Y2Nlc3NmdWwgY2FuZGlkYXRlcy4gDQoNClllcywgdGhh dCBpcyB0aGUgaW50ZW50IG9mIHRoZSBzcGVjaWZpY2F0aW9uLiBVc2UgY2FzZXMgd2l0aCBvciB3 aXRob3V0IG11bHRpcGxlIGludGVyZmFjZXMgY291bGQgYmU6DQpbMV0gZHJhZnQtd2lsbGlhbXMt cGVlci1yZWRpcmVjdDogVGVzdCBib3RoIHRoZSByZWxheWVkIGNhbmRpZGF0ZXMgYW5kIHBpY2sg dGhlIGJlc3QgcmVsYXllZCBjYW5kaWRhdGUgdG8gdXNlLg0KWzJdIGRyYWZ0LWlldGYtcHBzcC1i YXNlLXRyYWNrZXItcHJvdG9jb2w6IEluIFBQU1AsIHBlcmZvcm0gSUNFIGNvbm5lY3Rpdml0eSBj aGVja3Mgd2l0aCBsaXN0IG9mIHBlZXJzIGluIHRoZSBzd2FybSBhbmQgc2VsZWN0IHNlZWRlcihz KSBmb3IgZmV0Y2hpbmcgY29udGVudC4NCg0KLVRpcnUNCg0KPiBGdXJ0aGVyLCB0aGlzIHNob3Vs ZCBiZSBpbmZvcm1hdGlvbg0KPiANCj4gPg0KPiA+DQo+ID4gVGhlIHBhdGggY2hhcmFjdGVyaXN0 aWMsIHN1Y2ggYXMgbG9zcywgUlRULCBqaXR0ZXIgY2FuIGFsc28gYmUNCj4gPiBjb25zaWRlcmVk LCBidXQgdGhpcyBpbmZvcm1hdGlvbiBzaG91bGQgYmUgYWNxdWlyZWQgdmlhIG90aGVyIG91dC1i YW5kDQo+ID4gbWV0aG9kLCBub3QgdGhlIGluLWJhbmQgc29sdXRpb24gdGhhdCBkZXNjcmliZWQg aW4gdGhpcyBkcmFmdC4NCj4gDQo+IFN1cmUsIG91dC1vZi1iYW5kIG1lY2hhbmlzbXMgY2FuIGJl IHVzZWQgYXMgd2VsbC4gSG93ZXZlciwgdGhlIGVuZHBvaW50cw0KPiBhcmUgYW55d2F5IHBlcmZv cm1pbmcgY29ubmVjdGl2aXR5IGNoZWNrcywgaXQgcHJvdmlkZXMgYSBwZXJmZWN0IG9wcG9ydHVu aXR5DQo+IHRvIGdldCBzb21lIG1lYXN1cmVtZW50cyBiZWZvcmUgc2VuZGluZyBhbnkgbWVkaWEg cGFja2V0cyBvbiB0aG9zZQ0KPiBwYXRocy4NCj4gRnVydGhlciwgdGhlIFNUVU4gcGFja2V0cyBh cmUgZ29vZCBlbm91Z2ggZm9yIHBlcmZvcm1pbmcgUlRUDQo+IG1lYXN1cmVtZW50cyBhcyB0aGV5 IGFyZSBzZW50IG91dCBhdCByZWd1bGFyIGludGVydmFscy4NCj4gDQo+IA0KPiA+DQo+ID4NCj4g Pg0KPiA+IEJlc3QgUmVnYXJkcy4NCj4gPg0KPiA+DQo+ID4NCj4gPiBBaWp1biBXYW5nLg0KPiA+ DQo+ID4NCj4gPg0KPiA+IEZyb206IFZhcnVuIFNpbmdoIFttYWlsdG86dnNpbmdoLmlldGZAZ21h aWwuY29tXQ0KPiA+IFNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMjYsIDIwMTQgNTozNSBBTQ0KPiA+ IFRvOiBBaWp1biBXYW5nDQo+ID4gQ2M6IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk7IHRy YW1AaWV0Zi5vcmcNCj4gPg0KPiA+DQo+ID4gU3ViamVjdDogUmU6IFt0cmFtXSBGVzogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiA+IGRyYWZ0LXJlZGR5LXRyYW0tc3R1bi1wYXRoLWRh dGEtMDAudHh0DQo+ID4NCj4gPg0KPiA+DQo+ID4gSGkgQWlqdW4sDQo+ID4NCj4gPiBDb21tZW50 cyBpbmxpbmUuDQo+ID4NCj4gPg0KPiA+DQo+ID4gQ2hlZXJzLA0KPiA+DQo+ID4gVmFydW4uDQo+ ID4NCj4gPiBPbiBUaHVyc2RheSwgRGVjZW1iZXIgMjUsIDIwMTQsIEFpanVuIFdhbmcNCj4gPHdh bmdhaWp1bkB0c2luZ2h1YS5vcmcuY24+DQo+ID4gd3JvdGU6DQo+ID4NCj4gPiBIaSwgUmVkZHkN Cj4gPg0KPiA+IFBsZWFzZSBzZWUgdGhlIHJlcGx5IGlubGluZSBiZWxvdy4NCj4gPg0KPiA+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBUaXJ1bWFsZXN3YXIgUmVkZHkg KHRpcmVkZHkpIFttYWlsdG86dGlyZWRkeUBjaXNjby5jb21dDQo+ID4+IFNlbnQ6IFdlZG5lc2Rh eSwgRGVjZW1iZXIgMjQsIDIwMTQgNjowMyBQTQ0KPiA+PiBUbzogQWlqdW4gV2FuZzsgdHJhbUBp ZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSRTogW3RyYW1dIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yDQo+ID4+IGRyYWZ0LXJlZGR5LXRyYW0tc3R1bi1wYXRoLWRhdGEtMDAudHh0DQo+ ID4+DQo+ID4+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gPiBGcm9tOiB0cmFt IFttYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWlqdW4gV2FuZw0K PiA+PiA+IFNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMjQsIDIwMTQgMTI6MDcgUE0NCj4gPj4g PiBUbzogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsgdHJhbUBpZXRmLm9yZw0KPiA+PiA+ IFN1YmplY3Q6IFJlOiBbdHJhbV0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4g Pj4gPiBkcmFmdC1yZWRkeS10cmFtLXN0dW4tIHBhdGgtZGF0YS0wMC50eHQNCj4gPj4gPg0KPiA+ PiA+IEhpLCBSZWRkeToNCj4gPj4gPg0KPiA+PiA+IEkgZG91YnQgdGhlIGZlYXNpYmlsaXR5IG9m IHRoaXMgcHJvYmUgcHJvY2Vzcy4gRm9yIFVFIHRoYXQgaGFzDQo+ID4+ID4gbXVsdGlwbGUgaW50 ZXJmYWNlcywgdGhlIE9TIG9mIHRoZSBVRSB3aWxsIGF1dG9tYXRpY2FsbHkgY2hvb3NlDQo+ID4+ ID4gb25seSBvbmUgZGVmYXVsdCBpbnRlcmZhY2UgZm9yIGNvbW11bmljYXRpbmcuDQo+ID4+DQo+ ID4+IE5vLCBNUFRDUCBvbiBtb2JpbGUgZGV2aWNlcyBhbHJlYWR5IHVzZXMgbXVsdGlwbGUgaW50 ZXJmYWNlcyAoZm9yDQo+ID4+IGV4YW1wbGUgQXBwbGUgdXNlcyBNUFRDUCBmb3IgU2lyaSkuICBN UFJUUA0KPiA+PiAoZHJhZnQtaWV0Zi1hdnRjb3JlLW1wcnRwLTAwKSBhbHNvIHVzZXMgbXVsdGlw bGUgaW50ZXJmYWNlcy4NCj4gPj4NCj4gPg0KPiA+DQo+ID4gVGhlIHB1cnBvc2Ugb2YgTVBUQ1Ag YW5kIE1QUlRQIGlzIGp1c3QgY29udHJhcnkgdG8geW91ciBwcm9wb3NhbC4gVGhleQ0KPiA+IGp1 c3Qgd2FudCB0byB1dGlsaXplIGFsbCB0aGUgYXZhaWxhYmxlIHBhdGhzIGZvciBUQ1Agb3IgUlRQ IGNodW5rIGRhdGENCj4gPiB0cmFuc3BvcnQsIGJ1dCB0aGlzIGRyYWZ0IGp1c3Qgd2FudHMgdG8g c2VsZWN0IG9uZSBiZXN0IHBhaXI/IE9uIHRoZQ0KPiA+IG90aGVyIGhhbmQsIHRoZXJlDQo+ID4N Cj4gPg0KPiA+DQo+ID4gSU1PIHRoZSBkcmFmdCBleHBvc2VzIHR3byB0cmFuc3BvcnQgY2hhcmFj dGVyaXN0aWNzOiBSVFQgbWVhc3VyZW1lbnQsDQo+ID4gYW5kIGxvc3MgKHVwc3RyZWFtIGFuZCBk b3duc3RyZWFtIHBhdGgpLiBXaGlsZSB0aGVyZSBtYXkgYmUgYWRkaXRpb25hbA0KPiA+IG1ldHJp Y3MgbGlrZSBqaXR0ZXIsIHBvd2VyIGNvbnN1bXB0aW9uLCBhbmQgYXMgeW91IHBvaW50IG91dCBt b25leS4NCj4gPg0KPiA+DQo+ID4NCj4gPiBpcyBhbHNvIG90aGVyIGZhY3RvciBuZWVkZWQgdG8g YmUgY29uc2lkZXJlZCBmb3Igc2VsZWN0aW5nIHRoZQ0KPiA+IHVuZGVybHlpbmcgbmV0d29yaywg Zm9yIGV4YW1wbGUgdGhlIHByaWNlcyBvZiBkaWZmZXJlbnQgY29ubmVjdGlvbi4gSQ0KPiA+IHRo aW5rIHRoZSB1c2VycyB0aGVtc2VsdmVzIHNob3VsZCBkZWNpZGUgd2hpY2ggb25lIGFuZCBob3cg bWFueQ0KPiA+IGludGVyZmFjZXMgY2FuIGJlIHVzZWQgZm9yIGRhdGEgdHJhbnNmZXIsIG5vdCBv bmUgb2YgdGhlIGFwcGxpY2F0aW9uIG9uIHRoZWlyDQo+IGRldmljZXMuDQo+ID4NCj4gPiBUaGUg dXNlcnMgdHlwaWNhbGx5IGNob29zZSBpbnRlcmZhY2VzIChhbGxvd2luZyBhY2Nlc3MgdG8gdGhl IDNHL0xURQ0KPiA+IGF0IHRoZSBzeXN0ZW0gbGV2ZWwsIGJ1dCB0aGlzIGNhbiBlYXNpbHkgYmUg ZXhwb3NlZCBhdCB0aGUgYXBwIGxldmVsKSwNCj4gPiB3aGljaCB0aGVuIGJlY29tZXMgYSBzeXN0 ZW0gcG9saWN5LiBBbmQgdGhpcyBtZWNoYW5pc20gY2FuIHN0aWxsIHdvcmsNCj4gPiBieSBza2lw cGluZyB0aGUgY2FuZGlkYXRlIGdhdGhlcmluZyBwaGFzZSBmb3IgaW50ZXJmYWNlcyBpLmUuLCBu b3QNCj4gPiBhbGxvd2VkIGFjY2VzcyBieSB1c2VyL3N5c3RlbSBzZXR0aW5ncy4NCj4gPg0KPiA+ DQo+ID4NCj4gPj4gPiBBY2NvcmRpbmcgdG8gdGhpcyBkcmFmdCwgdGhlIElDRSBhZ2VudCB3aXRo aW4gdGhlIFVFIHdpbGwgdHJ5IGV2ZXJ5DQo+ID4+ID4gcG9zc2libGUgaW50ZXJmYWNlIHRvIHNl bmQgdGhlIFNUVU4gcGFja2V0Pw0KPiA+PiA+IFRoaXMgd2lsbCBtYWtlDQo+ID4+ID4gdGhlIGNv bm5lY3Rpb24gdGltZSBiZXR3ZWVuIHR3byBlbmRwb2ludHMgdW5hY2NlcHRhYmxlLg0KPiA+Pg0K PiA+PiBUaGUgbmV3IGF0dHJpYnV0ZSBjYW4gYmUgYWRkZWQgdG8gdGhlIFNUVU4gYmluZGluZyBy ZXF1ZXN0L3Jlc3BvbnNlDQo+ID4+IHVzZWQNCj4gPiBmb3INCj4gPj4gSUNFIGNvbm5lY3Rpdml0 eSBjaGVja3MgYW5kIGRvZXMgbm90IGludHJvZHVjZSBhbnkgYWRkaXRpb25hbCBtZXNzYWdlcy4N Cj4gPj4NCj4gPiBUaGUgY2hlY2tpbmcgcmVzdWx0cyBjYW4ndCBiZSBrZXB0IGNvbnNpc3RlbmN5 IGFsbCB0aGUgdGltZS4gSG93IGFib3V0DQo+ID4gdGhlIHNlbGVjdGVkIGludGVyZmFjZSBiZWNv bWUgY29uZ2VzdGVkIHdoZW4gaXQgYmVnaW5zIHRvIHRyYW5zZmVyIHRoZQ0KPiA+IGNodW5rIGRh dGE/IEZyb20gdGhpcyBwb2ludCwgdGhlIE1QVENQIGFuZCBNUFJUUCBtYXkgYmUgbW9yZQ0KPiBy ZWFzb25hYmxlIHNvbHV0aW9uLg0KPiA+IEl0IGNhbiBiYWxhbmNlIGJldHdlZW4gZGlmZmVyZW50 IGxpbmtzL2ludGVyZmFjZXMsIG5vdCBqdXN0IHNlbGVjdA0KPiA+IG9ubHkgb25lIHRoYXQgbG9v a3MgbGlrZSBpZGxlLg0KPiA+DQo+ID4NCj4gPg0KPiA+IFRoZSBtZXRyaWNzIGdhdGhlcmVkIGZy b20gdGhlIGNvbm5lY3Rpdml0eSBjaGVja3Mgc2hvdWxkIGJlIGZlZA0KPiA+IHVwd2FyZHMgaW50 byB0aGUgcm1jYXQgb3IgdG93YXJkcyB0aGUgY29uZ2VzdGlvbiBjb250cm9sLCB3aGljaCBjYW4N Cj4gPiBtYWtlIHRoZSBhcHByb3ByaWF0ZSBkZWNpc2lvbi4NCj4gPg0KPiA+DQo+ID4NCj4gPj4g LVRpcnUNCj4gPj4NCj4gPj4gPg0KPiA+PiA+IEJlc3QgUmVnYXJkcy4NCj4gPj4gPg0KPiA+PiA+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+ID4gRnJvbTogdHJhbSBbbWFpbHRvOnRy YW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRpcnVtYWxlc3dhcg0KPiA+PiA+IFJl ZGR5DQo+ID4+ID4gKHRpcmVkZHkpDQo+ID4+ID4gU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMjMs IDIwMTQgMTE6MjkgUE0NCj4gPj4gPiBUbzogdHJhbUBpZXRmLm9yZw0KPiA+PiA+IFN1YmplY3Q6 IFt0cmFtXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiA+PiA+IGRyYWZ0LXJl ZGR5LXRyYW0tc3R1bi1wYXRoLSBkYXRhLTAwLnR4dA0KPiA+PiA+DQo+ID4+ID4gVGhpcyBkcmFm dCBkZXNjcmliZXMgYSBtZWNoYW5pc20gZm9yIGFuIGVuZHBvaW50IHRvIGRpc2NvdmVyIHRoZQ0K PiA+PiA+IHBhdGggY2hhcmFjdGVyaXN0aWNzIHVzaW5nIFNUVU4uDQo+ID4+ID4gQ29tbWVudHMg YW5kIHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lLg0KPiA+PiA+DQo+ID4+ID4gLVRpcnUNCj4gPj4g Pg0KPiA+PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+ID4gRnJvbTogaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiA+ PiA+IFNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDIzLCAyMDE0IDg6MzcgUE0NCj4gPj4gPiBUbzog VmFydW4gU2luZ2g7IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk7IERhbiBXaW5nIChkd2lu Zyk7DQo+ID4+ID4gVmFydW4gU2luZ2g7IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk7IFBh bCBNYXJ0aW5zZW4NCj4gPj4gPiAocGFsbWFydGkpOyBEYW4gV2luZyAoZHdpbmcpOyBQYWwgTWFy dGluc2VuIChwYWxtYXJ0aSkNCj4gPj4gPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yDQo+ID4+ID4gZHJhZnQtcmVkZHktdHJhbS1zdHVuLXBhdGgtZGF0YS0wMC50eHQNCj4g Pj4gPg0KPiA+PiA+DQo+ID4+ID4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXJlZGR5LXRy YW0tc3R1bi1wYXRoLWRhdGEtMDAudHh0DQo+ID4+ID4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSBUaXJ1bWFsZXN3YXIgUmVkZHkgYW5kIHBvc3RlZCB0bw0KPiA+PiA+IHRoZSBJ RVRGIHJlcG9zaXRvcnkuDQo+ID4+ID4NCj4gPj4gPiBOYW1lOiAgICAgICAgICAgICAgIGRyYWZ0 LXJlZGR5LXRyYW0tc3R1bi1wYXRoLWRhdGENCj4gPj4gPiBSZXZpc2lvbjogICAwMA0KPiA+PiA+ IFRpdGxlOiAgICAgICAgICAgICAgRGlzY292ZXJ5IG9mIHBhdGggY2hhcmFjdGVyaXN0aWNzIHVz aW5nIFNUVU4NCj4gPj4gPiBEb2N1bWVudCBkYXRlOiAgICAgIDIwMTQtMTItMjMNCj4gPj4gPiBH cm91cDogICAgICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiA+PiA+IFBhZ2VzOiAg ICAgICAgICAgICAgOQ0KPiA+PiA+IFVSTDoNCj4gPj4gPiBodHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1yZWRkeS10cmFtLXN0dW4tcGF0aC1kYXRhDQo+ID4+ID4gLTAw DQo+ID4+ID4gLnR4dA0KPiA+PiA+IFN0YXR1czoNCj4gPj4gPiBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1yZWRkeS10cmFtLXN0dW4tcGF0aC1kYXRhLw0KPiA+PiA+IEh0 bWxpemVkOg0KPiA+PiA+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJlZGR5LXRy YW0tc3R1bi1wYXRoLWRhdGEtMDANCj4gPj4gPg0KPiA+PiA+DQo+ID4+ID4gQWJzdHJhY3Q6DQo+ ID4+ID4gICAgQSBob3N0IHdpdGggbXVsdGlwbGUgaW50ZXJmYWNlcyBuZWVkcyB0byBjaG9vc2Ug dGhlIGJlc3QgaW50ZXJmYWNlDQo+ID4+ID4gICAgZm9yIGNvbW11bmljYXRpb24uICBPZnRlbnRp bWVzLCB0aGlzIGRlY2lzaW9uIGlzIGJhc2VkIG9uIGEgc3RhdGljDQo+ID4+ID4gICAgY29uZmln dXJhdGlvbiBhbmQgZG9lcyBub3QgY29uc2lkZXIgdGhlIHBhdGggY2hhcmFjdGVyaXN0aWNzLCB3 aGljaA0KPiA+PiA+ICAgIG1heSBhZmZlY3QgdGhlIHVzZXIgZXhwZXJpZW5jZS4NCj4gPj4gPg0K PiA+PiA+ICAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWVjaGFuaXNtIGZvciBhbiBlbmRw b2ludCB0byBkaXNjb3ZlciB0aGUNCj4gPj4gPiAgICBwYXRoIGNoYXJhY3RlcmlzdGljcyB1c2lu ZyBTZXNzaW9uIFRyYXZlcnNhbCBVdGlsaXRpZXMgZm9yIE5BVCAoU1RVTikNCj4gPj4gPiAgICBt ZXNzYWdlcy4gIFRoZSBtZWFzdXJlbWVudCBpbmZvcm1hdGlvbiBjYW4gdGhlbiBiZSB1c2VkIHRv DQo+ID4+IGluZmx1ZW5jZQ0KPiA+PiA+ICAgIHRoZSBlbmRwb2ludCdzIEludGVyYWN0aXZlIENv bm5lY3Rpdml0eSBFc3RhYmxpc2htZW50IChJQ0UpIGNhbmRpZGF0ZQ0KPiA+PiA+ICAgIHBhaXIg c2VsZWN0aW9uIGFsZ29yaXRobS4NCj4gPj4gPg0KPiA+PiA+DQo+ID4+ID4NCj4gPj4gPg0KPiA+ PiA+DQo+ID4+ID4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51 dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gPj4gPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXpl ZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCj4gPiB0b29scy5pZXRmLm9yZy4N Cj4gPj4gPg0KPiA+PiA+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+ID4+ID4NCj4gPj4gPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiA+IHRyYW0g bWFpbGluZyBsaXN0DQo+ID4+ID4gdHJhbUBpZXRmLm9yZw0KPiA+PiA+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0KPiA+PiA+DQo+ID4+ID4NCj4gPj4gPg0KPiA+ PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ ID4gdHJhbSBtYWlsaW5nIGxpc3QNCj4gPj4gPiB0cmFtQGlldGYub3JnDQo+ID4+ID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQo+ID4NCj4gPg0KPiA+DQo+ID4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiB0cmFt IG1haWxpbmcgbGlzdA0KPiA+IHRyYW1AaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCj4gPg0KPiA+DQo+ID4NCj4gPiAtLQ0KPiA+IGh0dHA6 Ly93d3cubmV0bGFiLnRray5maS9+dmFydW4vDQo+IA0KPiANCj4gDQo+IC0tDQo+IGh0dHA6Ly93 d3cubmV0bGFiLnRray5maS9+dmFydW4vDQo= From nobody Mon Dec 29 14:03:51 2014 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 067341ACDF0 for ; Mon, 29 Dec 2014 14:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3py92noPSOgd for ; Mon, 29 Dec 2014 14:03:46 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id E13BC1ACDEB for ; Mon, 29 Dec 2014 14:03:45 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id DA07347611 for ; Mon, 29 Dec 2014 22:03:44 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id CCB814760E for ; Mon, 29 Dec 2014 22:03:44 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id B2D6F2029 for ; Mon, 29 Dec 2014 22:03:44 +0000 (GMT) Message-ID: <54A1CFC0.6030000@akamai.com> Date: Mon, 29 Dec 2014 17:03:44 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "tram@ietf.org" References: <20141229215347.25322.7080.idtracker@ietfa.amsl.com> In-Reply-To: <20141229215347.25322.7080.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20141229215347.25322.7080.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/W6Xs_wdFB8FBrVkVQKqYrCAuNtM Subject: [tram] Fwd: New Version Notification for draft-williams-peer-redirect-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 22:03:49 -0000 Hi all, I've just updated the peer redirect draft to provide the warning labels that Ted asked for back in Toronto. I also added brief discussion of a load balancing use case when adding a new flow to an existing allocation. There's some work going on both here and in mmusic related to ICE that can help provide a framework for making more effective use of this redirection capability. I hope that there might be enough interest in this draft for WG adoption and would like to hear thoughts on that from the list. Thanks, --Brandon -------- Forwarded Message -------- Subject: New Version Notification for draft-williams-peer-redirect-02.txt Date: Mon, 29 Dec 2014 16:53:47 -0500 From: internet-drafts@ietf.org To: Williams, Brandon , Tirumaleswar Reddy , Tirumaleswar Reddy , Williams, Brandon A new version of I-D, draft-williams-peer-redirect-02.txt has been successfully submitted by Brandon Williams and posted to the IETF repository. Name: draft-williams-peer-redirect Revision: 02 Title: Peer-specific Redirection for Traversal Using Relays around NAT (TURN) Document date: 2014-12-29 Group: Individual Submission Pages: 13 URL: http://www.ietf.org/internet-drafts/draft-williams-peer-redirect-02.txt Status: https://datatracker.ietf.org/doc/draft-williams-peer-redirect/ Htmlized: http://tools.ietf.org/html/draft-williams-peer-redirect-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-williams-peer-redirect-02 Abstract: This specification describes a peer-specific redirection method that allows the TURN server to redirect a client for the purpose of improving communication with a specific peer without negatively affecting communication with other peers. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Mon Dec 29 16:41:28 2014 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 8357A1ACEA8 for ; Mon, 29 Dec 2014 16:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cC8qr1wmAIb for ; Mon, 29 Dec 2014 16:41:22 -0800 (PST) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id E9EA81ACE9F for ; Mon, 29 Dec 2014 16:41:21 -0800 (PST) Received: from ctbriwangaij (unknown [219.142.69.76]) by app1 (Coremail) with SMTP id Z0GX06CbKQAK4KFUBMdOAA==.8716S4; Tue, 30 Dec 2014 07:13:31 +0800 (CST) From: "Aijun Wang" To: "'Simon Perreault'" References: <20141223150647.4003.56437.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35523A3E@xmb-rcd-x10.cisco.com> <003301d01f44$086ad280$19407780$@org.cn> <913383AAA69FF945B8F946018B75898A35523F70@xmb-rcd-x10.cisco.com> <005c01d02060$e81da2f0$b858e8d0$@org.cn> <000901d02101$8ab0a260$a011e720$@org.cn> In-Reply-To: Date: Tue, 30 Dec 2014 08:40:50 +0800 Message-ID: <002901d023c9$4b55d7a0$e20186e0$@org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002A_01D0240C.597917A0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdAjbgkc5ISn4J+8QjSqSvpwN8ZitQAUd7yA Content-Language: zh-cn X-CM-TRANSID: Z0GX06CbKQAK4KFUBMdOAA==.8716S4 X-Coremail-Antispam: 1U3129KBjvJXoWxGrWDAr4fuw1kCw13uF17Wrg_yoW5KF4xpF W5tw1aqF1kWr1xJw1Iyw1xuF93CrZ5Ar4UAFn5Kryjyws8KF1vvF93ta4YvFW7Crs5Zw12 vayjqrs7uFn8XaDanT9S1TB71UUUUU7v73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjQlb7 Iv0xC_Jr1l5I8CrVAYj202j2C_Xr0_Wr1l5I8CrVAqjxCE14ACF2xKxwAqx4xG64kEw2xG 04xIwI0_Jr0_Gr1l5I8CrVCF0I0E4I0vr24lb4IE77IF4wAFF20E14v26r4j6ryUM7C26x Cjj4IEI4klw4CSwwAFxVCaYxvI4VCIwcAKzIAtMcIj6x8ErcxFaVAv8VW8AwC2zVAF1VAY 17CE14v26r126r1D0xZFpf9x0JUZVyxUUUUU= Archived-At: http://mailarchive.ietf.org/arch/msg/tram/x_oc62pwnRmlwD0yAmSaxQ6xte8 Cc: tram@ietf.org, "'Tirumaleswar Reddy \(tireddy\)'" , 'Varun Singh' Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 00:41:26 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_002A_01D0240C.597917A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, Simon: =20 The process for ICE that described in RFC5245 is following: =20 8.1.1.1. Regular Nomination =20 With regular nomination, the agent lets some number of checks complete, each of which omit the USE-CANDIDATE attribute. Once one or more checks complete successfully for a component of a media stream, valid pairs are generated and added to the valid list. The agent lets the checks continue until some stopping criterion is met, and then picks amongst the valid pairs based on an evaluation criterion. The criteria for stopping the checks and for evaluating the valid pairs is entirely a matter of local optimization. =20 So, the ICE agent is not required to check all the connection = possibility. Once this is not mandatory, the information that get from = the =E2=80=9Cpath characteristic attribute=E2=80=9D is not complete, and = can=E2=80=99t be used to assist the selection of best path. If it = requires to check all the connection possibility, the latency for = connection will certainly be prolonged. =20 In another section of RFC5245, it is described as following: 8.1.2. Updating States =20 For both controlling and controlled agents, the state of ICE processing depends on the presence of nominated candidate pairs in the valid list and on the state of the check list. Note that, at any time, more than one of the following cases can apply: =20 o If there are no nominated pairs in the valid list for a media stream and the state of the check list is Running, ICE processing continues. =20 o If there is at least one nominated pair in the valid list for a media stream and the state of the check list is Running: =20 * The agent MUST remove all Waiting and Frozen pairs in the check list and triggered check queue for the same component as the nominated pairs for that media stream. =20 * If an In-Progress pair in the check list is for the same component as a nominated pair, the agent SHOULD cease retransmissions for its check if its pair priority is lower than the lowest-priority nominated pair for that component. =20 This section demonstrated that the check list and checking process are = controlled by the pair priority, the lowest priority pair will not be = checked once some criterion is met. And we can also find in this RFC, = that the pair priority is predefined, independence of the results of = path characteristic.=20 =20 =20 Best Regards. Aijun Wang. =20 From: Simon Perreault [mailto:sperreault@jive.com]=20 Sent: Monday, December 29, 2014 10:48 PM To: Aijun Wang Cc: Varun Singh; tram@ietf.org; Tirumaleswar Reddy (tireddy) Subject: Re: [tram] FW: New Version Notification for = draft-reddy-tram-stun-path-data-00.txt =20 =20 On Fri, Dec 26, 2014 at 6:45 AM, Aijun Wang = wrote: ICE defines three types candidates: HOST CANDIDATE, REFELXTIVE = CANDIDATE, RELAY CANDIDATE. For UE that has multiple interfaces(for = examples m interfaces), it will have 3*m CANDIDATE. If we uses the = mechanism that described in this draft to select the best local = interface, the UE must try all of these interfaces to send the STUN = request message. Correspondingly, the communication pair will try = [3*m]*[3*m] times connectivity check to find the path that has best = characteristics? =20 This will certainly make the connection process unacceptable. The ICE process is already how you describe (except there's usually only = 1 relayed candidate per address family). That's why e.g., trickle ICE = was created: to speed things up. =20 This draft doesn't change the number of messages or candidates, so I = view this line of argument as applying to ICE in general, and therefore = irrelevant to this draft. =20 Simon ------=_NextPart_000_002A_01D0240C.597917A0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi, Simon:

 

The process for ICE that described in RFC5245 is = following:

 

 8.1.1.1.=C2=A0 Regular =
Nomination

 

=C2=A0=C2=A0 With regular nomination, the agent lets some = number of checks

=C2=A0=C2=A0 complete, each of which omit the USE-CANDIDATE = attribute.=C2=A0 Once one

=C2=A0=C2=A0 or more checks = complete successfully for a component of a media

=C2=A0=C2=A0 stream, valid pairs = are generated and added to the valid list.=C2=A0 = The

=C2=A0=C2=A0 agent lets the checks continue until some = stopping criterion is met,

=C2=A0=C2=A0 and then picks amongst = the valid pairs based on an evaluation

=C2=A0=C2=A0 criterion.=C2=A0 The = criteria for stopping the checks and for = evaluating

=C2=A0=C2=A0 the valid pairs is entirely a matter of local = optimization.

 

So, the ICE agent is not required to check all the connection = possibility. Once this is not mandatory, the information that get from = the =E2=80=9Cpath characteristic attribute=E2=80=9D is not complete, and = can=E2=80=99t be used to =C2=A0assist the selection of best path. If it = requires to check all the connection possibility, the latency for = connection will certainly be prolonged.

 

In another section of RFC5245, it is described as = following:

8.1.2.=C2=A0 =
Updating States
 
=C2=A0=C2=A0 For both controlling and controlled agents, =
the state of ICE
=C2=A0=C2=A0 processing depends on the presence of =
nominated candidate pairs in
=C2=A0=C2=A0 the valid list and on the state of the check =
list.=C2=A0 Note that, at any
=C2=A0=C2=A0 time, more than one of the following cases can =
apply:
 
=C2=A0=C2=A0 o=C2=A0 If there are no nominated pairs in the =
valid list for a media
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 stream and the state of the =
check list is Running, ICE processing
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
continues.
 
=C2=A0=C2=A0 o=C2=A0 If there is at least one nominated =
pair in the valid list for a
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 media stream and the state =
of the check list is Running:
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2=A0 The agent MUST =
remove all Waiting and Frozen pairs in the =
check
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 list and =
triggered check queue for the same component as =
the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 nominated =
pairs for that media stream.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2=A0 If an In-Progress =
pair in the check list is for the same
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 component =
as a nominated pair, the agent SHOULD =
cease
 =
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0retransmissions for its =
check if its pair priority is lower
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 than the =
lowest-priority nominated pair for that =
component.
 

This section demonstrated that the check list and checking process = are controlled by the pair priority, the lowest priority pair will not = be checked once some criterion is met. And we can also find in this RFC, = that the pair priority is predefined, independence of the results of = path characteristic.

 

 

Best Regards.

Aijun Wang.

 

From:= Simon = Perreault [mailto:sperreault@jive.com]
Sent: Monday, December = 29, 2014 10:48 PM
To: Aijun Wang
Cc: Varun Singh; = tram@ietf.org; Tirumaleswar Reddy (tireddy)
Subject: Re: = [tram] FW: New Version Notification for = draft-reddy-tram-stun-path-data-00.txt

<= p class=3DMsoNormal> 

 

On Fri, Dec 26, 2014 at 6:45 AM, = Aijun Wang <wangaijun@tsinghua.org.cn> = wrote:

ICE defines three types candidates: HOST CANDIDATE, REFELXTIVE = CANDIDATE, RELAY CANDIDATE.  For UE that has multiple = interfaces(for examples m interfaces), it will have 3*m CANDIDATE. If we = uses the mechanism that described in this draft to select the best local = interface, the UE must try all of these interfaces to send the STUN = request message. Correspondingly, the communication pair will try =  [3*m]*[3*m] times connectivity check to find the path that has = best characteristics?

 

This will certainly make the connection process = unacceptable.


The ICE process is already how = you describe (except there's usually only 1 relayed candidate per = address family). That's why e.g., trickle ICE was created: to speed = things up.

 

This draft doesn't change the = number of messages or candidates, so I view this line of argument as = applying to ICE in general, and therefore irrelevant to this = draft.

 

Simon

------=_NextPart_000_002A_01D0240C.597917A0-- From nobody Tue Dec 30 06:31:44 2014 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 DD34A1A00CA for ; Tue, 30 Dec 2014 06:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 tyRTAiKlY3FI for ; Tue, 30 Dec 2014 06:31:38 -0800 (PST) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6C111A00CD for ; Tue, 30 Dec 2014 06:31:37 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id f15so13376015lbj.41 for ; Tue, 30 Dec 2014 06:31:36 -0800 (PST) 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=aJQ3MCEEkD5YPJUwhyKKptY3P3Z4XlyUryh+z44nGk4=; b=IWizPu8XonUXuDSb4Xqi6Y8OjC7KMyib5W6imxRyDvgCZOF+k/bMLN8KQ/Tfq6Hy43 hD28GfClVB1ZvXE7u1XfdHQ6peuH4GTlOfzD59fPYhiGlmjSe4XD1Q81GUdPxGiYyhyT sZxuYMMJQxiAy2bQaX7rpKQ3FFRlc1LPNbA1Z1L0RaXjlpAXbKH3tbiZ21+08Tu8kn+m I//iOJ0hgmS5EZOiYek03HIq8ZujJvDzwR+m2lCPZDwZxF+tnWSrLJrzrnYgB/FdMOTh r65kURCmfCdOzu5CwvvllJRmAZbUxeKwx+ACu6xI4RS3jLhq3QbxrMoKuYJZpWGQx6cP IYuw== X-Gm-Message-State: ALoCoQloMFQeyzcHVay3ajtW//uTS9tgxzKoUWpHEGjOC1KbuXRsX4HwX+qV8jD2uH1CQpXyN3lr MIME-Version: 1.0 X-Received: by 10.112.91.43 with SMTP id cb11mr61680157lbb.63.1419949895961; Tue, 30 Dec 2014 06:31:35 -0800 (PST) Received: by 10.25.84.145 with HTTP; Tue, 30 Dec 2014 06:31:35 -0800 (PST) In-Reply-To: <002901d023c9$4b55d7a0$e20186e0$@org.cn> References: <20141223150647.4003.56437.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35523A3E@xmb-rcd-x10.cisco.com> <003301d01f44$086ad280$19407780$@org.cn> <913383AAA69FF945B8F946018B75898A35523F70@xmb-rcd-x10.cisco.com> <005c01d02060$e81da2f0$b858e8d0$@org.cn> <000901d02101$8ab0a260$a011e720$@org.cn> <002901d023c9$4b55d7a0$e20186e0$@org.cn> Date: Tue, 30 Dec 2014 09:31:35 -0500 Message-ID: From: Simon Perreault To: Aijun Wang Content-Type: multipart/alternative; boundary=001a11348fd625e5d6050b6fd936 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/eddwrHL1q65Km9FBWUsAMNoVo2M Cc: "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" , Varun Singh Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 14:31:43 -0000 --001a11348fd625e5d6050b6fd936 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Dec 29, 2014 at 7:40 PM, Aijun Wang wrote: > > So, the ICE agent is not required to check all the connection possibility= . > Once this is not mandatory, the information that get from the =E2=80=9Cpa= th > characteristic attribute=E2=80=9D is not complete, and can=E2=80=99t be u= sed to assist the > selection of best path. If it requires to check all the connection > possibility, the latency for connection will certainly be prolonged. Ok I think I understand what you mean now: although this draft doesn't change ICE behaviour per se, in practice the successful use of the STUN attribute it introduces would require such a change. The behaviour change is that the ICE agent now needs to perform connectivity checks on all candidate pairs in order to be able to use the measured RTTs as input to the nomination algorithm. Is this a fair rewording? Thanks, Simon --001a11348fd625e5d6050b6fd936 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Dec 29, 2014 at 7:40 PM, Aijun Wang <wangaijun@tsinghua.= org.cn> wrote:
So, the ICE agen= t is not required to check all the connection possibility. Once this is not= mandatory, the information that get from the =E2=80=9Cpath characteristic = attribute=E2=80=9D is not complete, and can=E2=80=99t be used to =C2=A0assi= st the selection of best path. If it requires to check all the connection p= ossibility, the latency for connection will certainly be prolonged.

Ok I think I understand what you mean now: although this dra= ft doesn't change ICE behaviour per se, in practice the successful use = of the STUN attribute it introduces would require such a change. The behavi= our change is that the ICE agent now needs to perform connectivity checks o= n all candidate pairs in order to be able to use the measured RTTs as input= to the nomination algorithm. Is this a fair rewording?

Thanks,
Simon
--001a11348fd625e5d6050b6fd936-- From nobody Tue Dec 30 06:31:59 2014 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 3FECB1A00CA for ; Tue, 30 Dec 2014 06:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKRrfj7nhy5w for ; Tue, 30 Dec 2014 06:31:52 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id E02801A00E2 for ; Tue, 30 Dec 2014 06:31:51 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 406F447640; Tue, 30 Dec 2014 14:31:51 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 340E54763D; Tue, 30 Dec 2014 14:31:51 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 2F47E80047; Tue, 30 Dec 2014 14:31:51 +0000 (GMT) Message-ID: <54A2B757.9060500@akamai.com> Date: Tue, 30 Dec 2014 09:31:51 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: tram@ietf.org, wangaijun@tsinghua.org.cn References: <20141223150647.4003.56437.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35523A3E@xmb-rcd-x10.cisco.com> <003301d01f44$086ad280$19407780$@org.cn> <913383AAA69FF945B8F946018B75898A35523F70@xmb-rcd-x10.cisco.com> <005c01d02060$e81da2f0$b858e8d0$@org.cn> <000901d02101$8ab0a260$a011e720$@org.cn> <002901d023c9$4b55d7a0$e20186e0$@org.cn> In-Reply-To: <002901d023c9$4b55d7a0$e20186e0$@org.cn> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/9EY3xfkYnDMWgk-ZzHYDeBdgX4M Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 14:31:56 -0000 Hi Aijun, You are correct that the currently published RFC makes the path quality information harder to use in a meaningful way. However, there is ongoing work in both tram and mmusic focused on allowing more dynamic path selection that can use performance metrics rather than the currently defined static priorities. This draft is just one piece of that bigger picture. --Brandon On 12/29/2014 07:40 PM, Aijun Wang wrote: > Hi, Simon: > > The process for ICE that described in RFC5245 is following: > > 8.1.1.1. Regular Nomination > > With regular nomination, the agent lets some number of checks > > complete, each of which omit the USE-CANDIDATE attribute. Once one > > or more checks complete successfully for a component of a media > > stream, valid pairs are generated and added to the valid list. The > > agent lets the checks continue until some stopping criterion is met, > > and then picks amongst the valid pairs based on an evaluation > > criterion. The criteria for stopping the checks and for evaluating > > the valid pairs is entirely a matter of local optimization. > > So, the ICE agent is not required to check all the connection > possibility. Once this is not mandatory, the information that get from > the “path characteristic attribute” is not complete, and can’t be used > to assist the selection of best path. If it requires to check all the > connection possibility, the latency for connection will certainly be > prolonged. > > In another section of RFC5245, it is described as following: > > 8.1.2. Updating States > > > > For both controlling and controlled agents, the state of ICE > > processing depends on the presence of nominated candidate pairs in > > the valid list and on the state of the check list. Note that, at any > > time, more than one of the following cases can apply: > > > > o If there are no nominated pairs in the valid list for a media > > stream and the state of the check list is Running, ICE processing > > continues. > > > > o If there is at least one nominated pair in the valid list for a > > media stream and the state of the check list is Running: > > > > * The agent MUST remove all Waiting and Frozen pairs in the check > > list and triggered check queue for the same component as the > > nominated pairs for that media stream. > > > > * If an In-Progress pair in the check list is for the same > > component as a nominated pair, the agent SHOULD cease > > retransmissions for its check if its pair priority is lower > > than the lowest-priority nominated pair for that component. > > > > This section demonstrated that the check list and checking process are > controlled by the pair priority, the lowest priority pair will not be > checked once some criterion is met. And we can also find in this RFC, > that the pair priority is predefined, independence of the results of > path characteristic. > > Best Regards. > > Aijun Wang. > > *From:*Simon Perreault [mailto:sperreault@jive.com] > *Sent:* Monday, December 29, 2014 10:48 PM > *To:* Aijun Wang > *Cc:* Varun Singh; tram@ietf.org; Tirumaleswar Reddy (tireddy) > *Subject:* Re: [tram] FW: New Version Notification for > draft-reddy-tram-stun-path-data-00.txt > > On Fri, Dec 26, 2014 at 6:45 AM, Aijun Wang > wrote: > > ICE defines three types candidates: HOST CANDIDATE, REFELXTIVE > CANDIDATE, RELAY CANDIDATE. For UE that has multiple interfaces(for > examples m interfaces), it will have 3*m CANDIDATE. If we uses the > mechanism that described in this draft to select the best local > interface, the UE must try all of these interfaces to send the STUN > request message. Correspondingly, the communication pair will try > [3*m]*[3*m] times connectivity check to find the path that has best > characteristics? > > This will certainly make the connection process unacceptable. > > > The ICE process is already how you describe (except there's usually only > 1 relayed candidate per address family). That's why e.g., trickle ICE > was created: to speed things up. > > This draft doesn't change the number of messages or candidates, so I > view this line of argument as applying to ICE in general, and therefore > irrelevant to this draft. > > Simon > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Tue Dec 30 06:37:03 2014 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 B39371A00C5 for ; Tue, 30 Dec 2014 06:37:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 IqYrHx-UhUWh for ; Tue, 30 Dec 2014 06:37:01 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EF801A00BF for ; Tue, 30 Dec 2014 06:37:01 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id z12so4482261lbi.17 for ; Tue, 30 Dec 2014 06:36:59 -0800 (PST) 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=ikNFsm4pW/9SYju6BTPxEwoQn0wnRa4RSNc68wdQXpY=; b=HMug8/CAgG9vZjaXcgTqo8UinQdKW9RuEvvp6l5jBV/iXUC3ebL2/p6g9GcCMK6AsJ vbv2yakU93ZNTMwlz5Vdj9o8JuyKqsGvYCh/xTTJKEpVZ2L3RSR9qlTgv+d7S+shNMEz E6zk6w5QUB49Rx1Q1eoOM7XrDcPr/Y/gVA2TSeLsFpapTJTkoApnR4GKSD7JvLbDsVCj tQLHZjGBdvcM+JVOqhIhv7c6QrY0Hvu7e7Tt6E/zJ7YlAsgy75Zrv1Ud1w/hpbvyH2CP 4HhbdkXnt7t+Peo+gGl/yAEsozadw2Uq99zIHm2809dB60OUB1ewpYBoe5osYMN80vhs A/5A== X-Gm-Message-State: ALoCoQmWzsnOhZU7t2J2kkGh1IZpHNqoiR88LAv3Fre5Og7yWHkqryznw6iAuOyNsLno2QIoKLGx MIME-Version: 1.0 X-Received: by 10.152.19.7 with SMTP id a7mr61643580lae.16.1419950219653; Tue, 30 Dec 2014 06:36:59 -0800 (PST) Received: by 10.25.84.145 with HTTP; Tue, 30 Dec 2014 06:36:59 -0800 (PST) In-Reply-To: <54A2B757.9060500@akamai.com> References: <20141223150647.4003.56437.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35523A3E@xmb-rcd-x10.cisco.com> <003301d01f44$086ad280$19407780$@org.cn> <913383AAA69FF945B8F946018B75898A35523F70@xmb-rcd-x10.cisco.com> <005c01d02060$e81da2f0$b858e8d0$@org.cn> <000901d02101$8ab0a260$a011e720$@org.cn> <002901d023c9$4b55d7a0$e20186e0$@org.cn> <54A2B757.9060500@akamai.com> Date: Tue, 30 Dec 2014 09:36:59 -0500 Message-ID: From: Simon Perreault To: Brandon Williams Content-Type: multipart/alternative; boundary=089e014942687108f7050b6fec55 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/0Gk8wjzf_5egWtW9ky4oMn1elLA Cc: "tram@ietf.org" , Aijun Wang Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 14:37:02 -0000 --089e014942687108f7050b6fec55 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 30, 2014 at 9:31 AM, Brandon Williams < brandon.williams@akamai.com> wrote: > > You are correct that the currently published RFC makes the path quality > information harder to use in a meaningful way. However, there is ongoing > work in both tram and mmusic focused on allowing more dynamic path > selection that can use performance metrics rather than the currently > defined static priorities. This draft is just one piece of that bigger > picture. You're right, of course, but if there's no way to make practical use of this draft with regular ICE, then that's useful information that needs to go into the draft. Ideally with pointers to the bigger picture you mentioned. Simon --089e014942687108f7050b6fec55 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Dec 30, 2014 at 9:31 AM, Brandon Williams <brandon.willi= ams@akamai.com> wrote:
You are = correct that the currently published RFC makes the path quality information= harder to use in a meaningful way. However, there is ongoing work in both = tram and mmusic focused on allowing more dynamic path selection that can us= e performance metrics rather than the currently defined static priorities. = This draft is just one piece of that bigger picture.

= You're right, of course, but if there's no way to make practical us= e of this draft with regular ICE, then that's useful information that n= eeds to go into the draft. Ideally with pointers to the bigger picture you = mentioned.

Simon
--089e014942687108f7050b6fec55-- From nobody Tue Dec 30 06:48:39 2014 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 9AD431A00C5 for ; Tue, 30 Dec 2014 06:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g_vfDsOX4h6M for ; Tue, 30 Dec 2014 06:48:36 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF291A00BF for ; Tue, 30 Dec 2014 06:48:33 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 7E0BC47647 for ; Tue, 30 Dec 2014 14:48:33 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 71DF847640 for ; Tue, 30 Dec 2014 14:48:33 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 6D449202C for ; Tue, 30 Dec 2014 14:48:33 +0000 (GMT) Message-ID: <54A2BB41.3070407@akamai.com> Date: Tue, 30 Dec 2014 09:48:33 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: tram@ietf.org References: <20141229215347.25322.7080.idtracker@ietfa.amsl.com> <54A1CFC0.6030000@akamai.com> In-Reply-To: <54A1CFC0.6030000@akamai.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/kWM4xElGO7i1EJQVRE3qakX6zjk Subject: Re: [tram] Fwd: New Version Notification for draft-williams-peer-redirect-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 14:48:38 -0000 Revision 03 corrects a couple of small typos that were pointed out to me after revision 02 was submitted. -------- Forwarded Message -------- Subject: New Version Notification for draft-williams-peer-redirect-03.txt Date: Tue, 30 Dec 2014 09:44:18 -0500 From: internet-drafts@ietf.org To: Williams, Brandon , Tirumaleswar Reddy , Tirumaleswar Reddy , Williams, Brandon A new version of I-D, draft-williams-peer-redirect-03.txt has been successfully submitted by Brandon Williams and posted to the IETF repository. Name: draft-williams-peer-redirect Revision: 03 Title: Peer-specific Redirection for Traversal Using Relays around NAT (TURN) Document date: 2014-12-30 Group: Individual Submission Pages: 13 URL: http://www.ietf.org/internet-drafts/draft-williams-peer-redirect-03.txt Status: https://datatracker.ietf.org/doc/draft-williams-peer-redirect/ Htmlized: http://tools.ietf.org/html/draft-williams-peer-redirect-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-williams-peer-redirect-03 Abstract: This specification describes a peer-specific redirection method that allows the TURN server to redirect a client for the purpose of improving communication with a specific peer without negatively affecting communication with other peers. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat On 12/29/2014 05:03 PM, Brandon Williams wrote: > Hi all, > > I've just updated the peer redirect draft to provide the warning labels > that Ted asked for back in Toronto. I also added brief discussion of a > load balancing use case when adding a new flow to an existing allocation. > > There's some work going on both here and in mmusic related to ICE that > can help provide a framework for making more effective use of this > redirection capability. > > I hope that there might be enough interest in this draft for WG adoption > and would like to hear thoughts on that from the list. > > Thanks, > --Brandon > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-williams-peer-redirect-02.txt > Date: Mon, 29 Dec 2014 16:53:47 -0500 > From: internet-drafts@ietf.org > To: Williams, Brandon , Tirumaleswar Reddy > , Tirumaleswar Reddy , Williams, > Brandon > > > A new version of I-D, draft-williams-peer-redirect-02.txt > has been successfully submitted by Brandon Williams and posted to the > IETF repository. > > Name: draft-williams-peer-redirect > Revision: 02 > Title: Peer-specific Redirection for Traversal Using Relays around NAT > (TURN) > Document date: 2014-12-29 > Group: Individual Submission > Pages: 13 > URL: > http://www.ietf.org/internet-drafts/draft-williams-peer-redirect-02.txt > Status: > https://datatracker.ietf.org/doc/draft-williams-peer-redirect/ > Htmlized: http://tools.ietf.org/html/draft-williams-peer-redirect-02 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-williams-peer-redirect-02 > > Abstract: > This specification describes a peer-specific redirection method that > allows the TURN server to redirect a client for the purpose of > improving communication with a specific peer without negatively > affecting communication with other peers. > > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Tue Dec 30 11:20:54 2014 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 AD7871A1ABC for ; Tue, 30 Dec 2014 11:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D_9ieuhzjL6j for ; Tue, 30 Dec 2014 11:20:50 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7E21A1AAA for ; Tue, 30 Dec 2014 11:20:50 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8B52328537 for ; Tue, 30 Dec 2014 19:20:49 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 78F7A2852D for ; Tue, 30 Dec 2014 19:20:49 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 757032029 for ; Tue, 30 Dec 2014 19:20:49 +0000 (GMT) Message-ID: <54A2FB11.1030105@akamai.com> Date: Tue, 30 Dec 2014 14:20:49 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 CC: "tram@ietf.org" References: <20141223150647.4003.56437.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A35523A3E@xmb-rcd-x10.cisco.com> <003301d01f44$086ad280$19407780$@org.cn> <913383AAA69FF945B8F946018B75898A35523F70@xmb-rcd-x10.cisco.com> <005c01d02060$e81da2f0$b858e8d0$@org.cn> <000901d02101$8ab0a260$a011e720$@org.cn> <002901d023c9$4b55d7a0$e20186e0$@org.cn> <54A2B757.9060500@akamai.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/xlUteSqvT73SNrsE7dCU4uy9RBI Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 19:20:53 -0000 The draft already has a placeholder in the section on use cases to discuss the proposed ICE candidate nomination updates with a link to Justin's not-yet-submitted draft. My read of the introduction is that it intends to call out the problem of using this performance information in the context of RFC5245 defined priorities, but I agree that it could be clearer in that regard. --Brandon On 12/30/2014 09:36 AM, Simon Perreault wrote: > > On Tue, Dec 30, 2014 at 9:31 AM, Brandon Williams > > wrote: > > You are correct that the currently published RFC makes the path > quality information harder to use in a meaningful way. However, > there is ongoing work in both tram and mmusic focused on allowing > more dynamic path selection that can use performance metrics rather > than the currently defined static priorities. This draft is just one > piece of that bigger picture. > > > You're right, of course, but if there's no way to make practical use of > this draft with regular ICE, then that's useful information that needs > to go into the draft. Ideally with pointers to the bigger picture you > mentioned. > > Simon -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Tue Dec 30 22:19:25 2014 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 D927A1A1B46 for ; Tue, 30 Dec 2014 22:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 MUAVePzTMtX4 for ; Tue, 30 Dec 2014 22:19:19 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09A841A0382 for ; Tue, 30 Dec 2014 22:19:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8626; q=dns/txt; s=iport; t=1420006759; x=1421216359; h=from:to:cc:subject:date:message-id:mime-version; bh=YRgmuE25zO2Guy9/u76++6ExVxIwEz7i7Mu+rCYHm1A=; b=k5LgZHJwpYk0pYuO1ZTEWpNLs2PKo2E92RFx+EQPQ3r8ItcpRylEe9OS pDpThbCGpwWAujgvGLkMmQLhoOHyamkD3PSTWE3x5Dyrl1lAjrHZbRpGc AN0AZHczwKVELqKNSpJJqD+x0UgmO4T4hZ3JUwAKywdJY+okP1QMucOfs 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwFADeUo1StJV2T/2dsb2JhbABcgkNDUlgEgwHBMogYAhxqFgEBAQEBfYQMAQEBBCMKSgISAQgOAwQBAQsdAwIEMBQIAQkBBAENBQiIJLITlG4BAQEBAQEBAQEBAQEBAQEBAQEBAQEXj0YxBoJpLoETBY4VigCKMoYRIoIygTxvgUV+AQEB X-IronPort-AV: E=Sophos;i="5.07,671,1413244800"; d="scan'208,217";a="383481453" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-8.cisco.com with ESMTP; 31 Dec 2014 06:19:18 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id sBV6JINM010584 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Dec 2014 06:19:18 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.58]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Wed, 31 Dec 2014 00:19:18 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault , Brandon Williams Thread-Topic: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt Thread-Index: AdAkwa+ykqf+DoSAQNer84oBCPBEPw== Date: Wed, 31 Dec 2014 06:19:17 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A3552591A@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.59.98] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A3552591Axmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/7NTvwN0Fy6SJC4ECpH9aqSx-bpU Cc: "tram@ietf.org" , Aijun Wang Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-stun-path-data-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 06:19:24 -0000 --_000_913383AAA69FF945B8F946018B75898A3552591Axmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW5saW5lIFtUUl0NCg0KRnJvbTogdHJhbSBbbWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIFNpbW9uIFBlcnJlYXVsdA0KU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMzAs IDIwMTQgODowNyBQTQ0KVG86IEJyYW5kb24gV2lsbGlhbXMNCkNjOiB0cmFtQGlldGYub3JnOyBB aWp1biBXYW5nDQpTdWJqZWN0OiBSZTogW3RyYW1dIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LXJlZGR5LXRyYW0tc3R1bi1wYXRoLWRhdGEtMDAudHh0DQoNCg0KT24gVHVl LCBEZWMgMzAsIDIwMTQgYXQgOTozMSBBTSwgQnJhbmRvbiBXaWxsaWFtcyA8YnJhbmRvbi53aWxs aWFtc0Bha2FtYWkuY29tPG1haWx0bzpicmFuZG9uLndpbGxpYW1zQGFrYW1haS5jb20+PiB3cm90 ZToNCllvdSBhcmUgY29ycmVjdCB0aGF0IHRoZSBjdXJyZW50bHkgcHVibGlzaGVkIFJGQyBtYWtl cyB0aGUgcGF0aCBxdWFsaXR5IGluZm9ybWF0aW9uIGhhcmRlciB0byB1c2UgaW4gYSBtZWFuaW5n ZnVsIHdheS4gSG93ZXZlciwgdGhlcmUgaXMgb25nb2luZyB3b3JrIGluIGJvdGggdHJhbSBhbmQg bW11c2ljIGZvY3VzZWQgb24gYWxsb3dpbmcgbW9yZSBkeW5hbWljIHBhdGggc2VsZWN0aW9uIHRo YXQgY2FuIHVzZSBwZXJmb3JtYW5jZSBtZXRyaWNzIHJhdGhlciB0aGFuIHRoZSBjdXJyZW50bHkg ZGVmaW5lZCBzdGF0aWMgcHJpb3JpdGllcy4gVGhpcyBkcmFmdCBpcyBqdXN0IG9uZSBwaWVjZSBv ZiB0aGF0IGJpZ2dlciBwaWN0dXJlLg0KDQpZb3UncmUgcmlnaHQsIG9mIGNvdXJzZSwgYnV0IGlm IHRoZXJlJ3Mgbm8gd2F5IHRvIG1ha2UgcHJhY3RpY2FsIHVzZSBvZiB0aGlzIGRyYWZ0IHdpdGgg cmVndWxhciBJQ0UsIHRoZW4gdGhhdCdzIHVzZWZ1bCBpbmZvcm1hdGlvbiB0aGF0IG5lZWRzIHRv IGdvIGludG8gdGhlIGRyYWZ0LiBJZGVhbGx5IHdpdGggcG9pbnRlcnMgdG8gdGhlIGJpZ2dlciBw aWN0dXJlIHlvdSBtZW50aW9uZWQuDQoNCltUUl0gd2Ugd2lsbCB1cGRhdGUgdGhlIGludHJvZHVj dGlvbiBzZWN0aW9uIHRvIG1ha2UgaXQgY2xlYXIuICBUaGlzIGRyYWZ0IGNhbiBiZSB1c2VkIHdp dGggcmVndWxhciBJQ0Ugd2hlbiB0aGVyZSBpcyBubyBub3RpY2VhYmxlIGltcGFjdCBpbiBzZXR0 aW5nIHVwIHRoZSBtZWRpYSBzZXNzaW9uLiBJdCBkZXBlbmRzIG9uIHRoZSBudW1iZXIgb2YgY2Fu ZGlkYXRlIHBhaXJzLCB0aW1lIGludGVydmFsIChUYSkgZm9yIHBhY2luZyBJQ0UgY29ubmVjdGl2 aXR5IGNoZWNrcyBhbmQgUlRPIHZhbHVlcy4NCg0KLVRpcnUNCg0KU2ltb24NCg== --_000_913383AAA69FF945B8F946018B75898A3552591Axmbrcdx10ciscoc_ 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 LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5JbmxpbmUgW1RSXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiB0cmFtIFttYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5TaW1vbiBQZXJyZWF1bHQ8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgRGVjZW1iZXIg MzAsIDIwMTQgODowNyBQTTxicj4NCjxiPlRvOjwvYj4gQnJhbmRvbiBXaWxsaWFtczxicj4NCjxi PkNjOjwvYj4gdHJhbUBpZXRmLm9yZzsgQWlqdW4gV2FuZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW3RyYW1dIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXJlZGR5LXRy YW0tc3R1bi1wYXRoLWRhdGEtMDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIERlYyAzMCwgMjAxNCBhdCA5OjMxIEFNLCBC cmFuZG9uIFdpbGxpYW1zICZsdDs8YSBocmVmPSJtYWlsdG86YnJhbmRvbi53aWxsaWFtc0Bha2Ft YWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+YnJhbmRvbi53aWxsaWFtc0Bha2FtYWkuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3UgYXJlIGNv cnJlY3QgdGhhdCB0aGUgY3VycmVudGx5IHB1Ymxpc2hlZCBSRkMgbWFrZXMgdGhlIHBhdGggcXVh bGl0eSBpbmZvcm1hdGlvbiBoYXJkZXIgdG8gdXNlIGluIGEgbWVhbmluZ2Z1bCB3YXkuIEhvd2V2 ZXIsIHRoZXJlIGlzIG9uZ29pbmcgd29yayBpbiBib3RoIHRyYW0gYW5kIG1tdXNpYyBmb2N1c2Vk IG9uIGFsbG93aW5nIG1vcmUgZHluYW1pYyBwYXRoIHNlbGVjdGlvbiB0aGF0IGNhbiB1c2UgcGVy Zm9ybWFuY2UNCiBtZXRyaWNzIHJhdGhlciB0aGFuIHRoZSBjdXJyZW50bHkgZGVmaW5lZCBzdGF0 aWMgcHJpb3JpdGllcy4gVGhpcyBkcmFmdCBpcyBqdXN0IG9uZSBwaWVjZSBvZiB0aGF0IGJpZ2dl ciBwaWN0dXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQpZb3UncmUgcmlnaHQsIG9mIGNvdXJzZSwgYnV0IGlmIHRoZXJlJ3Mgbm8gd2F5IHRvIG1h a2UgcHJhY3RpY2FsIHVzZSBvZiB0aGlzIGRyYWZ0IHdpdGggcmVndWxhciBJQ0UsIHRoZW4gdGhh dCdzIHVzZWZ1bCBpbmZvcm1hdGlvbiB0aGF0IG5lZWRzIHRvIGdvIGludG8gdGhlIGRyYWZ0LiBJ ZGVhbGx5IHdpdGggcG9pbnRlcnMgdG8gdGhlIGJpZ2dlciBwaWN0dXJlIHlvdSBtZW50aW9uZWQu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPltUUl0gd2Ugd2lsbCB1cGRhdGUgdGhlIGludHJvZHVjdGlvbiBzZWN0aW9uIHRvIG1ha2Ug aXQgY2xlYXIuICZuYnNwO1RoaXMgZHJhZnQgY2FuIGJlIHVzZWQgd2l0aCByZWd1bGFyIElDRSB3 aGVuIHRoZXJlIGlzIG5vIG5vdGljZWFibGUgaW1wYWN0IGluIHNldHRpbmcgdXAgdGhlDQogbWVk aWEgc2Vzc2lvbi4gSXQgZGVwZW5kcyBvbiB0aGUgbnVtYmVyIG9mIGNhbmRpZGF0ZSBwYWlycywg dGltZSBpbnRlcnZhbCAoVGEpIGZvciBwYWNpbmcgSUNFIGNvbm5lY3Rpdml0eSBjaGVja3MgYW5k IFJUTyB2YWx1ZXMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1UaXJ1PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2ltb248bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_913383AAA69FF945B8F946018B75898A3552591Axmbrcdx10ciscoc_--