From nobody Mon Mar 2 04:35:35 2015 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 007D11A7013 for ; Mon, 2 Mar 2015 04:35:34 -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 LEdR0-VVhi_V for ; Mon, 2 Mar 2015 04:35:31 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FEA81A0066 for ; Mon, 2 Mar 2015 04:35:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14244; q=dns/txt; s=iport; t=1425299731; x=1426509331; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DaX4JPEBNJqM0kktAvFr7EiYZicffQjyZDdrbm1M9tM=; b=m/QWvXmlxDUj86zCDp/z3UMPxgWr8tLO08jp243H8boqTaArHqVGLY1b 76K2UMGPc/IGL0/GqVexqh96S1gkOlnjfhRtEswJlx9n5ws6FT91UFTQU Zd7P4EciWZ8Q8MzygrVE5aaoIAAVRticmcdr4e118BIJZqUyM2rC/npAD w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C9BgBfWPRU/51dJa1agwJSXoMGvEKBagELhW4CHIEGTQEBAQEBAXyEEAEBBAEBASBLCxACAQgOMQMCAgIlCxQDAQ0CBA4FCYgmDbwLmSUBAQEBAQEBAQEBAQEBAQEBAQEBAQEXixKEDV0EBwmCXy+BFAWNe4F9g2CFZ4EaOYJni2KDPiOBfYFxbwGBAkF/AQEB X-IronPort-AV: E=Sophos;i="5.09,675,1418083200"; d="scan'208,217";a="114346921" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by mtv-iport-2.cisco.com with ESMTP; 02 Mar 2015 12:35:30 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t22CZSt2002592 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Mar 2015 12:35:30 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.40]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Mon, 2 Mar 2015 06:35:28 -0600 From: "Pal Martinsen (palmarti)" To: Benjamin Schwartz Thread-Topic: [tram] STUNTrace Draft Thread-Index: AQHQUqOHsfB2hrwh90Gd8Ygz4gVbaZ0FDNoAgAR9LYA= Date: Mon, 2 Mar 2015 12:35:28 +0000 Message-ID: References: <20150227152034.989.5946.idtracker@ietfa.amsl.com> <5BD9B28E-26D7-4E2A-838B-4D788454D079@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.61.223.47] Content-Type: multipart/alternative; boundary="_000_D0664D5ACC69461AAAE7A25168A60448ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] STUNTrace Draft 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, 02 Mar 2015 12:35:34 -0000 --_000_D0664D5ACC69461AAAE7A25168A60448ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiAyNyBGZWIgMjAxNSwgYXQgMTc6MDIsIEJlbmphbWluIFNjaHdhcnR6IDxiZW1hc2NAd2Vi cnRjLm9yZzxtYWlsdG86YmVtYXNjQHdlYnJ0Yy5vcmc+PiB3cm90ZToNCg0KSG93IHdpZGVseSBk ZXBsb3llZCAoYW5kIGVuYWJsZWQpIGlzIHRoaXMga2luZCBvZiBJQ01QIGVycm9yIHJlcG9ydGlu ZyAoZS5nLiBUVEwgZXhjZWVkZWQpPyAgTXkgaW1wcmVzc2lvbiwgY29uc2lzdGVudCB3aXRoIHlv dXIgc2VjdXJpdHkgc2VjdGlvbiwgaXMgdGhhdCBtYW55IG5ldHdvcmsgYWRtaW5pc3RyYXRvcnMg ZGlzYWJsZSB0aGlzIGZ1bmN0aW9uYWxpdHkuDQoNCg0KVGhhdCBpcyB2ZXJ5IGdvb2QgcXVlc3Rp b24uDQoNCkZyb20gbXkgcGVyc3BlY3RpdmUgbW9zdCBJU1BzIHJlc3BvbmQgYmFjayB3aXRoIGEg cHJvcGVyIElDTVAgbWVzc2FnZS4gT25jZSB0aGUgcGFja2V0cyBzdGFydCB0byBoaXQgdGhlIOKA nGNsb3VkIGJvdW5kYXJpZXPigJ0gb2ZmIGdvb2dsZSwgYW1hem9uLCBha2FtYWkgYW5kIHNvIG9u IHlvdSBhcmUgbGlrZWx5IHRvIGdldCBubyBhbnN3ZXJzLg0KDQpPdXIgbWFpbiBtb3RpdmF0aW9u IGZvciB3cml0aW5nIHRoaXMgdXAgaXMgdG8gaGF2ZSBhIG5pY2UgdHJvdWJsZXNob290aW5nIHRv b2wgZm9yIHlvdXIgb3duIGludGVybmFsIG5ldHdvcmsgYW5kIG91dCB0byB5b3VyIElTUC4gQ29t YmluaW5nIGluZm9ybWF0aW9uIGZyb20gUlRQL1JUQ1AgcmVnYXJkaW5nIGxhdGVuY3kgYW5kIHBh Y2tldCBkcm9wIHdpdGggdGhlIHBhdGggaW5mb3JtYXRpb24gZ2l2ZW4gYnkgU1RVTlRyYWNlIGVu YWJsZXMgYSBuZXR3b3JrIGFkbWluaXN0cmF0b3IgYSBwcmV0dHkgbmljZSB2aWV3IG9mIHBvdGVu dGlhbCBwcm9ibGVtcyBpbiB0aGUgbmV0d29yay4NCg0KLi0uDQpQw6VsLUVyaWsNCg0KT24gRnJp LCBGZWIgMjcsIDIwMTUgYXQgMTA6MzkgQU0sIFBhbCBNYXJ0aW5zZW4gKHBhbG1hcnRpKSA8cGFs bWFydGlAY2lzY28uY29tPG1haWx0bzpwYWxtYXJ0aUBjaXNjby5jb20+PiB3cm90ZToNCkhpLA0K DQpXZSBqdXN0IHVwbG9hZGVkIGEgbmV3IGRyYWZ0LCBTVFVOVHJhY2UgKGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LW1hcnRpbnNlbi10cmFtLXN0dW50cmFjZS0wMCkuIEl0IGRlc2Ny aWJlcyBob3cgdG8gZHUg4oCcaW4tYmFuZOKAnSB0cmFjcmVvdXRlIG9uIHRoZSBzYW1lIDUtdHVw bGUgYXMgeW91IHNlbmQgbWVkaWEgdXNpbmcgU1RVTiBwcm9iZSBwYWNrZXRzIGFuZCBJQ01QIHJl c3BvbnNlcy4NCg0KSXQgYWxpZ25zIHdpdGggaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXBldGl0aHVndWVuaW4tdHJhbS1zdHVuLXBtdHVkLTAwIHVzaW5nIFNUVU4gYXMgYSBwcm9i ZSB0byBkaXNjb3ZlciBuZXR3b3JrIHByb3BlcnRpZXMuDQoNCldlIGFkZGVkIGNvZGUgZXhhbXBs ZXMgaW4gdGhlIGFwcGVuZGl4IHRvIGNsYXJpZnkgaG93IElDTVAgY2FuIGJlIHJlY2VpdmVkIGJ5 IGFwcGxpY2F0aW9ucyB3aXRob3V0IHJlcXVpcmluZyBhZG1pbiBwcml2aWxlZ2VzLiBXZSBzdGls bCBsYWNrIFdpbmRvd3MgZXhhbXBsZXMsIHNvIGhlbHAgd2l0aCB0aGF0IGlzIGFwcHJlY2lhdGVk LiBJQ01QIHRlc3QgY29kZSAobm90IGltcGxlbWVudGluZyB0aGlzIGRyYWZ0KSBjYW4gYmUgZm91 bmQgYXQ6IGh0dHBzOi8vZ2l0aHViLmNvbS9wYWxlcmlrbS9JQ01QVGVzdA0KDQpRdWVzdGlvbnMg YW5kIGNvbW1lbnRzIGFyZSBvZiBjb3Vyc2Ugd2VsY29tZS4NCg0KLi0uDQpQw6VsLUVyaWsNCg0K DQpCZWdpbiBmb3J3YXJkZWQgbWVzc2FnZToNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0 LW1hcnRpbnNlbi10cmFtLXN0dW50cmFjZS0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgUGFhbC1FcmlrIE1hcnRpbnNlbiBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiBy ZXBvc2l0b3J5Lg0KDQpOYW1lOiBkcmFmdC1tYXJ0aW5zZW4tdHJhbS1zdHVudHJhY2UNClJldmlz aW9uOiAwMA0KVGl0bGU6IFNUVU4gVHJhY2Vyb3V0ZQ0KRG9jdW1lbnQgZGF0ZTogMjAxNS0wMi0y Nw0KR3JvdXA6IEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6IDEyDQpVUkw6ICAgICAgICAg ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbWFydGluc2VuLXRy YW0tc3R1bnRyYWNlLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LW1hcnRpbnNlbi10cmFtLXN0dW50cmFjZS8NCkh0bWxpemVkOiAg ICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYXJ0aW5zZW4tdHJhbS1zdHVu dHJhY2UtMDANCg0KDQpBYnN0cmFjdDoNCiAgQWZ0ZXIgYSBVRFAgcHJvdG9jb2wgc3VjaCBhcyBS VFAgZGV0ZXJtaW5lcyBhIG5ldHdvcmsgcGF0aCBpcw0KICBleHBlcmllbmNpbmcgcHJvYmxlbXMs IGEgdHJhY2Vyb3V0ZSBpcyBvZnRlbiB1c2VmdWwgdG8gZGV0ZXJtaW5lDQogIHdoaWNoIHJvdXRl ciBvciB3aGljaCBsaW5rIGlzIGNvbnRyaWJ1dGluZyB0byB0aGUgcHJvYmxlbS4gIEhvd2V2ZXIs DQogIG9wZXJhdGluZyBzeXN0ZW0gdHJhY2Vyb3V0ZSBjb21tYW5kcyBmb2xsb3cgYSBkaWZmZXJl bnQgcGF0aCB0aGFuIHRoZQ0KICBhY3R1YWwgVURQIGZsb3cgd2hpY2ggY29tcGxpY2F0ZXMgdHJv dWJsZXNob290aW5nLiAgQSBzdXBlcmlvciBtZXRob2QNCiAgaXMgc2hvd24gd2hpY2ggaXMgYWJz b2x1dGVseSBwYXRoLWNvbmdydWVudCB3aXRoIHRoZSBVRFAgcHJvdG9jb2wNCiAgaXRzZWxmLCB3 b3JrcyBvbiBJUHY0IGFuZCBJUHY2LCBhbmQgZG9lcyBub3QgcmVxdWlyZSBhZG1pbmlzdHJhdGl2 ZQ0KICBwcml2aWxlZ2VzIG9uIG1vc3Qgb3BlcmF0aW5nIHN5c3RlbXMuDQoNCg0KDQoNClBsZWFz ZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1l IG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBh dmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnLz4uDQoNClRo ZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KdHJhbSBtYWlsaW5nIGxpc3QNCnRyYW1AaWV0Zi5vcmc8bWFpbHRv OnRyYW1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Ry YW0NCg0KDQoNCg== --_000_D0664D5ACC69461AAAE7A25168A60448ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <7D6759C1CCB80247B1C6D346D916EB42@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAyNyBG ZWIgMjAxNSwgYXQgMTc6MDIsIEJlbmphbWluIFNjaHdhcnR6ICZsdDs8YSBocmVmPSJtYWlsdG86 YmVtYXNjQHdlYnJ0Yy5vcmciIGNsYXNzPSIiPmJlbWFzY0B3ZWJydGMub3JnPC9hPiZndDsgd3Jv dGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPkhvdyB3aWRlbHkgZGVwbG95ZWQgKGFu ZCBlbmFibGVkKSBpcyB0aGlzIGtpbmQgb2YgSUNNUCBlcnJvciByZXBvcnRpbmcgKGUuZy4gVFRM IGV4Y2VlZGVkKT8mbmJzcDsgTXkgaW1wcmVzc2lvbiwgY29uc2lzdGVudCB3aXRoIHlvdXIgc2Vj dXJpdHkgc2VjdGlvbiwgaXMgdGhhdCBtYW55IG5ldHdvcmsgYWRtaW5pc3RyYXRvcnMgZGlzYWJs ZSB0aGlzIGZ1bmN0aW9uYWxpdHkuPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2PlRoYXQgaXMgdmVyeSBnb29kIHF1ZXN0aW9uLjwvZGl2Pg0KPGRp dj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+RnJvbSBteSBwZXJzcGVjdGl2ZSBtb3N0IElT UHMgcmVzcG9uZCBiYWNrIHdpdGggYSBwcm9wZXIgSUNNUCBtZXNzYWdlLiBPbmNlIHRoZSBwYWNr ZXRzIHN0YXJ0IHRvIGhpdCB0aGUg4oCcY2xvdWQgYm91bmRhcmllc+KAnSBvZmYgZ29vZ2xlLCBh bWF6b24sIGFrYW1haSBhbmQgc28gb24geW91IGFyZSBsaWtlbHkgdG8gZ2V0IG5vIGFuc3dlcnMu Jm5ic3A7PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5PdXIgbWFpbiBt b3RpdmF0aW9uIGZvciB3cml0aW5nIHRoaXMgdXAgaXMgdG8gaGF2ZSBhIG5pY2UgdHJvdWJsZXNo b290aW5nIHRvb2wgZm9yIHlvdXIgb3duIGludGVybmFsIG5ldHdvcmsgYW5kIG91dCB0byB5b3Vy IElTUC4gQ29tYmluaW5nIGluZm9ybWF0aW9uIGZyb20gUlRQL1JUQ1AgcmVnYXJkaW5nIGxhdGVu Y3kgYW5kIHBhY2tldCBkcm9wIHdpdGggdGhlIHBhdGggaW5mb3JtYXRpb24gZ2l2ZW4gYnkgU1RV TlRyYWNlIGVuYWJsZXMNCiBhIG5ldHdvcmsgYWRtaW5pc3RyYXRvciBhIHByZXR0eSBuaWNlIHZp ZXcgb2YgcG90ZW50aWFsIHByb2JsZW1zIGluIHRoZSBuZXR3b3JrLjwvZGl2Pg0KPGRpdj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+Li0uPC9kaXY+DQo8ZGl2PlDDpWwtRXJpazwvZGl2Pg0K PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVv dGUiPk9uIEZyaSwgRmViIDI3LCAyMDE1IGF0IDEwOjM5IEFNLCBQYWwgTWFydGluc2VuIChwYWxt YXJ0aSkNCjxzcGFuIGRpcj0ibHRyIiBjbGFzcz0iIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOnBhbG1h cnRpQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPnBhbG1hcnRpQGNpc2NvLmNv bTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSBjbGFzcz0i Z21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2Nj YyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13 b3JkIiBjbGFzcz0iIj5IaSwNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPldlIGp1c3QgdXBsb2FkZWQgYSBuZXcgZHJhZnQsIFNUVU5UcmFjZSAoPGEg aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWFydGluc2VuLXRyYW0tc3R1 bnRyYWNlLTAwIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtbWFydGluc2VuLXRyYW0tc3R1bnRyYWNlLTAwPC9hPikuIEl0IGRlc2NyaWJl cyBob3cgdG8gZHUg4oCcaW4tYmFuZOKAnSB0cmFjcmVvdXRlDQogb24gdGhlIHNhbWUgNS10dXBs ZSBhcyB5b3Ugc2VuZCBtZWRpYSB1c2luZyBTVFVOIHByb2JlIHBhY2tldHMgYW5kIElDTVAgcmVz cG9uc2VzLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+SXQgYWxpZ25zIHdpdGgmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtcGV0aXRodWd1ZW5pbi10cmFtLXN0dW4tcG10dWQtMDAiIHRh cmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt cGV0aXRodWd1ZW5pbi10cmFtLXN0dW4tcG10dWQtMDA8L2E+Jm5ic3A7dXNpbmcgU1RVTiBhcyBh IHByb2JlIHRvIGRpc2NvdmVyIG5ldHdvcmsgcHJvcGVydGllcy48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPldlIGFkZGVkIGNvZGUgZXhh bXBsZXMgaW4gdGhlIGFwcGVuZGl4IHRvIGNsYXJpZnkgaG93IElDTVAgY2FuIGJlIHJlY2VpdmVk IGJ5IGFwcGxpY2F0aW9ucyB3aXRob3V0IHJlcXVpcmluZyBhZG1pbiBwcml2aWxlZ2VzLiBXZSBz dGlsbCBsYWNrIFdpbmRvd3MgZXhhbXBsZXMsIHNvIGhlbHAgd2l0aCB0aGF0IGlzIGFwcHJlY2lh dGVkLiBJQ01QIHRlc3QgY29kZSAobm90IGltcGxlbWVudGluZyB0aGlzIGRyYWZ0KSBjYW4gYmUN CiBmb3VuZCBhdDombmJzcDs8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vcGFsZXJpa20vSUNN UFRlc3QiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL2dpdGh1Yi5jb20vcGFsZXJp a20vSUNNUFRlc3Q8L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj5RdWVzdGlvbnMgYW5kIGNvbW1lbnRzIGFyZSBvZiBjb3Vyc2Ugd2Vs Y29tZS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPi4tLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Qw6VsLUVyaWs8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+QmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1tYXJ0aW5zZW4tdHJhbS1z dHVudHJhY2UtMDAudHh0PGJyIGNsYXNzPSIiPg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBQYWFsLUVyaWsgTWFydGluc2VuIGFuZCBwb3N0ZWQgdG8gdGhlPGJyIGNsYXNzPSIi Pg0KSUVURiByZXBvc2l0b3J5LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk5hbWU6PHNw YW4gc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIiBjbGFzcz0iIj4gPC9zcGFuPjxzcGFuIHN0 eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCIgY2xhc3M9IiI+PC9zcGFuPmRyYWZ0LW1hcnRpbnNl bi10cmFtLXN0dW50cmFjZTxiciBjbGFzcz0iIj4NClJldmlzaW9uOjxzcGFuIHN0eWxlPSJ3aGl0 ZS1zcGFjZTpwcmUtd3JhcCIgY2xhc3M9IiI+IDwvc3Bhbj4wMDxiciBjbGFzcz0iIj4NClRpdGxl OjxzcGFuIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCIgY2xhc3M9IiI+IDwvc3Bhbj48c3Bh biBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXAiIGNsYXNzPSIiPjwvc3Bhbj5TVFVOIFRyYWNl cm91dGU8YnIgY2xhc3M9IiI+DQpEb2N1bWVudCBkYXRlOjxzcGFuIHN0eWxlPSJ3aGl0ZS1zcGFj ZTpwcmUtd3JhcCIgY2xhc3M9IiI+IDwvc3Bhbj4yMDE1LTAyLTI3PGJyIGNsYXNzPSIiPg0KR3Jv dXA6PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIiBjbGFzcz0iIj4gPC9zcGFuPjxz cGFuIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCIgY2xhc3M9IiI+PC9zcGFuPkluZGl2aWR1 YWwgU3VibWlzc2lvbjxiciBjbGFzcz0iIj4NClBhZ2VzOjxzcGFuIHN0eWxlPSJ3aGl0ZS1zcGFj ZTpwcmUtd3JhcCIgY2xhc3M9IiI+IDwvc3Bhbj48c3BhbiBzdHlsZT0id2hpdGUtc3BhY2U6cHJl LXdyYXAiIGNsYXNzPSIiPjwvc3Bhbj4xMjxiciBjbGFzcz0iIj4NClVSTDogJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEg aHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbWFydGluc2Vu LXRyYW0tc3R1bnRyYWNlLTAwLnR4dCIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHA6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW1hcnRpbnNlbi10cmFtLXN0dW50cmFj ZS0wMC50eHQ8L2E+PGJyIGNsYXNzPSIiPg0KU3RhdHVzOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1tYXJ0aW5zZW4tdHJhbS1zdHVudHJhY2UvIiB0YXJnZXQ9Il9ibGFu ayIgY2xhc3M9IiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWFydGlu c2VuLXRyYW0tc3R1bnRyYWNlLzwvYT48YnIgY2xhc3M9IiI+DQpIdG1saXplZDogJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtbWFydGluc2VuLXRyYW0tc3R1bnRyYWNlLTAwIiB0YXJnZXQ9Il9ibGFuayIg Y2xhc3M9IiI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWFydGluc2VuLXRyYW0t c3R1bnRyYWNlLTAwPC9hPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCkFic3RyYWN0OjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO0FmdGVyIGEgVURQIHByb3Rv Y29sIHN1Y2ggYXMgUlRQIGRldGVybWluZXMgYSBuZXR3b3JrIHBhdGggaXM8YnIgY2xhc3M9IiI+ DQombmJzcDsmbmJzcDtleHBlcmllbmNpbmcgcHJvYmxlbXMsIGEgdHJhY2Vyb3V0ZSBpcyBvZnRl biB1c2VmdWwgdG8gZGV0ZXJtaW5lPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7d2hpY2ggcm91 dGVyIG9yIHdoaWNoIGxpbmsgaXMgY29udHJpYnV0aW5nIHRvIHRoZSBwcm9ibGVtLiZuYnNwOyBI b3dldmVyLDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO29wZXJhdGluZyBzeXN0ZW0gdHJhY2Vy b3V0ZSBjb21tYW5kcyBmb2xsb3cgYSBkaWZmZXJlbnQgcGF0aCB0aGFuIHRoZTxiciBjbGFzcz0i Ij4NCiZuYnNwOyZuYnNwO2FjdHVhbCBVRFAgZmxvdyB3aGljaCBjb21wbGljYXRlcyB0cm91Ymxl c2hvb3RpbmcuJm5ic3A7IEEgc3VwZXJpb3IgbWV0aG9kPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5i c3A7aXMgc2hvd24gd2hpY2ggaXMgYWJzb2x1dGVseSBwYXRoLWNvbmdydWVudCB3aXRoIHRoZSBV RFAgcHJvdG9jb2w8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtpdHNlbGYsIHdvcmtzIG9uIElQ djQgYW5kIElQdjYsIGFuZCBkb2VzIG5vdCByZXF1aXJlIGFkbWluaXN0cmF0aXZlPGJyIGNsYXNz PSIiPg0KJm5ic3A7Jm5ic3A7cHJpdmlsZWdlcyBvbiBtb3N0IG9wZXJhdGluZyBzeXN0ZW1zLjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnIgY2xhc3M9IiI+DQp1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0 dHA6Ly90b29scy5pZXRmLm9yZy8iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj4NCnRvb2xzLmll dGYub3JnPC9hPi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgSUVURiBTZWNyZXRh cmlhdDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+ DQp0cmFtIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzp0cmFtQGll dGYub3JnIiBjbGFzcz0iIj50cmFtQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbSIgdGFyZ2V0PSJfYmxh bmsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbTwv YT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBj bGFzcz0iIj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D0664D5ACC69461AAAE7A25168A60448ciscocom_-- From nobody Tue Mar 3 12:43:19 2015 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 F19BB1A893C; Tue, 3 Mar 2015 12:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DwwGhomah3Td; Tue, 3 Mar 2015 12:43:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B25A51A1AA9; Tue, 3 Mar 2015 12:43:15 -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.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150303204315.965.89943.idtracker@ietfa.amsl.com> Date: Tue, 03 Mar 2015 12:43:15 -0800 Archived-At: Cc: tram@ietf.org Subject: [tram] Last Call: (An Origin Attribute for the STUN Protocol) to Proposed Standard X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org 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, 03 Mar 2015 20:43:17 -0000 The IESG has received a request from the TURN Revised and Modernized WG (tram) to consider the following document: - 'An Origin Attribute for the STUN Protocol' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-03-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract STUN, or Session Traversal Utilities for NAT, is a protocol used to assist other protocols traverse Network Address Translators or NATs. 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, SIP, and XMPP contexts. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tram-stun-origin/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tram-stun-origin/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Mar 5 12:17:57 2015 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 50A061A8A0C for ; Thu, 5 Mar 2015 12:17:55 -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 uLhFh3NrwHkO for ; Thu, 5 Mar 2015 12:17:53 -0800 (PST) Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 010BD1A8A0B for ; Thu, 5 Mar 2015 12:17:52 -0800 (PST) Received: by qgdz107 with SMTP id z107so7621494qgd.4 for ; Thu, 05 Mar 2015 12:17:52 -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=Fw3dDKeDxTCx562SqiThD/QbLuCPHf/Zi6S6iHyqQBU=; b=SrgBmV9f6phb+Iv3jFxtLsITi0aFpvHpgrx/Dm/Q/lqi95Pb7T/l7siazB+cWzcIB4 9Lv8Xs3A7tuyK+iwVRF2wM2KUATVzIy9c/Tk9gv39Jmy8EwyEdLNfpwMz1pBe7x6DZdB Z6H0OJ2mwvEFHfs2FFTEgV7jZ+3RnfvqZl3c9g8q7EzadByzZsmcx7LxbHBYK3sNR9oB PN02+xqVn1eILklldNC4kxLzlY5pmyNQm4VxkG013Pu0LrRfK9ybJp2S2Tm1/pE9eXrx RR86XCdjq2yv/NHST2zMmsqFT/VjN2h83XY49+W694JO/resOQ2o8p34+lTTrglsNt2i nyXg== X-Gm-Message-State: ALoCoQmcoKdMjsEVmrFaAzgIQbv/T/eJboDJx9Qy1yx7oECIYXCEfBtqBgMA4VG+4cjxL7GGu4Gu X-Received: by 10.140.128.73 with SMTP id 70mr15074728qha.75.1425586672229; Thu, 05 Mar 2015 12:17:52 -0800 (PST) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com. [209.85.216.175]) by mx.google.com with ESMTPSA id f8sm4427012qaa.10.2015.03.05.12.17.51 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Mar 2015 12:17:51 -0800 (PST) Received: by qcxr5 with SMTP id r5so45564127qcx.10 for ; Thu, 05 Mar 2015 12:17:51 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.140.238.87 with SMTP id j84mr15377543qhc.78.1425586671108; Thu, 05 Mar 2015 12:17:51 -0800 (PST) Received: by 10.229.90.68 with HTTP; Thu, 5 Mar 2015 12:17:51 -0800 (PST) In-Reply-To: <20150305201507.6192.13143.idtracker@ietfa.amsl.com> References: <20150305201507.6192.13143.idtracker@ietfa.amsl.com> Date: Thu, 5 Mar 2015 15:17:51 -0500 Message-ID: From: Benjamin Schwartz To: "tram@ietf.org" Content-Type: multipart/alternative; boundary=001a1135c8b820f743051090432f Archived-At: Subject: [tram] Fwd: New Version Notification for draft-schwartz-tram-turnbyname-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, 05 Mar 2015 20:17:55 -0000 --001a1135c8b820f743051090432f Content-Type: text/plain; charset=UTF-8 Hi TRAM, I've just written up a proposal for an optional extension to TURN that would add support for DNS names. I'd like to discuss this at the upcoming meeting. Let me know what you think! Thanks, Ben ---------- Forwarded message ---------- From: Date: Thu, Mar 5, 2015 at 3:15 PM Subject: New Version Notification for draft-schwartz-tram-turnbyname-00.txt To: Justin Uberti , "Benjamin M. Schwartz" < bemasc@webrtc.org> A new version of I-D, draft-schwartz-tram-turnbyname-00.txt has been successfully submitted by Benjamin M. Schwartz and posted to the IETF repository. Name: draft-schwartz-tram-turnbyname Revision: 00 Title: TURN by name: an extension to TURN for contacting an endpoint by its DNS name. Document date: 2015-03-05 Group: Individual Submission Pages: 15 URL: http://www.ietf.org/internet-drafts/draft-schwartz-tram-turnbyname-00.txt Status: https://datatracker.ietf.org/doc/draft-schwartz-tram-turnbyname/ Htmlized: http://tools.ietf.org/html/draft-schwartz-tram-turnbyname-00 Abstract: When tunneling traffic through TURN, a client may sometimes desire to contact a remote endpoint that it knows by its DNS name, not its IP address. This document describes an extension to TURN that allows such a client to contact a named endpoint. 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 --001a1135c8b820f743051090432f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi TRAM,

I've just writt= en up a proposal for an optional extension to TURN that would add support f= or DNS names.=C2=A0 I'd like to discuss this at the upcoming meeting.

Let me know what you think!

Thanks,
Ben

---------- Forw= arded message ----------
From: <internet-drafts= @ietf.org>
Date: Thu, Mar 5, 2015 at 3:15 PM
Subject: N= ew Version Notification for draft-schwartz-tram-turnbyname-00.txt
To: Ju= stin Uberti <justin@uberti.name>, "Benjamin M. Schwartz" <bemasc@webrtc.org>



A new version of I-D, draft-schwartz-tram-turnbyname-00.txt
has been successfully submitted by Benjamin M. Schwartz and posted to the IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-schwartz-tram-turnbynam= e
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TURN by name: an extension to TURN= for contacting an endpoint by its DNS name.
Document date:=C2=A0 2015-03-05
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 15
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = http://www.ietf.org/internet-drafts/draft-schwartz-tram-turnbyname-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatr= acker.ietf.org/doc/draft-schwartz-tram-turnbyname/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/h= tml/draft-schwartz-tram-turnbyname-00


Abstract:
=C2=A0 =C2=A0When tunneling traffic through TURN, a client may sometimes de= sire to
=C2=A0 =C2=A0contact a remote endpoint that it knows by its DNS name, not i= ts IP
=C2=A0 =C2=A0address.=C2=A0 This document describes an extension to TURN th= at allows
=C2=A0 =C2=A0such a client to contact a named endpoint.




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


--001a1135c8b820f743051090432f-- From nobody Thu Mar 5 12:55:48 2015 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 19E631A8AEB for ; Thu, 5 Mar 2015 12:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 h5JpqVVcg8Ns for ; Thu, 5 Mar 2015 12:55:45 -0800 (PST) Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C356F1A8AE3 for ; Thu, 5 Mar 2015 12:55:45 -0800 (PST) Received: by qgdz60 with SMTP id z60so7924316qgd.5 for ; Thu, 05 Mar 2015 12:55:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9qWjc1SWvQ8KZtDQJaGvBpVTs2hvy1XVesQ1+w2Flw0=; b=kvsftML15Bq/EfLyAL7rqxN7C/pKWpqWBESFPcxE0EY/G+2UlVmLFCx1AdPan8WP5f ec3rgFtBlDiHL4XlZwHp/XIyItoAzdXMgjj+uOEWz/+PqO7XMEi6Y++oLvMepHxisCNk 2fP706DbsluY3Jop2R6YHUhiZpZkS0fW83JrhBIAxw9RvccEFQSOjyskRbky4eyPF/o4 DpNwkGT1N2ynHIx8suBBE/L+zwBK5HvUmbuNCCEF3ejKIbHVBbiLCuGURZYn28l6GNEm RhtWmt4dwkCptOJqQ/VMiKl/5y0dSg6xlVQOc2o8RnLRUkPxfKnMo/IsMS1zNR1KD1Ul Wy2g== X-Gm-Message-State: ALoCoQmylMaJHsI+NccbiYAVVnFJ3iIOfXzXJNCxz1b8moiDEIvOePJrS7v3u1G5aXutspM2Rt59 X-Received: by 10.140.231.75 with SMTP id b72mr15428448qhc.3.1425588945008; Thu, 05 Mar 2015 12:55:45 -0800 (PST) Received: from [192.168.1.43] (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id d32sm4434261qga.12.2015.03.05.12.55.44 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Mar 2015 12:55:44 -0800 (PST) Message-ID: <54F8C2CF.1080201@jive.com> Date: Thu, 05 Mar 2015 15:55:43 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Benjamin Schwartz , "tram@ietf.org" References: <20150305201507.6192.13143.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tram] Fwd: New Version Notification for draft-schwartz-tram-turnbyname-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, 05 Mar 2015 20:55:47 -0000 Le 2015-03-05 15:17, Benjamin Schwartz a écrit : > I've just written up a proposal for an optional extension to TURN that > would add support for DNS names. I'd like to discuss this at the > upcoming meeting. > > Let me know what you think! Interesting! You have a twisted mind. ;) Some random comments/questions as I read the draft: - What happens when there are multiple A/AAAA records for a name? In many places it seems like it is assumed that there will only ever be one record. - The name mapping mechanism is super ugly. It breaks DNS caching. I think it would help if you could find a way to get rid of it. - As soon as the connection to your peer is established, you don't care about names anymore. What you care about is the 5-tuple. Yet in your proposal the client will keep referring to things by name. This seems brittle to me. A more robust design would be to use names in the connection initiation phase only, then go back to addresses and ports for steady-state. - Why not just use an unmodified TURN server to proxy UDP packets to 8.8.8.8:53, for example, and keep all the name-resolving logic client-side? Simon From nobody Thu Mar 5 13:28:58 2015 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 7F84A1A902F for ; Thu, 5 Mar 2015 13:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, WEIRD_PORT=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 i_TkPOpxIlzH for ; Thu, 5 Mar 2015 13:28:54 -0800 (PST) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B70601A9026 for ; Thu, 5 Mar 2015 13:28:52 -0800 (PST) Received: by qgdz60 with SMTP id z60so8164086qgd.5 for ; Thu, 05 Mar 2015 13:28:52 -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=L17KWPTe2aP9iFl4A4HQ0nLynmBTV8ctSz6s5mE6I1k=; b=MbWwrbAzo1+VBxuwtDNeq+3cwdZ5r81+Em/h6cC+PsI0qDCOFl3r/vUFML+xwyWshM 56/WJZ50VV8EFKO1MWgP3OhNPma89ix29qir9dkzth+rUuuG4gg5k6EI8FjU1kWnChKX 3c2XRD6spaiLd2oNfM6av6m2tIER8W2j9M5y5dDa3oUfQh8xVFmlywFpqhqWC2hSXsxc Y5fr0oIliCOBgy6CAgvq7TU7mBoN+KUxfq5a1dXPGRveuw0WibVBw3jpQliXkRbLl6/1 YphgTLxP6LfUrHdXMktHxaiQ4R3LWS1GV10QcOpHWPSS3W5F2H04/cCgBSLfIilA1rAr gNWw== X-Gm-Message-State: ALoCoQnfwY/9jcYNJB3UoCkksJyejEpBQmXiPLt1Zf1S/TBa7wAPQVcqGQHJjs5wp7WcthKaWlyI X-Received: by 10.55.41.69 with SMTP id p66mr22317771qkh.101.1425590931951; Thu, 05 Mar 2015 13:28:51 -0800 (PST) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com. [209.85.192.45]) by mx.google.com with ESMTPSA id e14sm3354559qka.31.2015.03.05.13.28.51 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Mar 2015 13:28:51 -0800 (PST) Received: by qgfh3 with SMTP id h3so8140807qgf.13 for ; Thu, 05 Mar 2015 13:28:50 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.140.32.52 with SMTP id g49mr14846823qgg.83.1425590930751; Thu, 05 Mar 2015 13:28:50 -0800 (PST) Received: by 10.229.90.68 with HTTP; Thu, 5 Mar 2015 13:28:50 -0800 (PST) In-Reply-To: <54F8C2CF.1080201@jive.com> References: <20150305201507.6192.13143.idtracker@ietfa.amsl.com> <54F8C2CF.1080201@jive.com> Date: Thu, 5 Mar 2015 16:28:50 -0500 Message-ID: From: Benjamin Schwartz To: Simon Perreault Content-Type: multipart/alternative; boundary=001a113a625405f1c70510914164 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Fwd: New Version Notification for draft-schwartz-tram-turnbyname-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, 05 Mar 2015 21:28:56 -0000 --001a113a625405f1c70510914164 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 5, 2015 at 3:55 PM, Simon Perreault wrote= : > Le 2015-03-05 15:17, Benjamin Schwartz a =C3=A9crit : > >> I've just written up a proposal for an optional extension to TURN that >> would add support for DNS names. I'd like to discuss this at the >> upcoming meeting. >> >> Let me know what you think! >> > > Interesting! You have a twisted mind. ;) > > Some random comments/questions as I read the draft: > > - What happens when there are multiple A/AAAA records for a name? In many > places it seems like it is assumed that there will only ever be one recor= d. > Implementation-defined. I specifically avoided specifying this so that implementers would be free to use gethostbyname() without worrying about what it does in this case. - The name mapping mechanism is super ugly. It breaks DNS caching. I think > it would help if you could find a way to get rid of it. > > - As soon as the connection to your peer is established, you don't care > about names anymore. What you care about is the 5-tuple. Yet in your > proposal the client will keep referring to things by name. This seems > brittle to me. A more robust design would be to use names in the connecti= on > initiation phase only, then go back to addresses and ports for steady-sta= te. > I sympathize with both of these points, and I'm totally happy to entertain alternatives. (In fact, I've written up several alternatives along those lines, including one that just introduces a "Resolve Request" message that resolves a name to an IP address.) The motivation for this Name Mapping design is to _avoid_ revealing the IP address to the client, and instead to maintain the kind of DNS abstraction barrier provided by HTTP CONNECT and SOCKS5 proxies. For a simple client, this kind of abstraction does seem convenient. Also, if the client operates by IP address, then it's likely that WebRTC will leak the IP through to javascript ... potentially creating a DNS resolution tool for javascript. There is currently no such mechanism built into browsers, so it seems like this should not be done lightly. If you don't find this convincing, then I'm happy to talk through alternatives! - Why not just use an unmodified TURN server to proxy UDP packets to > 8.8.8.8:53, for example, and keep all the name-resolving logic > client-side? Telling people to hardcode specific DNS server IP addresses in their code, bypassing network-level DNS configurations like DHCP, gives me the heebie-jeebies, but I have to admit that this would likely work quite well. > > > Simon > --001a113a625405f1c70510914164 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 5, 2015 at 3:55 PM, Simon Perreault <sperreault@jive.com&g= t; wrote:
Le 2015-03-05 15:17, Benjamin Schwartz= a =C3=A9crit :
I've just written up a proposal for an optional extension to TURN that<= br> would add support for DNS names.=C2=A0 I'd like to discuss this at the<= br> upcoming meeting.

Let me know what you think!

 Interesting! You have a twisted mind. ;)

Some random comments/questions as I read the draft:

- What happens when there are multiple A/AAAA records for a name? In many p= laces it seems like it is assumed that there will only ever be one record.<= br>

Implementation-defined.=C2=A0 I specifi= cally avoided specifying this so that implementers would be free to use get= hostbyname() without worrying about what it does in this case.
- The name mapping mechanism is super ugly. It breaks DNS caching. I think = it would help if you could find a way to get rid of it.

- As soon as the connection to your peer is established, you don't care= about names anymore. What you care about is the 5-tuple. Yet in your propo= sal the client will keep referring to things by name. This seems brittle to= me. A more robust design would be to use names in the connection initiatio= n phase only, then go back to addresses and ports for steady-state.

I sympathize with both of these points, and I&= #39;m totally happy to entertain alternatives. =C2=A0(In fact, I've wri= tten up several alternatives along those lines, including one that just int= roduces a "Resolve Request" message that resolves a name to an IP= address.)

The motivation for this Name Mapping de= sign is to _avoid_ revealing the IP address to the client, and instead to m= aintain the kind of DNS abstraction barrier provided by HTTP CONNECT and SO= CKS5 proxies.=C2=A0 For a simple client, this kind of abstraction does seem= convenient.

Also, if the client operates by IP ad= dress, then it's likely that WebRTC will leak the IP through to javascr= ipt ... potentially creating a DNS resolution tool for javascript.=C2=A0 Th= ere is currently no such mechanism built into browsers, so it seems like th= is should not be done lightly.

If you don't fi= nd this convincing, then I'm happy to talk through alternatives!
<= div>
- Why not just use an unmodified TURN server to proxy UDP packets to 8.8.8.8:53, for example, and = keep all the name-resolving logic client-side?

<= div>Telling people to hardcode specific DNS server IP addresses in their co= de, bypassing network-level DNS configurations like DHCP, gives me the heeb= ie-jeebies, but I have to admit that this would likely work quite well.
=C2=A0


Simon

--001a113a625405f1c70510914164-- From nobody Thu Mar 5 13:41:48 2015 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 DD9F41A9053 for ; Thu, 5 Mar 2015 13:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, WEIRD_PORT=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 hTsj8Mtu3Xoc for ; Thu, 5 Mar 2015 13:41:45 -0800 (PST) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C21B91A9048 for ; Thu, 5 Mar 2015 13:41:44 -0800 (PST) Received: by qcxr5 with SMTP id r5so46173151qcx.10 for ; Thu, 05 Mar 2015 13:41:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7d9QnkVBh6Z1D+TNltkFcaabU4PBlucslQb6umfjaVU=; b=cFvP522wgjXQnuBIXivr8lFnSWwyglrXWwHFf4zs1jEXeeC807m+8Yh1/y1lfaz+sI OIHO3nQxgPuJtlTqv41k9WXnA4LPVQp+NfPShFWDidU+s8W52b/KuMdn1n47SZj9P49I UJW94YFuIJy2CIfjzeFrNJtNqT3QFwHziyd7qO1cAC2cUHVVMZJ5P6guFVrUTjOLDuPn Ot0WpaWu+eDMTJyAjN6DiARnEQwBNmRLhieGUq7XAOt27c58mIbGfIPLTusP68v65Ri4 fsMYQlmC75wQ1cWspclOJ07FVbw/skmGxhq6t7231nvXYS0Y70woZvmPs1Ejr4+tPewt S2hQ== X-Gm-Message-State: ALoCoQlB70E/h97oYdtMI7SJdMR2mS67x9Uv7psYVF1YK9p6IR4hDxu8yyZdWHfpwsEMKSvYK+tR X-Received: by 10.140.101.22 with SMTP id t22mr15181284qge.9.1425591703989; Thu, 05 Mar 2015 13:41:43 -0800 (PST) Received: from [192.168.1.43] (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id o15sm4539577qaa.3.2015.03.05.13.41.43 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Mar 2015 13:41:43 -0800 (PST) Message-ID: <54F8CD96.7050607@jive.com> Date: Thu, 05 Mar 2015 16:41:42 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Benjamin Schwartz References: <20150305201507.6192.13143.idtracker@ietfa.amsl.com> <54F8C2CF.1080201@jive.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Fwd: New Version Notification for draft-schwartz-tram-turnbyname-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, 05 Mar 2015 21:41:47 -0000 Le 2015-03-05 16:28, Benjamin Schwartz a écrit : > - What happens when there are multiple A/AAAA records for a name? In > many places it seems like it is assumed that there will only ever be > one record. > > Implementation-defined. I specifically avoided specifying this so that > implementers would be free to use gethostbyname() without worrying about > what it does in this case. Then the text should say it is implementation-defined. I'm not saying that's gonna fly, but at least it won't appear like you overlooked the issue. > - The name mapping mechanism is super ugly. It breaks DNS caching. I > think it would help if you could find a way to get rid of it. > > - As soon as the connection to your peer is established, you don't > care about names anymore. What you care about is the 5-tuple. Yet in > your proposal the client will keep referring to things by name. This > seems brittle to me. A more robust design would be to use names in > the connection initiation phase only, then go back to addresses and > ports for steady-state. > > > I sympathize with both of these points, and I'm totally happy to > entertain alternatives. (In fact, I've written up several alternatives > along those lines, including one that just introduces a "Resolve > Request" message that resolves a name to an IP address.) > > The motivation for this Name Mapping design is to _avoid_ revealing the > IP address to the client, and instead to maintain the kind of DNS > abstraction barrier provided by HTTP CONNECT and SOCKS5 proxies. For a > simple client, this kind of abstraction does seem convenient. I agree. The big difference is HTTP CONNECT is TCP-based. The same abstraction would apply perfectly to TURN-TCP. For UDP it's much more clumsy. > Also, if the client operates by IP address, then it's likely that WebRTC > will leak the IP through to javascript ... potentially creating a DNS > resolution tool for javascript. There is currently no such mechanism > built into browsers, so it seems like this should not be done lightly. Good point. > If you don't find this convincing, then I'm happy to talk through > alternatives! > > - Why not just use an unmodified TURN server to proxy UDP packets to > 8.8.8.8:53 , for example, and keep all the > name-resolving logic client-side? > > Telling people to hardcode specific DNS server IP addresses in their > code, bypassing network-level DNS configurations like DHCP, gives me the > heebie-jeebies, but I have to admit that this would likely work quite well. Ok, here's a small tweak. Instead of hardcoding a DNS server, rely on TURN server config. You're already doing so implicitly in your proposal. So reserve a well-known address that will get translated into the actual DNS server's address by the TURN server, according to its configuration. That well-known address would be special signalling meaning "whatever's at the top of the TURN server's /etc/resolv.conf". ;) Simon From nobody Thu Mar 5 14:17:52 2015 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 E469C1A896C for ; Thu, 5 Mar 2015 14:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, WEIRD_PORT=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 ImolzzRms43T for ; Thu, 5 Mar 2015 14:17:49 -0800 (PST) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49F851A8946 for ; Thu, 5 Mar 2015 14:17:49 -0800 (PST) Received: by qcvx3 with SMTP id x3so18223446qcv.8 for ; Thu, 05 Mar 2015 14:17:48 -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=o3+C27uziAMbt4OY2pNZrtrE2TwN8nCKL5sya/7Kz1E=; b=X3mheTJ5njqbYFobrCDBxUJsgsggbYcTOl5O5au98FYT/JJ+NlpnenYpj51UJEFX0D QJthhXJVIX+ExbnFCeOrhg+EjMZegsPquLDjv+jvdHiI3vnW5aqjJkJMkdp5A4nCBRDq 6Ly0g0O9DEKRdhlzsrsYfr/Ox/swxKsQjFJpHSVZG1CVO++AB/USvYcZzDY2hL8wLIfd 2iRI6+6TMj8FvRdrtNIWrfMmrGK5iM9NuF9Uar8zsXs0ZgyuMY1UrKt9ygOctEuAHhT6 FvUxke3YzUHj7yiSLWLPqSWpjKU6QscX/qexsOsmO49WwZCpwzflMjsJizTHGw3LkCz6 44hQ== X-Gm-Message-State: ALoCoQnYT0+tLll5VCpLU2aymHo5SYT5EdWG2dsWU7jxOnSNwDeLRAoo2dVCeGHZIAoPNlATl0rU X-Received: by 10.55.42.80 with SMTP id q77mr23572832qkh.18.1425593868524; Thu, 05 Mar 2015 14:17:48 -0800 (PST) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com. [209.85.216.173]) by mx.google.com with ESMTPSA id e76sm3413213qkh.19.2015.03.05.14.17.47 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Mar 2015 14:17:47 -0800 (PST) Received: by qcwb13 with SMTP id b13so8688064qcw.12 for ; Thu, 05 Mar 2015 14:17:47 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.140.91.71 with SMTP id y65mr15010635qgd.90.1425593867522; Thu, 05 Mar 2015 14:17:47 -0800 (PST) Received: by 10.229.90.68 with HTTP; Thu, 5 Mar 2015 14:17:47 -0800 (PST) In-Reply-To: <54F8CD96.7050607@jive.com> References: <20150305201507.6192.13143.idtracker@ietfa.amsl.com> <54F8C2CF.1080201@jive.com> <54F8CD96.7050607@jive.com> Date: Thu, 5 Mar 2015 17:17:47 -0500 Message-ID: From: Benjamin Schwartz To: Simon Perreault Content-Type: multipart/alternative; boundary=001a113a335e1187df051091f0ab Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Fwd: New Version Notification for draft-schwartz-tram-turnbyname-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, 05 Mar 2015 22:17:52 -0000 --001a113a335e1187df051091f0ab Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 5, 2015 at 4:41 PM, Simon Perreault wrote= : > Le 2015-03-05 16:28, Benjamin Schwartz a =C3=A9crit : > >> - What happens when there are multiple A/AAAA records for a name? In >> many places it seems like it is assumed that there will only ever be >> one record. >> >> Implementation-defined. I specifically avoided specifying this so that >> implementers would be free to use gethostbyname() without worrying about >> what it does in this case. >> > > Then the text should say it is implementation-defined. I'm not saying > that's gonna fly, but at least it won't appear like you overlooked the > issue. OK, done. ( https://github.com/bemasc/ietf-drafts/commit/642f7281ed25272b86fd37bbe31043= 2bc9a75f54 ) > > > - The name mapping mechanism is super ugly. It breaks DNS caching. I >> think it would help if you could find a way to get rid of it. >> >> - As soon as the connection to your peer is established, you don't >> care about names anymore. What you care about is the 5-tuple. Yet in >> your proposal the client will keep referring to things by name. This >> seems brittle to me. A more robust design would be to use names in >> the connection initiation phase only, then go back to addresses and >> ports for steady-state. >> > I forgot to mention: When contacting a DNS ICE candidate, this strategy would result in superfluous peer-reflexive candidates, to represent the IP address of the remote peer. If you want to avoid making extra prflx candidates, then you have to keep everything tied to the DNS name. >> >> I sympathize with both of these points, and I'm totally happy to >> entertain alternatives. (In fact, I've written up several alternatives >> along those lines, including one that just introduces a "Resolve >> Request" message that resolves a name to an IP address.) >> >> The motivation for this Name Mapping design is to _avoid_ revealing the >> IP address to the client, and instead to maintain the kind of DNS >> abstraction barrier provided by HTTP CONNECT and SOCKS5 proxies. For a >> simple client, this kind of abstraction does seem convenient. >> > > I agree. The big difference is HTTP CONNECT is TCP-based. The same > abstraction would apply perfectly to TURN-TCP. For UDP it's much more > clumsy. > > Also, if the client operates by IP address, then it's likely that WebRTC >> will leak the IP through to javascript ... potentially creating a DNS >> resolution tool for javascript. There is currently no such mechanism >> built into browsers, so it seems like this should not be done lightly. >> > > Good point. > > If you don't find this convincing, then I'm happy to talk through >> alternatives! >> >> - Why not just use an unmodified TURN server to proxy UDP packets to >> 8.8.8.8:53 , for example, and keep all the >> name-resolving logic client-side? >> >> Telling people to hardcode specific DNS server IP addresses in their >> code, bypassing network-level DNS configurations like DHCP, gives me the >> heebie-jeebies, but I have to admit that this would likely work quite >> well. >> > > Ok, here's a small tweak. Instead of hardcoding a DNS server, rely on TUR= N > server config. You're already doing so implicitly in your proposal. So > reserve a well-known address that will get translated into the actual DNS > server's address by the TURN server, according to its configuration. That > well-known address would be special signalling meaning "whatever's at the > top of the TURN server's /etc/resolv.conf". ;) Who's twisted here? And if that server is unavailable, requiring fallback to the next entry in resolv.conf? Also, I'm pretty sure any strategy like this would require the client to include a complete DNS client implementation. That seems pretty unfortunate, when we have options that don't require the client or server to do that. > > > Simon > --001a113a335e1187df051091f0ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 5, 2015 at 4:41 PM, Simon Perreault <sperreault@jive.com&g= t; wrote:
Le 2015-03-05 16:28, Benjamin Schwartz= a =C3=A9crit :
=C2=A0 =C2=A0 - What happens when there are multiple A/AAAA records for a n= ame? In
=C2=A0 =C2=A0 many places it seems like it is assumed that there will only = ever be
=C2=A0 =C2=A0 one record.

Implementation-defined.=C2=A0 I specifically avoided specifying this so tha= t
implementers would be free to use gethostbyname() without worrying about what it does in this case.

 Then the text should say it is implementation-defined. I'm not saying t= hat's gonna fly, but at least it won't appear like you overlooked t= he issue.

OK, done.
=C2=A0


=C2=A0 =C2=A0 - The name mapping mechanism is super ugly. It breaks DNS cac= hing. I
=C2=A0 =C2=A0 think it would help if you could find a way to get rid of it.=

=C2=A0 =C2=A0 - As soon as the connection to your peer is established, you = don't
=C2=A0 =C2=A0 care about names anymore. What you care about is the 5-tuple.= Yet in
=C2=A0 =C2=A0 your proposal the client will keep referring to things by nam= e. This
=C2=A0 =C2=A0 seems brittle to me. A more robust design would be to use nam= es in
=C2=A0 =C2=A0 the connection initiation phase only, then go back to address= es and
=C2=A0 =C2=A0 ports for steady-state.
<= div>
I forgot to mention: When contacting a DNS ICE candidate= , this strategy would result in superfluous peer-reflexive candidates, to r= epresent the IP address of the remote peer.=C2=A0 If you want to avoid maki= ng extra prflx candidates, then you have to keep everything tied to the DNS= name.



I sympathize with both of these points, and I'm totally happy to
entertain alternatives.=C2=A0 (In fact, I've written up several alterna= tives
along those lines, including one that just introduces a "Resolve
Request" message that resolves a name to an IP address.)

The motivation for this Name Mapping design is to _avoid_ revealing the
IP address to the client, and instead to maintain the kind of DNS
abstraction barrier provided by HTTP CONNECT and SOCKS5 proxies.=C2=A0 For = a
simple client, this kind of abstraction does seem convenient.

 I agree. The big difference is HTTP CONNECT is TCP-based. The same abstract= ion would apply perfectly to TURN-TCP. For UDP it's much more clumsy.


Also, if the client operates by IP address, then it's likely that WebRT= C
will leak the IP through to javascript ... potentially creating a DNS
resolution tool for javascript.=C2=A0 There is currently no such mechanism<= br> built into browsers, so it seems like this should not be done lightly.

 Good point.

If you don't find this convincing, then I'm happy to talk through alternatives!

=C2=A0 =C2=A0 - Why not just use an unmodified TURN server to proxy UDP pac= kets to
 =C2=A0 =C2=A0 8.8.8.8:53 <http://8.8.8.8:53= >, for example, and keep all the
=C2=A0 =C2=A0 name-resolving logic client-side?

Telling people to hardcode specific DNS server IP addresses in their
code, bypassing network-level DNS configurations like DHCP, gives me the heebie-jeebies, but I have to admit that this would likely work quite well.=

Ok, here's a small tweak. Instead of hardcoding a DNS server, rely on T= URN server config. You're already doing so implicitly in your proposal.= So reserve a well-known address that will get translated into the actual D= NS server's address by the TURN server, according to its configuration.= That well-known address would be special signalling meaning "whatever= 's at the top of the TURN server's /etc/resolv.conf". ;)

Who's twisted here?

And if that server is unavailable, requiring fallback to the next entry in= resolv.conf?

Also, I'm pretty sure any strate= gy like this would require the client to include a complete DNS client impl= ementation. That seems pretty unfortunate, when we have options that don= 9;t require the client or server to do that.
=C2=A0


Simon

--001a113a335e1187df051091f0ab-- From nobody Thu Mar 5 14:52:30 2015 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 DF58A1A9074 for ; Thu, 5 Mar 2015 14:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, WEIRD_PORT=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 EkclLTQSuI6X for ; Thu, 5 Mar 2015 14:52:28 -0800 (PST) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32A291A9085 for ; Thu, 5 Mar 2015 14:52:26 -0800 (PST) Received: by qcvx3 with SMTP id x3so46459039qcv.5 for ; Thu, 05 Mar 2015 14:52:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=dyjpsxdyoRa8C5V8cfdzRCmHOyBN/KkXNGSyaoVUQwk=; b=JOW8p1wH3EwcCxwBChVRHmqgppQs9SJTpk72sXPJupFgCGB3ZevarbHYB7b8xVu4J+ 3aQeQo1oZU/3Cf2blui5TUb/Yno78G+s16XTTzgLnSsqWF9h6AKQjbjEy2ua/vxsBVqI pHKEFMlqi5YTEh/n0xpRQsxyvpsKYFvPHbPakGHVJLABPVtZ14ZZWu88ruMIScM7v39i oeQCdK75YwIpdTWXIMipnyvhTy4+JYj0KdZon7JujaKS9IjnM03sSVNraEYY/ecfg8Fk psSDezYSA3I3ZdNXGBqzLH+q6w4iqwa9BUoGNuKNYL1Kzj7zdrWCiQIHDg3LlDRU6B0C lLug== X-Gm-Message-State: ALoCoQkW7SK5Ak9o+2BEogAmwg8oWzM1KWazBPfT4SME4jdebtmk7L0n8FVOV9xccQyxfv/z1B5K X-Received: by 10.55.22.150 with SMTP id 22mr22530205qkw.39.1425595945444; Thu, 05 Mar 2015 14:52:25 -0800 (PST) Received: from [192.168.1.43] (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id z70sm3463473qkg.44.2015.03.05.14.52.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Mar 2015 14:52:24 -0800 (PST) Message-ID: <54F8DE27.3050609@jive.com> Date: Thu, 05 Mar 2015 17:52:23 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Benjamin Schwartz References: <20150305201507.6192.13143.idtracker@ietfa.amsl.com> <54F8C2CF.1080201@jive.com> <54F8CD96.7050607@jive.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Fwd: New Version Notification for draft-schwartz-tram-turnbyname-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, 05 Mar 2015 22:52:30 -0000 Le 2015-03-05 17:17, Benjamin Schwartz a écrit : > - Why not just use an unmodified TURN server to proxy UDP > packets to > 8.8.8.8:53 , for example, > and keep all the > name-resolving logic client-side? > > Telling people to hardcode specific DNS server IP addresses in their > code, bypassing network-level DNS configurations like DHCP, > gives me the > heebie-jeebies, but I have to admit that this would likely work > quite well. > > > Ok, here's a small tweak. Instead of hardcoding a DNS server, rely > on TURN server config. You're already doing so implicitly in your > proposal. So reserve a well-known address that will get translated > into the actual DNS server's address by the TURN server, according > to its configuration. That well-known address would be special > signalling meaning "whatever's at the top of the TURN server's > /etc/resolv.conf". ;) > > > Who's twisted here? :D > And if that server is unavailable, requiring fallback to the next entry > in resolv.conf? Then fallback on the second well-known address which you will have defined for that very purpose. ;) > Also, I'm pretty sure any strategy like this would require the client to > include a complete DNS client implementation. That seems pretty > unfortunate, when we have options that don't require the client or > server to do that. True. A DNS client implementation is of course already present underneath getaddrinfo(). If there's no lower-layer API that grants you access to it, and you can't just create one, you can fake it by positioning yourself as a generic UDP proxy. Just bind a UDP port on the loopback interface and use the lower-layer DNS functions already available to you (e.g., with glibc) to send DNS requests to yourself, then proxy that over TURN to the TURN server's DNS resolver using the well-known address as destination. :) Simon From nobody Thu Mar 5 15:43:38 2015 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 E41BC1A9094 for ; Thu, 5 Mar 2015 15:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.386 X-Spam-Level: X-Spam-Status: No, score=-1.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=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 KIuOvszs7IPQ for ; Thu, 5 Mar 2015 15:43:34 -0800 (PST) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CACAE1A9073 for ; Thu, 5 Mar 2015 15:43:33 -0800 (PST) Received: by iecat20 with SMTP id at20so27836212iec.6 for ; Thu, 05 Mar 2015 15:43:33 -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=TMcn7NfHU82X6YZJMprm9kc1PqHIVxnDqEeTwwpJsiI=; b=hn2Vf2PvG5K8gop5ZW1jYpamDwMsagSjGidSdodBp4XPJwE90Oo05O1VMtWmKa0Tus oe5xOwMbKndve5s9pHMs+PlEW1S1HNoVIk2QU5M56vSbkrEcC4+B9o0SHrc0lD5YSHov ZAboFXyai4owheL9XVrlh5U37JMeg0SDscaOA1dZeDdlNMNQz94giVarkuPGhP4Gfmq2 d5P9grHOjfjfkYgNnrgHAjcjb+rTzHhuJPgON5UqA4oXH02q5LF15uSwkp+V1h5lpGFb CgGbZUinHOHE7vjVw8HbP7jlJCzllAhv7BbID6B6kykmZu59W2QGd1hUvGXktARKyKGN 0Asw== 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=TMcn7NfHU82X6YZJMprm9kc1PqHIVxnDqEeTwwpJsiI=; b=R1w7AxjM34dPtrra3l7HcyHprzjCPIKR01gyDRJm6uY10KmKFAc+uZHjNOKx+CF4+v lAYkDpXbBccT1E2VBcl1s3wmJ84LvQ9bDQpQ+oSHI0HWTW5D2QTMlMewxbAdfmCXq8Ha dLfngsJOQc3VvguWB9ydf+H00Pu8IvlFkckbj2u4vJ1rKzxdI+A/KiJTj/AQTEWc2lbL bd8k3Ffm/q40LGUEhSRFHQcCMKkjU5U0UNpbZrJrePURnVQBk4ITAmEVj6dKOyzP2guf ULpV53eWjudGl7yCokgTRuAFs0jEkjlr3jtLpCSsayCLJxBulRBIJouhXCjBJeU1Y5WJ htqA== X-Gm-Message-State: ALoCoQm/UDF9KH3V+13oOBceF2UbP7s5gg8klNUEuLRlonjiHNrofsfIfq5mToO17EHt2404zWFs X-Received: by 10.42.229.132 with SMTP id ji4mr6977854icb.23.1425599013169; Thu, 05 Mar 2015 15:43:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.64.66 with HTTP; Thu, 5 Mar 2015 15:43:13 -0800 (PST) In-Reply-To: <54F8CD96.7050607@jive.com> References: <20150305201507.6192.13143.idtracker@ietfa.amsl.com> <54F8C2CF.1080201@jive.com> <54F8CD96.7050607@jive.com> From: Justin Uberti Date: Thu, 5 Mar 2015 15:43:13 -0800 Message-ID: To: Simon Perreault Content-Type: multipart/alternative; boundary=001a11c3b052c5c8ba0510932220 Archived-At: Cc: Benjamin Schwartz , "tram@ietf.org" Subject: Re: [tram] Fwd: New Version Notification for draft-schwartz-tram-turnbyname-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, 05 Mar 2015 23:43:36 -0000 --001a11c3b052c5c8ba0510932220 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 5, 2015 at 1:41 PM, Simon Perreault wrote= : > Le 2015-03-05 16:28, Benjamin Schwartz a =C3=A9crit : > >> - What happens when there are multiple A/AAAA records for a name? In >> many places it seems like it is assumed that there will only ever be >> one record. >> >> Implementation-defined. I specifically avoided specifying this so that >> implementers would be free to use gethostbyname() without worrying about >> what it does in this case. >> > > Then the text should say it is implementation-defined. I'm not saying > that's gonna fly, but at least it won't appear like you overlooked the > issue. > > - The name mapping mechanism is super ugly. It breaks DNS caching. I >> think it would help if you could find a way to get rid of it. >> >> - As soon as the connection to your peer is established, you don't >> care about names anymore. What you care about is the 5-tuple. Yet in >> your proposal the client will keep referring to things by name. This >> seems brittle to me. A more robust design would be to use names in >> the connection initiation phase only, then go back to addresses and >> ports for steady-state. >> >> >> I sympathize with both of these points, and I'm totally happy to >> entertain alternatives. (In fact, I've written up several alternatives >> along those lines, including one that just introduces a "Resolve >> Request" message that resolves a name to an IP address.) >> >> The motivation for this Name Mapping design is to _avoid_ revealing the >> IP address to the client, and instead to maintain the kind of DNS >> abstraction barrier provided by HTTP CONNECT and SOCKS5 proxies. For a >> simple client, this kind of abstraction does seem convenient. >> > > I agree. The big difference is HTTP CONNECT is TCP-based. The same > abstraction would apply perfectly to TURN-TCP. For UDP it's much more > clumsy. This distinction seems artificial to me. If I want to establish a channel to foo.com, why does it matter if it's over UDP or TCP? The ability for the client to behave identically regardless of whether the remote destination is an IP or hostname is a nice simplification of the client, and very much in the spirit of the proxy doing work on behalf of the client. > > Also, if the client operates by IP address, then it's likely that WebRTC >> will leak the IP through to javascript ... potentially creating a DNS >> resolution tool for javascript. There is currently no such mechanism >> built into browsers, so it seems like this should not be done lightly. >> > > Good point. > > If you don't find this convincing, then I'm happy to talk through >> alternatives! >> >> - Why not just use an unmodified TURN server to proxy UDP packets to >> 8.8.8.8:53 , for example, and keep all the >> name-resolving logic client-side? >> >> Telling people to hardcode specific DNS server IP addresses in their >> code, bypassing network-level DNS configurations like DHCP, gives me the >> heebie-jeebies, but I have to admit that this would likely work quite >> well. >> > > Ok, here's a small tweak. Instead of hardcoding a DNS server, rely on TUR= N > server config. You're already doing so implicitly in your proposal. So > reserve a well-known address that will get translated into the actual DNS > server's address by the TURN server, according to its configuration. That > well-known address would be special signalling meaning "whatever's at the > top of the TURN server's /etc/resolv.conf". ;) > > > Simon > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --001a11c3b052c5c8ba0510932220 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 5, 2015 at 1:41 PM, Simon Perreault <<= a href=3D"mailto:sperreault@jive.com" target=3D"_blank">sperreault@jive.com= > wrote:
Le 2015-03-05 16:2= 8, Benjamin Schwartz a =C3=A9crit :
=C2=A0 =C2=A0 - What happens when there are multiple A/AAAA records for a n= ame? In
=C2=A0 =C2=A0 many places it seems like it is assumed that there will only = ever be
=C2=A0 =C2=A0 one record.

Implementation-defined.=C2=A0 I specifically avoided specifying this so tha= t
implementers would be free to use gethostbyname() without worrying about what it does in this case.

 Then the text should say it is implementation-defined. I'm not saying t= hat's gonna fly, but at least it won't appear like you overlooked t= he issue.

=C2=A0 =C2=A0 - The name mapping mechanism is super ugly. It breaks DNS cac= hing. I
=C2=A0 =C2=A0 think it would help if you could find a way to get rid of it.=

=C2=A0 =C2=A0 - As soon as the connection to your peer is established, you = don't
=C2=A0 =C2=A0 care about names anymore. What you care about is the 5-tuple.= Yet in
=C2=A0 =C2=A0 your proposal the client will keep referring to things by nam= e. This
=C2=A0 =C2=A0 seems brittle to me. A more robust design would be to use nam= es in
=C2=A0 =C2=A0 the connection initiation phase only, then go back to address= es and
=C2=A0 =C2=A0 ports for steady-state.


I sympathize with both of these points, and I'm totally happy to
entertain alternatives.=C2=A0 (In fact, I've written up several alterna= tives
along those lines, including one that just introduces a "Resolve
Request" message that resolves a name to an IP address.)

The motivation for this Name Mapping design is to _avoid_ revealing the
IP address to the client, and instead to maintain the kind of DNS
abstraction barrier provided by HTTP CONNECT and SOCKS5 proxies.=C2=A0 For = a
simple client, this kind of abstraction does seem convenient.

 I agree. The big difference is HTTP CONNECT is TCP-based. The same abstract= ion would apply perfectly to TURN-TCP. For UDP it's much more clumsy.

This distinction seems artificial to me. If = I want to establish a channel to foo.com, why does it matter if it's over UDP or TCP?
<= br>
The ability for the client to behave identically regardless o= f whether the remote destination is an IP or hostname is a nice simplificat= ion of the client, and very much in the spirit of the proxy doing work on b= ehalf of the client.



Also, if the client operates by IP address, then it's likely that WebRT= C
will leak the IP through to javascript ... potentially creating a DNS
resolution tool for javascript.=C2=A0 There is currently no such mechanism<= br> built into browsers, so it seems like this should not be done lightly.

Good point.

If you don't find this convincing, then I'm happy to talk through alternatives!

=C2=A0 =C2=A0 - Why not just use an unmodified TURN server to proxy UDP pac= kets to
 =C2=A0 =C2=A0 8.8.8.8:53 <http://8.8.8.8:53= >, for example, and keep all the
=C2=A0 =C2=A0 name-resolving logic client-side?

Telling people to hardcode specific DNS server IP addresses in their
code, bypassing network-level DNS configurations like DHCP, gives me the heebie-jeebies, but I have to admit that this would likely work quite well.=

Ok, here's a small tweak. Instead of hardcoding a DNS server, rely on T= URN server config. You're already doing so implicitly in your proposal.= So reserve a well-known address that will get translated into the actual D= NS server's address by the TURN server, according to its configuration.= That well-known address would be special signalling meaning "whatever= 's at the top of the TURN server's /etc/resolv.conf". ;)
<= div>

Simon

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

--001a11c3b052c5c8ba0510932220-- From nobody Fri Mar 6 02:46:42 2015 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 2ADA71A03E3; Fri, 6 Mar 2015 02:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Jd7cI5dr_F8; Fri, 6 Mar 2015 02:46:39 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 980FF1A00F5; Fri, 6 Mar 2015 02:46:32 -0800 (PST) X-AuditID: c1b4fb25-f79b76d00000113a-b9-54f9858646b3 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 64.09.04410.68589F45; Fri, 6 Mar 2015 11:46:30 +0100 (CET) Received: from [131.160.126.7] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.210.2; Fri, 6 Mar 2015 11:46:30 +0100 Message-ID: <54F98585.7070203@ericsson.com> Date: Fri, 6 Mar 2015 12:46:29 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , "tram-chairs@ietf.org" , "tram@ietf.org" , "draft-ietf-tram-turn-third-party-authz@ietf.org" , "draft-ietf-tram-turn-third-party-authz.ad@ietf.org" , "draft-ietf-tram-turn-third-party-authz.shepherd@ietf.org" , "spencerdawkins.ietf@gmail.com" , "rlb@ipv.sx" , "stephen.farrell@cs.tcd.ie" References: <913383AAA69FF945B8F946018B75898A366AA244@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A366AA244@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+JvjW5b688Qgz0TzCwez+lnt9i19QOT RfulJywWU/tsLZZN2cNsMX3vNXaLE7u3MVos/7mSzeLD2gtsDpweU35vZPVY232VzWPnrLvs HkuW/GTymLxxFksAaxSXTUpqTmZZapG+XQJXxuMXT5kLFvFWnJxwiKWBcQ13FyMnh4SAicSi xm2sELaYxIV769m6GLk4hASOMEosb5jFBpIQEljFKPHyRwaIzSugLfH29UsmEJtFQEXi1csP 7CA2m4CFxJZb91lAbFGBKInZ5x+wQtQLSpyc+YQFZKiIwBcWiacTtzGCJIQFQiVefDzFCrHA R2LGwllgNqeAr8TRX01ACzg4mAU0Jdbv0gcJMwvIS2x/O4cZolxbYvmzFpYJjAKzkKyYhdAx C0nHAkbmVYyixanFSbnpRsZ6qUWZycXF+Xl6eaklmxiBYX9wy2/VHYyX3zgeYhTgYFTi4TWQ +BkixJpYVlyZe4hRmoNFSZzXzvhQiJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGYJkVH8K3 brK57zxlzsvn88O5C3tMl+TUfL49e82PndGiicb+S2X/T4p1ZHIQ5ltczLhk2/29jIs/hisd 3vSFub1JPYhb5fWjPfNWl0y/aMjhHBu36l13U6twsm2szu+TnA/OTzTz6d924vd1rV8CTs0B oTwcXrG7tzPphW24eJTxV8TfyEPKSizFGYmGWsxFxYkAvok7ylwCAAA= Archived-At: Subject: Re: [tram] New Version Notification - draft-ietf-tram-turn-third-party-authz-13.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, 06 Mar 2015 10:46:41 -0000 Stephen, Richard, you have discusses on this draft: https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ballot/ Could you please look at the new revision Tiru has put together and let him know if you are happy with it? Thanks, Gonzalo On 28/02/2015 5:10 AM, Tirumaleswar Reddy (tireddy) wrote: > We have responded to comments from ISEG and published updated draft. > > -Tiru > >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Thursday, February 26, 2015 10:26 AM >> To: tram-chairs@ietf.org; tram@ietf.org; draft-ietf-tram-turn-third-party- >> authz@ietf.org; gonzalo.camarillo@ericsson.com; draft-ietf-tram-turn-third- >> party-authz.ad@ietf.org; draft-ietf-tram-turn-third-party- >> authz.shepherd@ietf.org; spencerdawkins.ietf@gmail.com; rlb@ipv.sx; >> stephen.farrell@cs.tcd.ie >> Subject: New Version Notification - draft-ietf-tram-turn-third-party-authz- >> 13.txt >> >> >> A new version (-13) has been submitted for draft-ietf-tram-turn-third-party- >> authz: >> http://www.ietf.org/internet-drafts/draft-ietf-tram-turn-third-party-authz- >> 13.txt >> >> Sub state has been changed to AD Followup from Revised ID Needed >> >> >> The IETF datatracker page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ >> >> Diff from previous version: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-third-party-authz-13 >> >> 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. >> >> IETF Secretariat. > From nobody Fri Mar 6 07:46:50 2015 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 686BA1A0015; Fri, 6 Mar 2015 07:46:48 -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 voe7MmTmCx73; Fri, 6 Mar 2015 07:46:46 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F9B11A000F; Fri, 6 Mar 2015 07:46:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D818CBEAF; Fri, 6 Mar 2015 15:46:38 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbZlQ0P52xiP; Fri, 6 Mar 2015 15:46:38 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A5857BEAA; Fri, 6 Mar 2015 15:46:38 +0000 (GMT) Message-ID: <54F9CBDF.7010705@cs.tcd.ie> Date: Fri, 06 Mar 2015 15:46:39 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Gonzalo Camarillo , "Tirumaleswar Reddy (tireddy)" , "tram-chairs@ietf.org" , "tram@ietf.org" , "draft-ietf-tram-turn-third-party-authz@ietf.org" , "draft-ietf-tram-turn-third-party-authz.ad@ietf.org" , "draft-ietf-tram-turn-third-party-authz.shepherd@ietf.org" , "spencerdawkins.ietf@gmail.com" , "rlb@ipv.sx" References: <913383AAA69FF945B8F946018B75898A366AA244@xmb-rcd-x10.cisco.com> <54F98585.7070203@ericsson.com> In-Reply-To: <54F98585.7070203@ericsson.com> Content-Type: multipart/mixed; boundary="------------070805030904040105060907" Archived-At: Subject: Re: [tram] New Version Notification - draft-ietf-tram-turn-third-party-authz-13.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, 06 Mar 2015 15:46:48 -0000 This is a multi-part message in MIME format. --------------070805030904040105060907 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hey, #1 - nope, that version doesn't address things that I can see (and I've not seen a direct response to my discuss points that I recall) #2 - I sent an ask to the saag list just now, (attached) will let you know if I get offers. Please also ping me if you get any direct, just so's we don't cross streams. S. On 06/03/15 10:46, Gonzalo Camarillo wrote: > Stephen, Richard, > > you have discusses on this draft: > > https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ballot/ > > Could you please look at the new revision Tiru has put together and let > him know if you are happy with it? > > Thanks, > > Gonzalo > > On 28/02/2015 5:10 AM, Tirumaleswar Reddy (tireddy) wrote: >> We have responded to comments from ISEG and published updated draft. >> >> -Tiru >> >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Thursday, February 26, 2015 10:26 AM >>> To: tram-chairs@ietf.org; tram@ietf.org; draft-ietf-tram-turn-third-party- >>> authz@ietf.org; gonzalo.camarillo@ericsson.com; draft-ietf-tram-turn-third- >>> party-authz.ad@ietf.org; draft-ietf-tram-turn-third-party- >>> authz.shepherd@ietf.org; spencerdawkins.ietf@gmail.com; rlb@ipv.sx; >>> stephen.farrell@cs.tcd.ie >>> Subject: New Version Notification - draft-ietf-tram-turn-third-party-authz- >>> 13.txt >>> >>> >>> A new version (-13) has been submitted for draft-ietf-tram-turn-third-party- >>> authz: >>> http://www.ietf.org/internet-drafts/draft-ietf-tram-turn-third-party-authz- >>> 13.txt >>> >>> Sub state has been changed to AD Followup from Revised ID Needed >>> >>> >>> The IETF datatracker page for this Internet-Draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ >>> >>> Diff from previous version: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-third-party-authz-13 >>> >>> 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. >>> >>> IETF Secretariat. >> > --------------070805030904040105060907 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message" X-Mozilla-Keys: Return-Path: X-Original-To: stephen.farrell@cs.tcd.ie Delivered-To: stephen.farrell@cs.tcd.ie Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4ADBDBEAF for ; Fri, 6 Mar 2015 15:44:18 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9H3iUIwAnyB for ; Fri, 6 Mar 2015 15:44:16 +0000 (GMT) Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) by mercury.scss.tcd.ie (Postfix) with ESMTPS id 623E7BEAA for ; Fri, 6 Mar 2015 15:44:16 +0000 (GMT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 214581ACEBD; Fri, 6 Mar 2015 07:44:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1425656646; bh=NRUKsfK40H6f1iwc29ipBLo4yUwSYDAkcM730R3mxq8=; h=Message-ID:Date:From:MIME-Version:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=JvcgbCrDckonC7H+4gm/OcLp/4LOMQx6gge4Fg/kMfWrFdJeIBPXiDx7Jy/pPu6xN w8yGQdCoC0m7y6USa3eGJj5Zj/px7u66mXDCppsQB48VCrtPzjhHj71dqnA60FwEvz h/7BVAlpXUkxcDQ3j7yhXf1ExkUSF+ElrgLP8KdI= X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894581ACEBA for ; Fri, 6 Mar 2015 07:44:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 zICohkzLYCRG for ; Fri, 6 Mar 2015 07:43:58 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BECD1ACEAF for ; Fri, 6 Mar 2015 07:43:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 54588BEB3 for ; Fri, 6 Mar 2015 15:43:56 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYeN3jxlQ-l2 for ; Fri, 6 Mar 2015 15:43:56 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2F2FBBEAF for ; Fri, 6 Mar 2015 15:43:56 +0000 (GMT) Message-ID: <54F9CB3D.4000200@cs.tcd.ie> Date: Fri, 06 Mar 2015 15:43:57 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "saag@ietf.org" Archived-At: Subject: [saag] tram draft - anyone willing to help out? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: saag-bounces@ietf.org Sender: "saag" Hiya, There's a draft in IESG eval that attracted a bunch of perhaps fundamental discusses and comments [1] about its security properties. I think this may be one where the authors could do with a bit more help from the security mafia^H^H^H^H^Hcommunity. (I looked at their wg list and only see a v. thin smattering of names I'd recognise from this list.) So if you're willing and have a little time, please let me know and/or get in touch with the authors. And btw - this might not seem so important but I'd worry it may end up being a major source of system level vulnerabilities for WebRTC deployments if we get it wrong and many sites don't deploy usefully good security for this bit of the WebRTC story. Thanks in advance, S. [1] https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ballot/ _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --------------070805030904040105060907-- From nobody Fri Mar 6 08:18:16 2015 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 0FB3C1ACEEF; Fri, 6 Mar 2015 08:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tx53FWJaR7In; Fri, 6 Mar 2015 08:18:12 -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 301DF1ACED9; Fri, 6 Mar 2015 08:14:44 -0800 (PST) X-AuditID: c1b4fb2d-f79aa6d00000359d-fe-54f9d2728452 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id D4.42.13725.272D9F45; Fri, 6 Mar 2015 17:14:42 +0100 (CET) Received: from [131.160.126.7] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.210.2; Fri, 6 Mar 2015 17:14:41 +0100 Message-ID: <54F9D271.7020803@ericsson.com> Date: Fri, 6 Mar 2015 18:14:41 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Stephen Farrell , "Tirumaleswar Reddy (tireddy)" , "tram-chairs@ietf.org" , "tram@ietf.org" , "draft-ietf-tram-turn-third-party-authz@ietf.org" , "draft-ietf-tram-turn-third-party-authz.ad@ietf.org" , "draft-ietf-tram-turn-third-party-authz.shepherd@ietf.org" , "spencerdawkins.ietf@gmail.com" , "rlb@ipv.sx" References: <913383AAA69FF945B8F946018B75898A366AA244@xmb-rcd-x10.cisco.com> <54F98585.7070203@ericsson.com> <54F9CBDF.7010705@cs.tcd.ie> In-Reply-To: <54F9CBDF.7010705@cs.tcd.ie> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+JvjW7RpZ8hBkt/8Vk8ntPPbrFr6wcm i/ZLT1gspvbZWiybsofZYvrea+wWJ3ZvY7RY/nMlm8WHtRfYHDg9pvzeyOqxtvsqm8fOWXfZ PZYs+cnkMXnjLJYA1igum5TUnMyy1CJ9uwSujO+TZAo+CVUc/5nYwPiAv4uRk0NCwERi58+r zBC2mMSFe+vZuhi5OIQEjjBKXGn9wAThrGKU2Nf3B6iKg4NXQFvi3FdpkAYWARWJjp0HwJrZ BCwktty6zwJiiwpEScw+/4AVxOYVEJQ4OfMJC8gcEYFXLBILtk0FSwgLhEq8+HiKFWJBJ6PE 5HX9jCAJTgFNibfPv7ODLGMGstfv0gcJMwvIS2x/OwdsmRDQDcuftbBMYBSYhWTHLISOWUg6 FjAyr2IULU4tLs5NNzLWSy3KTC4uzs/Ty0st2cQIDPqDW37r7mBc/drxEKMAB6MSD6+BxM8Q IdbEsuLK3EOM0hwsSuK8dsaHQoQE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwJnTHTV3Y9/e4 4PWppZNNxMw1zjaEbLo0v4rvta6b+alFUm1x5bwT2L8r8R4K05tm8tXEdu20hYeO20Sa35mV dOAy78RKzkOiH0JW5qovu3hq0/2b89vW7DOO+e2/xiTv+PqCXTaKe9LuHFkn9Wj7s2qLl0dz 5NfOEFV/3Zx9l/FUw1abh6cufFFiKc5INNRiLipOBAC8j6NzWwIAAA== Archived-At: Subject: Re: [tram] New Version Notification - draft-ietf-tram-turn-third-party-authz-13.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, 06 Mar 2015 16:18:15 -0000 Hey Stephen, thanks for the status update. Sure, let's keep in sync regarding the request to get a dedicated reviewer for this draft. Cheers, Gonzalo On 06/03/2015 5:46 PM, Stephen Farrell wrote: > > Hey, > > #1 - nope, that version doesn't address things that I can see > (and I've not seen a direct response to my discuss points that > I recall) > > #2 - I sent an ask to the saag list just now, (attached) will > let you know if I get offers. Please also ping me if you get > any direct, just so's we don't cross streams. > > S. > > On 06/03/15 10:46, Gonzalo Camarillo wrote: >> Stephen, Richard, >> >> you have discusses on this draft: >> >> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ballot/ >> >> Could you please look at the new revision Tiru has put together and let >> him know if you are happy with it? >> >> Thanks, >> >> Gonzalo >> >> On 28/02/2015 5:10 AM, Tirumaleswar Reddy (tireddy) wrote: >>> We have responded to comments from ISEG and published updated draft. >>> >>> -Tiru >>> >>>> -----Original Message----- >>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>> Sent: Thursday, February 26, 2015 10:26 AM >>>> To: tram-chairs@ietf.org; tram@ietf.org; draft-ietf-tram-turn-third-party- >>>> authz@ietf.org; gonzalo.camarillo@ericsson.com; draft-ietf-tram-turn-third- >>>> party-authz.ad@ietf.org; draft-ietf-tram-turn-third-party- >>>> authz.shepherd@ietf.org; spencerdawkins.ietf@gmail.com; rlb@ipv.sx; >>>> stephen.farrell@cs.tcd.ie >>>> Subject: New Version Notification - draft-ietf-tram-turn-third-party-authz- >>>> 13.txt >>>> >>>> >>>> A new version (-13) has been submitted for draft-ietf-tram-turn-third-party- >>>> authz: >>>> http://www.ietf.org/internet-drafts/draft-ietf-tram-turn-third-party-authz- >>>> 13.txt >>>> >>>> Sub state has been changed to AD Followup from Revised ID Needed >>>> >>>> >>>> The IETF datatracker page for this Internet-Draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ >>>> >>>> Diff from previous version: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-third-party-authz-13 >>>> >>>> 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. >>>> >>>> IETF Secretariat. >>> >> From nobody Fri Mar 6 11:51:21 2015 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 0C74C1A1EE8 for ; Fri, 6 Mar 2015 11:51:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.797 X-Spam-Level: X-Spam-Status: No, score=-0.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, 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 YA3cV1Gi7w7o for ; Fri, 6 Mar 2015 11:51:19 -0800 (PST) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) by ietfa.amsl.com (Postfix) with ESMTP id B2BDA1A6F2D for ; Fri, 6 Mar 2015 11:51:19 -0800 (PST) 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 t26Jp74x009745; Fri, 6 Mar 2015 14:51:19 -0500 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 1suy5j2usg-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 06 Mar 2015 14:51:19 -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; Fri, 6 Mar 2015 13:51:18 -0600 From: Jonathan Lennox To: Benjamin Schwartz Thread-Topic: [tram] Fwd: New Version Notification for draft-schwartz-tram-turnbyname-00.txt Thread-Index: AQHQWESSHeB0toOSDEm6/7dboiIEfJ0QQeEA Date: Fri, 6 Mar 2015 19:51:17 +0000 Message-ID: <35F68F75-51A0-48BD-B5D0-DE0A6600F13D@vidyo.com> References: <20150305201507.6192.13143.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [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=2015-03-06_06:2015-03-06,2015-03-06,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-1503060220 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Fwd: New Version Notification for draft-schwartz-tram-turnbyname-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, 06 Mar 2015 19:51:21 -0000 On Mar 5, 2015, at 3:17 PM, Benjamin Schwartz wrote: > Hi TRAM, >=20 > I've just written up a proposal for an optional extension to TURN that wo= uld add support for DNS names. I'd like to discuss this at the upcoming me= eting. >=20 > Let me know what you think! What happens if DNS resolution is slow? As far as I can tell the TURN serv= er can=92t respond to the ChannelBind or CreatePermission request until DNS= completes (or fails), and I vaguely think (though I don=92t remember exact= numbers) that STUN transactions will time out faster than DNS ones will. The draft should also discuss its operation with TURN-TCP. As far as I can= tell it=92s straightforward, and easier than TURN-UDP, but it=92s worth di= scussing it.= From nobody Fri Mar 6 12:53:13 2015 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 CED8A1A86E2 for ; Fri, 6 Mar 2015 12:53:12 -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 AW5JRAWkHXvv for ; Fri, 6 Mar 2015 12:53:11 -0800 (PST) Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B84C21A86E0 for ; Fri, 6 Mar 2015 12:53:10 -0800 (PST) Received: by qgdq107 with SMTP id q107so15677590qgd.6 for ; Fri, 06 Mar 2015 12:53:10 -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=T+z3RcM25vfQfsD3qJTAtgiHGutrPpVwqcoC/bpj+oQ=; b=Qa6wffm+6yAv0Y5XFeWDGCU3YbrOn3ivPvMwJFhC0ETRQbBcUyah2O+D20xQcHJTFc SwE7+mxM8EPzWpkDLrIvE1tCxPXZvO1ydt8skVxSJHJtu8zt+FTrYdtpZx/0+iFrpZoN VEUNAMvb6xjbDgQBk50Gkj8I5gFOySWjlam1Un0jaNZMUCSY8K4XCy87dOYDrBsALkF1 9TAR0/e1yI8XA0fM5xQ9xy9Yar+mLkAse4mzTEauE+uLrt4ey1QYwRZ9t171wfMlSmdB HqT7apiob7BzX64GjgkLREPjA/DUFPVKddcIhNhdGY3GVcINvzyx9YOTP13zeBoBGHvr mX8Q== X-Gm-Message-State: ALoCoQkn/jZkZYvnNu+KmgHBteYQYlRXEqfBZhAq53zdqJISQjgCSUdOX2y1PhZKXzEzqgfNTrxU X-Received: by 10.140.32.52 with SMTP id g49mr21134324qgg.83.1425675189915; Fri, 06 Mar 2015 12:53:09 -0800 (PST) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com. [209.85.192.45]) by mx.google.com with ESMTPSA id d20sm6486679qhc.41.2015.03.06.12.53.08 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Mar 2015 12:53:09 -0800 (PST) Received: by qgfh3 with SMTP id h3so15680016qgf.2 for ; Fri, 06 Mar 2015 12:53:08 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.55.54.71 with SMTP id d68mr33162048qka.42.1425675188578; Fri, 06 Mar 2015 12:53:08 -0800 (PST) Received: by 10.229.90.68 with HTTP; Fri, 6 Mar 2015 12:53:08 -0800 (PST) In-Reply-To: <35F68F75-51A0-48BD-B5D0-DE0A6600F13D@vidyo.com> References: <20150305201507.6192.13143.idtracker@ietfa.amsl.com> <35F68F75-51A0-48BD-B5D0-DE0A6600F13D@vidyo.com> Date: Fri, 6 Mar 2015 15:53:08 -0500 Message-ID: From: Benjamin Schwartz To: Jonathan Lennox Content-Type: multipart/alternative; boundary=001a11470f422e49450510a4df4a Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Fwd: New Version Notification for draft-schwartz-tram-turnbyname-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, 06 Mar 2015 20:53:13 -0000 --001a11470f422e49450510a4df4a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 6, 2015 at 2:51 PM, Jonathan Lennox wrote: > > > On Mar 5, 2015, at 3:17 PM, Benjamin Schwartz wrote: > > > Hi TRAM, > > > > I've just written up a proposal for an optional extension to TURN that > would add support for DNS names. I'd like to discuss this at the upcomin= g > meeting. > > > > Let me know what you think! > > What happens if DNS resolution is slow? As far as I can tell the TURN > server can=E2=80=99t respond to the ChannelBind or CreatePermission reque= st until > DNS completes (or fails), and I vaguely think (though I don=E2=80=99t rem= ember > exact numbers) that STUN transactions will time out faster than DNS ones > will. > You're right; if the client sends a DNS-name CreatePermission or ChannelBind, the server can't send a success reply until DNS completes successfully. However, I don't share your intuition. I'm not familiar with DNS timeouts, but for example, this page [ http://support.microsoft.com/kb/2834226] claims that Microsoft's DNS resolution times out after 10 seconds. I'm not aware of any official, standardized STUN timeout that applies before the first packet has been received, but in practice implementations seem to allow for at least 30 seconds of delay after signaling is complete. > The draft should also discuss its operation with TURN-TCP. As far as I > can tell it=E2=80=99s straightforward, and easier than TURN-UDP, but it= =E2=80=99s worth > discussing it. I agree that the extension to TURN-TCP is straightforward, but I'd like to see if we have rough consensus on this approach for UDP first. --001a11470f422e49450510a4df4a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Mar 6, 2015 at 2:51 PM, Jonathan Lennox <jonathan@vidyo.com>= wrote:


On Mar 5, 2015, at 3:17 PM, Benjamin Schwartz <bemasc@webrtc.org> wrote:

> Hi TRAM,
>
> I've just written up a proposal for an optional extension to TURN = that would add support for DNS names.=C2=A0 I'd like to discuss this at= the upcoming meeting.
>
> Let me know what you think!

What happens if DNS resolution is slow?=C2=A0 As far as I can tell t= he TURN server can=E2=80=99t respond to the ChannelBind or CreatePermission= request until DNS completes (or fails), and I vaguely think (though I don= =E2=80=99t remember exact numbers) that STUN transactions will time out fas= ter than DNS ones will.

You're right; if= the client sends a DNS-name CreatePermission or ChannelBind, the server ca= n't send a success reply until DNS completes successfully.=C2=A0 Howeve= r, I don't share your intuition.=C2=A0 I'm not familiar with DNS ti= meouts, but for example, this page [http://support.microsoft.com/kb/2834226] claims that Micro= soft's DNS resolution times out after 10 seconds.=C2=A0 I'm not awa= re of any official, standardized STUN timeout that applies before the first= packet has been received, but in practice implementations seem to allow fo= r at least 30 seconds of delay after signaling is complete.
=C2=A0
The draft should also discuss its operation with TURN-TCP.=C2=A0 As far as = I can tell it=E2=80=99s straightforward, and easier than TURN-UDP, but it= =E2=80=99s worth discussing it.

I agree tha= t the extension to TURN-TCP is straightforward, but I'd like to see if = we have rough consensus on this approach for UDP first.
--001a11470f422e49450510a4df4a-- From nobody Fri Mar 6 14:08:37 2015 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 A60AD1A1BCD for ; Fri, 6 Mar 2015 14:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 SLh5Xl3hnvFW for ; Fri, 6 Mar 2015 14:08:34 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 964901A6F1E for ; Fri, 6 Mar 2015 14:08:34 -0800 (PST) Received: by igal13 with SMTP id l13so7605509iga.0 for ; Fri, 06 Mar 2015 14:08:34 -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=kOquuyR0tsMWMszYrqg3fGdVPWSWkXxmwuL6DL51qoo=; b=ke1LjeF37wshKkEYTaGy6rAdZydMwfPotiNXxa7RE0oTDGEEP9eFNrvjYF6JKwvVNB etUQfGz0ntqrieLC27BwF6tFEHe7sdxhTT7PaFwGWtqG2WJN0gv1BayW9q0cAhDHE8j+ 1TTXoFumoPIldbVL7w5FaWzPJ3ZgRw61OfGHUeRo4ZCnqTfrhurPJvlTjeIkaAAkTCwl c2NXGozAeppFKgvH3ld2cL7VTtnGRL2YrZhhI9ERgBwz7e4wFU7IwFIg3U0Z8KLNYAS8 UAFKBgnkYS7rTiz4rusDALfXTY+BXkcGdknZtFviZKOL/PFuIsqP591VWFXCPCUKf/eI l+YQ== 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=kOquuyR0tsMWMszYrqg3fGdVPWSWkXxmwuL6DL51qoo=; b=fpQbl93bpU3IAsf/JrVlUZ0xAZih2V8H45pe7mRcBCGCyxnbW3nkrAxorLO704ixao 9IGfLeODefNRK3v7Bt8r1XCwVsgqtzq6osuuNVhSzkpusJCn2vcf5BoY+6KuZxj+RCXv 9mcCSm8p0cE3bxc0djxZR5tvfxDeTvLl/jAng+C3T51mTu+k7sduZeTkP+Bcs/Rdg8jX WfcxXNtZ/vXQQ8XRfIogS2MuU4k0/+7JVRlqni+Qp2+cqJ9Kz2NnBw3mZB6Tg1UyV4jT jKE2Gu+k/ZSeZL88M/wk0UEnCJ8N0ON/bBL+N78FpLHacIgcaxvdpDzrBQfNINSczJJ5 n0Mw== X-Gm-Message-State: ALoCoQl/GN6PvlrQdb4sr96qX8WHuoBL6JZpWnWipyvHAaQewOnPmoXc1b8NJ+OYCkT25jV5lgKQ X-Received: by 10.50.137.99 with SMTP id qh3mr53578379igb.9.1425679713802; Fri, 06 Mar 2015 14:08:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.64.42 with HTTP; Fri, 6 Mar 2015 14:08:13 -0800 (PST) In-Reply-To: References: <20150305201507.6192.13143.idtracker@ietfa.amsl.com> <35F68F75-51A0-48BD-B5D0-DE0A6600F13D@vidyo.com> From: Justin Uberti Date: Fri, 6 Mar 2015 14:08:13 -0800 Message-ID: To: Benjamin Schwartz Content-Type: multipart/alternative; boundary=001a11c3bcbce7c64d0510a5ec3b Archived-At: Cc: Jonathan Lennox , "tram@ietf.org" Subject: Re: [tram] Fwd: New Version Notification for draft-schwartz-tram-turnbyname-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, 06 Mar 2015 22:08:36 -0000 --001a11c3bcbce7c64d0510a5ec3b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 6, 2015 at 12:53 PM, Benjamin Schwartz wrote: > On Fri, Mar 6, 2015 at 2:51 PM, Jonathan Lennox > wrote: > >> >> >> On Mar 5, 2015, at 3:17 PM, Benjamin Schwartz wrote: >> >> > Hi TRAM, >> > >> > I've just written up a proposal for an optional extension to TURN that >> would add support for DNS names. I'd like to discuss this at the upcomi= ng >> meeting. >> > >> > Let me know what you think! >> >> What happens if DNS resolution is slow? As far as I can tell the TURN >> server can=E2=80=99t respond to the ChannelBind or CreatePermission requ= est until >> DNS completes (or fails), and I vaguely think (though I don=E2=80=99t re= member >> exact numbers) that STUN transactions will time out faster than DNS ones >> will. >> > > You're right; if the client sends a DNS-name CreatePermission or > ChannelBind, the server can't send a success reply until DNS completes > successfully. However, I don't share your intuition. I'm not familiar > with DNS timeouts, but for example, this page [ > http://support.microsoft.com/kb/2834226] claims that Microsoft's DNS > resolution times out after 10 seconds. I'm not aware of any official, > standardized STUN timeout that applies before the first packet has been > received, but in practice implementations seem to allow for at least 30 > seconds of delay after signaling is complete. > The algorithm in https://tools.ietf.org/html/rfc5389#section-7.2.1 defines the STUN timeouts. As in, if the client sends channel-bind and gets no response, it will retransmit several times before giving up, at defined intervals. Typically this is 5-10 seconds, but it depends on RTO; for a < 50 ms RTO, the timeout could be ~5 s, i.e. shorter than the DNS timeout. Typically I think this case will be encountered when the hostname is invalid; in these cases, the permission/bind will simply be treated as an error by the client, and that particular candidate pair will fail, with no impact on other pairs. > >> The draft should also discuss its operation with TURN-TCP. As far as I >> can tell it=E2=80=99s straightforward, and easier than TURN-UDP, but it= =E2=80=99s worth >> discussing it. > > > I agree that the extension to TURN-TCP is straightforward, but I'd like t= o > see if we have rough consensus on this approach for UDP first. > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > --001a11c3bcbce7c64d0510a5ec3b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 6, 2015 at 12:53 PM, Benjamin Schwartz &l= t;bemasc@webrtc.org<= /a>> wrote:
On Fri, Mar 6, 2015 = at 2:51 PM, Jonathan Lennox <jonathan@vidyo.com> wrote:
=


On Mar 5, 2015, at 3:17 PM, Benjamin Schwartz <bemasc@webrtc.org> wrote:

> Hi TRAM,
>
> I've just written up a proposal for an optional extension to TURN = that would add support for DNS names.=C2=A0 I'd like to discuss this at= the upcoming meeting.
>
> Let me know what you think!

What happens if DNS resolution is slow?=C2=A0 As far as I can tell t= he TURN server can=E2=80=99t respond to the ChannelBind or CreatePermission= request until DNS completes (or fails), and I vaguely think (though I don= =E2=80=99t remember exact numbers) that STUN transactions will time out fas= ter than DNS ones will.

You're ri= ght; if the client sends a DNS-name CreatePermission or ChannelBind, the se= rver can't send a success reply until DNS completes successfully.=C2=A0= However, I don't share your intuition.=C2=A0 I'm not familiar with= DNS timeouts, but for example, this page [http://support.microsoft.com/kb/28342= 26] claims that Microsoft's DNS resolution times out after 10 secon= ds.=C2=A0 I'm not aware of any official, standardized STUN timeout that= applies before the first packet has been received, but in practice impleme= ntations seem to allow for at least 30 seconds of delay after signaling is = complete.

The algorithm i= n https://too= ls.ietf.org/html/rfc5389#section-7.2.1 defines the STUN timeouts. As in= , if the client sends channel-bind and gets no response, it will retransmit= several times before giving up, at defined intervals. Typically this is 5-= 10 seconds, but it depends on RTO; for a < 50 ms RTO, the timeout could = be ~5 s, i.e. shorter than the DNS timeout.

Typica= lly I think this case will be encountered when the hostname is invalid; in = these cases, the permission/bind will simply be treated as an error by the = client, and that particular candidate pair will fail, with no impact on oth= er pairs.

=C2=A0
The draft should also discuss its operation with TURN-TCP.=C2=A0 As far as = I can tell it=E2=80=99s straightforward, and easier than TURN-UDP, but it= =E2=80=99s worth discussing it.

I ag= ree that the extension to TURN-TCP is straightforward, but I'd like to = see if we have rough consensus on this approach for UDP first.
<= /div>

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


--001a11c3bcbce7c64d0510a5ec3b-- From nobody Fri Mar 6 14:25:32 2015 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 455F11A1BAA for ; Fri, 6 Mar 2015 14:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, 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 KA3PECKccZIt for ; Fri, 6 Mar 2015 14:25:29 -0800 (PST) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 791B21A1B22 for ; Fri, 6 Mar 2015 14:25:29 -0800 (PST) Received: by qgdz60 with SMTP id z60so16267681qgd.5 for ; Fri, 06 Mar 2015 14:25:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jEOPFa4deU4o74GDzbdF+zXgeOGDg1DoIwv5KTAc2/I=; b=mv+8AH3xdduNSbxHSu3uHPvFP0NIPNXNozmDnq43OLfUJaBseoMf3mCgAU/UYaW1cE rVvEPgF00AvaXVu0tFTbEOyCek8fg7lGF6gjq8wZ1cuOIWFYfHkzdDBT6ULUl4zllnZr VggC2jYZNXvWmUEcgoG5FIxJyqOqyVwofsDq/F9Zx7JdfO50pcZkjts+qDQsVGFvq3jK Pmem4dtujpwSBP7UmeKv5wXaWzdY0rs01Y4n2zM2huTWOzxPEf56Uodmvnuh2JGk17Yf nYAkjGZoSQb5XrFj8ZwZ+lCFwFct1Zp7JlM11kIwHJGfBKWxQUARngumv23lD2GtbcqG C3OA== X-Gm-Message-State: ALoCoQl40SlHLVm9WnDHBuG6QZnib9bbD8y747ihDihC3RQkRk2Wpy7HsCkSyhYabaVCLiD6o0iD X-Received: by 10.140.23.40 with SMTP id 37mr21169316qgo.93.1425680728816; Fri, 06 Mar 2015 14:25:28 -0800 (PST) Received: from [192.168.1.43] (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id 22sm6631609qgj.49.2015.03.06.14.25.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Mar 2015 14:25:27 -0800 (PST) Message-ID: <54FA2954.2060400@jive.com> Date: Fri, 06 Mar 2015 17:25:24 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Justin Uberti , Benjamin Schwartz References: <20150305201507.6192.13143.idtracker@ietfa.amsl.com> <35F68F75-51A0-48BD-B5D0-DE0A6600F13D@vidyo.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Jonathan Lennox , "tram@ietf.org" Subject: Re: [tram] Fwd: New Version Notification for draft-schwartz-tram-turnbyname-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, 06 Mar 2015 22:25:31 -0000 Le 2015-03-06 17:08, Justin Uberti a écrit : > What happens if DNS resolution is slow? As far as I can tell > the TURN server can’t respond to the ChannelBind or > CreatePermission request until DNS completes (or fails), and I > vaguely think (though I don’t remember exact numbers) that STUN > transactions will time out faster than DNS ones will. > > > You're right; if the client sends a DNS-name CreatePermission or > ChannelBind, the server can't send a success reply until DNS > completes successfully. However, I don't share your intuition. I'm > not familiar with DNS timeouts, but for example, this page > [http://support.microsoft.com/kb/2834226] claims that Microsoft's > DNS resolution times out after 10 seconds. I'm not aware of any > official, standardized STUN timeout that applies before the first > packet has been received, but in practice implementations seem to > allow for at least 30 seconds of delay after signaling is complete. > > > The algorithm in https://tools.ietf.org/html/rfc5389#section-7.2.1 > defines the STUN timeouts. As in, if the client sends channel-bind and > gets no response, it will retransmit several times before giving up, at > defined intervals. Typically this is 5-10 seconds, but it depends on > RTO; for a < 50 ms RTO, the timeout could be ~5 s, i.e. shorter than the > DNS timeout. > > Typically I think this case will be encountered when the hostname is > invalid; in these cases, the permission/bind will simply be treated as > an error by the client, and that particular candidate pair will fail, > with no impact on other pairs. I too don't see this as problematic. I think it would be enough to say that timeout = min(STUN timeout, DNS timeout), and leave it at that. Simon From nobody Fri Mar 6 14:30:11 2015 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 A54701A0113 for ; Fri, 6 Mar 2015 14:30: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 m0iQqCrpFfIj for ; Fri, 6 Mar 2015 14:30:08 -0800 (PST) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1906D1A00A2 for ; Fri, 6 Mar 2015 14:30:08 -0800 (PST) Received: by qcvx3 with SMTP id x3so54103631qcv.5 for ; Fri, 06 Mar 2015 14:30: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=focZEEpDo8iUI0y4PQIf6pmRHRt+SQZqWI1M5CZVDD4=; b=iJOmmWhBhFy+vZzIx//DQpqxZu56n8g09LB0hhPRpUeDSMCLZFgU4MAiyCe2L0nfwt 3h43tRT5VW4Ehtu1yrHCXyORJouSviCseBlrlv4wBJz0AUKh/So+sHDAO6VegmSM825M s1qG3eJmkwnoPRRnVrbdFzMuxtVHrD8OTER6zQ+MKstFyO4jybmHy7QeB7hf6czBrz5K 7DGGpP0fwC2YaUDYpP+CG5ETTRer1rW/jm3Bp+AZKZfvNqWdnd7+Sw04UZole2wTpwoO m4vF/SpZ1wNhFEXqKa0EfNulezum8L/ZMZgVNcMqjxiurUOAxKHURg0AkT8QycMzDF/e 4ccw== X-Gm-Message-State: ALoCoQlUWsivtWOU9fHcmbQKlxjb3wk0U6ppxJZLVJ/0Bh/4qM8EZBIcrhSUpimbe2nUxsupr3DC X-Received: by 10.55.22.24 with SMTP id g24mr33623726qkh.31.1425681007363; Fri, 06 Mar 2015 14:30:07 -0800 (PST) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com. [209.85.216.169]) by mx.google.com with ESMTPSA id n19sm6658561qhb.12.2015.03.06.14.30.06 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Mar 2015 14:30:06 -0800 (PST) Received: by qcxn11 with SMTP id n11so32174053qcx.3 for ; Fri, 06 Mar 2015 14:30:06 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.55.21.142 with SMTP id 14mr34278134qkv.30.1425681006235; Fri, 06 Mar 2015 14:30:06 -0800 (PST) Received: by 10.229.90.68 with HTTP; Fri, 6 Mar 2015 14:30:06 -0800 (PST) In-Reply-To: References: <20150305201507.6192.13143.idtracker@ietfa.amsl.com> <35F68F75-51A0-48BD-B5D0-DE0A6600F13D@vidyo.com> Date: Fri, 6 Mar 2015 17:30:06 -0500 Message-ID: From: Benjamin Schwartz To: Justin Uberti Content-Type: multipart/alternative; boundary=001a1147af6ef0a95d0510a6394c Archived-At: Cc: Jonathan Lennox , "tram@ietf.org" Subject: Re: [tram] Fwd: New Version Notification for draft-schwartz-tram-turnbyname-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, 06 Mar 2015 22:30:10 -0000 --001a1147af6ef0a95d0510a6394c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I don't understand. Why would these STUN timeouts apply before permission is granted, or before the channel is bound? It seems to me that these timeouts refer to timers that start when you make the first outbound request to a remote candidate, which is always after the success response to CreatePermission or ChannelBind. On Fri, Mar 6, 2015 at 5:08 PM, Justin Uberti wrote: > > > On Fri, Mar 6, 2015 at 12:53 PM, Benjamin Schwartz > wrote: > >> On Fri, Mar 6, 2015 at 2:51 PM, Jonathan Lennox >> wrote: >> >>> >>> >>> On Mar 5, 2015, at 3:17 PM, Benjamin Schwartz wrote= : >>> >>> > Hi TRAM, >>> > >>> > I've just written up a proposal for an optional extension to TURN tha= t >>> would add support for DNS names. I'd like to discuss this at the upcom= ing >>> meeting. >>> > >>> > Let me know what you think! >>> >>> What happens if DNS resolution is slow? As far as I can tell the TURN >>> server can=E2=80=99t respond to the ChannelBind or CreatePermission req= uest until >>> DNS completes (or fails), and I vaguely think (though I don=E2=80=99t r= emember >>> exact numbers) that STUN transactions will time out faster than DNS one= s >>> will. >>> >> >> You're right; if the client sends a DNS-name CreatePermission or >> ChannelBind, the server can't send a success reply until DNS completes >> successfully. However, I don't share your intuition. I'm not familiar >> with DNS timeouts, but for example, this page [ >> http://support.microsoft.com/kb/2834226] claims that Microsoft's DNS >> resolution times out after 10 seconds. I'm not aware of any official, >> standardized STUN timeout that applies before the first packet has been >> received, but in practice implementations seem to allow for at least 30 >> seconds of delay after signaling is complete. >> > > The algorithm in https://tools.ietf.org/html/rfc5389#section-7.2.1 > defines the STUN timeouts. As in, if the client sends channel-bind and ge= ts > no response, it will retransmit several times before giving up, at define= d > intervals. Typically this is 5-10 seconds, but it depends on RTO; for a < > 50 ms RTO, the timeout could be ~5 s, i.e. shorter than the DNS timeout. > > Typically I think this case will be encountered when the hostname is > invalid; in these cases, the permission/bind will simply be treated as an > error by the client, and that particular candidate pair will fail, with n= o > impact on other pairs. > > >> >>> The draft should also discuss its operation with TURN-TCP. As far as I >>> can tell it=E2=80=99s straightforward, and easier than TURN-UDP, but it= =E2=80=99s worth >>> discussing it. >> >> >> I agree that the extension to TURN-TCP is straightforward, but I'd like >> to see if we have rough consensus on this approach for UDP first. >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> >> > --001a1147af6ef0a95d0510a6394c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't understand.=C2=A0 Why would these STUN timeout= s apply before permission is granted, or before the channel is bound?=C2=A0= It seems to me that these timeouts refer to timers that start when you mak= e the first outbound request to a remote candidate, which is always after t= he success response to CreatePermission or ChannelBind.

On Fri, Mar 6, 2015 at 5:08 PM,= Justin Uberti <juberti@google.com> wrote:


On Fri, Mar 6, 2015 at 12:53 PM, Ben= jamin Schwartz <bemasc@webrtc.org> wrote:
On Fri, Mar 6, 2015 at 2:51 PM, Jonathan Lennox <<= a href=3D"mailto:jonathan@vidyo.com" target=3D"_blank">jonathan@vidyo.com> wrote:


On Mar 5, 2015, at 3:17 PM, Benjamin Schwartz <bemasc@webrtc.org> wrote:

> Hi TRAM,
>
> I've just written up a proposal for an optional extension to TURN = that would add support for DNS names.=C2=A0 I'd like to discuss this at= the upcoming meeting.
>
> Let me know what you think!

What happens if DNS resolution is slow?=C2=A0 As far as I can tell t= he TURN server can=E2=80=99t respond to the ChannelBind or CreatePermission= request until DNS completes (or fails), and I vaguely think (though I don= =E2=80=99t remember exact numbers) that STUN transactions will time out fas= ter than DNS ones will.

You're ri= ght; if the client sends a DNS-name CreatePermission or ChannelBind, the se= rver can't send a success reply until DNS completes successfully.=C2=A0= However, I don't share your intuition.=C2=A0 I'm not familiar with= DNS timeouts, but for example, this page [http://support.microsoft.com/kb/28342= 26] claims that Microsoft's DNS resolution times out after 10 secon= ds.=C2=A0 I'm not aware of any official, standardized STUN timeout that= applies before the first packet has been received, but in practice impleme= ntations seem to allow for at least 30 seconds of delay after signaling is = complete.

The algo= rithm in https://tools.ietf.org/html/rfc5389#section-7.2.1 defines= the STUN timeouts. As in, if the client sends channel-bind and gets no res= ponse, it will retransmit several times before giving up, at defined interv= als. Typically this is 5-10 seconds, but it depends on RTO; for a < 50 m= s RTO, the timeout could be ~5 s, i.e. shorter than the DNS timeout.
<= div>
Typically I think this case will be encountered when the= hostname is invalid; in these cases, the permission/bind will simply be tr= eated as an error by the client, and that particular candidate pair will fa= il, with no impact on other pairs.

=C2=A0
The draft should also discuss its operation with TURN-TCP.=C2=A0 As far as = I can tell it=E2=80=99s straightforward, and easier than TURN-UDP, but it= =E2=80=99s worth discussing it.

I ag= ree that the extension to TURN-TCP is straightforward, but I'd like to = see if we have rough consensus on this approach for UDP first.
<= /div>

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



--001a1147af6ef0a95d0510a6394c-- From nobody Fri Mar 6 16:32:49 2015 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 A45D31A8034 for ; Fri, 6 Mar 2015 16:32:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dW0B3GnDyvUv for ; Fri, 6 Mar 2015 16:32:45 -0800 (PST) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEB361A700F for ; Fri, 6 Mar 2015 16:32:45 -0800 (PST) Received: by iecrl12 with SMTP id rl12so7213346iec.8 for ; Fri, 06 Mar 2015 16:32:45 -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=9BqNQ99Da/NvW6koBcx//GvSHHvuARHKwyV3/1PmhYE=; b=oHMMMUCEUtKkTee/QEVJjBh/E2kupMvr5zISF62f08Oua7I4/Qr4/WfN5CaDO0UuyW cuXiDFvQYSnCkWQZc3lzRt861v9te5JmnIEUSweoBRbbChCPj8SVNHZ4TTFvaU9f6pb9 Kh07dwxkOIcyNuKhSg1S4c1611MXNlDJ11cAzdf0vFJ54f7yenurJzbEt64NnWFyv+F1 8UOeET/WjhaEHAoVLSSzSgq0X/DNi59bJ8QBbk1JN0+SjLX6I6Fr0jOnF7aBOU3KQdV2 nJm7swDXiT7cXlIHT1NmqFTViK3ixO02IWBzYYUuyKhy+t9B4wOio3XsZgkR4o/nbmF/ /ScQ== 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=9BqNQ99Da/NvW6koBcx//GvSHHvuARHKwyV3/1PmhYE=; b=J5Ht5z8ypVvgJpQC9+gn4EmeOmS5GJdX+NPM6V1bS8H4qY+m/bT6rQkTtvF09/HX9x zEuaDldZxjb/rT4mXmpNrY2ZHFRSltwJKGSlaWdYAFt+0+9AaRiS7HJpwk10GVpyF+fA RtawJHsXLEaxfen96ssyXQZpklR34dxZx2hYwf/vDNEFrBjFschQucdURrJFlijmqaK6 G1MQoYOWedzZzLAAC4eLH1oYvKKJo5Nio5GKGwIuGwyfxuQmr10OTwcYTsRSk8tAUj3o HBiC6+3leGRFq/MMen9X7eilYuBCQd91jvOp5qaDk5Q32e/xg5SO+aGiOXxTFjIzNruQ j5Xw== X-Gm-Message-State: ALoCoQmqoA9za0ngWcm1nWWqxcl50ImaL5O4jky1YYhLqHuE9FZ1slwqO4e034NIcTjopQ9jANvT X-Received: by 10.107.6.212 with SMTP id f81mr25691197ioi.37.1425688365185; Fri, 06 Mar 2015 16:32:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.64.42 with HTTP; Fri, 6 Mar 2015 16:32:24 -0800 (PST) In-Reply-To: References: <20150305201507.6192.13143.idtracker@ietfa.amsl.com> <35F68F75-51A0-48BD-B5D0-DE0A6600F13D@vidyo.com> From: Justin Uberti Date: Fri, 6 Mar 2015 16:32:24 -0800 Message-ID: To: Benjamin Schwartz Content-Type: multipart/alternative; boundary=001a113f8d5c9162440510a7f08f Archived-At: Cc: Jonathan Lennox , "tram@ietf.org" Subject: Re: [tram] Fwd: New Version Notification for draft-schwartz-tram-turnbyname-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: Sat, 07 Mar 2015 00:32:47 -0000 --001a113f8d5c9162440510a7f08f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable These are the timeouts for the TURN interaction, not the ICE checks. It's over UDP, so the client has to do its own retry semantics, which means retransmission of the CreatePermission/ChannelBind. If the server doesn't respond for 15 seconds, the client may think the network or server has died. On Fri, Mar 6, 2015 at 2:30 PM, Benjamin Schwartz wrote= : > I don't understand. Why would these STUN timeouts apply before permissio= n > is granted, or before the channel is bound? It seems to me that these > timeouts refer to timers that start when you make the first outbound > request to a remote candidate, which is always after the success response > to CreatePermission or ChannelBind. > > On Fri, Mar 6, 2015 at 5:08 PM, Justin Uberti wrote: > >> >> >> On Fri, Mar 6, 2015 at 12:53 PM, Benjamin Schwartz >> wrote: >> >>> On Fri, Mar 6, 2015 at 2:51 PM, Jonathan Lennox >>> wrote: >>> >>>> >>>> >>>> On Mar 5, 2015, at 3:17 PM, Benjamin Schwartz >>>> wrote: >>>> >>>> > Hi TRAM, >>>> > >>>> > I've just written up a proposal for an optional extension to TURN >>>> that would add support for DNS names. I'd like to discuss this at the >>>> upcoming meeting. >>>> > >>>> > Let me know what you think! >>>> >>>> What happens if DNS resolution is slow? As far as I can tell the TURN >>>> server can=E2=80=99t respond to the ChannelBind or CreatePermission re= quest until >>>> DNS completes (or fails), and I vaguely think (though I don=E2=80=99t = remember >>>> exact numbers) that STUN transactions will time out faster than DNS on= es >>>> will. >>>> >>> >>> You're right; if the client sends a DNS-name CreatePermission or >>> ChannelBind, the server can't send a success reply until DNS completes >>> successfully. However, I don't share your intuition. I'm not familiar >>> with DNS timeouts, but for example, this page [ >>> http://support.microsoft.com/kb/2834226] claims that Microsoft's DNS >>> resolution times out after 10 seconds. I'm not aware of any official, >>> standardized STUN timeout that applies before the first packet has been >>> received, but in practice implementations seem to allow for at least 30 >>> seconds of delay after signaling is complete. >>> >> >> The algorithm in https://tools.ietf.org/html/rfc5389#section-7.2.1 >> defines the STUN timeouts. As in, if the client sends channel-bind and g= ets >> no response, it will retransmit several times before giving up, at defin= ed >> intervals. Typically this is 5-10 seconds, but it depends on RTO; for a = < >> 50 ms RTO, the timeout could be ~5 s, i.e. shorter than the DNS timeout. >> >> Typically I think this case will be encountered when the hostname is >> invalid; in these cases, the permission/bind will simply be treated as a= n >> error by the client, and that particular candidate pair will fail, with = no >> impact on other pairs. >> >> >>> >>>> The draft should also discuss its operation with TURN-TCP. As far as = I >>>> can tell it=E2=80=99s straightforward, and easier than TURN-UDP, but i= t=E2=80=99s worth >>>> discussing it. >>> >>> >>> I agree that the extension to TURN-TCP is straightforward, but I'd like >>> to see if we have rough consensus on this approach for UDP first. >>> >>> _______________________________________________ >>> tram mailing list >>> tram@ietf.org >>> https://www.ietf.org/mailman/listinfo/tram >>> >>> >> > --001a113f8d5c9162440510a7f08f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
These are the timeouts for the TURN interaction, not the I= CE checks. It's over UDP, so the client has to do its own retry semanti= cs, which means retransmission of the CreatePermission/ChannelBind.
If the server doesn't respond for 15 seconds, the client ma= y think the network or server has died.

On Fri, Mar 6, 2015 at 2:30 PM, Benjamin = Schwartz <bemasc@webrtc.org> wrote:
I don't understand.=C2=A0 Why would these S= TUN timeouts apply before permission is granted, or before the channel is b= ound?=C2=A0 It seems to me that these timeouts refer to timers that start w= hen you make the first outbound request to a remote candidate, which is alw= ays after the success response to CreatePermission or ChannelBind.

On Fri, Mar 6, 2015 at 5:08 PM, Justin Uberti <jubert= i@google.com> wrote:


On Fri, Mar 6, 2015 at 12:53 PM, Benjamin Schwartz &l= t;bemasc@webrtc.org<= /a>> wrote:
On Fri, Mar 6, 2015 at 2:51 PM,= Jonathan Lennox <jonathan@vidyo.com> wrote:


On Mar 5, 2015, at 3:17 PM, Benjamin Schwartz <bemasc@webrtc.org> wrote:

> Hi TRAM,
>
> I've just written up a proposal for an optional extension to TURN = that would add support for DNS names.=C2=A0 I'd like to discuss this at= the upcoming meeting.
>
> Let me know what you think!

What happens if DNS resolution is slow?=C2=A0 As far as I can tell t= he TURN server can=E2=80=99t respond to the ChannelBind or CreatePermission= request until DNS completes (or fails), and I vaguely think (though I don= =E2=80=99t remember exact numbers) that STUN transactions will time out fas= ter than DNS ones will.

You're ri= ght; if the client sends a DNS-name CreatePermission or ChannelBind, the se= rver can't send a success reply until DNS completes successfully.=C2=A0= However, I don't share your intuition.=C2=A0 I'm not familiar with= DNS timeouts, but for example, this page [http://support.microsoft.com/kb/28342= 26] claims that Microsoft's DNS resolution times out after 10 secon= ds.=C2=A0 I'm not aware of any official, standardized STUN timeout that= applies before the first packet has been received, but in practice impleme= ntations seem to allow for at least 30 seconds of delay after signaling is = complete.

The algo= rithm in https://tools.ietf.org/html/rfc5389#section-7.2.1 defines= the STUN timeouts. As in, if the client sends channel-bind and gets no res= ponse, it will retransmit several times before giving up, at defined interv= als. Typically this is 5-10 seconds, but it depends on RTO; for a < 50 m= s RTO, the timeout could be ~5 s, i.e. shorter than the DNS timeout.
<= div>
Typically I think this case will be encountered when the= hostname is invalid; in these cases, the permission/bind will simply be tr= eated as an error by the client, and that particular candidate pair will fa= il, with no impact on other pairs.

<= span>
=C2=A0
The draft should also discuss its operation with TURN-TCP.=C2=A0 As far as = I can tell it=E2=80=99s straightforward, and easier than TURN-UDP, but it= =E2=80=99s worth discussing it.

I ag= ree that the extension to TURN-TCP is straightforward, but I'd like to = see if we have rough consensus on this approach for UDP first.
<= /div>

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




--001a113f8d5c9162440510a7f08f-- From nobody Fri Mar 6 16:35:10 2015 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 0A6811A7025 for ; Fri, 6 Mar 2015 16:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, 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 F0kI_Hldadxy for ; Fri, 6 Mar 2015 16:35:07 -0800 (PST) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 796011A700F for ; Fri, 6 Mar 2015 16:35:07 -0800 (PST) Received: by iecvy18 with SMTP id vy18so25847505iec.9 for ; Fri, 06 Mar 2015 16:35:07 -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=SMIz6m6HD3w41Vodqs0R3Ihwxpcc6QaWCdMwbipi5kc=; b=J+NL2yLFycFZBz8UWSFNVV31cMnhUWWyRQlWUVP1YFyTqpFX/UpMmV7TdK0Lb5NwfC sD6DbGLyxFZ6e6BltPg0H6fJ/pgrmkWx+I0B7ya9Ry8B4Llz5jByPtBHfko9hcjQCfuW NAw/rc25h7N/xz8lZ7LSZaiBGwZtTiHzfJ2afO/eEWsaTYVQMaV3v95xG2vkbnTCZftv 3aL6QM1bn+jRj20Ics8Y5061XemO/oEx8ncxKsDH1rpOPqqM3UJwaS+/UIGvfIwapiiR cHg/MtuDDm+K6+Jtfoyk+ME6NpdA7hsf7Q8LNVKn3bEIxLU7OBoIQ72vpkpGsUVfpxe0 BHnQ== 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=SMIz6m6HD3w41Vodqs0R3Ihwxpcc6QaWCdMwbipi5kc=; b=OMjlbU/sjsLggDyPBPw6rc35cyhmd3/ugTn5CUMIFW9jnUMBtmRzj89mrRKIycfQ3t Sz33U85rXrll/z8YbGjWXT8Jazf6A3HD72FLsLOy6qeAmx31lt0JFn8UcgV8oWQLkJ8t 6ebmusQ7JXoYOyy8brKCwq511sV6T2IbowHBZuMjNREvwObAFR7MYIwGhr6frCiTTKjg 2rTlnkg8QPL3nU0/rPZJ5Lcyu6ZTNbxvclgjgTSo+mNOQ7pNAFJ+ICYvoP6c91C46nZu 3nx+fpkR8O86B0lssxMBraYE+ub1TexhtudUh439GzCy/kmbqOK83YrRuZfE83djZoJ3 wGhA== X-Gm-Message-State: ALoCoQljmaKEG59iLYkMqZjjAY2KfP9aNNmV3w+jXbb6O0exh4wiiollFGuSzB7T0GWgLRhm57Ca X-Received: by 10.107.15.155 with SMTP id 27mr13463100iop.49.1425688506825; Fri, 06 Mar 2015 16:35:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.64.42 with HTTP; Fri, 6 Mar 2015 16:34:46 -0800 (PST) In-Reply-To: <54FA2954.2060400@jive.com> References: <20150305201507.6192.13143.idtracker@ietfa.amsl.com> <35F68F75-51A0-48BD-B5D0-DE0A6600F13D@vidyo.com> <54FA2954.2060400@jive.com> From: Justin Uberti Date: Fri, 6 Mar 2015 16:34:46 -0800 Message-ID: To: Simon Perreault Content-Type: multipart/alternative; boundary=001a113eeca802a6550510a7f9a6 Archived-At: Cc: Jonathan Lennox , Benjamin Schwartz , "tram@ietf.org" Subject: Re: [tram] Fwd: New Version Notification for draft-schwartz-tram-turnbyname-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: Sat, 07 Mar 2015 00:35:09 -0000 --001a113eeca802a6550510a7f9a6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 6, 2015 at 2:25 PM, Simon Perreault wrote= : > Le 2015-03-06 17:08, Justin Uberti a =C3=A9crit : > >> What happens if DNS resolution is slow? As far as I can tell >> the TURN server can=E2=80=99t respond to the ChannelBind or >> CreatePermission request until DNS completes (or fails), and I >> vaguely think (though I don=E2=80=99t remember exact numbers) th= at STUN >> transactions will time out faster than DNS ones will. >> >> >> You're right; if the client sends a DNS-name CreatePermission or >> ChannelBind, the server can't send a success reply until DNS >> completes successfully. However, I don't share your intuition. I'm >> not familiar with DNS timeouts, but for example, this page >> [http://support.microsoft.com/kb/2834226] claims that Microsoft's >> DNS resolution times out after 10 seconds. I'm not aware of any >> official, standardized STUN timeout that applies before the first >> packet has been received, but in practice implementations seem to >> allow for at least 30 seconds of delay after signaling is complete. >> >> >> The algorithm in https://tools.ietf.org/html/rfc5389#section-7.2.1 >> defines the STUN timeouts. As in, if the client sends channel-bind and >> gets no response, it will retransmit several times before giving up, at >> defined intervals. Typically this is 5-10 seconds, but it depends on >> RTO; for a < 50 ms RTO, the timeout could be ~5 s, i.e. shorter than the >> DNS timeout. >> >> Typically I think this case will be encountered when the hostname is >> invalid; in these cases, the permission/bind will simply be treated as >> an error by the client, and that particular candidate pair will fail, >> with no impact on other pairs. >> > > I too don't see this as problematic. I think it would be enough to say > that timeout =3D min(STUN timeout, DNS timeout), and leave it at that. The problem is that the STUN timeout is on the client, whereas the DNS timeout is on the server, so the client needs to somehow be aware of the DNS timeout in its STUN calculations. Generally I think that we could just say that if DNS doesn't respond in X seconds (e.g. 5), the server MUST consider the lookup to have failed and return a 4YY error code. --001a113eeca802a6550510a7f9a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 6, 2015 at 2:25 PM, Simon Perreault <<= a href=3D"mailto:sperreault@jive.com" target=3D"_blank">sperreault@jive.com= > wrote:
Le 2015-03-06 17:0= 8, Justin Uberti a =C3=A9crit :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 What happens if DNS resolution is slow?=C2=A0 A= s far as I can tell
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the TURN server can=E2=80=99t respond to the Ch= annelBind or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 CreatePermission request until DNS completes (o= r fails), and I
=C2=A0 =C2=A0 =C2=A0 =C2=A0 vaguely think (though I don=E2=80=99t remember = exact numbers) that STUN
=C2=A0 =C2=A0 =C2=A0 =C2=A0 transactions will time out faster than DNS ones= will.


=C2=A0 =C2=A0 You're right; if the client sends a DNS-name CreatePermis= sion or
=C2=A0 =C2=A0 ChannelBind, the server can't send a success reply until = DNS
=C2=A0 =C2=A0 completes successfully.=C2=A0 However, I don't share your= intuition.=C2=A0 I'm
=C2=A0 =C2=A0 not familiar with DNS timeouts, but for example, this page =C2=A0 =C2=A0 [http://support.microsoft.com/kb/2834226] claims that= Microsoft's
=C2=A0 =C2=A0 DNS resolution times out after 10 seconds.=C2=A0 I'm not = aware of any
=C2=A0 =C2=A0 official, standardized STUN timeout that applies before the f= irst
=C2=A0 =C2=A0 packet has been received, but in practice implementations see= m to
=C2=A0 =C2=A0 allow for at least 30 seconds of delay after signaling is com= plete.


The algorithm in https://tools.ietf.org/html/rfc5389#section-7.= 2.1
defines the STUN timeouts. As in, if the client sends channel-bind and
gets no response, it will retransmit several times before giving up, at
defined intervals. Typically this is 5-10 seconds, but it depends on
RTO; for a < 50 ms RTO, the timeout could be ~5 s, i.e. shorter than the=
DNS timeout.

Typically I think this case will be encountered when the hostname is
invalid; in these cases, the permission/bind will simply be treated as
an error by the client, and that particular candidate pair will fail,
with no impact on other pairs.

 I too don't see this as problematic. I think it would be enough to say = that timeout =3D min(STUN timeout, DNS timeout), and leave it at that.

The problem is that the STUN timeout is on the = client, whereas the DNS timeout is on the server, so the client needs to so= mehow be aware of the DNS timeout in its STUN calculations.

<= /div>
Generally I think that we could just say that if DNS doesn't = respond in X seconds (e.g. 5), the server MUST consider the lookup to have = failed and return a 4YY error code.

--001a113eeca802a6550510a7f9a6-- From nobody Fri Mar 6 18:44:43 2015 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 E9F611A87BD for ; Fri, 6 Mar 2015 18:44:42 -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 Nqq-QJXePl4Q for ; Fri, 6 Mar 2015 18:44:41 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2C141A87B8 for ; Fri, 6 Mar 2015 18:44:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13692; q=dns/txt; s=iport; t=1425696280; x=1426905880; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=wo55DIbIO8Bc5YGzWZ4R18+IfZumLhFB0b/PMtAJAEU=; b=VLNnWx+MCygpAl+csQg5snSDCrnviMTzdSSuuGrFB+n5ZsTVNwP6q+YO Q0dtSFIjPeyHz/zf+ni7qolxHIcKx59nDGVHjRqJOPgHUC9CFm6V4k2np wYN3ayTyyMuFSaMs0uCBCbZhepi33IW1jmIi7bfSSoZmrKo2zJqYeWGOK c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DsCQBMZfpU/4cNJK1cgkNDUloEgwa8NDyBfIVuAhyBGE0BAQEBAQF8hA8BAQEEIwpKEgIBCA4DAwEBAQsdAwICAjAUCQgCBAESCAGIJg20LZowAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sXhD0gDQoBBoJiL4EUBYV3iBCCAINjhwQ5gm2PLyOCMoE8bwGBQ38BAQE X-IronPort-AV: E=Sophos;i="5.11,356,1422921600"; d="scan'208,217";a="401964819" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-2.cisco.com with ESMTP; 07 Mar 2015 02:44:40 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t272idkk026969 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 7 Mar 2015 02:44:39 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Fri, 6 Mar 2015 20:44:39 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Benjamin Schwartz , "tram@ietf.org" Thread-Topic: [tram] Fwd: New Version Notification for draft-schwartz-tram-turnbyname-00.txt Thread-Index: AQHQV4F+o4JG0o831USfxRWlVq7wzJ0QS/hQ Date: Sat, 7 Mar 2015 02:44:39 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A366B0BA6@xmb-rcd-x10.cisco.com> References: <20150305201507.6192.13143.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.75.237] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A366B0BA6xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Subject: Re: [tram] Fwd: New Version Notification for draft-schwartz-tram-turnbyname-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: Sat, 07 Mar 2015 02:44:43 -0000 --_000_913383AAA69FF945B8F946018B75898A366B0BA6xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHdvcmsgaW4gRFBSSVZFIFdHIChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1o emh3bS1kcHJpdmUtc3RhcnQtdGxzLWZvci1kbnMtMDEpIGNhbiBhbHNvIGhlbHAgYWRkcmVzcyB0 aGUgcHJvYmxlbSBkaXNjdXNzZWQgaW4gdGhpcyBkcmFmdCB3aGVuIHRoZSBjbGllbnQgdXNlcyBE TlMtb3Zlci1UTFMgYW5kIGNvbnRhY3RzIGJvdGggdGhlIEROUyBzZXJ2ZXJzIG9uIHRoZSBsb2Nh bCBuZXR3b3JrIGFuZCBvbiB0aGUgSW50ZXJuZXQgKE9wZW5ETlMsIEdvb2dsZSBldGMuKS4NCg0K DQoNCkl0IHdpbGwgYmUgZ29vZCB0byBjb21wYXJlIHRoZSBtZWNoYW5pc20gaW4gdGhpcyBkcmFm dCB3aXRoIHRoZSB3b3JrIGdvaW5nIG9uIGluIHRoZSBhYm92ZSBXRy4NCg0KDQoNCi1UaXJ1DQoN Cg0KRnJvbTogdHJhbSBbbWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEJlbmphbWluIFNjaHdhcnR6DQpTZW50OiBGcmlkYXksIE1hcmNoIDA2LCAyMDE1IDE6NDggQU0N ClRvOiB0cmFtQGlldGYub3JnDQpTdWJqZWN0OiBbdHJhbV0gRndkOiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LXNjaHdhcnR6LXRyYW0tdHVybmJ5bmFtZS0wMC50eHQNCg0KSGkg VFJBTSwNCg0KSSd2ZSBqdXN0IHdyaXR0ZW4gdXAgYSBwcm9wb3NhbCBmb3IgYW4gb3B0aW9uYWwg ZXh0ZW5zaW9uIHRvIFRVUk4gdGhhdCB3b3VsZCBhZGQgc3VwcG9ydCBmb3IgRE5TIG5hbWVzLiAg SSdkIGxpa2UgdG8gZGlzY3VzcyB0aGlzIGF0IHRoZSB1cGNvbWluZyBtZWV0aW5nLg0KDQpMZXQg bWUga25vdyB3aGF0IHlvdSB0aGluayENCg0KVGhhbmtzLA0KQmVuDQoNCi0tLS0tLS0tLS0gRm9y d2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLQ0KRnJvbTogPGludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPj4NCkRhdGU6IFRodSwgTWFyIDUsIDIw MTUgYXQgMzoxNSBQTQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1zY2h3YXJ0ei10cmFtLXR1cm5ieW5hbWUtMDAudHh0DQpUbzogSnVzdGluIFViZXJ0aSA8anVz dGluQHViZXJ0aS5uYW1lPG1haWx0bzpqdXN0aW5AdWJlcnRpLm5hbWU+PiwgIkJlbmphbWluIE0u IFNjaHdhcnR6IiA8YmVtYXNjQHdlYnJ0Yy5vcmc8bWFpbHRvOmJlbWFzY0B3ZWJydGMub3JnPj4N Cg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1zY2h3YXJ0ei10cmFtLXR1cm5ieW5h bWUtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEJlbmphbWluIE0u IFNjaHdhcnR6IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6ICAg ICAgICAgICBkcmFmdC1zY2h3YXJ0ei10cmFtLXR1cm5ieW5hbWUNClJldmlzaW9uOiAgICAgICAw MA0KVGl0bGU6ICAgICAgICAgIFRVUk4gYnkgbmFtZTogYW4gZXh0ZW5zaW9uIHRvIFRVUk4gZm9y IGNvbnRhY3RpbmcgYW4gZW5kcG9pbnQgYnkgaXRzIEROUyBuYW1lLg0KRG9jdW1lbnQgZGF0ZTog IDIwMTUtMDMtMDUNCkdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2Vz OiAgICAgICAgICAxNQ0KVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LXNjaHdhcnR6LXRyYW0tdHVybmJ5bmFtZS0wMC50eHQNClN0YXR1czog ICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zY2h3YXJ0ei10 cmFtLXR1cm5ieW5hbWUvDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtc2Nod2FydHotdHJhbS10dXJuYnluYW1lLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBX aGVuIHR1bm5lbGluZyB0cmFmZmljIHRocm91Z2ggVFVSTiwgYSBjbGllbnQgbWF5IHNvbWV0aW1l cyBkZXNpcmUgdG8NCiAgIGNvbnRhY3QgYSByZW1vdGUgZW5kcG9pbnQgdGhhdCBpdCBrbm93cyBi eSBpdHMgRE5TIG5hbWUsIG5vdCBpdHMgSVANCiAgIGFkZHJlc3MuICBUaGlzIGRvY3VtZW50IGRl c2NyaWJlcyBhbiBleHRlbnNpb24gdG8gVFVSTiB0aGF0IGFsbG93cw0KICAgc3VjaCBhIGNsaWVu dCB0byBjb250YWN0IGEgbmFtZWQgZW5kcG9pbnQuDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQg aXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Np b24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQg dG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCg0KVGhlIElFVEYgU2VjcmV0 YXJpYXQNCg0K --_000_913383AAA69FF945B8F946018B75898A366B0BA6xmbrcdx10ciscoc_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2 Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9 DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENo YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBU ZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uSFRNTFByZWZvcm1h dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwcmU+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSB3b3JrIGluIERQUklWRSBXRyAoPGEg aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHpod20tZHByaXZlLXN0YXJ0 LXRscy1mb3ItZG5zLTAxIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oemh3bS1k cHJpdmUtc3RhcnQtdGxzLWZvci1kbnMtMDE8L2E+KSBjYW4gYWxzbyBoZWxwIGFkZHJlc3MgdGhl IHByb2JsZW0gZGlzY3Vzc2VkIGluIHRoaXMgZHJhZnQgd2hlbiB0aGUgY2xpZW50IHVzZXMgRE5T LW92ZXItVExTIGFuZCBjb250YWN0cyBib3RoIHRoZSBETlMgc2VydmVycyBvbiB0aGUgbG9jYWwg bmV0d29yayBhbmQgb24gdGhlIEludGVybmV0IChPcGVuRE5TLCBHb29nbGUgZXRjLikuPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkl0IHdpbGwgYmUgZ29vZCB0byBjb21w YXJlIHRoZSBtZWNoYW5pc20gaW4gdGhpcyBkcmFmdCB3aXRoIHRoZSB3b3JrIGdvaW5nIG9uIGlu IHRoZSBhYm92ZSBXRy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LVRp cnU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gdHJhbSBbbWFpbHRvOnRyYW0tYm91 bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QmVuamFtaW4gU2Nod2FydHo8YnI+ DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXJjaCAwNiwgMjAxNSAxOjQ4IEFNPGJyPg0KPGI+VG86 PC9iPiB0cmFtQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFt0cmFtXSBGd2Q6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc2Nod2FydHotdHJhbS10dXJuYnluYW1lLTAw LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SGkgVFJBTSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSd2ZSBqdXN0IHdyaXR0ZW4gdXAgYSBwcm9wb3NhbCBmb3IgYW4gb3B0 aW9uYWwgZXh0ZW5zaW9uIHRvIFRVUk4gdGhhdCB3b3VsZCBhZGQgc3VwcG9ydCBmb3IgRE5TIG5h bWVzLiZuYnNwOyBJJ2QgbGlrZSB0byBkaXNjdXNzIHRoaXMgYXQgdGhlIHVwY29taW5nIG1lZXRp bmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkxldCBtZSBrbm93IHdoYXQgeW91IHRoaW5rITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4tLS0tLS0tLS0tIEZv cndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS08YnI+DQpGcm9tOiAmbHQ7PGEgaHJlZj0ibWFpbHRv OmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiZn dDs8YnI+DQpEYXRlOiBUaHUsIE1hciA1LCAyMDE1IGF0IDM6MTUgUE08YnI+DQpTdWJqZWN0OiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNjaHdhcnR6LXRyYW0tdHVybmJ5bmFt ZS0wMC50eHQ8YnI+DQpUbzogSnVzdGluIFViZXJ0aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmp1c3Rp bkB1YmVydGkubmFtZSI+anVzdGluQHViZXJ0aS5uYW1lPC9hPiZndDssICZxdW90O0JlbmphbWlu IE0uIFNjaHdhcnR6JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YmVtYXNjQHdlYnJ0Yy5vcmci PmJlbWFzY0B3ZWJydGMub3JnPC9hPiZndDs8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpBIG5ldyB2 ZXJzaW9uIG9mIEktRCwgZHJhZnQtc2Nod2FydHotdHJhbS10dXJuYnluYW1lLTAwLnR4dDxicj4N CmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQmVuamFtaW4gTS4gU2Nod2FydHog YW5kIHBvc3RlZCB0byB0aGU8YnI+DQpJRVRGIHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KTmFtZTom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LXNjaHdhcnR6LXRy YW0tdHVybmJ5bmFtZTxicj4NClJldmlzaW9uOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzAw PGJyPg0KVGl0bGU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUVVJOIGJ5IG5h bWU6IGFuIGV4dGVuc2lvbiB0byBUVVJOIGZvciBjb250YWN0aW5nIGFuIGVuZHBvaW50IGJ5IGl0 cyBETlMgbmFtZS48YnI+DQpEb2N1bWVudCBkYXRlOiZuYnNwOyAyMDE1LTAzLTA1PGJyPg0KR3Jv dXA6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Np b248YnI+DQpQYWdlczombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDE1PGJyPg0K VVJMOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXNjaHdhcnR6LXRyYW0tdHVy bmJ5bmFtZS0wMC50eHQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LXNjaHdhcnR6LXRyYW0tdHVybmJ5bmFtZS0wMC50eHQ8L2E+PGJy Pg0KU3RhdHVzOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zY2h3YXJ0ei10cmFtLXR1cm5ieW5h bWUvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtc2Nod2FydHotdHJhbS10dXJuYnluYW1lLzwvYT48YnI+DQpIdG1saXplZDombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1zY2h3YXJ0ei10cmFtLXR1cm5ieW5hbWUtMDAiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zY2h3YXJ0ei10cmFtLXR1cm5ieW5hbWUtMDA8L2E+PGJy Pg0KPGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5ic3A7ICZuYnNwO1doZW4gdHVubmVsaW5n IHRyYWZmaWMgdGhyb3VnaCBUVVJOLCBhIGNsaWVudCBtYXkgc29tZXRpbWVzIGRlc2lyZSB0bzxi cj4NCiZuYnNwOyAmbmJzcDtjb250YWN0IGEgcmVtb3RlIGVuZHBvaW50IHRoYXQgaXQga25vd3Mg YnkgaXRzIEROUyBuYW1lLCBub3QgaXRzIElQPGJyPg0KJm5ic3A7ICZuYnNwO2FkZHJlc3MuJm5i c3A7IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGFuIGV4dGVuc2lvbiB0byBUVVJOIHRoYXQgYWxs b3dzPGJyPg0KJm5ic3A7ICZuYnNwO3N1Y2ggYSBjbGllbnQgdG8gY29udGFjdCBhIG5hbWVkIGVu ZHBvaW50Ljxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248 YnI+DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9vbHMu aWV0Zi5vcmc8L2E+Ljxicj4NCjxicj4NClRoZSBJRVRGIFNlY3JldGFyaWF0PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_913383AAA69FF945B8F946018B75898A366B0BA6xmbrcdx10ciscoc_-- From nobody Fri Mar 6 19:00:15 2015 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 50D9E1A87BF for ; Fri, 6 Mar 2015 19:00:14 -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 4zxnTJZpbPkg for ; Fri, 6 Mar 2015 19:00:12 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FBB11A87A9 for ; Fri, 6 Mar 2015 19:00:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15244; q=dns/txt; s=iport; t=1425697212; x=1426906812; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=UTA9Ihj1OKuVJN7m2bp8taK8ZAxBhveQjBIOv8xHSSI=; b=At1IwQnxNX1u+aCCh7wMCiG2Pjss7OsxVvcFbb1MOni59OM9ubon6wYh ol2adREmOsMZR8+c/duKvVmsu7KfiTrfarPPfUHn9UGE67H81iLlVtE6k MS2RuC2aKQlxRTaYJxoMVZBizoK5NwmAQdNJSWvxS9PtOssk8OlC+C6a9 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DsCQDNaPpU/4cNJK1SCoJDQ1JaBIMGvDM8gXyFbgIcgRhNAQEBAQEBfIQPAQEBBCMKShICAQgOAwMBAQELHQMCAgIwFAkIAgQBEggBiCYNtCqaMgEBAQEBAQEBAQEBAQEBAQEBAQEBAReLF4QSKyANCgEGgmIvgRQFhXeIEIIAg2OHBDmCbY8vI4IygTxvAYFDfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,356,1422921600"; d="scan'208,217";a="401966067" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-2.cisco.com with ESMTP; 07 Mar 2015 03:00:11 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t2730BVl001376 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 7 Mar 2015 03:00:11 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Fri, 6 Mar 2015 21:00:10 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Benjamin Schwartz , "tram@ietf.org" Thread-Topic: [tram] Fwd: New Version Notification for draft-schwartz-tram-turnbyname-00.txt Thread-Index: AQHQV4F+o4JG0o831USfxRWlVq7wzJ0QVSXA Date: Sat, 7 Mar 2015 03:00:10 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A366B0BD3@xmb-rcd-x10.cisco.com> References: <20150305201507.6192.13143.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.75.237] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A366B0BD3xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Subject: Re: [tram] Fwd: New Version Notification for draft-schwartz-tram-turnbyname-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: Sat, 07 Mar 2015 03:00:14 -0000 --_000_913383AAA69FF945B8F946018B75898A366B0BD3xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gc29tZSByZXN0cmljdGVkIG5ldHdvcmtzLCBETlMgYWNjZXNzIGlzIGFsc28gcmVzdHJpY3Rl ZCwgd2hpY2ggbWF5DQpwcmV2ZW50IHVzZXJzIGZyb20gZGV0ZXJtaW5pbmcgdGhlIElQIGFkZHJl c3Mgb2YgYSBkb21haW4gKGUuZy4gYW4NCmFwcGxpY2F0aW9uLXNwZWNpZmllZCBUVVJOIHNlcnZl ciwgZm9yIFJFVFVSTg0KW0ktRC5zY2h3YXJ0ei1ydGN3ZWItcmV0dXJuPGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXNjaHdhcnR6LXRyYW0tdHVybmJ5bmFtZS0wMCNyZWYtSS1ELnNj aHdhcnR6LXJ0Y3dlYi1yZXR1cm4+XSwgb3IgYW4gSUNFIGNhbmRpZGF0ZSB0aGF0IGNvbnRhaW5z IGENCmRvbWFpbiBuYW1lKSB0aGF0IHRoZXkgd2lzaCB0byBjb250YWN0IHRocm91Z2ggdGhlIGVz Y2FwZS1oYXRjaCBUVVJODQpzZXJ2ZXIuDQoNCkNvbW1lbnQ+IEZXIGluIHN1Y2ggcmVzdHJpY3Rl ZCBuZXR3b3JrIG1heSB1c2UgdmFyaW91cyBtZWNoYW5pc21zIGxpa2UgZnVuY3Rpb24gYXMgSFRU UFMgcHJveHksIHByb3RvY29sIGlkZW50aWZpY2F0aW9uIG9mIGVuY3J5cHRlZCBjb250ZW50IHZp YSBzdGF0aXN0aWNhbCBhbmFseXNpcyB0byBpZGVudGlmeSBhbmQgYmxvY2sgYXBwbGljYXRpb25z IGV0Yy4NCkhvdyB3aWxsIHRoaXMgdGVjaG5pcXVlIHdvcmsgaW4gc3VjaCByZXN0cmljdGVkIG5l dHdvcmtzID8NCg0KLVRpcnUNCg0KRnJvbTogdHJhbSBbbWFpbHRvOnRyYW0tYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEJlbmphbWluIFNjaHdhcnR6DQpTZW50OiBGcmlkYXksIE1hcmNo IDA2LCAyMDE1IDE6NDggQU0NClRvOiB0cmFtQGlldGYub3JnDQpTdWJqZWN0OiBbdHJhbV0gRndk OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNjaHdhcnR6LXRyYW0tdHVybmJ5 bmFtZS0wMC50eHQNCg0KSGkgVFJBTSwNCg0KSSd2ZSBqdXN0IHdyaXR0ZW4gdXAgYSBwcm9wb3Nh bCBmb3IgYW4gb3B0aW9uYWwgZXh0ZW5zaW9uIHRvIFRVUk4gdGhhdCB3b3VsZCBhZGQgc3VwcG9y dCBmb3IgRE5TIG5hbWVzLiAgSSdkIGxpa2UgdG8gZGlzY3VzcyB0aGlzIGF0IHRoZSB1cGNvbWlu ZyBtZWV0aW5nLg0KDQpMZXQgbWUga25vdyB3aGF0IHlvdSB0aGluayENCg0KVGhhbmtzLA0KQmVu DQoNCi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLQ0KRnJvbTogPGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPj4NCkRh dGU6IFRodSwgTWFyIDUsIDIwMTUgYXQgMzoxNSBQTQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1zY2h3YXJ0ei10cmFtLXR1cm5ieW5hbWUtMDAudHh0DQpUbzog SnVzdGluIFViZXJ0aSA8anVzdGluQHViZXJ0aS5uYW1lPG1haWx0bzpqdXN0aW5AdWJlcnRpLm5h bWU+PiwgIkJlbmphbWluIE0uIFNjaHdhcnR6IiA8YmVtYXNjQHdlYnJ0Yy5vcmc8bWFpbHRvOmJl bWFzY0B3ZWJydGMub3JnPj4NCg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1zY2h3 YXJ0ei10cmFtLXR1cm5ieW5hbWUtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IEJlbmphbWluIE0uIFNjaHdhcnR6IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9z aXRvcnkuDQoNCk5hbWU6ICAgICAgICAgICBkcmFmdC1zY2h3YXJ0ei10cmFtLXR1cm5ieW5hbWUN ClJldmlzaW9uOiAgICAgICAwMA0KVGl0bGU6ICAgICAgICAgIFRVUk4gYnkgbmFtZTogYW4gZXh0 ZW5zaW9uIHRvIFRVUk4gZm9yIGNvbnRhY3RpbmcgYW4gZW5kcG9pbnQgYnkgaXRzIEROUyBuYW1l Lg0KRG9jdW1lbnQgZGF0ZTogIDIwMTUtMDMtMDUNCkdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFs IFN1Ym1pc3Npb24NClBhZ2VzOiAgICAgICAgICAxNQ0KVVJMOiAgICAgICAgICAgIGh0dHA6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXNjaHdhcnR6LXRyYW0tdHVybmJ5bmFt ZS0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1zY2h3YXJ0ei10cmFtLXR1cm5ieW5hbWUvDQpIdG1saXplZDogICAgICAgaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2Nod2FydHotdHJhbS10dXJuYnluYW1lLTAwDQoN Cg0KQWJzdHJhY3Q6DQogICBXaGVuIHR1bm5lbGluZyB0cmFmZmljIHRocm91Z2ggVFVSTiwgYSBj bGllbnQgbWF5IHNvbWV0aW1lcyBkZXNpcmUgdG8NCiAgIGNvbnRhY3QgYSByZW1vdGUgZW5kcG9p bnQgdGhhdCBpdCBrbm93cyBieSBpdHMgRE5TIG5hbWUsIG5vdCBpdHMgSVANCiAgIGFkZHJlc3Mu ICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhbiBleHRlbnNpb24gdG8gVFVSTiB0aGF0IGFsbG93 cw0KICAgc3VjaCBhIGNsaWVudCB0byBjb250YWN0IGEgbmFtZWQgZW5kcG9pbnQuDQoNCg0KDQoN ClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4N Cg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K --_000_913383AAA69FF945B8F946018B75898A366B0BD3xmbrcdx10ciscoc_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2 Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9 DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENo YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBU ZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uSFRNTFByZWZvcm1h dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij5PbiBzb21lIHJlc3RyaWN0ZWQgbmV0d29ya3MsIEROUyBhY2Nlc3MgaXMg YWxzbyByZXN0cmljdGVkLCB3aGljaCBtYXk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+cHJldmVudCB1c2VycyBmcm9tIGRldGVybWluaW5nIHRo ZSBJUCBhZGRyZXNzIG9mIGEgZG9tYWluIChlLmcuIGFuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmFwcGxpY2F0aW9uLXNwZWNpZmllZCBUVVJO IHNlcnZlciwgZm9yIFJFVFVSTjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij5bPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtc2Nod2FydHotdHJhbS10dXJuYnluYW1lLTAwI3JlZi1JLUQuc2Nod2FydHotcnRjd2ViLXJl dHVybiI+SS1ELnNjaHdhcnR6LXJ0Y3dlYi1yZXR1cm48L2E+XSwgb3IgYW4gSUNFIGNhbmRpZGF0 ZSB0aGF0IGNvbnRhaW5zIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+ZG9tYWluIG5hbWUpIHRoYXQgdGhleSB3aXNoIHRvIGNvbnRhY3QgdGhy b3VnaCB0aGUgZXNjYXBlLWhhdGNoIFRVUk48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+c2VydmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Q29tbWVudCZndDsgRlcgaW4gc3VjaCBy ZXN0cmljdGVkIG5ldHdvcmsgbWF5IHVzZSB2YXJpb3VzIG1lY2hhbmlzbXMgbGlrZSBmdW5jdGlv biBhcyBIVFRQUyBwcm94eSwgcHJvdG9jb2wgaWRlbnRpZmljYXRpb24gb2YgZW5jcnlwdGVkIGNv bnRlbnQgdmlhIHN0YXRpc3RpY2FsIGFuYWx5c2lzIHRvIGlkZW50aWZ5IGFuZA0KIGJsb2NrIGFw cGxpY2F0aW9ucyBldGMuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij5Ib3cgd2lsbCB0aGlzIHRlY2huaXF1ZSB3b3JrIGluIHN1Y2ggcmVzdHJp Y3RlZCBuZXR3b3JrcyA/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4tVGlydTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiB0cmFtIFttYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5CZW5qYW1pbiBTY2h3YXJ0ejxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE1h cmNoIDA2LCAyMDE1IDE6NDggQU08YnI+DQo8Yj5Ubzo8L2I+IHRyYW1AaWV0Zi5vcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gW3RyYW1dIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1zY2h3YXJ0ei10cmFtLXR1cm5ieW5hbWUtMDAudHh0PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBUUkFNLDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ3ZlIGp1c3Qg d3JpdHRlbiB1cCBhIHByb3Bvc2FsIGZvciBhbiBvcHRpb25hbCBleHRlbnNpb24gdG8gVFVSTiB0 aGF0IHdvdWxkIGFkZCBzdXBwb3J0IGZvciBETlMgbmFtZXMuJm5ic3A7IEknZCBsaWtlIHRvIGRp c2N1c3MgdGhpcyBhdCB0aGUgdXBjb21pbmcgbWVldGluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGV0IG1lIGtub3cgd2hhdCB5b3UgdGhp bmshPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkJlbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0t LTxicj4NCkZyb206ICZsdDs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn Ij5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCkRhdGU6IFRodSwgTWFyIDUs IDIwMTUgYXQgMzoxNSBQTTxicj4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtc2Nod2FydHotdHJhbS10dXJuYnluYW1lLTAwLnR4dDxicj4NClRvOiBKdXN0aW4g VWJlcnRpICZsdDs8YSBocmVmPSJtYWlsdG86anVzdGluQHViZXJ0aS5uYW1lIj5qdXN0aW5AdWJl cnRpLm5hbWU8L2E+Jmd0OywgJnF1b3Q7QmVuamFtaW4gTS4gU2Nod2FydHomcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpiZW1hc2NAd2VicnRjLm9yZyI+YmVtYXNjQHdlYnJ0Yy5vcmc8L2E+Jmd0 Ozxicj4NCjxicj4NCjxicj4NCjxicj4NCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1zY2h3 YXJ0ei10cmFtLXR1cm5ieW5hbWUtMDAudHh0PGJyPg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSBCZW5qYW1pbiBNLiBTY2h3YXJ0eiBhbmQgcG9zdGVkIHRvIHRoZTxicj4NCklF VEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpOYW1lOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ZHJhZnQtc2Nod2FydHotdHJhbS10dXJuYnluYW1lPGJyPg0KUmV2aXNp b246Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MDA8YnI+DQpUaXRsZTombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRVUk4gYnkgbmFtZTogYW4gZXh0ZW5zaW9uIHRvIFRVUk4g Zm9yIGNvbnRhY3RpbmcgYW4gZW5kcG9pbnQgYnkgaXRzIEROUyBuYW1lLjxicj4NCkRvY3VtZW50 IGRhdGU6Jm5ic3A7IDIwMTUtMDMtMDU8YnI+DQpHcm91cDombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IEluZGl2aWR1YWwgU3VibWlzc2lvbjxicj4NClBhZ2VzOiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMTU8YnI+DQpVUkw6Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtc2Nod2FydHotdHJhbS10dXJuYnluYW1lLTAwLnR4dCIgdGFyZ2V0PSJf YmxhbmsiPg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc2Nod2Fy dHotdHJhbS10dXJuYnluYW1lLTAwLnR4dDwvYT48YnI+DQpTdGF0dXM6Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LXNjaHdhcnR6LXRyYW0tdHVybmJ5bmFtZS8iIHRhcmdldD0iX2JsYW5rIj5odHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zY2h3YXJ0ei10cmFtLXR1cm5ieW5h bWUvPC9hPjxicj4NCkh0bWxpemVkOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNjaHdhcnR6LXRyYW0tdHVybmJ5bmFt ZS0wMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNj aHdhcnR6LXRyYW0tdHVybmJ5bmFtZS0wMDwvYT48YnI+DQo8YnI+DQo8YnI+DQpBYnN0cmFjdDo8 YnI+DQombmJzcDsgJm5ic3A7V2hlbiB0dW5uZWxpbmcgdHJhZmZpYyB0aHJvdWdoIFRVUk4sIGEg Y2xpZW50IG1heSBzb21ldGltZXMgZGVzaXJlIHRvPGJyPg0KJm5ic3A7ICZuYnNwO2NvbnRhY3Qg YSByZW1vdGUgZW5kcG9pbnQgdGhhdCBpdCBrbm93cyBieSBpdHMgRE5TIG5hbWUsIG5vdCBpdHMg SVA8YnI+DQombmJzcDsgJm5ic3A7YWRkcmVzcy4mbmJzcDsgVGhpcyBkb2N1bWVudCBkZXNjcmli ZXMgYW4gZXh0ZW5zaW9uIHRvIFRVUk4gdGhhdCBhbGxvd3M8YnI+DQombmJzcDsgJm5ic3A7c3Vj aCBhIGNsaWVudCB0byBjb250YWN0IGEgbmFtZWQgZW5kcG9pbnQuPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51 dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxicj4NCnVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQp0b29scy5pZXRmLm9yZzwvYT4uPGJyPg0KPGJyPg0K VGhlIElFVEYgU2VjcmV0YXJpYXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_913383AAA69FF945B8F946018B75898A366B0BD3xmbrcdx10ciscoc_-- From nobody Sat Mar 7 00:30:33 2015 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 CED161A7002; Fri, 6 Mar 2015 12:13:32 -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 mOEFO3FMkmjB; Fri, 6 Mar 2015 12:13:29 -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 A53ED1A7003; Fri, 6 Mar 2015 12:13:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6882; q=dns/txt; s=iport; t=1425672809; x=1426882409; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=+UHxk9PAUprVB7cDoEzHSqhMph7DYT55suXEgh2cYcM=; b=lkEEnJKplKdnRkEbmetD/C/hIbNEhAenwZ8uWV8BObg95UNQcKg/kw83 fjcNh/YXYqnyCH9eKneniRBZRTR4ZsCsDRWkY2dcC1bY/v72VOcAq0hD6 8K7fS7WgpxPxbwPyfneilOaJgl8pfau+AAiv56jGEIlMr8Mlf7Bn3utX3 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DHBgDiCfpU/5hdJa1cgwZSVQUEvziCOIUlSQKBO00BAQEBAQF8hA8BAQEEdw4EAgEIEQQBAQEZDgchERQJCAIEAQkJCYgSAxEIBcglDYU0AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sXgkSBWQEBHDUFBoQlBZAHg2OEIoFIgRo5gm2IUUyCUINCI4ICHIFQbwFkBRoHFwYcfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,354,1422921600"; d="scan'208";a="401544154" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 06 Mar 2015 20:13:28 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t26KDRx7022715 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Mar 2015 20:13:27 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.249]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Fri, 6 Mar 2015 14:13:27 -0600 From: "Prashanth Patil (praspati)" To: Stephen Farrell , Gonzalo Camarillo , "Tirumaleswar Reddy (tireddy)" , "tram-chairs@ietf.org" , "tram@ietf.org" , "draft-ietf-tram-turn-third-party-authz@ietf.org" , "draft-ietf-tram-turn-third-party-authz.ad@ietf.org" , "draft-ietf-tram-turn-third-party-authz.shepherd@ietf.org" , "spencerdawkins.ietf@gmail.com" , "rlb@ipv.sx" Thread-Topic: New Version Notification - draft-ietf-tram-turn-third-party-authz-13.txt Thread-Index: AQHQWEoBV1i33XHUqUubcUfsOv5F9w== Date: Fri, 6 Mar 2015 20:13:26 +0000 Message-ID: References: <913383AAA69FF945B8F946018B75898A366AA244@xmb-rcd-x10.cisco.com> <54F98585.7070203@ericsson.com> <54F9CBDF.7010705@cs.tcd.ie> In-Reply-To: <54F9CBDF.7010705@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.155.208.75] Content-Type: text/plain; charset="Windows-1252" Content-ID: <9D3B348130A5154C8C2F1720A689E1DF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Sat, 07 Mar 2015 00:30:32 -0800 Subject: Re: [tram] New Version Notification - draft-ietf-tram-turn-third-party-authz-13.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, 06 Mar 2015 20:13:33 -0000 Hi Stephen, We did respond to your discussion points. In any case, responses pasted below: (1) Making none of 4.1.x mandatory to implement will result in a lack of interop. What is the developer supposed to implement? Why is it ok to not say? (For example, defining 4.1.1 and 4.1.2 simply so as to appear "more secure" whilst really expecting 4.1.3 to be used, but not saying so, would seem like a bad plan to me.) =20 Response> Sections 4.1.x are only meant to be examples of mechanisms that could be potentially used. The authors don=B9t have a preference of one ove= r the others, 4.1.2 (REST) could be something that can be recommended to be implemented (easy to develop and provides algorithm agility). (2) What is the status of Appendix B? Am I supposed to implement that? What does "Client could..." mean? =20 Response> Appendix B is only meant to be provide an illustration of interaction between the WebRTC client and authorization server (WebRTC server). Please note that the communication between the two is proprietary, WebRTC does not mandate any signaling protocol. (3) In the secdir review [1] discussion, I see the authors mention adding ECC, but I see nothing in the draft. I don't believe that that discussion has really ended and would like to continue it. Why is the WebRTC server not simply signing something for the STUN server to verify? https://www.ietf.org/mail-archive/web/secdir/current/msg05425.html =20 Response> We did have an offline discussion with Yaron Sheffer (who had suggested ECC). ECDH-ES can be used to agree upon a symmetric key for encrypting/decrypting the token and ECDSA to generate digital signature for the token. But this would result in a symmetric key, just like the approaches described in 4.1.1 and 4.1.2. We=B9ve hence decided not to include any details pertaining to ECC. =20 Intro: "impossible in web applications" isn't really true in principle, but impossible in WebRTC as it uses JS is true.=20 Response> Yes. It is not possible for WebRTC as it uses JS. We=B9ll correct it. =20 NEW: "However, in web applications like WebRTC [I-D.ietf-rtcweb-overview] where JavaScript uses the browser functionality to make real-time audio and/or video calls, Web conferencing, and direct data transfer, ensuring this secrecy is typically not possible." - 4.1.2 - which "two servers"? WebRTC can have more servers than that. =20 Response> The STUN server and the AS. As far as the STUN server is concerned, it only deals with the AS of interest for key establishment. The AS could be the application server itself or could be a Key management function syncing the keying material to the WebRTC servers. - 4.1.2 - now we're using TLS mutual auth? And how does the TLS client know which CA to use that'll work with the TLS server here? I don't think that'll scale will it? =20 Response> We presume the two parties involved know what CA to consider when using the REST APIs =AD they would have to do this to trust each other= . Please note that the AS is allocating symmetric keys meant exclusively for that STUN Server, so some level of co-ordination is already involved. - 4.1.3 - this looks like what the WG/authors really want, would that be a fair statement? =20 Response> No. The =8CNote:=B9 at the end of the section is probably misleading, will update it. =20 NEW: "Note : The mechanism specified in Section 4.1.3 lacks encryption and HMAC algorithm agility." - 9: Figure 2 should be way up at the top of the document and not here =20 Response> In the previous versions it was in the top of the document but moved down after comments received from the WG that WebRTC is only an example usage of third party authorization. - 9: Why 5 seconds? =20 Response> STUN messages can be sent over UDP, 5 seconds is to accommodate packet loss and RTO interval. =20 - Assuming the AS that can authorize the user shares a secret with the STUN server chosen by the WebRTC server seems very brittle. Why would that be true in general? =20 Response> The AS and WebRTC server are in the same administrative domain of the application provider. The user never sends the session key learned from the AS to the STUN server it only uses the session key to compute message integrity of STUN request and to validate the message integrity of the STUN response. The STUN server will only know the session key if it can decrypt the token. -Prashanth On 3/6/15, 7:46 AM, "Stephen Farrell" wrote: > >Hey, > >#1 - nope, that version doesn't address things that I can see >(and I've not seen a direct response to my discuss points that >I recall) > >#2 - I sent an ask to the saag list just now, (attached) will >let you know if I get offers. Please also ping me if you get >any direct, just so's we don't cross streams. > >S. > >On 06/03/15 10:46, Gonzalo Camarillo wrote: >> Stephen, Richard, >>=20 >> you have discusses on this draft: >>=20 >>=20 >>https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/b >>allot/ >>=20 >> Could you please look at the new revision Tiru has put together and let >> him know if you are happy with it? >>=20 >> Thanks, >>=20 >> Gonzalo >>=20 >> On 28/02/2015 5:10 AM, Tirumaleswar Reddy (tireddy) wrote: >>> We have responded to comments from ISEG and published updated draft. >>> >>> -Tiru >>> >>>> -----Original Message----- >>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>> Sent: Thursday, February 26, 2015 10:26 AM >>>> To: tram-chairs@ietf.org; tram@ietf.org; >>>>draft-ietf-tram-turn-third-party- >>>> authz@ietf.org; gonzalo.camarillo@ericsson.com; >>>>draft-ietf-tram-turn-third- >>>> party-authz.ad@ietf.org; draft-ietf-tram-turn-third-party- >>>> authz.shepherd@ietf.org; spencerdawkins.ietf@gmail.com; rlb@ipv.sx; >>>> stephen.farrell@cs.tcd.ie >>>> Subject: New Version Notification - >>>>draft-ietf-tram-turn-third-party-authz- >>>> 13.txt >>>> >>>> >>>> A new version (-13) has been submitted for >>>>draft-ietf-tram-turn-third-party- >>>> authz: >>>>=20 >>>>http://www.ietf.org/internet-drafts/draft-ietf-tram-turn-third-party-au >>>>thz- >>>> 13.txt >>>> >>>> Sub state has been changed to AD Followup from Revised ID Needed >>>> >>>> >>>> The IETF datatracker page for this Internet-Draft is: >>>>=20 >>>>https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz >>>>/ >>>> >>>> Diff from previous version: >>>>=20 >>>>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turn-third-party-aut= hz >>>>-13 >>>> >>>> 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. >>>> >>>> IETF Secretariat. >>> >>=20 From nobody Sat Mar 7 00:30:35 2015 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 02C2E1A86E8; Fri, 6 Mar 2015 12:59: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 b1Zc6Rye9Hw8; Fri, 6 Mar 2015 12:59:11 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBF341A86E2; Fri, 6 Mar 2015 12:59:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EB741BE8A; Fri, 6 Mar 2015 20:59:07 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpK6Kymmlfgn; Fri, 6 Mar 2015 20:59:05 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.42.19.237]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6D0EDBE39; Fri, 6 Mar 2015 20:59:05 +0000 (GMT) Message-ID: <54FA1519.5040809@cs.tcd.ie> Date: Fri, 06 Mar 2015 20:59:05 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Prashanth Patil (praspati)" , Gonzalo Camarillo , "Tirumaleswar Reddy (tireddy)" , "tram-chairs@ietf.org" , "tram@ietf.org" , "draft-ietf-tram-turn-third-party-authz@ietf.org" , "draft-ietf-tram-turn-third-party-authz.ad@ietf.org" , "draft-ietf-tram-turn-third-party-authz.shepherd@ietf.org" , "spencerdawkins.ietf@gmail.com" , "rlb@ipv.sx" References: <913383AAA69FF945B8F946018B75898A366AA244@xmb-rcd-x10.cisco.com> <54F98585.7070203@ericsson.com> <54F9CBDF.7010705@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Sat, 07 Mar 2015 00:30:32 -0800 Subject: Re: [tram] New Version Notification - draft-ietf-tram-turn-third-party-authz-13.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, 06 Mar 2015 20:59:14 -0000 On 06/03/15 20:13, Prashanth Patil (praspati) wrote: > Hi Stephen, > We did respond to your discussion points. Ah sorry - you omitted the IESG I guess, as with this and that was where I looked. Can you respond cc'ing all? That way any other ADs who may be interested also see the discussion. Ta, S. In any case, responses pasted > below: > > (1) Making none of 4.1.x mandatory to implement will > result in a lack of interop. What is the developer > supposed to implement? Why is it ok to not say? (For > example, defining 4.1.1 and 4.1.2 simply so as to appear > "more secure" whilst really expecting 4.1.3 to be used, > but not saying so, would seem like a bad plan to me.) > > > Response> Sections 4.1.x are only meant to be examples of mechanisms that > could be potentially used. The authors don¹t have a preference of one over > the others, 4.1.2 (REST) could be something that can be recommended to be > implemented (easy to develop and provides algorithm agility). > > (2) What is the status of Appendix B? Am I supposed to > implement that? What does "Client could..." mean? > > > Response> Appendix B is only meant to be provide an illustration of > interaction between the WebRTC client and authorization server (WebRTC > server). Please note that the communication between the two is > proprietary, WebRTC does not mandate any signaling protocol. > > (3) In the secdir review [1] discussion, I see the authors > mention adding ECC, but I see nothing in the draft. I > don't believe that that discussion has really ended and > would like to continue it. Why is the WebRTC server not > simply signing something for the STUN server to verify? > https://www.ietf.org/mail-archive/web/secdir/current/msg05425.html > > > Response> We did have an offline discussion with Yaron Sheffer (who had > suggested ECC). ECDH-ES can be used to agree upon a symmetric key for > encrypting/decrypting the token and ECDSA to generate digital signature > for the token. But this would result in a symmetric key, just like the > approaches described in 4.1.1 and 4.1.2. We¹ve hence decided not to > include any details pertaining to ECC. > > > Intro: "impossible in web applications" isn't really > true in principle, but impossible in WebRTC as it uses JS > is true. > > Response> Yes. It is not possible for WebRTC as it uses JS. We¹ll correct > it. > > NEW: > "However, in web applications like WebRTC [I-D.ietf-rtcweb-overview] where > JavaScript uses the browser functionality to make real-time audio and/or > video calls, Web conferencing, and direct data transfer, ensuring this > secrecy is typically not possible." > > - 4.1.2 - which "two servers"? WebRTC can have more > servers than that. > > > Response> The STUN server and the AS. As far as the STUN server is > concerned, it only deals with the AS of interest for key establishment. > The AS could be the application server itself or could be a Key management > function syncing the keying material to the WebRTC servers. > > - 4.1.2 - now we're using TLS mutual auth? And how does > the TLS client know which CA to use that'll work with the > TLS server here? I don't think that'll scale will it? > > > Response> We presume the two parties involved know what CA to consider > when using the REST APIs ­ they would have to do this to trust each other. > Please note that the AS is allocating symmetric keys meant exclusively for > that STUN Server, so some level of co-ordination is already involved. > > - 4.1.3 - this looks like what the WG/authors really want, > would that be a fair statement? > > > Response> No. The Å’Note:¹ at the end of the section is probably > misleading, will update it. > > NEW: > "Note : The mechanism specified in Section 4.1.3 lacks encryption and HMAC > algorithm agility." > > - 9: Figure 2 should be way up at the top of the document > and not here > > > Response> In the previous versions it was in the top of the document but > moved down after comments received from the WG that WebRTC is only an > example usage of third party authorization. > > - 9: Why 5 seconds? > > > Response> STUN messages can be sent over UDP, 5 seconds is to accommodate > packet loss and RTO interval. > > > - Assuming the AS that can authorize the user shares a > secret with the STUN server chosen by the WebRTC server > seems very brittle. Why would that be true in general? > > > Response> The AS and WebRTC server are in the same administrative domain > of the application provider. The user never sends the session key learned > from the AS to the STUN server it only uses the session key to compute > message integrity of STUN request and to validate the message integrity of > the STUN response. The STUN server will only know the session key if it > can decrypt the token. > > > -Prashanth > > On 3/6/15, 7:46 AM, "Stephen Farrell" wrote: > >> >> Hey, >> >> #1 - nope, that version doesn't address things that I can see >> (and I've not seen a direct response to my discuss points that >> I recall) >> >> #2 - I sent an ask to the saag list just now, (attached) will >> let you know if I get offers. Please also ping me if you get >> any direct, just so's we don't cross streams. >> >> S. >> >> On 06/03/15 10:46, Gonzalo Camarillo wrote: >>> Stephen, Richard, >>> >>> you have discusses on this draft: >>> >>> >>> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/b >>> allot/ >>> >>> Could you please look at the new revision Tiru has put together and let >>> him know if you are happy with it? >>> >>> Thanks, >>> >>> Gonzalo >>> >>> On 28/02/2015 5:10 AM, Tirumaleswar Reddy (tireddy) wrote: >>>> We have responded to comments from ISEG and published updated draft. >>>> >>>> -Tiru >>>> >>>>> -----Original Message----- >>>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>>> Sent: Thursday, February 26, 2015 10:26 AM >>>>> To: tram-chairs@ietf.org; tram@ietf.org; >>>>> draft-ietf-tram-turn-third-party- >>>>> authz@ietf.org; gonzalo.camarillo@ericsson.com; >>>>> draft-ietf-tram-turn-third- >>>>> party-authz.ad@ietf.org; draft-ietf-tram-turn-third-party- >>>>> authz.shepherd@ietf.org; spencerdawkins.ietf@gmail.com; rlb@ipv.sx; >>>>> stephen.farrell@cs.tcd.ie >>>>> Subject: New Version Notification - >>>>> draft-ietf-tram-turn-third-party-authz- >>>>> 13.txt >>>>> >>>>> >>>>> A new version (-13) has been submitted for >>>>> draft-ietf-tram-turn-third-party- >>>>> authz: >>>>> >>>>> http://www.ietf.org/internet-drafts/draft-ietf-tram-turn-third-party-au >>>>> thz- >>>>> 13.txt >>>>> >>>>> Sub state has been changed to AD Followup from Revised ID Needed >>>>> >>>>> >>>>> The IETF datatracker page for this Internet-Draft is: >>>>> >>>>> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz >>>>> / >>>>> >>>>> Diff from previous version: >>>>> >>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-third-party-authz >>>>> -13 >>>>> >>>>> 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. >>>>> >>>>> IETF Secretariat. >>>> >>> > From nobody Sat Mar 7 02:06:25 2015 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 836361A8A90; Sat, 7 Mar 2015 02:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLzisxxgfkgj; Sat, 7 Mar 2015 02:05:07 -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 BFC811A8A89; Sat, 7 Mar 2015 02:05:05 -0800 (PST) X-AuditID: c1b4fb2d-f79aa6d00000359d-25-54facd4fcf31 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 52.96.13725.F4DCAF45; Sat, 7 Mar 2015 11:05:03 +0100 (CET) Received: from [131.160.126.7] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.3.210.2; Sat, 7 Mar 2015 11:05:02 +0100 Message-ID: <54FACD4E.8030706@ericsson.com> Date: Sat, 7 Mar 2015 12:05:02 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Prashanth Patil (praspati)" , Stephen Farrell , "Tirumaleswar Reddy (tireddy)" , "tram-chairs@ietf.org" , "tram@ietf.org" , "draft-ietf-tram-turn-third-party-authz@ietf.org" , "draft-ietf-tram-turn-third-party-authz.ad@ietf.org" , "draft-ietf-tram-turn-third-party-authz.shepherd@ietf.org" , "spencerdawkins.ietf@gmail.com" , "rlb@ipv.sx" , IESG References: <913383AAA69FF945B8F946018B75898A366AA244@xmb-rcd-x10.cisco.com> <54F98585.7070203@ericsson.com> <54F9CBDF.7010705@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+Jvja7/2V8hBtPvS1g8ntPPbrFr6wcm i/ZLT1gsZvyZyGzRvfMoo8XUPluLZVP2MFtM33uN3eLE7m2MFst/rmSz+LD2ApsDt8eU3xtZ PdZ2X2Xz2DnrLrvHkiU/mTwmb5zFEsAaxWWTkpqTWZZapG+XwJUx+80RtoKJlhXX9/SzNjA+ 0e1i5OSQEDCROHZuNSuELSZx4d56NhBbSOAIo8TNDZVdjFxA9ipGidftBxlBErwC2hJvbh0G auDgYBFQkViwNwokzCZgIbHl1n0WEFtUIEpi9vkHrBDlghInZz4Bi4sIbGWVeHqkEMQWFgiV ePHxFCvErrWMEtdnKYPYnAIGEnuuHAWrZwayjyyawwphy0s0b53NDFGvLbH8WQvLBEaBWUhW zELSMgtJywJG5lWMosWpxcW56UbGeqlFmcnFxfl5enmpJZsYgbFwcMtv3R2Mq187HmIU4GBU 4uH9sPBXiBBrYllxZe4hRmkOFiVxXjvjQyFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGEt1 zJJNV1s/EdQN3S18uLJye8UV71mHFpYEhd9cp1H3aIdswDWpFd+2fn+d8PeQ5TbbSVoP1OeU K+/97jFXxaL+u3Rn3xxTF7mlLt5XzjgFPXx07t0ihfnNF9albmVbuICjyEEh1dhwNqvfD85P dw/23i0/mBQ459Pp7cUZt7+u4zpTNFvSO12JpTgj0VCLuag4EQA2lF+/ZgIAAA== Archived-At: X-Mailman-Approved-At: Sat, 07 Mar 2015 02:06:23 -0800 Subject: Re: [tram] New Version Notification - draft-ietf-tram-turn-third-party-authz-13.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: Sat, 07 Mar 2015 10:05:09 -0000 Hi, I am adding the IESG list to the cc: so that everyone can follow these discussions. Cheers, Gonzalo On 06/03/2015 10:13 PM, Prashanth Patil (praspati) wrote: > Hi Stephen, > We did respond to your discussion points. In any case, responses pasted > below: > > (1) Making none of 4.1.x mandatory to implement will > result in a lack of interop. What is the developer > supposed to implement? Why is it ok to not say? (For > example, defining 4.1.1 and 4.1.2 simply so as to appear > "more secure" whilst really expecting 4.1.3 to be used, > but not saying so, would seem like a bad plan to me.) > > > Response> Sections 4.1.x are only meant to be examples of mechanisms that > could be potentially used. The authors don¹t have a preference of one over > the others, 4.1.2 (REST) could be something that can be recommended to be > implemented (easy to develop and provides algorithm agility). > > (2) What is the status of Appendix B? Am I supposed to > implement that? What does "Client could..." mean? > > > Response> Appendix B is only meant to be provide an illustration of > interaction between the WebRTC client and authorization server (WebRTC > server). Please note that the communication between the two is > proprietary, WebRTC does not mandate any signaling protocol. > > (3) In the secdir review [1] discussion, I see the authors > mention adding ECC, but I see nothing in the draft. I > don't believe that that discussion has really ended and > would like to continue it. Why is the WebRTC server not > simply signing something for the STUN server to verify? > https://www.ietf.org/mail-archive/web/secdir/current/msg05425.html > > > Response> We did have an offline discussion with Yaron Sheffer (who had > suggested ECC). ECDH-ES can be used to agree upon a symmetric key for > encrypting/decrypting the token and ECDSA to generate digital signature > for the token. But this would result in a symmetric key, just like the > approaches described in 4.1.1 and 4.1.2. We¹ve hence decided not to > include any details pertaining to ECC. > > > Intro: "impossible in web applications" isn't really > true in principle, but impossible in WebRTC as it uses JS > is true. > > Response> Yes. It is not possible for WebRTC as it uses JS. We¹ll correct > it. > > NEW: > "However, in web applications like WebRTC [I-D.ietf-rtcweb-overview] where > JavaScript uses the browser functionality to make real-time audio and/or > video calls, Web conferencing, and direct data transfer, ensuring this > secrecy is typically not possible." > > - 4.1.2 - which "two servers"? WebRTC can have more > servers than that. > > > Response> The STUN server and the AS. As far as the STUN server is > concerned, it only deals with the AS of interest for key establishment. > The AS could be the application server itself or could be a Key management > function syncing the keying material to the WebRTC servers. > > - 4.1.2 - now we're using TLS mutual auth? And how does > the TLS client know which CA to use that'll work with the > TLS server here? I don't think that'll scale will it? > > > Response> We presume the two parties involved know what CA to consider > when using the REST APIs ­ they would have to do this to trust each other. > Please note that the AS is allocating symmetric keys meant exclusively for > that STUN Server, so some level of co-ordination is already involved. > > - 4.1.3 - this looks like what the WG/authors really want, > would that be a fair statement? > > > Response> No. The ŒNote:¹ at the end of the section is probably > misleading, will update it. > > NEW: > "Note : The mechanism specified in Section 4.1.3 lacks encryption and HMAC > algorithm agility." > > - 9: Figure 2 should be way up at the top of the document > and not here > > > Response> In the previous versions it was in the top of the document but > moved down after comments received from the WG that WebRTC is only an > example usage of third party authorization. > > - 9: Why 5 seconds? > > > Response> STUN messages can be sent over UDP, 5 seconds is to accommodate > packet loss and RTO interval. > > > - Assuming the AS that can authorize the user shares a > secret with the STUN server chosen by the WebRTC server > seems very brittle. Why would that be true in general? > > > Response> The AS and WebRTC server are in the same administrative domain > of the application provider. The user never sends the session key learned > from the AS to the STUN server it only uses the session key to compute > message integrity of STUN request and to validate the message integrity of > the STUN response. The STUN server will only know the session key if it > can decrypt the token. > > > -Prashanth > > On 3/6/15, 7:46 AM, "Stephen Farrell" wrote: > >> >> Hey, >> >> #1 - nope, that version doesn't address things that I can see >> (and I've not seen a direct response to my discuss points that >> I recall) >> >> #2 - I sent an ask to the saag list just now, (attached) will >> let you know if I get offers. Please also ping me if you get >> any direct, just so's we don't cross streams. >> >> S. >> >> On 06/03/15 10:46, Gonzalo Camarillo wrote: >>> Stephen, Richard, >>> >>> you have discusses on this draft: >>> >>> >>> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/b >>> allot/ >>> >>> Could you please look at the new revision Tiru has put together and let >>> him know if you are happy with it? >>> >>> Thanks, >>> >>> Gonzalo >>> >>> On 28/02/2015 5:10 AM, Tirumaleswar Reddy (tireddy) wrote: >>>> We have responded to comments from ISEG and published updated draft. >>>> >>>> -Tiru >>>> >>>>> -----Original Message----- >>>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>>> Sent: Thursday, February 26, 2015 10:26 AM >>>>> To: tram-chairs@ietf.org; tram@ietf.org; >>>>> draft-ietf-tram-turn-third-party- >>>>> authz@ietf.org; gonzalo.camarillo@ericsson.com; >>>>> draft-ietf-tram-turn-third- >>>>> party-authz.ad@ietf.org; draft-ietf-tram-turn-third-party- >>>>> authz.shepherd@ietf.org; spencerdawkins.ietf@gmail.com; rlb@ipv.sx; >>>>> stephen.farrell@cs.tcd.ie >>>>> Subject: New Version Notification - >>>>> draft-ietf-tram-turn-third-party-authz- >>>>> 13.txt >>>>> >>>>> >>>>> A new version (-13) has been submitted for >>>>> draft-ietf-tram-turn-third-party- >>>>> authz: >>>>> >>>>> http://www.ietf.org/internet-drafts/draft-ietf-tram-turn-third-party-au >>>>> thz- >>>>> 13.txt >>>>> >>>>> Sub state has been changed to AD Followup from Revised ID Needed >>>>> >>>>> >>>>> The IETF datatracker page for this Internet-Draft is: >>>>> >>>>> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz >>>>> / >>>>> >>>>> Diff from previous version: >>>>> >>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-third-party-authz >>>>> -13 >>>>> >>>>> 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. >>>>> >>>>> IETF Secretariat. >>>> >>> > From nobody Sat Mar 7 02:06:26 2015 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 F3FB41A8A93; Sat, 7 Mar 2015 02:05:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXUi9OJ8Dbbl; Sat, 7 Mar 2015 02:05:22 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CCE81A8A91; Sat, 7 Mar 2015 02:05:21 -0800 (PST) X-AuditID: c1b4fb3a-f79036d000001e94-1b-54facd5fb702 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 1A.EC.07828.F5DCAF45; Sat, 7 Mar 2015 11:05:19 +0100 (CET) Received: from [131.160.126.7] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.3.210.2; Sat, 7 Mar 2015 11:05:18 +0100 Message-ID: <54FACD5E.4010205@ericsson.com> Date: Sat, 7 Mar 2015 12:05:18 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Stephen Farrell , "Prashanth Patil (praspati)" , "Tirumaleswar Reddy (tireddy)" , "tram-chairs@ietf.org" , "tram@ietf.org" , "draft-ietf-tram-turn-third-party-authz@ietf.org" , "draft-ietf-tram-turn-third-party-authz.ad@ietf.org" , "draft-ietf-tram-turn-third-party-authz.shepherd@ietf.org" , "spencerdawkins.ietf@gmail.com" , "rlb@ipv.sx" References: <913383AAA69FF945B8F946018B75898A366AA244@xmb-rcd-x10.cisco.com> <54F98585.7070203@ericsson.com> <54F9CBDF.7010705@cs.tcd.ie> <54FA1519.5040809@cs.tcd.ie> In-Reply-To: <54FA1519.5040809@cs.tcd.ie> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUyM+JvjW782V8hBs37tSwez+lnt9i19QOT RfulJywW3TuPMlpM7bO1WDZlD7PF9L3X2C1O7N7GaLH850o2iw9rL7A5cHlM+b2R1WNt91U2 j52z7rJ7LFnyk8lj8sZZLAGsUVw2Kak5mWWpRfp2CVwZy/6fZyzYZFPxfP4S9gbG2wZdjJwc EgImEg/etTNC2GISF+6tZwOxhQSOMEo82V/bxcgFZK9ilJg16xIzSIJXQFvicM9vVhCbRUBF YvvX62A2m4CFxJZb91lAbFGBKInZ5x+wQtQLSpyc+YQFZJCIwFxWib9LWplAEsICoRIvPp5i hdhwilFiwaM3YAlOAU2JluktQAkODmYge/0ufZAws4C8RPPW2cwQ12lLLH/WwjKBUWAWkh2z EDpmIelYwMi8ilG0OLW4ODfdyEgvtSgzubg4P08vL7VkEyMwBg5u+W21g/Hgc8dDjAIcjEo8 vB8X/goRYk0sK67MPcQozcGiJM5rZ3woREggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjqnJk qPnl8n2vf9/e9MUq6dCT4F/aLL922/Mt/cE+Ye2TJfoH97XwLXLj7hLi/X9+dcystidPqnJr dp4+s/7D863Xfr/awdR9+77hj3/iYi+nd207u93uSjd7xxTZy+aBi3hvJPa5dWcKn902RYbf Xs1ZJcFRUapX/bvrZWaJ8hrNMyY5cXPmKbEUZyQaajEXFScCAN8r4QFiAgAA Archived-At: X-Mailman-Approved-At: Sat, 07 Mar 2015 02:06:24 -0800 Subject: Re: [tram] New Version Notification - draft-ietf-tram-turn-third-party-authz-13.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: Sat, 07 Mar 2015 10:05:26 -0000 Hi Stephen, I just added the IESG list, as you suggested. Thanks, Gonzalo On 06/03/2015 10:59 PM, Stephen Farrell wrote: > > > On 06/03/15 20:13, Prashanth Patil (praspati) wrote: >> Hi Stephen, >> We did respond to your discussion points. > > Ah sorry - you omitted the IESG I guess, as with this and that was > where I looked. Can you respond cc'ing all? That way any other ADs > who may be interested also see the discussion. > > Ta, > S. > > In any case, responses pasted >> below: >> >> (1) Making none of 4.1.x mandatory to implement will >> result in a lack of interop. What is the developer >> supposed to implement? Why is it ok to not say? (For >> example, defining 4.1.1 and 4.1.2 simply so as to appear >> "more secure" whilst really expecting 4.1.3 to be used, >> but not saying so, would seem like a bad plan to me.) >> >> >> Response> Sections 4.1.x are only meant to be examples of mechanisms that >> could be potentially used. The authors don¹t have a preference of one over >> the others, 4.1.2 (REST) could be something that can be recommended to be >> implemented (easy to develop and provides algorithm agility). >> >> (2) What is the status of Appendix B? Am I supposed to >> implement that? What does "Client could..." mean? >> >> >> Response> Appendix B is only meant to be provide an illustration of >> interaction between the WebRTC client and authorization server (WebRTC >> server). Please note that the communication between the two is >> proprietary, WebRTC does not mandate any signaling protocol. >> >> (3) In the secdir review [1] discussion, I see the authors >> mention adding ECC, but I see nothing in the draft. I >> don't believe that that discussion has really ended and >> would like to continue it. Why is the WebRTC server not >> simply signing something for the STUN server to verify? >> https://www.ietf.org/mail-archive/web/secdir/current/msg05425.html >> >> >> Response> We did have an offline discussion with Yaron Sheffer (who had >> suggested ECC). ECDH-ES can be used to agree upon a symmetric key for >> encrypting/decrypting the token and ECDSA to generate digital signature >> for the token. But this would result in a symmetric key, just like the >> approaches described in 4.1.1 and 4.1.2. We¹ve hence decided not to >> include any details pertaining to ECC. >> >> >> Intro: "impossible in web applications" isn't really >> true in principle, but impossible in WebRTC as it uses JS >> is true. >> >> Response> Yes. It is not possible for WebRTC as it uses JS. We¹ll correct >> it. >> >> NEW: >> "However, in web applications like WebRTC [I-D.ietf-rtcweb-overview] where >> JavaScript uses the browser functionality to make real-time audio and/or >> video calls, Web conferencing, and direct data transfer, ensuring this >> secrecy is typically not possible." >> >> - 4.1.2 - which "two servers"? WebRTC can have more >> servers than that. >> >> >> Response> The STUN server and the AS. As far as the STUN server is >> concerned, it only deals with the AS of interest for key establishment. >> The AS could be the application server itself or could be a Key management >> function syncing the keying material to the WebRTC servers. >> >> - 4.1.2 - now we're using TLS mutual auth? And how does >> the TLS client know which CA to use that'll work with the >> TLS server here? I don't think that'll scale will it? >> >> >> Response> We presume the two parties involved know what CA to consider >> when using the REST APIs ­ they would have to do this to trust each other. >> Please note that the AS is allocating symmetric keys meant exclusively for >> that STUN Server, so some level of co-ordination is already involved. >> >> - 4.1.3 - this looks like what the WG/authors really want, >> would that be a fair statement? >> >> >> Response> No. The Å’Note:¹ at the end of the section is probably >> misleading, will update it. >> >> NEW: >> "Note : The mechanism specified in Section 4.1.3 lacks encryption and HMAC >> algorithm agility." >> >> - 9: Figure 2 should be way up at the top of the document >> and not here >> >> >> Response> In the previous versions it was in the top of the document but >> moved down after comments received from the WG that WebRTC is only an >> example usage of third party authorization. >> >> - 9: Why 5 seconds? >> >> >> Response> STUN messages can be sent over UDP, 5 seconds is to accommodate >> packet loss and RTO interval. >> >> >> - Assuming the AS that can authorize the user shares a >> secret with the STUN server chosen by the WebRTC server >> seems very brittle. Why would that be true in general? >> >> >> Response> The AS and WebRTC server are in the same administrative domain >> of the application provider. The user never sends the session key learned >> from the AS to the STUN server it only uses the session key to compute >> message integrity of STUN request and to validate the message integrity of >> the STUN response. The STUN server will only know the session key if it >> can decrypt the token. >> >> >> -Prashanth >> >> On 3/6/15, 7:46 AM, "Stephen Farrell" wrote: >> >>> >>> Hey, >>> >>> #1 - nope, that version doesn't address things that I can see >>> (and I've not seen a direct response to my discuss points that >>> I recall) >>> >>> #2 - I sent an ask to the saag list just now, (attached) will >>> let you know if I get offers. Please also ping me if you get >>> any direct, just so's we don't cross streams. >>> >>> S. >>> >>> On 06/03/15 10:46, Gonzalo Camarillo wrote: >>>> Stephen, Richard, >>>> >>>> you have discusses on this draft: >>>> >>>> >>>> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/b >>>> allot/ >>>> >>>> Could you please look at the new revision Tiru has put together and let >>>> him know if you are happy with it? >>>> >>>> Thanks, >>>> >>>> Gonzalo >>>> >>>> On 28/02/2015 5:10 AM, Tirumaleswar Reddy (tireddy) wrote: >>>>> We have responded to comments from ISEG and published updated draft. >>>>> >>>>> -Tiru >>>>> >>>>>> -----Original Message----- >>>>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>>>> Sent: Thursday, February 26, 2015 10:26 AM >>>>>> To: tram-chairs@ietf.org; tram@ietf.org; >>>>>> draft-ietf-tram-turn-third-party- >>>>>> authz@ietf.org; gonzalo.camarillo@ericsson.com; >>>>>> draft-ietf-tram-turn-third- >>>>>> party-authz.ad@ietf.org; draft-ietf-tram-turn-third-party- >>>>>> authz.shepherd@ietf.org; spencerdawkins.ietf@gmail.com; rlb@ipv.sx; >>>>>> stephen.farrell@cs.tcd.ie >>>>>> Subject: New Version Notification - >>>>>> draft-ietf-tram-turn-third-party-authz- >>>>>> 13.txt >>>>>> >>>>>> >>>>>> A new version (-13) has been submitted for >>>>>> draft-ietf-tram-turn-third-party- >>>>>> authz: >>>>>> >>>>>> http://www.ietf.org/internet-drafts/draft-ietf-tram-turn-third-party-au >>>>>> thz- >>>>>> 13.txt >>>>>> >>>>>> Sub state has been changed to AD Followup from Revised ID Needed >>>>>> >>>>>> >>>>>> The IETF datatracker page for this Internet-Draft is: >>>>>> >>>>>> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz >>>>>> / >>>>>> >>>>>> Diff from previous version: >>>>>> >>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-third-party-authz >>>>>> -13 >>>>>> >>>>>> 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. >>>>>> >>>>>> IETF Secretariat. >>>>> >>>> >> From nobody Sun Mar 8 06:44:05 2015 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 163B61A0318; Sat, 7 Mar 2015 11:54:41 -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 FU3P1XqfnqvA; Sat, 7 Mar 2015 11:54:38 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC6A81A033A; Sat, 7 Mar 2015 11:54:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 961FFBEC6; Sat, 7 Mar 2015 19:54:35 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QC_qQK39Kch8; Sat, 7 Mar 2015 19:54:33 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.42.19.237]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EBF9CBE7D; Sat, 7 Mar 2015 19:54:32 +0000 (GMT) Message-ID: <54FB5778.2030405@cs.tcd.ie> Date: Sat, 07 Mar 2015 19:54:32 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Gonzalo Camarillo , "Prashanth Patil (praspati)" , "Tirumaleswar Reddy (tireddy)" , "tram-chairs@ietf.org" , "tram@ietf.org" , "draft-ietf-tram-turn-third-party-authz@ietf.org" , "draft-ietf-tram-turn-third-party-authz.ad@ietf.org" , "draft-ietf-tram-turn-third-party-authz.shepherd@ietf.org" , "spencerdawkins.ietf@gmail.com" , "rlb@ipv.sx" , IESG References: <913383AAA69FF945B8F946018B75898A366AA244@xmb-rcd-x10.cisco.com> <54F98585.7070203@ericsson.com> <54F9CBDF.7010705@cs.tcd.ie> <54FACD4E.8030706@ericsson.com> In-Reply-To: <54FACD4E.8030706@ericsson.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Sun, 08 Mar 2015 06:44:04 -0700 Subject: Re: [tram] New Version Notification - draft-ietf-tram-turn-third-party-authz-13.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: Sat, 07 Mar 2015 19:54:41 -0000 On 07/03/15 10:05, Gonzalo Camarillo wrote: > Hi, > > I am adding the IESG list to the cc: so that everyone can follow these > discussions. Thanks. And sorry for missing this and not responding before. > > Cheers, > > Gonzalo > > On 06/03/2015 10:13 PM, Prashanth Patil (praspati) wrote: >> Hi Stephen, >> We did respond to your discussion points. In any case, responses pasted >> below: >> >> (1) Making none of 4.1.x mandatory to implement will >> result in a lack of interop. What is the developer >> supposed to implement? Why is it ok to not say? (For >> example, defining 4.1.1 and 4.1.2 simply so as to appear >> "more secure" whilst really expecting 4.1.3 to be used, >> but not saying so, would seem like a bad plan to me.) >> >> >> Response> Sections 4.1.x are only meant to be examples of mechanisms that >> could be potentially used. The authors don¹t have a preference of one over >> the others, That's not going to get us interop though is it? And interop is needed here - we have the browser, the web-site and the TURN/STUN server all involved. I think you need one mechanism that is MTI and that is RECOMMENDED to use for this to be useful. >> 4.1.2 (REST) could be something that can be recommended to be >> implemented (easy to develop and provides algorithm agility). >> >> (2) What is the status of Appendix B? Am I supposed to >> implement that? What does "Client could..." mean? >> >> >> Response> Appendix B is only meant to be provide an illustration of >> interaction between the WebRTC client and authorization server (WebRTC >> server). The use of the AS term in WebRTC is unusual. Sufficiently so as to be a bad idea I think. (And one could wonder about who is the real resource owner in WebRTC - I don't think it's the web site that sets up the calls myself.) >> Please note that the communication between the two is >> proprietary, WebRTC does not mandate any signaling protocol. Hmm. I'm not sure I see the benefit of including that, if you're right above. >> >> (3) In the secdir review [1] discussion, I see the authors >> mention adding ECC, but I see nothing in the draft. I >> don't believe that that discussion has really ended and >> would like to continue it. Why is the WebRTC server not >> simply signing something for the STUN server to verify? >> https://www.ietf.org/mail-archive/web/secdir/current/msg05425.html >> >> >> Response> We did have an offline discussion with Yaron Sheffer (who had >> suggested ECC). ECDH-ES can be used to agree upon a symmetric key for >> encrypting/decrypting the token and ECDSA to generate digital signature >> for the token. But this would result in a symmetric key, just like the >> approaches described in 4.1.1 and 4.1.2. We¹ve hence decided not to >> include any details pertaining to ECC. ECDSA is a signature scheme. No symmetric key would be needed. So I'm not following your logic there tbh. At least at a high level, a signature scheme makes a lot of sense in this case. Cheers, S. PS: We can cover the comments below later, when the discuss points are sorted. >> >> >> Intro: "impossible in web applications" isn't really >> true in principle, but impossible in WebRTC as it uses JS >> is true. >> >> Response> Yes. It is not possible for WebRTC as it uses JS. We¹ll correct >> it. >> >> NEW: >> "However, in web applications like WebRTC [I-D.ietf-rtcweb-overview] where >> JavaScript uses the browser functionality to make real-time audio and/or >> video calls, Web conferencing, and direct data transfer, ensuring this >> secrecy is typically not possible." >> >> - 4.1.2 - which "two servers"? WebRTC can have more >> servers than that. >> >> >> Response> The STUN server and the AS. As far as the STUN server is >> concerned, it only deals with the AS of interest for key establishment. >> The AS could be the application server itself or could be a Key management >> function syncing the keying material to the WebRTC servers. >> >> - 4.1.2 - now we're using TLS mutual auth? And how does >> the TLS client know which CA to use that'll work with the >> TLS server here? I don't think that'll scale will it? >> >> >> Response> We presume the two parties involved know what CA to consider >> when using the REST APIs ­ they would have to do this to trust each other. >> Please note that the AS is allocating symmetric keys meant exclusively for >> that STUN Server, so some level of co-ordination is already involved. >> >> - 4.1.3 - this looks like what the WG/authors really want, >> would that be a fair statement? >> >> >> Response> No. The Å’Note:¹ at the end of the section is probably >> misleading, will update it. >> >> NEW: >> "Note : The mechanism specified in Section 4.1.3 lacks encryption and HMAC >> algorithm agility." >> >> - 9: Figure 2 should be way up at the top of the document >> and not here >> >> >> Response> In the previous versions it was in the top of the document but >> moved down after comments received from the WG that WebRTC is only an >> example usage of third party authorization. >> >> - 9: Why 5 seconds? >> >> >> Response> STUN messages can be sent over UDP, 5 seconds is to accommodate >> packet loss and RTO interval. >> >> >> - Assuming the AS that can authorize the user shares a >> secret with the STUN server chosen by the WebRTC server >> seems very brittle. Why would that be true in general? >> >> >> Response> The AS and WebRTC server are in the same administrative domain >> of the application provider. The user never sends the session key learned >> from the AS to the STUN server it only uses the session key to compute >> message integrity of STUN request and to validate the message integrity of >> the STUN response. The STUN server will only know the session key if it >> can decrypt the token. >> >> >> -Prashanth >> >> On 3/6/15, 7:46 AM, "Stephen Farrell" wrote: >> >>> >>> Hey, >>> >>> #1 - nope, that version doesn't address things that I can see >>> (and I've not seen a direct response to my discuss points that >>> I recall) >>> >>> #2 - I sent an ask to the saag list just now, (attached) will >>> let you know if I get offers. Please also ping me if you get >>> any direct, just so's we don't cross streams. >>> >>> S. >>> >>> On 06/03/15 10:46, Gonzalo Camarillo wrote: >>>> Stephen, Richard, >>>> >>>> you have discusses on this draft: >>>> >>>> >>>> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/b >>>> allot/ >>>> >>>> Could you please look at the new revision Tiru has put together and let >>>> him know if you are happy with it? >>>> >>>> Thanks, >>>> >>>> Gonzalo >>>> >>>> On 28/02/2015 5:10 AM, Tirumaleswar Reddy (tireddy) wrote: >>>>> We have responded to comments from ISEG and published updated draft. >>>>> >>>>> -Tiru >>>>> >>>>>> -----Original Message----- >>>>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>>>> Sent: Thursday, February 26, 2015 10:26 AM >>>>>> To: tram-chairs@ietf.org; tram@ietf.org; >>>>>> draft-ietf-tram-turn-third-party- >>>>>> authz@ietf.org; gonzalo.camarillo@ericsson.com; >>>>>> draft-ietf-tram-turn-third- >>>>>> party-authz.ad@ietf.org; draft-ietf-tram-turn-third-party- >>>>>> authz.shepherd@ietf.org; spencerdawkins.ietf@gmail.com; rlb@ipv.sx; >>>>>> stephen.farrell@cs.tcd.ie >>>>>> Subject: New Version Notification - >>>>>> draft-ietf-tram-turn-third-party-authz- >>>>>> 13.txt >>>>>> >>>>>> >>>>>> A new version (-13) has been submitted for >>>>>> draft-ietf-tram-turn-third-party- >>>>>> authz: >>>>>> >>>>>> http://www.ietf.org/internet-drafts/draft-ietf-tram-turn-third-party-au >>>>>> thz- >>>>>> 13.txt >>>>>> >>>>>> Sub state has been changed to AD Followup from Revised ID Needed >>>>>> >>>>>> >>>>>> The IETF datatracker page for this Internet-Draft is: >>>>>> >>>>>> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz >>>>>> / >>>>>> >>>>>> Diff from previous version: >>>>>> >>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-third-party-authz >>>>>> -13 >>>>>> >>>>>> 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. >>>>>> >>>>>> IETF Secretariat. >>>>> >>>> >> > From nobody Sun Mar 8 19:19:59 2015 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 19CD71A03A6 for ; Sun, 8 Mar 2015 19:19:58 -0700 (PDT) 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 DUHxlvHWHYrW for ; Sun, 8 Mar 2015 19:19:56 -0700 (PDT) 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 8DF4B1A026E for ; Sun, 8 Mar 2015 19:19:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2383; q=dns/txt; s=iport; t=1425867596; x=1427077196; h=from:to:subject:date:message-id:mime-version; bh=BMaoPlFgW9yn/IX3k06wpJ7PaeQHVhvlzEUPrYH2TBg=; b=RKVLvUsQwSo72XzfT8PPUneAxon1NPpT6Io/IwDdu0Xv5hw6Wb2Dndja 69NJh6s6HGpyB90C6Y1ZgfReHz2WAij1UgcihFCPuDoRqn919JhE7dtq3 J0K63vd/SyK4zuNa7Q0ME1aDZO1DSosN9ooYyGiBbWPsFuZZ6e2AKdGXW Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AbBgCqaeJU/5pdJa1bgkNDUloEwBKCLIVvgRpDAQEBAQEBfIQTbh0BDAFzJwSIQA2nU6ZVAQEBBwEBAQEBGQSPdYQ1BY84g1eFYJMNIoNubwEBgUJ/AQEB X-IronPort-AV: E=Sophos;i="5.11,365,1422921600"; d="scan'208,217";a="401698820" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 09 Mar 2015 02:19:56 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t292JttO003965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 9 Mar 2015 02:19:55 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.249]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Sun, 8 Mar 2015 21:19:55 -0500 From: "Prashanth Patil (praspati)" To: "tram@ietf.org" Thread-Topic: TURN Server Discovery - WG feedback Thread-Index: AQHQWg+IYQeR92ZcOUufdjH5Kt098w== Date: Mon, 9 Mar 2015 02:19:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.24.216.142] Content-Type: multipart/alternative; boundary="_000_D1225159340C1praspaticiscocom_" MIME-Version: 1.0 Archived-At: Subject: [tram] TURN Server Discovery - WG feedback 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, 09 Mar 2015 02:19:58 -0000 --_000_D1225159340C1praspaticiscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Folks, Based on some of the comments on the mailing list for https://tools.ietf.or= g/html/draft-ietf-tram-turn-server-discovery-01, we'd like feedback from th= e WG on the following: 1. Reverse PTR lookup on the client=92s public IP address to determine t= he domain-name (https://tools.ietf.org/html/draft-ietf-tram-turn-server-dis= covery-01#section-4.1.2) - Using RFC7216 to achieve this has dependencies o= n STUN server discovery, which is a concern. Given this, we=92re considerin= g removing sections pertaining to resolution using IP address (Sections 4.1= .2 & 4.2.1). 2. DNS Service Discovery - Is there interest in the WG to include this m= echanism in the draft? -Prashanth --_000_D1225159340C1praspaticiscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <6FF8BD5E53CAF446B4075E30676C0A28@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Folks,
Based on some of the comments on the mailing list for https= ://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-01, we'd l= ike feedback from the WG on the following:
  1. Reverse PTR lookup on the client=92s public IP address to determine the= domain-name (https://tools.ietf.org/html/draft-ietf-tr= am-turn-server-discovery-01#section-4.1.2) - Using RFC7216 to achieve this has dependencies on STUN server discovery,= which is a concern. Given this, we=92re considering removing sections pert= aining to resolution using IP address (Sections 4.1.2 & 4.2.1). 
  2. DNS Service Discovery - Is there interest in the WG to include this = mechanism in the draft?
-Prashanth
--_000_D1225159340C1praspaticiscocom_-- From nobody Sun Mar 8 20:47:09 2015 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 2E4BA1A1A3B for ; Sun, 8 Mar 2015 20:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 p8pMDXA5xb9D for ; Sun, 8 Mar 2015 20:47:06 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C08141A1A31 for ; Sun, 8 Mar 2015 20:47:06 -0700 (PDT) Received: by iecrl12 with SMTP id rl12so16872673iec.8 for ; Sun, 08 Mar 2015 20:47:06 -0700 (PDT) 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=4iHTOlhExy1nuF1sDwnhP5kmx7fGsmbqc0tJJK6Yb/A=; b=OmMRbcfE0cMvMZZ6JNQSobmI386n5y4UrivRnQGWai9aDSCK+/+A/PQ0n62fYXSD8j Ffeqp9U7KdBKwln21QA0P3LgAzKPf4IRmMakb147O0Mo09Q54tmdQ8FWeVPNXYK9qXJ1 EZbenlR33FhQg3ti/+Cmo0CC23z5LdqbKQcVwKlTpU+jRDWHBIe4Od/umqnZt9RH/2mY CVlrtfC1xG+GCtRkvu8lAyQCvalnpNXJJquxg5dzloNA5mEJ3blbROAEW9O3DlE8Gi8V FRPk4IaOHQySHatiXKT8zBsMCGJO35w7x/JhFZYvSX4Vg2NlSrVtlzrPHtEJR8AQPEbW S8Tg== 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=4iHTOlhExy1nuF1sDwnhP5kmx7fGsmbqc0tJJK6Yb/A=; b=c3Gk5Bvop0VuriVd/PePtnH2Q1IWaL/vcM7F8UX+Tu6NsXKFyNSX0P0VzKLVcXp4Nb iPqKGLN232sd+ZkFsnNlK6lWq5+jEhLM0mhIFswXw3DTvjyZ2Yt2mc9hWwMNrVC2cv78 y6IjubbJ1UVvLHfkQn9yS4MEnba60MvoK56ApTjXjAvQ3zt38kYUI19RL5sBWI17SWfS VCUHhNsxRmqvPV9zncUMnaaEDIFMFMLr52JBXxvawD2etrSkNgHVmc+2ehjBfqE0vNMX pGEAHMfWqA09geOIep2F3C2ZbvYbZzQzslQbIWwBo4mrXQJogBuIQCjmUzPWmBAf75d/ FdOg== X-Gm-Message-State: ALoCoQmV4nxqMIcs4WewmyrQeA4HUH8/s3f52KuwTLAGi5FPu7NpdIJ6G6EB7AqnbJ33HcnEeB4z X-Received: by 10.43.65.207 with SMTP id xn15mr23734515icb.60.1425872826094; Sun, 08 Mar 2015 20:47:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.64.42 with HTTP; Sun, 8 Mar 2015 20:46:45 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Sun, 8 Mar 2015 20:46:45 -0700 Message-ID: To: "Prashanth Patil (praspati)" Content-Type: multipart/alternative; boundary=bcaec51f97314b7f310510d2e37b Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] TURN Server Discovery - WG feedback 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, 09 Mar 2015 03:47:08 -0000 --bcaec51f97314b7f310510d2e37b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Mar 8, 2015 at 7:19 PM, Prashanth Patil (praspati) < praspati@cisco.com> wrote: > Hi Folks, > Based on some of the comments on the mailing list for > https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-01, > we'd like feedback from the WG on the following: > > 1. Reverse PTR lookup on the client=E2=80=99s public IP address to det= ermine > the domain-name ( > https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-01#s= ection-4.1.2) > - Using RFC7216 to achieve this has dependencies on STUN server discov= ery, > which is a concern. Given this, we=E2=80=99re considering removing sec= tions > pertaining to resolution using IP address (Sections 4.1.2 & 4.2.1). > > I think this would be a good simplification. --bcaec51f97314b7f310510d2e37b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Mar 8, 2015 at 7:19 PM, Prashanth Patil (praspati) <praspati@= cisco.com> wrote:
Hi Folks,
Based on some of the comments on the mailing list for=C2=A0https://tools.ietf.org/html/draft-ietf-tram-turn-server-discov= ery-01, we'd like feedback from the WG on the following:
  1. Reverse PTR lookup on the client=E2=80=99s public IP address to determi= ne the domain-name (https://tools.iet= f.org/html/draft-ietf-tram-turn-server-discovery-01#section-4.1.2) - Using RFC7216 to achieve this has dependencies on STUN server discovery,= which is a concern. Given this, we=E2=80=99re considering removing section= s pertaining to resolution using IP address (Sections 4.1.2 & 4.2.1).= =C2=A0
I think this would be a good = simplification.=C2=A0


--bcaec51f97314b7f310510d2e37b-- From nobody Sun Mar 8 21:54:37 2015 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 B22151A6EDE for ; Sun, 8 Mar 2015 21:54:36 -0700 (PDT) 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 2JcWsfzUEiAI for ; Sun, 8 Mar 2015 21:54:34 -0700 (PDT) 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 B40941A3BA5 for ; Sun, 8 Mar 2015 21:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6571; q=dns/txt; s=iport; t=1425876874; x=1427086474; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=3N2VvBKjdafx63rTlcqoNfjYE88jf05r4Bi5SEH+JDc=; b=Q5U2paLSPi5rwfnLYMZPu+MQZae948s43tprF13PPvNIBeEaml9+lyBw tT82tx1XTR3z75e6iFDNv/p3NGdY32wi1DaYSObpZZI5dZrx3WvWwH2qN QJh2Ckc0lIROg01rrIUdd7Nc/F38FJdg9j9MQ4RwlatJqwgxjcPCyQURa M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DKIgBOJv1U/5xdJa1agkNDUloEvEWDSII4hW4CgSRNAQEBAQEBfIQPAQEBBC1BGwIBCBEEAQELHQcyFAkIAgQBEgiIJw3DQgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEixeEPS0KAYMXgRYFkA+DZJljI4NubwEBgUJ/AQEB X-IronPort-AV: E=Sophos;i="5.11,365,1422921600"; d="scan'208,217";a="401914074" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 09 Mar 2015 04:54:34 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t294sXMC009008 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 9 Mar 2015 04:54:33 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Sun, 8 Mar 2015 23:54:33 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Prashanth Patil (praspati)" , "tram@ietf.org" Thread-Topic: TURN Server Discovery - WG feedback Thread-Index: AQHQWg+IYQeR92ZcOUufdjH5Kt09850Tkp9g Date: Mon, 9 Mar 2015 04:54:33 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A366B143B@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.41.238] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A366B143Bxmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Subject: Re: [tram] TURN Server Discovery - WG feedback 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, 09 Mar 2015 04:54:36 -0000 --_000_913383AAA69FF945B8F946018B75898A366B143Bxmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 to support DNS-SD; I am okay with removing [1] or make it optional to im= plement. -Tiru From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Prashanth Patil (pra= spati) Sent: Monday, March 09, 2015 7:50 AM To: tram@ietf.org Subject: [tram] TURN Server Discovery - WG feedback Hi Folks, Based on some of the comments on the mailing list for https://tools.ietf.or= g/html/draft-ietf-tram-turn-server-discovery-01, we'd like feedback from th= e WG on the following: 1. Reverse PTR lookup on the client's public IP address to determine the= domain-name (https://tools.ietf.org/html/draft-ietf-tram-turn-server-disco= very-01#section-4.1.2) - Using RFC7216 to achieve this has dependencies on = STUN server discovery, which is a concern. Given this, we're considering re= moving sections pertaining to resolution using IP address (Sections 4.1.2 &= 4.2.1). 2. DNS Service Discovery - Is there interest in the WG to include this m= echanism in the draft? -Prashanth --_000_913383AAA69FF945B8F946018B75898A366B143Bxmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1 to support DNS-SD;= I am okay with removing [1] or make it optional to implement.

 <= /p>

-Tiru

 <= /p>

From: tram [ma= ilto:tram-bounces@ietf.org] On Behalf Of Prashanth Patil (praspati)
Sent: Monday, March 09, 2015 7:50 AM
To: tram@ietf.org
Subject: [tram] TURN Server Discovery - WG feedback

 

Hi Folks,=

Based on some of the commen= ts on the mailing list for https://tools.ietf.org/html/draft-iet= f-tram-turn-server-discovery-01, we'd like feedback from the WG on the following:

  1. Reverse PTR lookup on the client’s public IP address to = determine the domain-name (https://tools.ietf.org/html/= draft-ietf-tram-turn-server-discovery-01#section-4.1.2) - Using RFC7216 to achieve this has dependencies on STUN server discovery,= which is a concern. Given this, we’re considering removing sections = pertaining to resolution using IP address (Sections 4.1.2 & 4.2.1).&nbs= p;
  2. DNS Service Discovery - Is there interest in the WG to include= this mechanism in the draft?

-Prashanth

--_000_913383AAA69FF945B8F946018B75898A366B143Bxmbrcdx10ciscoc_-- From nobody Mon Mar 9 02:06:23 2015 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 B4D4E1A8752 for ; Mon, 9 Mar 2015 02:06:21 -0700 (PDT) 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 wBvgiWkr5Iv9 for ; Mon, 9 Mar 2015 02:06:18 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 806CA1A8749 for ; Mon, 9 Mar 2015 02:06:18 -0700 (PDT) Received: from [IPv6:2602:43:2da:6400:7599:c947:217b:59e7] (unknown [IPv6:2602:43:2da:6400:7599:c947:217b:59e7]) (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 BE541203C1; Mon, 9 Mar 2015 10:06:16 +0100 (CET) Message-ID: <54FD6286.5040702@acm.org> Date: Mon, 09 Mar 2015 03:06:14 -0600 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , "tram@ietf.org" References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> <54E46D9C.3010507@acm.org> <913383AAA69FF945B8F946018B75898A366A73A5@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A366A73A5@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.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, 09 Mar 2015 09:06:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/24/2015 09:51 PM, Tirumaleswar Reddy (tireddy) wrote: > The cipher suites and other recommendations in http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-09 must be used and there is no need explicitly mention the subset in section 6.2.4 I read draft-ietf-uta-tls-bcp, and it is clear from its introduction that it is a set of advices for deployments and implementations, not a set of advices for new protocols, so I do not think that this is the right usage. I added an informative reference and made it clear that the advices in this draft should be followed by implementers and deployers, but I did not change section 6.2.4. > > -Tiru > >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Marc Petit- >> Huguenin >> Sent: Wednesday, February 18, 2015 4:17 PM >> To: tram@ietf.org >> Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.txt >> > All, > > We have requested 40 minutes in Dallas to discuss the modifications > summarized below. We plan to release -02 before the cutoff with minor > edits for the remaining of the TODO list, but we wanted to release a first > version with the most important modifications ahead of the meeting. We > may not have the time to answer every email before Dallas, but we will > collect the feedback and address it appropriately during the meeting. > > Thanks. > > Changelog: > > o Add negotiation mechanism for new password algorithms. > o Describe the MESSAGE-INTEGRITY/MESSAGE-INTEGRITY2 protocol. > o Add support for SCTP to solve the fragmentation problem. > o Merge RFC 7350: > * Split the "Sending over..." sections in 3. > * Add DTLS-over-UDP as transport. > * Update the cipher suites and cipher/compression restrictions. > * A stuns uri with an IP address is rejected. > * Replace most of the RFC 3489 compatibility by a reference to > the section in RFC 5389. > * Update the STUN Usages list with transport applicability. > o Merge RFC 7064: > * DNS discovery is done from the URI. > * Reorganized the text about default ports. > o Add more C snippets. > o Make clear that the cached RTO is discarded only if there is no > new transactions for 10 minutes. > > On 02/17/2015 09:32 AM, internet-drafts@ietf.org wrote: >>>> >>>> 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 : Session Traversal Utilities for NAT (STUN) >>>> Authors : Marc Petit-Huguenin >>>> Gonzalo Salgueiro >>>> Jonathan Rosenberg >>>> Dan Wing >>>> Rohan Mahy >>>> Philip Matthews >>>> Filename : draft-ietf-tram-stunbis-01.txt >>>> Pages : 57 >>>> Date : 2015-02-17 >>>> >>>> Abstract: >>>> Session Traversal Utilities for NAT (STUN) is a protocol that serves >>>> as a tool for other protocols in dealing with Network Address >>>> Translator (NAT) traversal. It can be used by an endpoint to >>>> determine the IP address and port allocated to it by a NAT. It can >>>> also be used to check connectivity between two endpoints, and as a >>>> keep-alive protocol to maintain NAT bindings. STUN works with many >>>> existing NATs, and does not require any special behavior from them. >>>> >>>> STUN is not a NAT traversal solution by itself. Rather, it is a tool >>>> to be used in the context of a NAT traversal solution. >>>> >>>> This document obsoletes RFC 5389. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-tram-stunbis-01 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stunbis-01 >>>> >>>> >>>> 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/ >>>> > - -- 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 iQIcBAEBCAAGBQJU/WKGAAoJECnERZXWan7EZXMP/1By6x0gLfkzsrmoEMviezTx 4oFZk6O4ugZMcjINPQI7isZZZmFvNXKPJAUHgDnK6XTtg88G3EcIzqrgrXNGuBuj Il6ORUw5px6ey4mYyCz7ccSjIAiPHBjunDPP+AF5eVW/GymF97Clz3JchqZS2Go0 OaC2WPrv5beUm1EfYtypQLAacBOGbM94TL78PXQnnjgG5vrn0zgGMSzOmMmiQoKh OQxyKqktl9jSzfwqKNjDrCtVJcVw8Yf+nAB3okqH+nAjKyVckj6AVCRHHCUAEeh2 9H9zx9xrReAgOyZqvPBZUir7qmGPyS0V6DRcxW0qaT27anBRy/9U28iE20VaczBg Ctl2J5CNa90rnzN2NxqJFjZqPK4ejGMr6uWTCdbGhl35rEBDvXG2jNq9AzbHSGPd CXM5QK+6U+e180ldbDGPuG5/zYaNpXEphPiwjsmQtEiwcFcDGMHbunMMYfhOH5lZ 3gNEjkhxrHDVMeI26ALKJ7Jkmq8GHW4QECSUxk5AmpoC7hFrjbm3ZWwnvXyb7AI6 Ow/ZtyaWmy0hW+zjGUIOv28SAj6qvpKpkz0W5QNpsxHuqQ7ZanxDy0emdKIkp790 m7OUaoGs/H7IyUagTZsEQ2rUHXJMavEZ8sn7Cs4Ug70IRp0vniX4tiozU86VnyVI J4trYlZlfdQYrHRSQKR0 =Kd9R -----END PGP SIGNATURE----- From nobody Mon Mar 9 02:14:08 2015 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 852D11A8749 for ; Mon, 9 Mar 2015 02:14:07 -0700 (PDT) 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 VnZ1DKK1UR4f for ; Mon, 9 Mar 2015 02:14:06 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 170F61A873B for ; Mon, 9 Mar 2015 02:14:06 -0700 (PDT) Received: from [IPv6:2602:43:2da:6400:7599:c947:217b:59e7] (unknown [IPv6:2602:43:2da:6400:7599:c947:217b:59e7]) (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 701B7203C1; Mon, 9 Mar 2015 10:14:05 +0100 (CET) Message-ID: <54FD645B.9000905@acm.org> Date: Mon, 09 Mar 2015 03:14:03 -0600 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 To: Oleg Moskalenko References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> <54EF3616.4040704@acm.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.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, 09 Mar 2015 09:14:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/26/2015 09:56 AM, Oleg Moskalenko wrote: > On Thu, Feb 26, 2015 at 7:04 AM, Marc Petit-Huguenin wrote: > >>> There is a well-defined association between the hash length and the >>> algorithm. SHA-1 produce 20 bytes, SHA-256 produce 32 bytes, SHA-384 >>> produce 48 bytes and SHA-512 produce 64 bytes. Why we cannot use the >>> MESSAGE-INTEGRITY length to determine the algorithm that the peer is >>> using ? >> >> Does not work with SHA-3. >> > > If there is a requirement to support wide multiplicity of algorithms, > even SHA-3, then I see two clear choices: > > 1) Leave the algorithm negotiation to the out-of-bound communication > channel between the client and the server. They can negotiate what > kind of hash is used, and what is the size of the MESSAGE-INTEGRITY to > be. > 2) Implement a usual negotiation scheme, like in TLS. We can introduce > a new attribute that contains "algorithm ID" and optionally "algorithm > attribute(s)" (specific to algorithm). The client sends a number of > supported algorithm attributes to the server, server either rejects or > picks one and sends back authenticated response with the chosen > algorithm attribute. If no attribute is included in the client or > server message, that means default "SHA-1, 160 bits". If a variable > length hash algorithm chosen, then that's fine, the message recipient > will just use the MESSAGE-INTEGRITY attribute length (given they > already agree on a particular algorithm). > > I'd vote for the second approach. That way, we introduce no extra > round trips, we cover multiple algorithms (including the future ones), > and we have full backward compatibility. We do not vote here. You will have to build a consensus for your solution of choice, and as co-editor I will modify the draft to follow this consensus. As an individual, I support neither of the solutions you proposed for the following reasons: - - HMAC-SHA is not broken but going to HMAC-SHA256 is a cautious step I (reluctantly) agree with. - - Negotiation is more often used to decrease security than to increase it so let's not unless we have no choice (as for the password hash, that is broken). - - Adding negotiation means that short-term authentication may get an additional round-trip for each ICE's connectivity check. - - The solution proposed in the draft follows what the authors of RFC 5389 suggested in section 16.3. - -- 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 iQIcBAEBCAAGBQJU/WRbAAoJECnERZXWan7E3ogQAJ5PxXsSCF+vNe+RQDtcPC0Z oWEaZReKccpBpgZU/U/DVbPamemOXX0nKdOErr2kP2pkM4t/IFKMr1kF5muQ1ibi dp5XeT3oy8S/Vd06xczlvbeMyjm2PcTR3v9s4rpRoTpaf63uuGEufHA41Q3uHxvs KABOe9cBRdq1IhUerggpMXxoX77iQAyAUgG1ey2njYhKD8zhANnNiZngAI+U7VUL y7A7f1GUvjg9iP/YzdhRna38Z4iwEYIIUYMhTakMeXNSE77dEUe244qw5XS6ooxD 0QvL18KJeJ0LOHXEQQxxiepuCeX6EqyiUn97eE2yPXqitQMlVVTUtBSX9Tem5xPr 6sgv7rVk2iIu/vljFa0+XBGA65lO7JBFHr2Obt5jK8vn8bLHoYxroeOJHmtTQHH2 hWMhpzYNvWF5NVMK+3ZpwgO++vVt8jHflMidMUyqBJie7wF6DWPhP2glEHBFedmp 5MSxj65pBvZfoEubDF7Q0G68876pfVMgED1QEWoN9S670wI+9wf4OFF1FXttqE/e wNlmgOjiLNUktzRGYU24HZhh8BmuB1yzN4aOKjjfWLShdJRW5ZtkxU06mj4XrUEF sF/i6aLLRKSWituScQ0wi9JSfYWTmf4j10dIonaxX51HIHYxY3LxR00RABQcDLYt jvYsSoBxbWjQ3T+Wecty =ZVh2 -----END PGP SIGNATURE----- From nobody Mon Mar 9 05:10:29 2015 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 56F821A8822 for ; Mon, 9 Mar 2015 05:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ll1rNfbmWaqu for ; Mon, 9 Mar 2015 05:10:26 -0700 (PDT) Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 930DE1A87C4 for ; Mon, 9 Mar 2015 05:10:22 -0700 (PDT) Received: by qgdq107 with SMTP id q107so27592286qgd.7 for ; Mon, 09 Mar 2015 05:10:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=W6A9ShhVNlBBpG9PPwxIar0lRxk57++hVzHq9aPx6XM=; b=ivWHMgm9Ir5fCJBW+ktNPgM6ayuEIK+r+QF+odMjnx7Vr0vZt4sRQzFNmbL0af2iw0 q8P/K2EHmKAazGIuRHPH9yGG72mbbAcX2YJmVcIfMqljOkRK3ceCJEkxfqkOJR7bl3AK BET+e+szi7slPVbDfxkipaBcDukeG74DX0tuEhOd6e/m9Fs2gRkiDFrehZrap3U3U/Qw mJ8RWLvCqvMltbiIjDWxMjE/UJBRhYpzoZUUixuuTwhxt6Iico9i9hdJi0J/vo+N9lJq ilX65GQd3M1webv3Uy9zXMjpUWh3cBrRsdbA8Q+6TY0d7g/dcqYfcYMZCckerYlquWGh 9Yhw== X-Gm-Message-State: ALoCoQl1V/GxfoElv5mWQ2BhxVte6B9u7Ui3PQ2EA5DX4bYsZI9108appJyXGNru6Iw+lC/TVGT6 X-Received: by 10.55.31.71 with SMTP id f68mr48815346qkf.7.1425903021857; Mon, 09 Mar 2015 05:10:21 -0700 (PDT) Received: from [192.168.1.43] (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id d186sm11399939qhc.3.2015.03.09.05.10.20 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2015 05:10:20 -0700 (PDT) Message-ID: <54FD8DAB.10807@jive.com> Date: Mon, 09 Mar 2015 08:10:19 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Justin Uberti References: <20150305201507.6192.13143.idtracker@ietfa.amsl.com> <35F68F75-51A0-48BD-B5D0-DE0A6600F13D@vidyo.com> <54FA2954.2060400@jive.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Jonathan Lennox , Benjamin Schwartz , "tram@ietf.org" Subject: Re: [tram] Fwd: New Version Notification for draft-schwartz-tram-turnbyname-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, 09 Mar 2015 12:10:28 -0000 Le 2015-03-06 19:34, Justin Uberti a écrit : > The problem is that the STUN timeout is on the client, whereas the DNS > timeout is on the server, so the client needs to somehow be aware of the > DNS timeout in its STUN calculations. Why? From the client's point of view, the server is just taking longer than usual to process the request. > Generally I think that we could just say that if DNS doesn't respond in > X seconds (e.g. 5), the server MUST consider the lookup to have failed > and return a 4YY error code. Why? Simon From nobody Mon Mar 9 05:22:47 2015 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 CE64C1A8879 for ; Mon, 9 Mar 2015 05:22:46 -0700 (PDT) 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 hJy8HnLG6RaY for ; Mon, 9 Mar 2015 05:22:43 -0700 (PDT) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E36C1A8863 for ; Mon, 9 Mar 2015 05:22:43 -0700 (PDT) Received: by qcvs11 with SMTP id s11so31891877qcv.7 for ; Mon, 09 Mar 2015 05:22:43 -0700 (PDT) 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=gyfpKEMOkkxr/QB2hegTVTiAgJlGUwqXQ8o54xy2Ig0=; b=Zjqh7RUiiP503xJCg7DSv++BSZvoxUHcOBacLEYvf2aB5/SSvlOFQzIcXjfwdsjMKH zW4hy2gGGk7GqmyqRoiLUUg4ORWu/S4O5IRktx1WCq2i6TScvtvxCDDSEUKD/BICuWP4 KFXTpiB4gfhjKP7XoHbv/mQ5U5xWUL/jnEDRXIkBibIi8CQooX4C0EjCtWpCiu+RaEuO iyc+/xfOB2Srl2xQQG7GErVcg6nHuSeUWgMG3iMs5/xtYAk5wCCgXlmdljHo3sBYs+L1 DW23Rgq1VC9sGS64ITaf90TI/KA3hQF1ou9+2VKVaPs1gOkF7BVzXXn6AW5h09DKWGyP gnyw== X-Gm-Message-State: ALoCoQnmq3dKiz8Zfezz/0jyMqGVKniVAPp8M8txrBIBjDVLIe9mWSBATdtRmuQLb0CqElVMlyKt X-Received: by 10.55.24.160 with SMTP id 32mr37049286qky.23.1425903762982; Mon, 09 Mar 2015 05:22:42 -0700 (PDT) Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com. [209.85.192.43]) by mx.google.com with ESMTPSA id 4sm9480188qkt.47.2015.03.09.05.22.41 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2015 05:22:42 -0700 (PDT) Received: by qgdz107 with SMTP id z107so27672716qgd.4 for ; Mon, 09 Mar 2015 05:22:41 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.232.142 with SMTP id d136mr12017423qhc.99.1425903761553; Mon, 09 Mar 2015 05:22:41 -0700 (PDT) Received: by 10.229.90.68 with HTTP; Mon, 9 Mar 2015 05:22:41 -0700 (PDT) In-Reply-To: References: <20150305201507.6192.13143.idtracker@ietfa.amsl.com> <35F68F75-51A0-48BD-B5D0-DE0A6600F13D@vidyo.com> Date: Mon, 9 Mar 2015 08:22:41 -0400 Message-ID: From: Benjamin Schwartz To: Justin Uberti Content-Type: multipart/alternative; boundary=001a113537c0312b9b0510da17f8 Archived-At: Cc: Jonathan Lennox , "tram@ietf.org" Subject: Re: [tram] Fwd: New Version Notification for draft-schwartz-tram-turnbyname-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, 09 Mar 2015 12:22:47 -0000 --001a113537c0312b9b0510da17f8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 6, 2015 at 7:32 PM, Justin Uberti wrote: > These are the timeouts for the TURN interaction, not the ICE checks. It's > over UDP, so the client has to do its own retry semantics, which means > retransmission of the CreatePermission/ChannelBind. > > If the server doesn't respond for 15 seconds, the client may think the > network or server has died. > Could we resolve this by recommending that clients use STUN binding requests as a heartbeat? > On Fri, Mar 6, 2015 at 2:30 PM, Benjamin Schwartz > wrote: > >> I don't understand. Why would these STUN timeouts apply before >> permission is granted, or before the channel is bound? It seems to me t= hat >> these timeouts refer to timers that start when you make the first outbou= nd >> request to a remote candidate, which is always after the success respons= e >> to CreatePermission or ChannelBind. >> >> On Fri, Mar 6, 2015 at 5:08 PM, Justin Uberti wrote= : >> >>> >>> >>> On Fri, Mar 6, 2015 at 12:53 PM, Benjamin Schwartz >>> wrote: >>> >>>> On Fri, Mar 6, 2015 at 2:51 PM, Jonathan Lennox >>>> wrote: >>>> >>>>> >>>>> >>>>> On Mar 5, 2015, at 3:17 PM, Benjamin Schwartz >>>>> wrote: >>>>> >>>>> > Hi TRAM, >>>>> > >>>>> > I've just written up a proposal for an optional extension to TURN >>>>> that would add support for DNS names. I'd like to discuss this at th= e >>>>> upcoming meeting. >>>>> > >>>>> > Let me know what you think! >>>>> >>>>> What happens if DNS resolution is slow? As far as I can tell the TUR= N >>>>> server can=E2=80=99t respond to the ChannelBind or CreatePermission r= equest until >>>>> DNS completes (or fails), and I vaguely think (though I don=E2=80=99t= remember >>>>> exact numbers) that STUN transactions will time out faster than DNS o= nes >>>>> will. >>>>> >>>> >>>> You're right; if the client sends a DNS-name CreatePermission or >>>> ChannelBind, the server can't send a success reply until DNS completes >>>> successfully. However, I don't share your intuition. I'm not familia= r >>>> with DNS timeouts, but for example, this page [ >>>> http://support.microsoft.com/kb/2834226] claims that Microsoft's DNS >>>> resolution times out after 10 seconds. I'm not aware of any official, >>>> standardized STUN timeout that applies before the first packet has bee= n >>>> received, but in practice implementations seem to allow for at least 3= 0 >>>> seconds of delay after signaling is complete. >>>> >>> >>> The algorithm in https://tools.ietf.org/html/rfc5389#section-7.2.1 >>> defines the STUN timeouts. As in, if the client sends channel-bind and = gets >>> no response, it will retransmit several times before giving up, at defi= ned >>> intervals. Typically this is 5-10 seconds, but it depends on RTO; for a= < >>> 50 ms RTO, the timeout could be ~5 s, i.e. shorter than the DNS timeout= . >>> >>> Typically I think this case will be encountered when the hostname is >>> invalid; in these cases, the permission/bind will simply be treated as = an >>> error by the client, and that particular candidate pair will fail, with= no >>> impact on other pairs. >>> >>> >>>> >>>>> The draft should also discuss its operation with TURN-TCP. As far as >>>>> I can tell it=E2=80=99s straightforward, and easier than TURN-UDP, bu= t it=E2=80=99s worth >>>>> discussing it. >>>> >>>> >>>> I agree that the extension to TURN-TCP is straightforward, but I'd lik= e >>>> to see if we have rough consensus on this approach for UDP first. >>>> >>>> _______________________________________________ >>>> tram mailing list >>>> tram@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tram >>>> >>>> >>> >> > --001a113537c0312b9b0510da17f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Mar 6, 2015 at 7:32 PM, Justin Uberti <juberti@google.com> wrote:
These are the timeouts for = the TURN interaction, not the ICE checks. It's over UDP, so the client = has to do its own retry semantics, which means retransmission of the Create= Permission/ChannelBind.

If the server doesn't respon= d for 15 seconds, the client may think the network or server has died.

Could we resolve this by recommendi= ng that clients use STUN binding requests as a heartbeat?
=C2= =A0
On Fri, Mar 6, 2015 at 2:30 PM, Benj= amin Schwartz <bemasc@webrtc.org> wrote:
I don't understand.=C2=A0 Why would these STUN timeou= ts apply before permission is granted, or before the channel is bound?=C2= =A0 It seems to me that these timeouts refer to timers that start when you = make the first outbound request to a remote candidate, which is always afte= r the success response to CreatePermission or ChannelBind.
<= div class=3D"gmail_extra">
On Fri, Mar 6, 201= 5 at 5:08 PM, Justin Uberti <juberti@google.com> wrote:
=


On Fri, Mar 6, 2015 at 12:53 PM, Benjamin Schwar= tz <bemasc@webrtc.org> wrote:
On Fri= , Mar 6, 2015 at 2:51 PM, Jonathan Lennox <jonathan@vidyo.com> wrote:


On Mar 5, 2015, at 3:17 PM, Benjamin Schwartz <bemasc@webrtc.org> wrote:

> Hi TRAM,
>
> I've just written up a proposal for an optional extension to TURN = that would add support for DNS names.=C2=A0 I'd like to discuss this at= the upcoming meeting.
>
> Let me know what you think!

What happens if DNS resolution is slow?=C2=A0 As far as I can tell t= he TURN server can=E2=80=99t respond to the ChannelBind or CreatePermission= request until DNS completes (or fails), and I vaguely think (though I don= =E2=80=99t remember exact numbers) that STUN transactions will time out fas= ter than DNS ones will.

You're ri= ght; if the client sends a DNS-name CreatePermission or ChannelBind, the se= rver can't send a success reply until DNS completes successfully.=C2=A0= However, I don't share your intuition.=C2=A0 I'm not familiar with= DNS timeouts, but for example, this page [http://support.microsoft.com/kb/28342= 26] claims that Microsoft's DNS resolution times out after 10 secon= ds.=C2=A0 I'm not aware of any official, standardized STUN timeout that= applies before the first packet has been received, but in practice impleme= ntations seem to allow for at least 30 seconds of delay after signaling is = complete.

The algo= rithm in https://tools.ietf.org/html/rfc5389#section-7.2.1 defines= the STUN timeouts. As in, if the client sends channel-bind and gets no res= ponse, it will retransmit several times before giving up, at defined interv= als. Typically this is 5-10 seconds, but it depends on RTO; for a < 50 m= s RTO, the timeout could be ~5 s, i.e. shorter than the DNS timeout.
<= div>
Typically I think this case will be encountered when the= hostname is invalid; in these cases, the permission/bind will simply be tr= eated as an error by the client, and that particular candidate pair will fa= il, with no impact on other pairs.

<= span>
=C2=A0
The draft should also discuss its operation with TURN-TCP.=C2=A0 As far as = I can tell it=E2=80=99s straightforward, and easier than TURN-UDP, but it= =E2=80=99s worth discussing it.

I ag= ree that the extension to TURN-TCP is straightforward, but I'd like to = see if we have rough consensus on this approach for UDP first.
<= /div>

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





--001a113537c0312b9b0510da17f8-- From nobody Mon Mar 9 05:33:21 2015 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 364C81A7034 for ; Mon, 9 Mar 2015 05:33:19 -0700 (PDT) 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 IJHConRazAap for ; Mon, 9 Mar 2015 05:33:15 -0700 (PDT) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6ACF1A887C for ; Mon, 9 Mar 2015 05:33:13 -0700 (PDT) Received: by qcwr17 with SMTP id r17so13898526qcw.2 for ; Mon, 09 Mar 2015 05:33:13 -0700 (PDT) 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=ab+eKPHeCizqqdiXh4++3buR5bt4UTNSZWcWCcMBtqA=; b=KVeZv6KMGwerKR/Gmqs49pRcfnUTw+xNypqcubLks2RJnsuhzSdsZmt1uxAn/C3IZO YgvFLV2RLeQtAUKzsQMj/4KI0KxLs+Syd7qF3g3ue1KrWu+zYsFb5LcsYMcWuu/dIcQi pejdEHAG1MdNs2swHNWRXCLj4qtE3CM/xFbCUy7OofZY8Yp53pK6iA8DNAgUi1DaJI4P f129EXldD4wLhYh8vIgOeAKEPBM3BS2fLUgWRJSon/xvd0OjoBi5X+jW39JyfbwALKNs 4pxnvo61ERTNia//2EfJjK704Ut65kl9U6D5jkE2KSYS+JX5E8qK9zH5TA/crVL8Fq4/ 6DRQ== X-Gm-Message-State: ALoCoQmMIH/+9Xxdhj5o4nowEBtOaULdYrqtVINgnttkkwSeCRpD/pWidJpvbsdaS0jufe4mpafa X-Received: by 10.55.16.83 with SMTP id a80mr42406644qkh.86.1425904393183; Mon, 09 Mar 2015 05:33:13 -0700 (PDT) Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com. [209.85.192.43]) by mx.google.com with ESMTPSA id n19sm11429808qhb.12.2015.03.09.05.33.12 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2015 05:33:12 -0700 (PDT) Received: by qgea108 with SMTP id a108so27702897qge.8 for ; Mon, 09 Mar 2015 05:33:12 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.55.21.40 with SMTP id f40mr31101436qkh.96.1425904392301; Mon, 09 Mar 2015 05:33:12 -0700 (PDT) Received: by 10.229.90.68 with HTTP; Mon, 9 Mar 2015 05:33:12 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A366B0BA6@xmb-rcd-x10.cisco.com> References: <20150305201507.6192.13143.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A366B0BA6@xmb-rcd-x10.cisco.com> Date: Mon, 9 Mar 2015 08:33:12 -0400 Message-ID: From: Benjamin Schwartz To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=001a1147d3eac994680510da3cf1 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Fwd: New Version Notification for draft-schwartz-tram-turnbyname-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, 09 Mar 2015 12:33:19 -0000 --001a1147d3eac994680510da3cf1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the TLS for DNS reference. I wasn't aware of that work. I think these efforts are complementary. TLS for DNS improves the privacy of connections to a cooperative, correctly functioning DNS server. TURN by name helps the user to perform name lookups when their DNS server is unavailable, uncooperative, or restricted. On Fri, Mar 6, 2015 at 9:44 PM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > The work in DPRIVE WG (http://tools.ietf.org/html/draft-hzhwm-dprive-sta= rt-tls-for-dns-01) can also help address the problem discussed in this draf= t when the client uses DNS-over-TLS and contacts both the DNS servers on th= e local network and on the Internet (OpenDNS, Google etc.). > > > > It will be good to compare the mechanism in this draft with the work goin= g on in the above WG. > > > > -Tiru > > > > *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Benjamin > Schwartz > *Sent:* Friday, March 06, 2015 1:48 AM > *To:* tram@ietf.org > *Subject:* [tram] Fwd: New Version Notification for > draft-schwartz-tram-turnbyname-00.txt > > > > Hi TRAM, > > > > I've just written up a proposal for an optional extension to TURN that > would add support for DNS names. I'd like to discuss this at the upcomin= g > meeting. > > > > Let me know what you think! > > > > Thanks, > > Ben > > > > ---------- Forwarded message ---------- > From: > Date: Thu, Mar 5, 2015 at 3:15 PM > Subject: New Version Notification for draft-schwartz-tram-turnbyname-00.t= xt > To: Justin Uberti , "Benjamin M. Schwartz" < > bemasc@webrtc.org> > > > > A new version of I-D, draft-schwartz-tram-turnbyname-00.txt > has been successfully submitted by Benjamin M. Schwartz and posted to the > IETF repository. > > Name: draft-schwartz-tram-turnbyname > Revision: 00 > Title: TURN by name: an extension to TURN for contacting an > endpoint by its DNS name. > Document date: 2015-03-05 > Group: Individual Submission > Pages: 15 > URL: > http://www.ietf.org/internet-drafts/draft-schwartz-tram-turnbyname-00.txt > Status: > https://datatracker.ietf.org/doc/draft-schwartz-tram-turnbyname/ > Htmlized: > http://tools.ietf.org/html/draft-schwartz-tram-turnbyname-00 > > > Abstract: > When tunneling traffic through TURN, a client may sometimes desire to > contact a remote endpoint that it knows by its DNS name, not its IP > address. This document describes an extension to TURN that allows > such a client to contact a named endpoint. > > > > > 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 > > > --001a1147d3eac994680510da3cf1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the TLS for DNS reference.=C2=A0 I wasn't a= ware of that work.

I think these efforts are complementa= ry.=C2=A0 TLS for DNS improves the privacy of connections to a cooperative,= correctly functioning DNS server.=C2=A0 TURN by name helps the user to per= form name lookups when their DNS server is unavailable, uncooperative, or r= estricted.

On Fri, Mar 6, 2015 at 9:44 PM, Tirumaleswar Reddy (tireddy) <tireddy= @cisco.com> wrote:
The work in DPRIVE WG (http://tools.ietf.org/html/draft-hzhwm-dprive-start-tls-for-dns-01) c=
an also help address the problem discussed in this draft when the client us=
es DNS-over-TLS and contacts both the DNS servers on the local network and =
on the Internet (OpenDNS, Google etc.).
=C2=A0
It will be good to compare the mechanism in=
 this draft with the work going on in the above WG.

=C2=A0


-Tiru


=C2=A0








From: tram [ma=
ilto:tram-bounce=
s@ietf.org]
On Behalf Of Benjamin Schwartz

Sent: Friday, March 06, 2015 1:48 AM

To: tram@ietf.org=


Subject: [tram] Fwd: New Version Notification for draft-schwartz-tra=
m-turnbyname-00.txt






=C2=A0






Hi TRAM,






=C2=A0






I've just written up a proposal for an optional =
extension to TURN that would add support for DNS names.=C2=A0 I'd like =
to discuss this at the upcoming meeting.






=C2=A0






Let me know what you think!






=C2=A0






Thanks,






Ben




=C2=A0




---------- Forwarded =
message ----------

From: <int=
ernet-drafts@ietf.org>

Date: Thu, Mar 5, 2015 at 3:15 PM

Subject: New Version Notification for draft-schwartz-tram-turnbyname-00.txt=


To: Justin Uberti <justin@uberti.name>, "Benjamin M. Schwartz" <bemasc@webrtc.org>






A new version of I-D, draft-schwartz-tram-turnbyname-00.txt

has been successfully submitted by Benjamin M. Schwartz and posted to the
IETF repository.



Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-schwartz-tram-turnbynam=
e

Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000

Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TURN by name: an extension to TURN=
 for contacting an endpoint by its DNS name.

Document date:=C2=A0 2015-03-05

Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission

Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 15

URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 
http://www.ietf.org/internet-drafts/draft-schwartz-tram-turnbyname-00.txt

Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatr=
acker.ietf.org/doc/draft-schwartz-tram-turnbyname/

Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/h=
tml/draft-schwartz-tram-turnbyname-00





Abstract:

=C2=A0 =C2=A0When tunneling traffic through TURN, a client may sometimes de=
sire to

=C2=A0 =C2=A0contact a remote endpoint that it knows by its DNS name, not i=
ts IP

=C2=A0 =C2=A0address.=C2=A0 This document describes an extension to TURN th=
at allows

=C2=A0 =C2=A0such a client to contact a named endpoint.









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




=C2=A0

--001a1147d3eac994680510da3cf1-- From nobody Mon Mar 9 05:44:23 2015 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 CFD591A88C0 for ; Mon, 9 Mar 2015 05:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 doyX0S2yN10e for ; Mon, 9 Mar 2015 05:44:21 -0700 (PDT) Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D3031A7034 for ; Mon, 9 Mar 2015 05:44:21 -0700 (PDT) Received: by qgdz107 with SMTP id z107so27816577qgd.3 for ; Mon, 09 Mar 2015 05:44:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=V2sgZApqAIJPqpc1QU1y4lXRhMZ7v2rsQVK9du3Maiw=; b=h3DeC8U8Pq1FUlE6jTipVn01KTED9vOmVbvsw6iW6zUd6tRhdD3H3vGjSzCl9kMmP4 Y81d4f3kMj3sJ2TZIAzNv4XKqoyM+AfBv9gmKAt2M1ZUWegy/cqgZ1Ew9cQ4PXPdE3HK 2Iwppjo79Uiwr2tcFTJvhr+olblXXlUVqoTp/zP4f1PfuYzWfUtohKfjWk9X98STdhvb grvaVrtZvYA1eFKKDH2RYcUdM3wEavDntxZJ0UXgsST5WTb91QCQh7XQMikZhj5Jvlff FsCGsBZfLwhzOlx7SClCCsiG8pozcLZ3KP9uY/uhQqBEMLIRESYaaRv197z524tT7N9G 3hhg== X-Gm-Message-State: ALoCoQkfZc9+3RPtq05/oilnh22STLFNycE7BtOpwU9mCDwZtYuHdRQ6eDeGl33m8W7RDG+qmTVX X-Received: by 10.55.49.207 with SMTP id x198mr54262505qkx.49.1425905060570; Mon, 09 Mar 2015 05:44:20 -0700 (PDT) Received: from [192.168.1.43] (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id n77sm11444852qha.19.2015.03.09.05.44.19 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2015 05:44:19 -0700 (PDT) Message-ID: <54FD95A2.2040407@jive.com> Date: Mon, 09 Mar 2015 08:44:18 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Prashanth Patil (praspati)" , "tram@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tram] TURN Server Discovery - WG feedback 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, 09 Mar 2015 12:44:23 -0000 Le 2015-03-08 22:19, Prashanth Patil (praspati) a écrit : > 1. Reverse PTR lookup on the client’s public IP address to determine > the domain-name > (https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-01#section-4.1.2) > - Using RFC7216 to achieve this has dependencies on STUN server > discovery, which is a concern. Given this, we’re considering > removing sections pertaining to resolution using IP address > (Sections 4.1.2 & 4.2.1). I'm OK with removing this based on Adam's comments, but I truly don't understand the rationale above. > 2. DNS Service Discovery - Is there interest in the WG to include this > mechanism in the draft? I say if Adam thinks this can work, let's give it a shot. Simon From nobody Mon Mar 9 06:55:17 2015 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 BA7FE1A8919 for ; Mon, 9 Mar 2015 06:55:15 -0700 (PDT) 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 y_RW_r0FpRE4 for ; Mon, 9 Mar 2015 06:55:13 -0700 (PDT) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58B311A895B for ; Mon, 9 Mar 2015 06:51:45 -0700 (PDT) Received: by qgdz107 with SMTP id z107so28349838qgd.3 for ; Mon, 09 Mar 2015 06:51:44 -0700 (PDT) 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=s68f3jtVg3ik1059qTr3SGFYUG2tWdeESztY6noYQRw=; b=EXWzxXgMjex9+C4zq4QXFkWRaOpINnYWMcbHVnCXcbx5qAajoYRMM+dzlgyhQqDH52 CK0vrL2BTWpUJnn+fpLEQl9H8UC3Wgt58DTIqQxj4PNdtdYkEXLiLRf4O+zfEz3yJCU7 E6Z8wwtPHS+qiF4rvELjtK6Nsc2YBVV8aijxOjiA84SZy4rMrAEoZthxlQxZhmAZll82 OLHkU2kBaxSvIEFUnXK3jOJHu2SgLSlGlJF6kYvr9nGUjP+mbUaHvOespkq5sOeDSEkg YG44OgJMDrJbh48sV5LD33TeG33cODPxqWR1NAFiZKDucGKQk5aXg1fEOkF73TgcNsbr s5kA== X-Gm-Message-State: ALoCoQlk3elppxZ6IGLp8LKvUKkfGiarR7K0XgQ0eiheujSNUVnbTLNS6dLI+8vCLCDREMONPjzs X-Received: by 10.140.237.6 with SMTP id i6mr36518712qhc.32.1425909104006; Mon, 09 Mar 2015 06:51:44 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com. [209.85.216.170]) by mx.google.com with ESMTPSA id i16sm6837197qkh.5.2015.03.09.06.51.43 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2015 06:51:43 -0700 (PDT) Received: by qcvp6 with SMTP id p6so22819657qcv.1 for ; Mon, 09 Mar 2015 06:51:43 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.238.87 with SMTP id j84mr36396821qhc.78.1425909102973; Mon, 09 Mar 2015 06:51:42 -0700 (PDT) Received: by 10.229.90.68 with HTTP; Mon, 9 Mar 2015 06:51:42 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A366B0BD3@xmb-rcd-x10.cisco.com> References: <20150305201507.6192.13143.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A366B0BD3@xmb-rcd-x10.cisco.com> Date: Mon, 9 Mar 2015 09:51:42 -0400 Message-ID: From: Benjamin Schwartz To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=001a1135c8b890b7350510db5561 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Fwd: New Version Notification for draft-schwartz-tram-turnbyname-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, 09 Mar 2015 13:55:15 -0000 --001a1135c8b890b7350510db5561 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 6, 2015 at 10:00 PM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > On some restricted networks, DNS access is also restricted, which may > > prevent users from determining the IP address of a domain (e.g. an > > application-specified TURN server, for RETURN > > [I-D.schwartz-rtcweb-return > ], > or an ICE candidate that contains a > > domain name) that they wish to contact through the escape-hatch TURN > > server. > > > > Comment> FW in such restricted network may use various mechanisms like > function as HTTPS proxy, protocol identification of encrypted content via > statistical analysis to identify and block applications etc. > > How will this technique work in such restricted networks ? > When I describe "escape hatches" in restricted networks, I am principally referring to situations where the network administrator (who is applying the restrictions) also deliberately creates such an escape hatch, which is only available to certain authorized users. "TURN by name" allows the network administrator to enable these users to access the whole public network, on networks where unauthorized users have restricted DNS access. More broadly, "TURN by name" parallels SOCKS-5 or HTTP CONNECT proxies for UDP applications (such as WebRTC), so I expect it can be used to extend most proxy systems to support WebRTC. > > -Tiru > > > > *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Benjamin > Schwartz > *Sent:* Friday, March 06, 2015 1:48 AM > *To:* tram@ietf.org > *Subject:* [tram] Fwd: New Version Notification for > draft-schwartz-tram-turnbyname-00.txt > > > > Hi TRAM, > > > > I've just written up a proposal for an optional extension to TURN that > would add support for DNS names. I'd like to discuss this at the upcoming > meeting. > > > > Let me know what you think! > > > > Thanks, > > Ben > > > > ---------- Forwarded message ---------- > From: > Date: Thu, Mar 5, 2015 at 3:15 PM > Subject: New Version Notification for draft-schwartz-tram-turnbyname-00.txt > To: Justin Uberti , "Benjamin M. Schwartz" < > bemasc@webrtc.org> > > > > A new version of I-D, draft-schwartz-tram-turnbyname-00.txt > has been successfully submitted by Benjamin M. Schwartz and posted to the > IETF repository. > > Name: draft-schwartz-tram-turnbyname > Revision: 00 > Title: TURN by name: an extension to TURN for contacting an > endpoint by its DNS name. > Document date: 2015-03-05 > Group: Individual Submission > Pages: 15 > URL: > http://www.ietf.org/internet-drafts/draft-schwartz-tram-turnbyname-00.txt > Status: > https://datatracker.ietf.org/doc/draft-schwartz-tram-turnbyname/ > Htmlized: > http://tools.ietf.org/html/draft-schwartz-tram-turnbyname-00 > > > Abstract: > When tunneling traffic through TURN, a client may sometimes desire to > contact a remote endpoint that it knows by its DNS name, not its IP > address. This document describes an extension to TURN that allows > such a client to contact a named endpoint. > > > > > 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 > > > --001a1135c8b890b7350510db5561 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Mar 6, 2015 at 10:00 PM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.c= om> wrote:

On some restricted networks, DNS access is also restricted= , which may

prevent users from determining the IP address of a domain = (e.g. an

application-specified TURN server, for RETURN

[I-D.schwar= tz-rtcweb-return], or an ICE candidate that contains a

domain name) that they wish to contact through the escape-= hatch TURN

server.

=C2=A0

Comment> FW in such restricted network may use various = mechanisms like function as HTTPS proxy, protocol identification of encrypt= ed content via statistical analysis to identify and block applications etc.

How will this technique work in such restricted networks ?=


When I describe &qu= ot;escape hatches" in restricted networks, I am principally referring = to situations where the network administrator (who is applying the restrict= ions) also deliberately creates such an escape hatch, which is only availab= le to certain authorized users. =C2=A0"TURN by name" allows the n= etwork administrator to enable these users to access the whole public netwo= rk, on networks where unauthorized users have restricted DNS access.
<= div>
More broadly, "TURN by name" parallels SOCKS-5= or HTTP CONNECT proxies for UDP applications (such as WebRTC), so I expect= it can be used to extend most proxy systems to support WebRTC.
<= br>

=C2=A0

-Tiru

=C2=A0

From: tram [ma= ilto:tram-bounce= s@ietf.org] On Behalf Of Benjamin Schwartz
Sent: Friday, March 06, 2015 1:48 AM
To: tram@ietf.org=
Subject: [tram] Fwd: New Version Notification for draft-schwa= rtz-tram-turnbyname-00.txt

=C2=A0

Hi TRAM,

=C2=A0

I've just written up a proposal for an optional = extension to TURN that would add support for DNS names.=C2=A0 I'd like = to discuss this at the upcoming meeting.

=C2=A0

Let me know what you think!

=C2=A0

Thanks,

Ben

=C2=A0

---------- Forwarded = message ----------
From: <int= ernet-drafts@ietf.org>
Date: Thu, Mar 5, 2015 at 3:15 PM
Subject: New Version Notification for draft-schwartz-tram-turnbyname-00.txt=
To: Justin Uberti <justin@uberti.name>, "Benjamin M. Schwartz" <bemasc@webrtc.org>


A new version of I-D, draft-schwartz-tram-turnbyname-00.txt
has been successfully submitted by Benjamin M. Schwartz and posted to the IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-schwartz-tram-turnbynam= e
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TURN by name: an extension to TURN= for contacting an endpoint by its DNS name.
Document date:=C2=A0 2015-03-05
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 15
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/internet-drafts/draft-schwartz-tram-turnbyname-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatr= acker.ietf.org/doc/draft-schwartz-tram-turnbyname/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/h= tml/draft-schwartz-tram-turnbyname-00


Abstract:
=C2=A0 =C2=A0When tunneling traffic through TURN, a client may sometimes de= sire to
=C2=A0 =C2=A0contact a remote endpoint that it knows by its DNS name, not i= ts IP
=C2=A0 =C2=A0address.=C2=A0 This document describes an extension to TURN th= at allows
=C2=A0 =C2=A0such a client to contact a named endpoint.




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

=C2=A0


--001a1135c8b890b7350510db5561-- From nobody Mon Mar 9 06:59:55 2015 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 95EF71A886D for ; Mon, 9 Mar 2015 06:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, 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 XsjinoXc-Efi for ; Mon, 9 Mar 2015 06:59:52 -0700 (PDT) Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1531A87D1 for ; Mon, 9 Mar 2015 06:59:14 -0700 (PDT) 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 t29DlDnp011122; Mon, 9 Mar 2015 09:59:12 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 1syu3xh2pk-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 09 Mar 2015 09:59:12 -0400 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, 9 Mar 2015 08:59:11 -0500 From: Jonathan Lennox To: Simon Perreault Thread-Topic: [tram] New Version Notification for draft-schwartz-tram-turnbyname-00.txt Thread-Index: AQHQWnE3LQTZ/EiaNUCouZW+6YLy6Q== Date: Mon, 9 Mar 2015 13:59:10 +0000 Message-ID: <525817F6-4E8F-4052-BB13-27B1F332756B@vidyo.com> References: <20150305201507.6192.13143.idtracker@ietfa.amsl.com> <35F68F75-51A0-48BD-B5D0-DE0A6600F13D@vidyo.com> <54FA2954.2060400@jive.com> <54FD8DAB.10807@jive.com> In-Reply-To: <54FD8DAB.10807@jive.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.116.135.94] Content-Type: text/plain; charset="Windows-1252" Content-ID: <694E22C55F3C9C4EBF8CF2E0640A6FFA@vidyo.com> 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=2015-03-09_02:2015-03-09,2015-03-09,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-1503090141 Archived-At: Cc: Benjamin Schwartz , "tram@ietf.org" , Justin Uberti Subject: Re: [tram] New Version Notification for draft-schwartz-tram-turnbyname-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, 09 Mar 2015 13:59:53 -0000 On Mar 9, 2015, at 8:10 AM, Simon Perreault wrote: > Le 2015-03-06 19:34, Justin Uberti a =E9crit : >> The problem is that the STUN timeout is on the client, whereas the DNS >> timeout is on the server, so the client needs to somehow be aware of the >> DNS timeout in its STUN calculations. >=20 > Why? From the client's point of view, the server is just taking longer th= an usual to process the request. >=20 >> Generally I think that we could just say that if DNS doesn't respond in >> X seconds (e.g. 5), the server MUST consider the lookup to have failed >> and return a 4YY error code. According to the STUN spec (section 7.2.1 in RFC 5389, 6.2.1 in the stun-bi= s draft), over unreliable channels, a STUN client will consider a transacti= on to have failed if it gets no response after (2^(Rc-1)-1+Rm)*RTT, i.e. 79= *RTT for the default values of Rc (7) and Rm (16). For short RTTs (between= the client and the TURN server) that=92ll likely be shorter than the DNS t= imeout. We could tweak Rc and/or Rm for requests that cause the server to do a DNS = lookup, but it seems rather like a layer violation.= From nobody Mon Mar 9 07:32:13 2015 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 4869E1A8967 for ; Mon, 9 Mar 2015 07:32:09 -0700 (PDT) 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 fLM9c1SRuHdK for ; Mon, 9 Mar 2015 07:32:07 -0700 (PDT) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 395861A894C for ; Mon, 9 Mar 2015 07:32:07 -0700 (PDT) Received: by qcyl6 with SMTP id l6so8825708qcy.13 for ; Mon, 09 Mar 2015 07:32:06 -0700 (PDT) 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=fSyOdIZzG22Yii43AmSgAUkezSHJVFICx3Js8eQpD0g=; b=h16IEa5pJzHYVGrtSCdHA8+RNTrxr10wAAVnXcPS4/A2GqBWYyYXO8ZfBVf5H4sk/A gVT+j55U8W7PL9Md6jHQHaQMVOAQSNPr0aSCLmYSqGmYhnWvfcgs5E/vKI+7potMfUyg jerxAh7a0y7mVvy8sGE7QXFAlHUvjp+fit0YIesbOVuTSc0bykw2/36tkKZ40YwnYmX1 HgaRIOWp067PbyqadOZ8chYA/Bm9mNfzWdo0ofOYnZOGFI9hMggAXdr253FZQnhkqORV prNWCLBPNFIhO2V9BWxxy2T5bK0tNrVUWTZKy0MscysKFC9raca0g7rat9ROvQAC7MXD sGeA== X-Gm-Message-State: ALoCoQmC+BGyW8B4ZOOkux31bdDS1cD1e8CVyfBiOgZNDFW9S9Zp1bea8F+HZhX3ziv4Acdr7aFr X-Received: by 10.55.23.34 with SMTP id i34mr20692648qkh.6.1425911526480; Mon, 09 Mar 2015 07:32:06 -0700 (PDT) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com. [209.85.216.169]) by mx.google.com with ESMTPSA id y10sm11643960qgd.14.2015.03.09.07.32.05 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2015 07:32:05 -0700 (PDT) Received: by qcwr17 with SMTP id r17so14875430qcw.2 for ; Mon, 09 Mar 2015 07:32:05 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.32.52 with SMTP id g49mr34807331qgg.83.1425911525239; Mon, 09 Mar 2015 07:32:05 -0700 (PDT) Received: by 10.229.90.68 with HTTP; Mon, 9 Mar 2015 07:32:05 -0700 (PDT) In-Reply-To: <525817F6-4E8F-4052-BB13-27B1F332756B@vidyo.com> References: <20150305201507.6192.13143.idtracker@ietfa.amsl.com> <35F68F75-51A0-48BD-B5D0-DE0A6600F13D@vidyo.com> <54FA2954.2060400@jive.com> <54FD8DAB.10807@jive.com> <525817F6-4E8F-4052-BB13-27B1F332756B@vidyo.com> Date: Mon, 9 Mar 2015 10:32:05 -0400 Message-ID: From: Benjamin Schwartz To: Jonathan Lennox Content-Type: multipart/alternative; boundary=001a113a6254f1c8e50510dbe513 Archived-At: Cc: Simon Perreault , "tram@ietf.org" , Justin Uberti Subject: Re: [tram] New Version Notification for draft-schwartz-tram-turnbyname-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, 09 Mar 2015 14:32:09 -0000 --001a113a6254f1c8e50510dbe513 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ah, so the STUN spec is not designed to carry any message whose response waits for external communication. Hmm. I think we need a mechanism to report DNS resolution failures, and the client needs to wait for success before attempting to send messages. (Otherwise they would have to be queued or dropped on the server for up to ~10 seconds while waiting for DNS resolution to complete.) To me, it seems like the easiest solution would be to document an exception for slow transactions. However, if that seems unappealing, what do you think about a sequence like: C->S: Request S->C (immediately): Error Response, with an attribute indicating "pending" S->C (later): Success (or Error) Indication, with identifying attributes (XOR-PEER-ADDRESS or CHANNEL-NUMBER) On Mon, Mar 9, 2015 at 9:59 AM, Jonathan Lennox wrote: > On Mar 9, 2015, at 8:10 AM, Simon Perreault wrote: > > > Le 2015-03-06 19:34, Justin Uberti a =C3=A9crit : > >> The problem is that the STUN timeout is on the client, whereas the DNS > >> timeout is on the server, so the client needs to somehow be aware of t= he > >> DNS timeout in its STUN calculations. > > > > Why? From the client's point of view, the server is just taking longer > than usual to process the request. > > > >> Generally I think that we could just say that if DNS doesn't respond i= n > >> X seconds (e.g. 5), the server MUST consider the lookup to have failed > >> and return a 4YY error code. > > According to the STUN spec (section 7.2.1 in RFC 5389, 6.2.1 in the > stun-bis draft), over unreliable channels, a STUN client will consider a > transaction to have failed if it gets no response after > (2^(Rc-1)-1+Rm)*RTT, i.e. 79*RTT for the default values of Rc (7) and Rm > (16). For short RTTs (between the client and the TURN server) that=E2=80= =99ll > likely be shorter than the DNS timeout. > > We could tweak Rc and/or Rm for requests that cause the server to do a DN= S > lookup, but it seems rather like a layer violation. --001a113a6254f1c8e50510dbe513 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ah, so the STUN spec is not designed to carry any message = whose response waits for external communication.=C2=A0 Hmm.

<= div>I think we need a mechanism to report DNS resolution failures, and the = client needs to wait for success before attempting to send messages. =C2=A0= (Otherwise they would have to be queued or dropped on the server for up to = ~10 seconds while waiting for DNS resolution to complete.)

To me, it seems like the easiest solution would be to document an = exception for slow transactions.=C2=A0 However, if that seems unappealing, = what do you think about a sequence like:
C->S: Request
S->C (immediately): Error Response, with an attribute indicating &quo= t;pending"
S->C (later): Success (or Error) Indication, w= ith identifying attributes (XOR-PEER-ADDRESS or CHANNEL-NUMBER)
=

On Mon, Mar 9, 20= 15 at 9:59 AM, Jonathan Lennox <jonathan@vidyo.com> wrote:<= br>
O= n Mar 9, 2015, at 8:10 AM, Simon Perreault <sperreault@jive.com> wrote:

> Le 2015-03-06 19:34, Justin Uberti a =C3=A9crit :
>> The problem is that the STUN timeout is on the client, whereas the= DNS
>> timeout is on the server, so the client needs to somehow be aware = of the
>> DNS timeout in its STUN calculations.
>
> Why? From the client's point of view, the server is just taking lo= nger than usual to process the request.
>
>> Generally I think that we could just say that if DNS doesn't r= espond in
>> X seconds (e.g. 5), the server MUST consider the lookup to have fa= iled
>> and return a 4YY error code.

According to the STUN spec (section 7.2.1 in RFC 5389, 6.2.1 in= the stun-bis draft), over unreliable channels, a STUN client will consider= a transaction to have failed if it gets no response after (2^(Rc-1)-1+Rm)*= RTT, i.e. 79*RTT for the default values of Rc (7) and Rm (16).=C2=A0 For sh= ort RTTs (between the client and the TURN server) that=E2=80=99ll likely be= shorter than the DNS timeout.

We could tweak Rc and/or Rm for requests that cause the server to do a DNS = lookup, but it seems rather like a layer violation.

<= /div> --001a113a6254f1c8e50510dbe513-- From nobody Mon Mar 9 08:13:38 2015 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 8A70A1A8F43 for ; Mon, 9 Mar 2015 08:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 FCKeiLr6vWXe for ; Mon, 9 Mar 2015 08:13:32 -0700 (PDT) Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) by ietfa.amsl.com (Postfix) with ESMTP id 663961A9124 for ; Mon, 9 Mar 2015 07:59:55 -0700 (PDT) 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 t29EpxnO016257; Mon, 9 Mar 2015 10:59:54 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 1syu3xh42a-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 09 Mar 2015 10:59:54 -0400 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, 9 Mar 2015 09:59:53 -0500 From: Jonathan Lennox To: Benjamin Schwartz Thread-Topic: [tram] New Version Notification for draft-schwartz-tram-turnbyname-00.txt Thread-Index: AQHQWnE3LQTZ/EiaNUCouZW+6YLy6Z0UipCAgAAHxIA= Date: Mon, 9 Mar 2015 14:59:52 +0000 Message-ID: References: <20150305201507.6192.13143.idtracker@ietfa.amsl.com> <35F68F75-51A0-48BD-B5D0-DE0A6600F13D@vidyo.com> <54FA2954.2060400@jive.com> <54FD8DAB.10807@jive.com> <525817F6-4E8F-4052-BB13-27B1F332756B@vidyo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.116.135.94] Content-Type: multipart/alternative; boundary="_000_E8D5DAD493D9446E95123BCF1FC34ACCvidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-03-09_02:2015-03-09,2015-03-09,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-1503090152 Archived-At: Cc: Simon Perreault , "tram@ietf.org" , Justin Uberti Subject: Re: [tram] New Version Notification for draft-schwartz-tram-turnbyname-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, 09 Mar 2015 15:13:36 -0000 --_000_E8D5DAD493D9446E95123BCF1FC34ACCvidyocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Mar 9, 2015, at 10:32 AM, Benjamin Schwartz > wrote: Ah, so the STUN spec is not designed to carry any message whose response wa= its for external communication. Hmm. I think we need a mechanism to report DNS resolution failures, and the clie= nt needs to wait for success before attempting to send messages. (Otherwis= e they would have to be queued or dropped on the server for up to ~10 secon= ds while waiting for DNS resolution to complete.) To me, it seems like the easiest solution would be to document an exception= for slow transactions. However, if that seems unappealing, what do you th= ink about a sequence like: C->S: Request S->C (immediately): Error Response, with an attribute indicating "pending" S->C (later): Success (or Error) Indication, with identifying attributes (X= OR-PEER-ADDRESS or CHANNEL-NUMBER) I=92d do it slightly differently =97 have the first S->C be a success respo= nse (but still with the =93pending=94 attribute), and have the second S->C = be a Request, not an Indication. (You want reliability here, since the mes= sage can be lost.) To be sure, this would be the first S->C Request in TURN, and if we went th= is way it=92d require some thought to make sure we understood properly how = authentication should work. On Mon, Mar 9, 2015 at 9:59 AM, Jonathan Lennox > wrote: On Mar 9, 2015, at 8:10 AM, Simon Perreault > wrote: > Le 2015-03-06 19:34, Justin Uberti a =E9crit : >> The problem is that the STUN timeout is on the client, whereas the DNS >> timeout is on the server, so the client needs to somehow be aware of the >> DNS timeout in its STUN calculations. > > Why? From the client's point of view, the server is just taking longer th= an usual to process the request. > >> Generally I think that we could just say that if DNS doesn't respond in >> X seconds (e.g. 5), the server MUST consider the lookup to have failed >> and return a 4YY error code. According to the STUN spec (section 7.2.1 in RFC 5389, 6.2.1 in the stun-bi= s draft), over unreliable channels, a STUN client will consider a transacti= on to have failed if it gets no response after (2^(Rc-1)-1+Rm)*RTT, i.e. 79= *RTT for the default values of Rc (7) and Rm (16). For short RTTs (between= the client and the TURN server) that=92ll likely be shorter than the DNS t= imeout. We could tweak Rc and/or Rm for requests that cause the server to do a DNS = lookup, but it seems rather like a layer violation. --_000_E8D5DAD493D9446E95123BCF1FC34ACCvidyocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1C1E351EC12A724BA874DFC8043015E6@vidyo.com> Content-Transfer-Encoding: quoted-printable
On Mar 9, 2015, at 10:32 AM, Benjamin Schwartz <bemasc@webrtc.org> wrote:

Ah, so the STUN spec is not designed to carry any message = whose response waits for external communication.  Hmm.

I think we need a mechanism to report DNS resolution failures, and the= client needs to wait for success before attempting to send messages.  = ;(Otherwise they would have to be queued or dropped on the server for up to= ~10 seconds while waiting for DNS resolution to complete.)

To me, it seems like the easiest solution would be to document an exce= ption for slow transactions.  However, if that seems unappealing, what= do you think about a sequence like:
C->S: Request
S->C (immediately): Error Response, with an attribute indicating &q= uot;pending"
S->C (later): Success (or Error) Indication, with identifying attri= butes (XOR-PEER-ADDRESS or CHANNEL-NUMBER)

I=92d do it slightly differently =97 have the first S->C be a succe= ss response (but still with the =93pending=94 attribute), and have the seco= nd S->C be a Request, not an Indication.  (You want reliability her= e, since the message can be lost.)

To be sure, this would be the first S->C Request in TURN, and if we= went this way it=92d require some thought to make sure we understood prope= rly how authentication should work.

On Mon, Mar 9, 2015 at 9:59 AM, Jonathan Lennox = <jonathan@vidyo.= com> wrote:
On Mar 9, 2015, at 8:10 AM, Simon Perreault <sperreault@jive.com> wrote:

> Le 2015-03-06 19:34, Justin Uberti a =E9crit :
>> The problem is that the STUN timeout is on the client, whereas the= DNS
>> timeout is on the server, so the client needs to somehow be aware = of the
>> DNS timeout in its STUN calculations.
>
> Why? From the client's point of view, the server is just taking longer= than usual to process the request.
>
>> Generally I think that we could just say that if DNS doesn't respo= nd in
>> X seconds (e.g. 5), the server MUST consider the lookup to have fa= iled
>> and return a 4YY error code.

According to the STUN spec (section 7.2.1 in RFC 5389, 6.2.1 in the stun-bi= s draft), over unreliable channels, a STUN client will consider a transacti= on to have failed if it gets no response after (2^(Rc-1)-1+Rm)*RTT, i.e= . 79*RTT for the default values of Rc (7) and Rm (16).  For short RTTs (between the client and the TURN ser= ver) that=92ll likely be shorter than the DNS timeout.

We could tweak Rc and/or Rm for requests that cause the server to do a DNS = lookup, but it seems rather like a layer violation.


--_000_E8D5DAD493D9446E95123BCF1FC34ACCvidyocom_-- From nobody Mon Mar 9 08:17:42 2015 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 5A0431A8F4C for ; Mon, 9 Mar 2015 08:17:40 -0700 (PDT) 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 t0D5BOl8SiIi for ; Mon, 9 Mar 2015 08:17:38 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AE0D1A92E6 for ; Mon, 9 Mar 2015 08:02:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22928; q=dns/txt; s=iport; t=1425913358; x=1427122958; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/GTPrUY3cDMbLbCeENCPKlKIN9o0A6UN+0cuN85fYow=; b=gIghq+Qy3ZwFPFwSFWOks2aFboj5X7YbYP7IT/9OXKCQQnQlWI7yQfLC C8jfVBb4NzaDcz564PBmi500zyI8iV/WgQtm+GQ4Ox4fDMYUyePhlDq7N wmYq3VTtpHBrRnFD4YXdXQ487mzt+kyRg9Z01pl+Uc3caMdMvCyna3oNS o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AGDgAjtf1U/5FdJa1SAQmCQ0NSWgSDBr0rPIF8hW4CHIEITQEBAQEBAXyEDwEBAQQjCkoCEAIBCA4DAwEBAQsdAwICAjAUCQgCBA4FCAGIJg2oQpsiAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sXhBIBKiANBAYBBgOCXy+BFgEEhXmIFIICg2SHCTmCb48yI4F9NYE8bwGBQ38BAQE X-IronPort-AV: E=Sophos;i="5.11,368,1422921600"; d="scan'208,217";a="402123885" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-4.cisco.com with ESMTP; 09 Mar 2015 15:02:37 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t29F2bkY007977 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Mar 2015 15:02:37 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Mon, 9 Mar 2015 10:02:37 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Benjamin Schwartz Thread-Topic: [tram] Fwd: New Version Notification for draft-schwartz-tram-turnbyname-00.txt Thread-Index: AQHQV4F+o4JG0o831USfxRWlVq7wzJ0QVSXAgAQwAgD//79fQA== Date: Mon, 9 Mar 2015 15:02:36 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A366B1D51@xmb-rcd-x10.cisco.com> References: <20150305201507.6192.13143.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A366B0BD3@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.238] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A366B1D51xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Fwd: New Version Notification for draft-schwartz-tram-turnbyname-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, 09 Mar 2015 15:17:40 -0000 --_000_913383AAA69FF945B8F946018B75898A366B1D51xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW5saW5lIFtUUl0NCg0KRnJvbTogQmVuamFtaW4gU2Nod2FydHogW21haWx0bzpiZW1hc2NAd2Vi cnRjLm9yZ10NClNlbnQ6IE1vbmRheSwgTWFyY2ggMDksIDIwMTUgNzoyMiBQTQ0KVG86IFRpcnVt YWxlc3dhciBSZWRkeSAodGlyZWRkeSkNCkNjOiB0cmFtQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W3RyYW1dIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1zY2h3YXJ0ei10 cmFtLXR1cm5ieW5hbWUtMDAudHh0DQoNCk9uIEZyaSwgTWFyIDYsIDIwMTUgYXQgMTA6MDAgUE0s IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgPHRpcmVkZHlAY2lzY28uY29tPG1haWx0bzp0 aXJlZGR5QGNpc2NvLmNvbT4+IHdyb3RlOg0KT24gc29tZSByZXN0cmljdGVkIG5ldHdvcmtzLCBE TlMgYWNjZXNzIGlzIGFsc28gcmVzdHJpY3RlZCwgd2hpY2ggbWF5DQpwcmV2ZW50IHVzZXJzIGZy b20gZGV0ZXJtaW5pbmcgdGhlIElQIGFkZHJlc3Mgb2YgYSBkb21haW4gKGUuZy4gYW4NCmFwcGxp Y2F0aW9uLXNwZWNpZmllZCBUVVJOIHNlcnZlciwgZm9yIFJFVFVSTg0KW0ktRC5zY2h3YXJ0ei1y dGN3ZWItcmV0dXJuPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNjaHdhcnR6LXRy YW0tdHVybmJ5bmFtZS0wMCNyZWYtSS1ELnNjaHdhcnR6LXJ0Y3dlYi1yZXR1cm4+XSwgb3IgYW4g SUNFIGNhbmRpZGF0ZSB0aGF0IGNvbnRhaW5zIGENCmRvbWFpbiBuYW1lKSB0aGF0IHRoZXkgd2lz aCB0byBjb250YWN0IHRocm91Z2ggdGhlIGVzY2FwZS1oYXRjaCBUVVJODQpzZXJ2ZXIuDQoNCkNv bW1lbnQ+IEZXIGluIHN1Y2ggcmVzdHJpY3RlZCBuZXR3b3JrIG1heSB1c2UgdmFyaW91cyBtZWNo YW5pc21zIGxpa2UgZnVuY3Rpb24gYXMgSFRUUFMgcHJveHksIHByb3RvY29sIGlkZW50aWZpY2F0 aW9uIG9mIGVuY3J5cHRlZCBjb250ZW50IHZpYSBzdGF0aXN0aWNhbCBhbmFseXNpcyB0byBpZGVu dGlmeSBhbmQgYmxvY2sgYXBwbGljYXRpb25zIGV0Yy4NCkhvdyB3aWxsIHRoaXMgdGVjaG5pcXVl IHdvcmsgaW4gc3VjaCByZXN0cmljdGVkIG5ldHdvcmtzID8NCg0KV2hlbiBJIGRlc2NyaWJlICJl c2NhcGUgaGF0Y2hlcyIgaW4gcmVzdHJpY3RlZCBuZXR3b3JrcywgSSBhbSBwcmluY2lwYWxseSBy ZWZlcnJpbmcgdG8gc2l0dWF0aW9ucyB3aGVyZSB0aGUgbmV0d29yayBhZG1pbmlzdHJhdG9yICh3 aG8gaXMgYXBwbHlpbmcgdGhlIHJlc3RyaWN0aW9ucykgYWxzbyBkZWxpYmVyYXRlbHkgY3JlYXRl cyBzdWNoIGFuIGVzY2FwZSBoYXRjaCwgd2hpY2ggaXMgb25seSBhdmFpbGFibGUgdG8gY2VydGFp biBhdXRob3JpemVkIHVzZXJzLiAgIlRVUk4gYnkgbmFtZSIgYWxsb3dzIHRoZSBuZXR3b3JrIGFk bWluaXN0cmF0b3IgdG8gZW5hYmxlIHRoZXNlIHVzZXJzIHRvIGFjY2VzcyB0aGUgd2hvbGUgcHVi bGljIG5ldHdvcmssIG9uIG5ldHdvcmtzIHdoZXJlIHVuYXV0aG9yaXplZCB1c2VycyBoYXZlIHJl c3RyaWN0ZWQgRE5TIGFjY2Vzcy4NCg0KW1RSXSBTZWN1cml0eSBkZXZpY2VzIHNvbHZlIHRoaXMg cHJvYmxlbSBieSBlbmZvcmNpbmcgaWRlbnRpdHktYmFzZWQgcG9saWNpZXMuDQoNCi1UaXJ1DQoN Ck1vcmUgYnJvYWRseSwgIlRVUk4gYnkgbmFtZSIgcGFyYWxsZWxzIFNPQ0tTLTUgb3IgSFRUUCBD T05ORUNUIHByb3hpZXMgZm9yIFVEUCBhcHBsaWNhdGlvbnMgKHN1Y2ggYXMgV2ViUlRDKSwgc28g SSBleHBlY3QgaXQgY2FuIGJlIHVzZWQgdG8gZXh0ZW5kIG1vc3QgcHJveHkgc3lzdGVtcyB0byBz dXBwb3J0IFdlYlJUQy4NCg0KDQotVGlydQ0KDQpGcm9tOiB0cmFtIFttYWlsdG86dHJhbS1ib3Vu Y2VzQGlldGYub3JnPG1haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2Yg QmVuamFtaW4gU2Nod2FydHoNClNlbnQ6IEZyaWRheSwgTWFyY2ggMDYsIDIwMTUgMTo0OCBBTQ0K VG86IHRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBbdHJhbV0g RndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNjaHdhcnR6LXRyYW0tdHVy bmJ5bmFtZS0wMC50eHQNCg0KSGkgVFJBTSwNCg0KSSd2ZSBqdXN0IHdyaXR0ZW4gdXAgYSBwcm9w b3NhbCBmb3IgYW4gb3B0aW9uYWwgZXh0ZW5zaW9uIHRvIFRVUk4gdGhhdCB3b3VsZCBhZGQgc3Vw cG9ydCBmb3IgRE5TIG5hbWVzLiAgSSdkIGxpa2UgdG8gZGlzY3VzcyB0aGlzIGF0IHRoZSB1cGNv bWluZyBtZWV0aW5nLg0KDQpMZXQgbWUga25vdyB3aGF0IHlvdSB0aGluayENCg0KVGhhbmtzLA0K QmVuDQoNCi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLQ0KRnJvbTogPGlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPj4N CkRhdGU6IFRodSwgTWFyIDUsIDIwMTUgYXQgMzoxNSBQTQ0KU3ViamVjdDogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC1zY2h3YXJ0ei10cmFtLXR1cm5ieW5hbWUtMDAudHh0DQpU bzogSnVzdGluIFViZXJ0aSA8anVzdGluQHViZXJ0aS5uYW1lPG1haWx0bzpqdXN0aW5AdWJlcnRp Lm5hbWU+PiwgIkJlbmphbWluIE0uIFNjaHdhcnR6IiA8YmVtYXNjQHdlYnJ0Yy5vcmc8bWFpbHRv OmJlbWFzY0B3ZWJydGMub3JnPj4NCg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1z Y2h3YXJ0ei10cmFtLXR1cm5ieW5hbWUtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3Vi bWl0dGVkIGJ5IEJlbmphbWluIE0uIFNjaHdhcnR6IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJl cG9zaXRvcnkuDQoNCk5hbWU6ICAgICAgICAgICBkcmFmdC1zY2h3YXJ0ei10cmFtLXR1cm5ieW5h bWUNClJldmlzaW9uOiAgICAgICAwMA0KVGl0bGU6ICAgICAgICAgIFRVUk4gYnkgbmFtZTogYW4g ZXh0ZW5zaW9uIHRvIFRVUk4gZm9yIGNvbnRhY3RpbmcgYW4gZW5kcG9pbnQgYnkgaXRzIEROUyBu YW1lLg0KRG9jdW1lbnQgZGF0ZTogIDIwMTUtMDMtMDUNCkdyb3VwOiAgICAgICAgICBJbmRpdmlk dWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAgICAgICAxNQ0KVVJMOiAgICAgICAgICAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXNjaHdhcnR6LXRyYW0tdHVybmJ5 bmFtZS0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1zY2h3YXJ0ei10cmFtLXR1cm5ieW5hbWUvDQpIdG1saXplZDogICAgICAgaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2Nod2FydHotdHJhbS10dXJuYnluYW1lLTAw DQoNCg0KQWJzdHJhY3Q6DQogICBXaGVuIHR1bm5lbGluZyB0cmFmZmljIHRocm91Z2ggVFVSTiwg YSBjbGllbnQgbWF5IHNvbWV0aW1lcyBkZXNpcmUgdG8NCiAgIGNvbnRhY3QgYSByZW1vdGUgZW5k cG9pbnQgdGhhdCBpdCBrbm93cyBieSBpdHMgRE5TIG5hbWUsIG5vdCBpdHMgSVANCiAgIGFkZHJl c3MuICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhbiBleHRlbnNpb24gdG8gVFVSTiB0aGF0IGFs bG93cw0KICAgc3VjaCBhIGNsaWVudCB0byBjb250YWN0IGEgbmFtZWQgZW5kcG9pbnQuDQoNCg0K DQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBk aWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3Jn Pi4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQo= --_000_913383AAA69FF945B8F946018B75898A366B1D51xmbrcdx10ciscoc_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli 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 dDsiPiBCZW5qYW1pbiBTY2h3YXJ0eiBbbWFpbHRvOmJlbWFzY0B3ZWJydGMub3JnXQ0KPGJyPg0K PGI+U2VudDo8L2I+IE1vbmRheSwgTWFyY2ggMDksIDIwMTUgNzoyMiBQTTxicj4NCjxiPlRvOjwv Yj4gVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTxicj4NCjxiPkNjOjwvYj4gdHJhbUBpZXRm Lm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3RyYW1dIEZ3ZDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1zY2h3YXJ0ei10cmFtLXR1cm5ieW5hbWUtMDAudHh0PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gRnJpLCBNYXIgNiwgMjAxNSBhdCAxMDowMCBQTSwgVGlydW1hbGVzd2FyIFJlZGR5 ICh0aXJlZGR5KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRpcmVkZHlAY2lzY28uY29tIiB0YXJnZXQ9 Il9ibGFuayI+dGlyZWRkeUBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+T24gc29tZSBy ZXN0cmljdGVkIG5ldHdvcmtzLCBETlMgYWNjZXNzIGlzIGFsc28gcmVzdHJpY3RlZCwgd2hpY2gg bWF5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+cHJldmVudCB1c2VycyBmcm9tIGRldGVybWluaW5nIHRoZSBJUCBhZGRyZXNzIG9mIGEgZG9t YWluIChlLmcuIGFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+YXBwbGljYXRpb24tc3BlY2lmaWVkIFRVUk4gc2VydmVyLCBmb3IgUkVUVVJO PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ WzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNjaHdhcnR6LXRyYW0t dHVybmJ5bmFtZS0wMCNyZWYtSS1ELnNjaHdhcnR6LXJ0Y3dlYi1yZXR1cm4iIHRhcmdldD0iX2Js YW5rIj5JLUQuc2Nod2FydHotcnRjd2ViLXJldHVybjwvYT5dLA0KIG9yIGFuIElDRSBjYW5kaWRh dGUgdGhhdCBjb250YWlucyBhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+ZG9tYWluIG5hbWUpIHRoYXQgdGhleSB3aXNoIHRvIGNvbnRhY3Qg dGhyb3VnaCB0aGUgZXNjYXBlLWhhdGNoIFRVUk48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5zZXJ2ZXIuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Q29tbWVudCZndDsgRlcg aW4gc3VjaCByZXN0cmljdGVkIG5ldHdvcmsgbWF5IHVzZSB2YXJpb3VzIG1lY2hhbmlzbXMgbGlr ZSBmdW5jdGlvbiBhcyBIVFRQUyBwcm94eSwgcHJvdG9jb2wgaWRlbnRpZmljYXRpb24NCiBvZiBl bmNyeXB0ZWQgY29udGVudCB2aWEgc3RhdGlzdGljYWwgYW5hbHlzaXMgdG8gaWRlbnRpZnkgYW5k IGJsb2NrIGFwcGxpY2F0aW9ucyBldGMuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Ib3cgd2lsbCB0aGlzIHRlY2huaXF1ZSB3b3JrIGlu IHN1Y2ggcmVzdHJpY3RlZCBuZXR3b3JrcyA/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoZW4gSSBkZXNjcmliZSAm cXVvdDtlc2NhcGUgaGF0Y2hlcyZxdW90OyBpbiByZXN0cmljdGVkIG5ldHdvcmtzLCBJIGFtIHBy aW5jaXBhbGx5IHJlZmVycmluZyB0byBzaXR1YXRpb25zIHdoZXJlIHRoZSBuZXR3b3JrIGFkbWlu aXN0cmF0b3IgKHdobyBpcyBhcHBseWluZyB0aGUgcmVzdHJpY3Rpb25zKSBhbHNvIGRlbGliZXJh dGVseSBjcmVhdGVzIHN1Y2ggYW4gZXNjYXBlIGhhdGNoLCB3aGljaCBpcyBvbmx5IGF2YWlsYWJs ZQ0KIHRvIGNlcnRhaW4gYXV0aG9yaXplZCB1c2Vycy4gJm5ic3A7JnF1b3Q7VFVSTiBieSBuYW1l JnF1b3Q7IGFsbG93cyB0aGUgbmV0d29yayBhZG1pbmlzdHJhdG9yIHRvIGVuYWJsZSB0aGVzZSB1 c2VycyB0byBhY2Nlc3MgdGhlIHdob2xlIHB1YmxpYyBuZXR3b3JrLCBvbiBuZXR3b3JrcyB3aGVy ZSB1bmF1dGhvcml6ZWQgdXNlcnMgaGF2ZSByZXN0cmljdGVkIEROUyBhY2Nlc3MuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltUUl0g U2VjdXJpdHkgZGV2aWNlcyBzb2x2ZSB0aGlzIHByb2JsZW0gYnkgZW5mb3JjaW5nIGlkZW50aXR5 LWJhc2VkIHBvbGljaWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LVRpcnU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1vcmUgYnJvYWRseSwgJnF1b3Q7 VFVSTiBieSBuYW1lJnF1b3Q7IHBhcmFsbGVscyBTT0NLUy01IG9yIEhUVFAgQ09OTkVDVCBwcm94 aWVzIGZvciBVRFAgYXBwbGljYXRpb25zIChzdWNoIGFzIFdlYlJUQyksIHNvIEkgZXhwZWN0IGl0 IGNhbiBiZSB1c2VkIHRvIGV4dGVuZCBtb3N0IHByb3h5IHN5c3RlbXMgdG8gc3VwcG9ydCBXZWJS VEMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LVRpcnU8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHRyYW0gW21haWx0bzo8YSBocmVm PSJtYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dHJhbS1ib3Vu Y2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QmVuamFtaW4gU2Nod2FydHo8 YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXJjaCAwNiwgMjAxNSAxOjQ4IEFNPGJyPg0KPGI+ VG86PC9iPiA8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRy YW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFt0cmFtXSBGd2Q6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc2Nod2FydHotdHJhbS10dXJuYnluYW1lLTAwLnR4 dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgVFJBTSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkndmUganVzdCB3cml0dGVuIHVwIGEg cHJvcG9zYWwgZm9yIGFuIG9wdGlvbmFsIGV4dGVuc2lvbiB0byBUVVJOIHRoYXQgd291bGQgYWRk IHN1cHBvcnQgZm9yIEROUyBuYW1lcy4mbmJzcDsgSSdkIGxpa2UgdG8gZGlzY3VzcyB0aGlzIGF0 IHRoZSB1cGNvbWluZyBtZWV0aW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TGV0IG1lIGtub3cgd2hhdCB5b3UgdGhpbmshPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGFu a3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkJlbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+LS0tLS0tLS0tLSBGb3J3 YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tPGJyPg0KRnJvbTogJmx0OzxhIGhyZWY9Im1haWx0bzpp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCkRhdGU6IFRodSwgTWFyIDUsIDIwMTUgYXQgMzoxNSBQTTxi cj4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc2Nod2FydHot dHJhbS10dXJuYnluYW1lLTAwLnR4dDxicj4NClRvOiBKdXN0aW4gVWJlcnRpICZsdDs8YSBocmVm PSJtYWlsdG86anVzdGluQHViZXJ0aS5uYW1lIiB0YXJnZXQ9Il9ibGFuayI+anVzdGluQHViZXJ0 aS5uYW1lPC9hPiZndDssICZxdW90O0JlbmphbWluIE0uIFNjaHdhcnR6JnF1b3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86YmVtYXNjQHdlYnJ0Yy5vcmciIHRhcmdldD0iX2JsYW5rIj5iZW1hc2NAd2Vi cnRjLm9yZzwvYT4mZ3Q7PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KQSBuZXcgdmVyc2lvbiBvZiBJ LUQsIGRyYWZ0LXNjaHdhcnR6LXRyYW0tdHVybmJ5bmFtZS0wMC50eHQ8YnI+DQpoYXMgYmVlbiBz dWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEJlbmphbWluIE0uIFNjaHdhcnR6IGFuZCBwb3N0ZWQg dG8gdGhlPGJyPg0KSUVURiByZXBvc2l0b3J5Ljxicj4NCjxicj4NCk5hbWU6Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC1zY2h3YXJ0ei10cmFtLXR1cm5ieW5h bWU8YnI+DQpSZXZpc2lvbjombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDswMDxicj4NClRpdGxl OiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVFVSTiBieSBuYW1lOiBhbiBleHRl bnNpb24gdG8gVFVSTiBmb3IgY29udGFjdGluZyBhbiBlbmRwb2ludCBieSBpdHMgRE5TIG5hbWUu PGJyPg0KRG9jdW1lbnQgZGF0ZTombmJzcDsgMjAxNS0wMy0wNTxicj4NCkdyb3VwOiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyPg0KUGFn ZXM6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAxNTxicj4NClVSTDombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1zY2h3YXJ0ei10cmFtLXR1cm5ieW5hbWUtMDAu dHh0IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1zY2h3YXJ0ei10cmFtLXR1cm5ieW5hbWUtMDAudHh0PC9hPjxicj4NClN0YXR1czom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc2Nod2FydHotdHJhbS10dXJuYnluYW1lLyIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNjaHdhcnR6 LXRyYW0tdHVybmJ5bmFtZS88L2E+PGJyPg0KSHRtbGl6ZWQ6Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2Nod2FydHot dHJhbS10dXJuYnluYW1lLTAwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtc2Nod2FydHotdHJhbS10dXJuYnluYW1lLTAwPC9hPjxicj4NCjxicj4NCjxi cj4NCkFic3RyYWN0Ojxicj4NCiZuYnNwOyAmbmJzcDtXaGVuIHR1bm5lbGluZyB0cmFmZmljIHRo cm91Z2ggVFVSTiwgYSBjbGllbnQgbWF5IHNvbWV0aW1lcyBkZXNpcmUgdG88YnI+DQombmJzcDsg Jm5ic3A7Y29udGFjdCBhIHJlbW90ZSBlbmRwb2ludCB0aGF0IGl0IGtub3dzIGJ5IGl0cyBETlMg bmFtZSwgbm90IGl0cyBJUDxicj4NCiZuYnNwOyAmbmJzcDthZGRyZXNzLiZuYnNwOyBUaGlzIGRv Y3VtZW50IGRlc2NyaWJlcyBhbiBleHRlbnNpb24gdG8gVFVSTiB0aGF0IGFsbG93czxicj4NCiZu YnNwOyAmbmJzcDtzdWNoIGEgY2xpZW50IHRvIGNvbnRhY3QgYSBuYW1lZCBlbmRwb2ludC48YnI+ DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyPg0KdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCA8YSBocmVmPSJo dHRwOi8vdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnRvb2xzLmlldGYub3JnPC9h Pi48YnI+DQo8YnI+DQpUaGUgSUVURiBTZWNyZXRhcmlhdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_913383AAA69FF945B8F946018B75898A366B1D51xmbrcdx10ciscoc_-- From nobody Mon Mar 9 08:42:26 2015 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 2AF8E1A8AEC for ; Mon, 9 Mar 2015 08:42:24 -0700 (PDT) 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 xR4krXQUkliM for ; Mon, 9 Mar 2015 08:42:21 -0700 (PDT) Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C52641A902D for ; Mon, 9 Mar 2015 08:38:32 -0700 (PDT) Received: by qgaj5 with SMTP id j5so29318151qga.12 for ; Mon, 09 Mar 2015 08:38:32 -0700 (PDT) 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=BIU1ygoyCH/CSIxFxHDk4nKSLVajaydDNQ4PunJKvHs=; b=mPH/HWxm/WbvJCEL3i8Jjgr0XPzqjFXbziSqs3zovQ5AWSEvbr2bQ8/oiHSfZm4uuv aX0ctqFtGpPFNkxijmUp5QFGotQ8ertR5VVMlQImaEZeWzQd02PNcWgKQULf/MxO+uZg MQaX5tpUGnPrqhRtdZXg7P6iGki+isw+3cmCXeHqOGrAZ9kNrNNPuR5oeHZ4bFfIxRSp Ehr0n0Q76V62DBtvsTxSI65h6RzOU0vIFL+AeZTcgnMShZzBV4u+TETaNtce1J5KWc2g uHPB+ZLu2fEEnssfVc8/qPoZZb4EfUhmUctknGQ9yPMsV4GopAtoYsKkeErbgl/3GUko ywxA== X-Gm-Message-State: ALoCoQkCJEvcUtr20WrpSgXg/6BKCAAUzxQEUi5YDGHhSY46Bn8jU2LsLLzjCBZ6eoQUtL1XIASh X-Received: by 10.140.91.201 with SMTP id z67mr34950992qgd.27.1425915512019; Mon, 09 Mar 2015 08:38:32 -0700 (PDT) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com. [209.85.216.171]) by mx.google.com with ESMTPSA id t51sm11755993qge.28.2015.03.09.08.38.31 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2015 08:38:31 -0700 (PDT) Received: by qcwr17 with SMTP id r17so3063938qcw.11 for ; Mon, 09 Mar 2015 08:38:31 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.55.54.71 with SMTP id d68mr56221940qka.42.1425915511080; Mon, 09 Mar 2015 08:38:31 -0700 (PDT) Received: by 10.229.90.68 with HTTP; Mon, 9 Mar 2015 08:38:30 -0700 (PDT) In-Reply-To: References: <20150305201507.6192.13143.idtracker@ietfa.amsl.com> <35F68F75-51A0-48BD-B5D0-DE0A6600F13D@vidyo.com> <54FA2954.2060400@jive.com> <54FD8DAB.10807@jive.com> <525817F6-4E8F-4052-BB13-27B1F332756B@vidyo.com> Date: Mon, 9 Mar 2015 11:38:30 -0400 Message-ID: From: Benjamin Schwartz To: Jonathan Lennox Content-Type: multipart/alternative; boundary=001a11470f4284c0800510dcd3f1 Archived-At: Cc: Simon Perreault , "tram@ietf.org" , Justin Uberti Subject: Re: [tram] New Version Notification for draft-schwartz-tram-turnbyname-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, 09 Mar 2015 15:42:24 -0000 --001a11470f4284c0800510dcd3f1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Rather than introducing the first ever S->C STUN Request, what if the "pending" attribute indicates a timeout, i.e. result-indication guaranteed in this many seconds. If there's no response by then, the packet must have been dropped, and the client should retry. It's slower than a reliable request/response if the indication is lost, but it's a lot simpler. On Mon, Mar 9, 2015 at 10:59 AM, Jonathan Lennox wrote= : > > On Mar 9, 2015, at 10:32 AM, Benjamin Schwartz wrote= : > > Ah, so the STUN spec is not designed to carry any message whose response > waits for external communication. Hmm. > > I think we need a mechanism to report DNS resolution failures, and the > client needs to wait for success before attempting to send messages. > (Otherwise they would have to be queued or dropped on the server for up = to > ~10 seconds while waiting for DNS resolution to complete.) > > To me, it seems like the easiest solution would be to document an > exception for slow transactions. However, if that seems unappealing, wha= t > do you think about a sequence like: > C->S: Request > S->C (immediately): Error Response, with an attribute indicating "pending= " > S->C (later): Success (or Error) Indication, with identifying attributes > (XOR-PEER-ADDRESS or CHANNEL-NUMBER) > > > I=E2=80=99d do it slightly differently =E2=80=94 have the first S->C be = a success > response (but still with the =E2=80=9Cpending=E2=80=9D attribute), and ha= ve the second S->C > be a Request, not an Indication. (You want reliability here, since the > message can be lost.) > > To be sure, this would be the first S->C Request in TURN, and if we went > this way it=E2=80=99d require some thought to make sure we understood pro= perly how > authentication should work. > > On Mon, Mar 9, 2015 at 9:59 AM, Jonathan Lennox > wrote: > >> On Mar 9, 2015, at 8:10 AM, Simon Perreault wrote= : >> >> > Le 2015-03-06 19:34, Justin Uberti a =C3=A9crit : >> >> The problem is that the STUN timeout is on the client, whereas the DN= S >> >> timeout is on the server, so the client needs to somehow be aware of >> the >> >> DNS timeout in its STUN calculations. >> > >> > Why? From the client's point of view, the server is just taking longer >> than usual to process the request. >> > >> >> Generally I think that we could just say that if DNS doesn't respond = in >> >> X seconds (e.g. 5), the server MUST consider the lookup to have faile= d >> >> and return a 4YY error code. >> >> According to the STUN spec (section 7.2.1 in RFC 5389, 6.2.1 in the >> stun-bis draft), over unreliable channels, a STUN client will consider a >> transaction to have failed if it gets no response after >> (2^(Rc-1)-1+Rm)*RTT, i.e. 79*RTT for the default values of Rc (7) and Rm >> (16). For short RTTs (between the client and the TURN server) that=E2= =80=99ll >> likely be shorter than the DNS timeout. >> >> We could tweak Rc and/or Rm for requests that cause the server to do a >> DNS lookup, but it seems rather like a layer violation. > > > > --001a11470f4284c0800510dcd3f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Rather than introducing the first ever S->C STUN Reques= t, what if the "pending" attribute indicates a timeout, i.e. resu= lt-indication guaranteed in this many seconds.=C2=A0 If there's no resp= onse by then, the packet must have been dropped, and the client should retr= y.

It's slower than a reliable request/response if t= he indication is lost, but it's a lot simpler.

On Mon, Mar 9, 2015 at 10:59 A= M, Jonathan Lennox <jonathan@vidyo.com> wrote:

On Mar 9, 2015, at 10:32 AM, Benjamin Schwartz <bemasc@webrtc.org> wrote:

Ah, so the STUN spec is not designed to carry any message = whose response waits for external communication.=C2=A0 Hmm.

I think we need a mechanism to report DNS resolution failures, and the= client needs to wait for success before attempting to send messages. =C2= =A0(Otherwise they would have to be queued or dropped on the server for up = to ~10 seconds while waiting for DNS resolution to complete.)

To me, it seems like the easiest solution would be to document an exce= ption for slow transactions.=C2=A0 However, if that seems unappealing, what= do you think about a sequence like:
C->S: Request
S->C (immediately): Error Response, with an attribute indicating &q= uot;pending"
S->C (later): Success (or Error) Indication, with identifying attri= butes (XOR-PEER-ADDRESS or CHANNEL-NUMBER)

I=E2=80=99d do it slightly differently =E2=80=94 have the first= S->C be a success response (but still with the =E2=80=9Cpending=E2=80= =9D attribute), and have the second S->C be a Request, not an Indication= . =C2=A0(You want reliability here, since the message can be lost.)

To be sure, this would be the first S->C Request in TURN, and if we= went this way it=E2=80=99d require some thought to make sure we understood= properly how authentication should work.

On Mon, Mar 9, 2015 at 9:59 AM, Jonathan Lennox = <jonathan@vidyo.= com> wrote:
On Mar 9, 2015, at 8:10 AM, Simon Perreault <sperreault@jive.com> wrote:

> Le 2015-03-06 19:34, Justin Uberti a =C3=A9crit :
>> The problem is that the STUN timeout is on the client, whereas the= DNS
>> timeout is on the server, so the client needs to somehow be aware = of the
>> DNS timeout in its STUN calculations.
>
> Why? From the client's point of view, the server is just taking lo= nger than usual to process the request.
>
>> Generally I think that we could just say that if DNS doesn't r= espond in
>> X seconds (e.g. 5), the server MUST consider the lookup to have fa= iled
>> and return a 4YY error code.

According to the STUN spec (section 7.2.1 in RFC 5389, 6.2.1 in the stun-bi= s draft), over unreliable channels, a STUN client will consider a transacti= on to have failed if it gets no response after (2^(Rc-1)-1+Rm)*RTT, i.e. 79= *RTT for the default values of Rc (7) and Rm (16).=C2=A0 For short RTTs (between the client and the TURN ser= ver) that=E2=80=99ll likely be shorter than the DNS timeout.

We could tweak Rc and/or Rm for requests that cause the server to do a DNS = lookup, but it seems rather like a layer violation.



--001a11470f4284c0800510dcd3f1-- From nobody Mon Mar 9 09:59:29 2015 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 7BEDF1A891C for ; Mon, 9 Mar 2015 09:59:27 -0700 (PDT) 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 uI2DOYaHlUWf for ; Mon, 9 Mar 2015 09:59:24 -0700 (PDT) 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 367B51A8ABE for ; Mon, 9 Mar 2015 09:59:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14844; q=dns/txt; s=iport; t=1425920362; x=1427129962; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=jG/bRikuTBs2OJHJy5iWCHd8UWJwlJ4y5ncHlvuEQls=; b=ExZ2bklQvb5EU2GXTnSs5+nXXNkL/s+X/H3pImbmLJvnE01KqrPMW/GK EYUErydFtWFynvQ8r3frctVFip6Kb8gUqN61szCCVKwGA6qCAXviHFisc KZYl2kLwF+p2hGQuVoxdjVspOvLRelcWygWXpY1INhuPXdRiBne22RHl+ w=; X-IronPort-AV: E=Sophos;i="5.11,368,1422921600"; d="scan'208,217";a="402075641" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 09 Mar 2015 16:59:21 +0000 Received: from [10.24.35.200] ([10.24.35.200]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t29GxKQq027764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Mar 2015 16:59:20 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_EA7E9710-ED05-4E77-89BC-450CFEF17DDC" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: Date: Mon, 9 Mar 2015 09:59:19 -0700 Message-Id: References: <20150227152034.989.5946.idtracker@ietfa.amsl.com> <5BD9B28E-26D7-4E2A-838B-4D788454D079@cisco.com> To: Benjamin Schwartz X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: =?utf-8?Q?P=C3=A5l_Martinsen?= , "tram@ietf.org" Subject: Re: [tram] STUNTrace Draft 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, 09 Mar 2015 16:59:27 -0000 --Apple-Mail=_EA7E9710-ED05-4E77-89BC-450CFEF17DDC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 02-Mar-2015 04:35 AM, Pal Martinsen (palmarti) = wrote:=20 >=20 >> On 27 Feb 2015, at 17:02, Benjamin Schwartz > wrote: >>=20 >> How widely deployed (and enabled) is this kind of ICMP error = reporting (e.g. TTL exceeded)? My impression, consistent with your = security section, is that many network administrators disable this = functionality. >>=20 >=20 > That is very good question. >=20 > =46rom my perspective most ISPs respond back with a proper ICMP = message. Once the packets start to hit the =E2=80=9Ccloud boundaries=E2=80= =9D off google, amazon, akamai and so on you are likely to get no = answers.=20 Nothing else will work inside those networks, either. They are blocking = network diagnostic packets on purpose, for business reasons and to = discourage learning the network topology. *shrug*. But traceroute = works for me at airports, hotels, coffee shops, enterprises, and home = networks; users and network administrators expect traceroute to work. > Our main motivation for writing this up is to have a nice = troubleshooting tool for your own internal network and out to your ISP. = Combining information from RTP/RTCP regarding latency and packet drop = with the path information given by STUNTrace enables a network = administrator a pretty nice view of potential problems in the network. Yeah, just like we all use traceroute to diagnose problems all the time, = this provides the same sort of information, except STUNTrace has the = advantage of being path-congruent with the RTP media (unlike standalone = traceroute utilities). -d >=20 > .-. > P=C3=A5l-Erik >=20 >> On Fri, Feb 27, 2015 at 10:39 AM, Pal Martinsen (palmarti) = > wrote: >> Hi, >>=20 >> We just uploaded a new draft, STUNTrace = (http://tools.ietf.org/html/draft-martinsen-tram-stuntrace-00 = ). It = describes how to du =E2=80=9Cin-band=E2=80=9D tracreoute on the same = 5-tuple as you send media using STUN probe packets and ICMP responses.=20= >>=20 >> It aligns with = https://tools.ietf.org/html/draft-petithuguenin-tram-stun-pmtud-00 = = using STUN as a probe to discover network properties. >>=20 >> We added code examples in the appendix to clarify how ICMP can be = received by applications without requiring admin privileges. We still = lack Windows examples, so help with that is appreciated. ICMP test code = (not implementing this draft) can be found at: = https://github.com/palerikm/ICMPTest = >>=20 >> Questions and comments are of course welcome. >>=20 >> .-. >> P=C3=A5l-Erik >>=20 >>=20 >>> Begin forwarded message: >>>=20 >>> A new version of I-D, draft-martinsen-tram-stuntrace-00.txt >>> has been successfully submitted by Paal-Erik Martinsen and posted to = the >>> IETF repository. >>>=20 >>> Name: draft-martinsen-tram-stuntrace >>> Revision: 00 >>> Title: STUN Traceroute >>> Document date: 2015-02-27 >>> Group: Individual Submission >>> Pages: 12 >>> URL: = http://www.ietf.org/internet-drafts/draft-martinsen-tram-stuntrace-00.txt = >>> Status: = https://datatracker.ietf.org/doc/draft-martinsen-tram-stuntrace/ = >>> Htmlized: = http://tools.ietf.org/html/draft-martinsen-tram-stuntrace-00 = >>>=20 >>>=20 >>> Abstract: >>> After a UDP protocol such as RTP determines a network path is >>> experiencing problems, a traceroute is often useful to determine >>> which router or which link is contributing to the problem. = However, >>> operating system traceroute commands follow a different path than = the >>> actual UDP flow which complicates troubleshooting. A superior = method >>> is shown which is absolutely path-congruent with the UDP protocol >>> itself, works on IPv4 and IPv6, and does not require = administrative >>> privileges on most operating systems. >>>=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 >>=20 >>=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 --Apple-Mail=_EA7E9710-ED05-4E77-89BC-450CFEF17DDC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 02-Mar-2015 04:35 AM, Pal Martinsen = (palmarti) <palmarti@cisco.com> wrote:

On 27 Feb 2015, at 17:02, Benjamin Schwartz <bemasc@webrtc.org> = wrote:

How widely deployed (and enabled) is this = kind of ICMP error reporting (e.g. TTL exceeded)?  My impression, = consistent with your security section, is that many network = administrators disable this functionality.


That is very good question.

=46rom my perspective most ISPs respond back with a = proper ICMP message. Once the packets start to hit the =E2=80=9Ccloud = boundaries=E2=80=9D off google, amazon, akamai and so on you are likely = to get no answers. 

Nothing else will work inside those networks, = either.  They are blocking network diagnostic packets on purpose, = for business reasons and to discourage learning the network topology. =  *shrug*.   But traceroute works for me at airports, hotels, = coffee shops, enterprises, and home networks; users and network = administrators expect traceroute to work.

Our main motivation for writing this up is to have a = nice troubleshooting tool for your own internal network and out to your = ISP. Combining information from RTP/RTCP regarding latency and packet = drop with the path information given by STUNTrace enables a network administrator a pretty nice view of potential problems in the = network.

Yeah, just like we all use traceroute to diagnose = problems all the time, this provides the same sort of information, = except STUNTrace has the advantage of being path-congruent with the RTP = media (unlike standalone traceroute utilities).

-d



.-.
P=C3=A5l-Erik

On Fri, Feb 27, 2015 at 10:39 AM, Pal = Martinsen (palmarti) <palmarti@cisco.com> wrote:
Hi,

We just uploaded a new draft, STUNTrace (http://tools.ietf.org/html/draft-martinsen-tram-stuntrace-00). It describes how to du =E2=80=9Cin-band=E2=80=9D tracreoute on the same 5-tuple as you send media using STUN probe packets and ICMP = responses. 

It aligns with https://tools.ietf.org/html/draft-petithuguenin-tram-stun-pmtud= -00 using STUN as a probe to discover network properties.

We added code examples in the appendix to clarify how = ICMP can be received by applications without requiring admin privileges. = We still lack Windows examples, so help with that is appreciated. ICMP = test code (not implementing this draft) can be found at: https://github.com/palerikm/ICMPTest

Questions and comments are of course welcome.

.-.
P=C3=A5l-Erik


Begin forwarded message:

A new version of I-D, draft-martinsen-tram-stuntrace-00.txt
= has been successfully submitted by Paal-Erik Martinsen and posted to = the
IETF repository.

Name: draft-martinsen-tram-stuntrace
Revision: 00
Title: STUN Traceroute
Document date: = 2015-02-27
Group: Individual = Submission
Pages: 12
URL: =            http://www.ietf.org/internet-drafts/draft-martinsen-tram-stuntr= ace-00.txt
Status:         https://datatracker.ietf.org/doc/draft-martinsen-tram-stuntrace= /
Htmlized:       http://tools.ietf.org/html/draft-martinsen-tram-stuntrace-00


Abstract:
  After a UDP protocol such as RTP determines a network path = is
  experiencing problems, a traceroute is often useful to = determine
  which router or which link is contributing to the = problem.  However,
  operating system traceroute commands follow a different path = than the
  actual UDP flow which complicates troubleshooting.  A = superior method
  is shown which is absolutely path-congruent with the UDP = protocol
  itself, works on IPv4 and IPv6, and does not require = administrative
  privileges on most operating systems.




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=_EA7E9710-ED05-4E77-89BC-450CFEF17DDC-- From nobody Mon Mar 9 10:26:22 2015 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 C19921A90D5 for ; Mon, 9 Mar 2015 10:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hkHw3PAyI6Xy for ; Mon, 9 Mar 2015 10:26:17 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 084C01A90D9 for ; Mon, 9 Mar 2015 10:25:56 -0700 (PDT) Received: by qcvx3 with SMTP id x3so4464264qcv.0 for ; Mon, 09 Mar 2015 10:25:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=tz2SVJD+i43DhbgOS5cSaYuYz8l0jMYuOCoeOiyK05w=; b=WESpbRojXORAY0IZsJvyH8GZ5h0LpX9DH6ha/s2lNFuCoHCPMnZ7+yL6NTBGtzg5Gv 1QvXiDio6Vm/i4w1yeK5yqsIHOujAGKHOP1STnxVYbh59sEk2tHAjij1ppWUhlJqq9BH WDLkwOrinjLRG9EXtdg0XWchNVuLOK/tuWTNMmzdG7aQOryWu+eoku4THzezaXtBCj/0 z3TFSQ1CUOXojycrmbXK+wpyTYhR9UfkLl8uklfNCTNFcuwp/E3fXMc7ytOcgcBwF01H 3RlTls6Ehw6G3p2az3BZC3NgDPqQD8FHUvhAf27b6BERgdj0TG9grpfn7uoxwd5dr0P5 n1Nw== X-Gm-Message-State: ALoCoQkDLCeWR7XXt/ke+Abr7soYOi8Q/hyhW2249+NMM0oVAHgx/TOd/DxaXh69FI/EspzjzR4t X-Received: by 10.55.56.199 with SMTP id f190mr55972116qka.75.1425921955348; Mon, 09 Mar 2015 10:25:55 -0700 (PDT) Received: from [192.168.1.43] (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id e23sm11929532qhc.21.2015.03.09.10.25.53 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2015 10:25:54 -0700 (PDT) Message-ID: <54FDD7A0.4010308@jive.com> Date: Mon, 09 Mar 2015 13:25:52 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Jonathan Lennox References: <20150305201507.6192.13143.idtracker@ietfa.amsl.com> <35F68F75-51A0-48BD-B5D0-DE0A6600F13D@vidyo.com> <54FA2954.2060400@jive.com> <54FD8DAB.10807@jive.com> <525817F6-4E8F-4052-BB13-27B1F332756B@vidyo.com> In-Reply-To: <525817F6-4E8F-4052-BB13-27B1F332756B@vidyo.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: Benjamin Schwartz , "tram@ietf.org" , Justin Uberti Subject: Re: [tram] New Version Notification for draft-schwartz-tram-turnbyname-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, 09 Mar 2015 17:26:18 -0000 Le 2015-03-09 09:59, Jonathan Lennox a écrit : > On Mar 9, 2015, at 8:10 AM, Simon Perreault wrote: > >> > Le 2015-03-06 19:34, Justin Uberti a écrit : >>> >> The problem is that the STUN timeout is on the client, whereas the DNS >>> >> timeout is on the server, so the client needs to somehow be aware of the >>> >> DNS timeout in its STUN calculations. >> > >> > Why? From the client's point of view, the server is just taking longer than usual to process the request. >> > >>> >> Generally I think that we could just say that if DNS doesn't respond in >>> >> X seconds (e.g. 5), the server MUST consider the lookup to have failed >>> >> and return a 4YY error code. > According to the STUN spec (section 7.2.1 in RFC 5389, 6.2.1 in the stun-bis draft), over unreliable channels, a STUN client will consider a transaction to have failed if it gets no response after (2^(Rc-1)-1+Rm)*RTT, i.e. 79*RTT for the default values of Rc (7) and Rm (16). For short RTTs (between the client and the TURN server) that’ll likely be shorter than the DNS timeout. So what? Why does DNS timeout need to be shorter than STUN timeout? Simon From nobody Mon Mar 9 13:30:00 2015 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 E24BC1ACCE3 for ; Mon, 9 Mar 2015 13:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6H3cyEZmlwnF for ; Mon, 9 Mar 2015 13:29:57 -0700 (PDT) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1579F1AC44E for ; Mon, 9 Mar 2015 13:29:57 -0700 (PDT) Received: by qcyl6 with SMTP id l6so11772279qcy.13 for ; Mon, 09 Mar 2015 13:29:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=BsoSruwUm6fRpnPH2DE8SAeZLFbYpU65TaiRPUFgjnY=; b=Z6ahBfx6vHvgaYilnQDshy0bgTLoH4qa5k9AUltJOdMTO4hzFhqF/R5RjOsHVMBu3U IBApupixROxCzLovhxKncqM7Lx6X6xnaxkzotv0yZwfffEd5iHJf64Ms/NYfDMRfNFUX 0Fgtgsk7TRDdgU9QFMBt16dXDjYScTXBocjKz7f/YFfu7HiZNpQcHKKJsWzUfa27N2u4 iZ7fAXexsmRsPIz85uQTpBI8ii1sVX9R+s9SGt0KmspUREY6926xE4cqAxEZakXWzv5G 2JSUT3Vv5RSJetoWDD4VG6DHgT2RbY4vEwPlypxbfeTds/itExTnpIwTzjBqqSYRabr8 qkuA== X-Gm-Message-State: ALoCoQkaNigWabB/Do1SIGxAPcEN417qZVFsicaFWNxBE1LtBOnbjHEeKHz/lK3LzpBhS816Qbtc X-Received: by 10.140.37.7 with SMTP id q7mr36081937qgq.29.1425932996381; Mon, 09 Mar 2015 13:29:56 -0700 (PDT) Received: from [192.168.1.43] (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id 59sm12266497qgf.37.2015.03.09.13.29.54 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2015 13:29:54 -0700 (PDT) Message-ID: <54FE02C1.9060206@jive.com> Date: Mon, 09 Mar 2015 16:29:53 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "tram@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [tram] TRAM draft agenda posted 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, 09 Mar 2015 20:29:59 -0000 http://www.ietf.org/proceedings/92/agenda/agenda-92-tram Please let the chairs know of any problem/question/suggestion/etc. We asked for 1:30 but we got only 1:00. So it looks like we won't have much time for extracurricular drafts... Simon From nobody Mon Mar 9 13:31:05 2015 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 8E5D31ACD03; Mon, 9 Mar 2015 13:31:01 -0700 (PDT) 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 Hu5DaXhK1XSm; Mon, 9 Mar 2015 13:31:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 371581ACCF5; Mon, 9 Mar 2015 13:30:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309203059.25248.15571.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 13:30:59 -0700 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-stunbis-02.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, 09 Mar 2015 20:31:01 -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 : Session Traversal Utilities for NAT (STUN) Authors : Marc Petit-Huguenin Gonzalo Salgueiro Jonathan Rosenberg Dan Wing Rohan Mahy Philip Matthews Filename : draft-ietf-tram-stunbis-02.txt Pages : 58 Date : 2015-03-09 Abstract: Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This document obsoletes RFC 5389. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tram-stunbis-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stunbis-02 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 Mon Mar 9 13:47:03 2015 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 0E8F01A010E for ; Mon, 9 Mar 2015 13:47:02 -0700 (PDT) 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 WNxWkAK9HbWP for ; Mon, 9 Mar 2015 13:47:00 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id E26CF1A90D3 for ; Mon, 9 Mar 2015 13:46:59 -0700 (PDT) Received: from [IPv6:2602:43:2da:6400:b4a0:f53c:d004:b127] (unknown [IPv6:2602:43:2da:6400:b4a0:f53c:d004:b127]) (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 0F79D2078C for ; Mon, 9 Mar 2015 21:46:58 +0100 (CET) Message-ID: <54FE06C1.1060203@acm.org> Date: Mon, 09 Mar 2015 14:46:57 -0600 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 To: tram@ietf.org References: <20150309203059.25248.15571.idtracker@ietfa.amsl.com> In-Reply-To: <20150309203059.25248.15571.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-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, 09 Mar 2015 20:47:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 All, That's the final version until IETF 92. Theoretically there is something in this version for all the issues that were listed so far. Hopefully we can build a consensus around this text in Dallas and in the mailing-list and getting closer to the submission to the IESG. Note that there is a mistake in the Changelog of the draft. The correct one is below (s/RTP/RTO/). Thanks. Changelog: o Prevent the server to allocate the same NONCE to clients with different IP address and/or different port. This prevent sharing the nonce between TURN allocations in TURN. o Add reference to draft-ietf-uta-tls-bcp o Add a new attribute ALTERNATE-DOMAIN to verify the certificate of the ALTERNATE-SERVER after a 300 over (D)TLS. o The RTP delay between transactions applies only to parallel transactions, not to serial transactions. That prevents a 3RTT delay between the first transaction and the second transaction with long term authentication. o Add text saying ORIGIN can increase a request size beyond the MTU and so require an SCTPoUDP transport. o Add a new attribute ALTERNATE-DOMAIN to verify the certificate of the ALTERNATE-SERVER after a 300 over (D)TLS. o The RTO delay between transactions applies only to parallel transactions, not to serial transactions. That prevents a 3RTT delay between the first transaction and the second transaction with long term authentication. o Add text saying ORIGIN can increase a request size beyond the MTU and so require an SCTPoUDP transport. o Move the Acknowledgments and Contributor sections to the end of the document, in accordance with RFC 7322 section 4. On 03/09/2015 02:30 PM, internet-drafts@ietf.org wrote: > > 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 : Session Traversal Utilities for NAT (STUN) > Authors : Marc Petit-Huguenin > Gonzalo Salgueiro > Jonathan Rosenberg > Dan Wing > Rohan Mahy > Philip Matthews > Filename : draft-ietf-tram-stunbis-02.txt > Pages : 58 > Date : 2015-03-09 > > Abstract: > Session Traversal Utilities for NAT (STUN) is a protocol that serves > as a tool for other protocols in dealing with Network Address > Translator (NAT) traversal. It can be used by an endpoint to > determine the IP address and port allocated to it by a NAT. It can > also be used to check connectivity between two endpoints, and as a > keep-alive protocol to maintain NAT bindings. STUN works with many > existing NATs, and does not require any special behavior from them. > > STUN is not a NAT traversal solution by itself. Rather, it is a tool > to be used in the context of a NAT traversal solution. > > This document obsoletes RFC 5389. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tram-stunbis-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stunbis-02 > > > 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/ > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > - -- 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 iQIcBAEBCAAGBQJU/gbBAAoJECnERZXWan7EgyQQAKgeAOyk8d8gSPjDwFx0oYn9 EC5ffDxMACiHuqdDOmZGqEStFrtWtaZsXTFYGAYw5e/IWxYo5q0BYmbIJDMLgBBO CY9YALHqwIWGl3gnC8ISvxEw9wLqN6KggXDHTggmPx7rSzTbpr/ilXfrdcdmiPRM DtkV4WKjlRtKRX9zp9TE8iNr/Fyhw4/QYKD4PqMxGi5+q5d/ML3ynkA/bCJiwVYp JsQYy76ZHNleWg2PVQ7gU19t21GPs1twRa6x7M+qRaIPXvh5FiNQOcCWFN8hQCkh qgHnrLL/5vYtjfIo2MpLAHFBNCZSR1z9z/nK9R3vzG21/rgwDUnTFcxMUpPhXg8z X4qW33y7hZk4eysc59d7xLq97Vp2gOPROV2RXn/JbHJd8Q1XLlDx50X7L3WBu1RC zsfjU9coKRJyRSdfTqBddhWa6Qz46DEsDwAxCVFSvPNhHZU2QckvZECCU1B4vXB+ v1z1eORjZWoeAYWYiinDo14KoXBeMNoAZm4ir9weKq7SDGBfRkmnn3eLjEImvaSb dYolJLR++3O4i8NCSNW6qnIXGXFW1+FQTbXYlE8ulHEufsJ9EVG5zzYaeIJF3NPi 4yXIKazVo/VuZTUj0C6h+NTvD30TEjQU2gESGKQc5/FSlzdA/BOqQeKu0GlD1GV+ RoieCT7n7EoaDfWeo4sz =yUEg -----END PGP SIGNATURE----- From nobody Mon Mar 9 17:56:14 2015 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 362E41ACE8B for ; Mon, 9 Mar 2015 17:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.242 X-Spam-Level: X-Spam-Status: No, score=-0.242 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, RCVD_IN_BL_SPAMCOP_NET=1.347] 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 MRkQaRb4wyzc for ; Mon, 9 Mar 2015 17:56:11 -0700 (PDT) Received: from tsinghua.org.cn (mail.alumail.com [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id CE9F51ACE7B for ; Mon, 9 Mar 2015 17:56:10 -0700 (PDT) Received: from ctbriwangaij (unknown [124.127.116.138]) by app1 (Coremail) with SMTP id Z0GX06BbUgBmKP5U5Nd7Aw==.4229S2; Tue, 10 Mar 2015 07:10:45 +0800 (CST) From: "Aijun Wang" To: Date: Tue, 10 Mar 2015 08:55:52 +0800 Message-ID: <000701d05acc$fe283320$fa789960$@org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdBaFySvUDON/DiqRAuuWLj5RsBGZQAs2NYg Content-Language: zh-cn X-CM-TRANSID: Z0GX06BbUgBmKP5U5Nd7Aw==.4229S2 X-Coremail-Antispam: 1U3129KBjvJXoW7KFWDGFWxXF45KryDuFy5twb_yoW5JFW8pa y5Wr4aqw1ktr93CFs7Wr47u3Wru3s5CrZ7CFyUGr1UCa98Za4IqrW7tF1F9ry8WrWrGrZ0 qF1avF15Ca1rZFJanT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjQqb7 Iv0xC_Jr1l5I8CrVACY4xI64kE6c02F40Ex7xfM7kC6x804xWl14x267AKxVWUJVW8JwAF xVCF77xC6IxKo4kEV4yl1I0EscIYIxCEI4klw4CSwwAv7VCjz48v1sIEY20_GF1lx4CE17 CEb7AF67AKxVWUXVWUAwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E 14v26r1j6r4U0xZFpf9x0JUd8nOUUUUU= Archived-At: Cc: "'Liubing \(Leo\)'" Subject: [tram] FW: New Version Notification for draft-wang-tram-turnlite-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, 10 Mar 2015 00:56:13 -0000 Hi All Tramer: We updated one new version about TURNLite(lightweight TURN) architecture = and its solution to the host-to-host communication via the relay = devices. This draft summarizes also all the discussions about current = TURN solution in the TRAM mailing list, gives the main procedures of = TURNLite and two detail examples for IPv4/IPv4(under Non-BEHAVE = compliant NAT environment) and IPv4/IPv6 communication. The purpose of this draft is to design one simplified relay solution = that can easily incorporated into some distributed deployed network = devices, for example CGN devices or CDN nodes within ISP's network. Any comments for this draft are welcome, we can also discuss it with all = the Tramers in the coming IETF meeting. The URL of this update draft is here: = http://datatracker.ietf.org/doc/draft-wang-tram-turnlite/ Best Regards. Aijun Wang. -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Monday, March 09, 2015 11:14 AM To: Aijun Wang; Bing Liu; Aijun Wang; Bing Liu Subject: New Version Notification for draft-wang-tram-turnlite-02.txt A new version of I-D, draft-wang-tram-turnlite-02.txt has been = successfully submitted by Bing Liu and posted to the IETF repository. Name: draft-wang-tram-turnlite Revision: 02 Title: A Lightweight TURN Architecture and Specification (TURN-Lite) Document date: 2015-03-09 Group: Individual Submission Pages: 17 URL: = http://www.ietf.org/internet-drafts/draft-wang-tram-turnlite-02.txt Status: = https://datatracker.ietf.org/doc/draft-wang-tram-turnlite/ Htmlized: http://tools.ietf.org/html/draft-wang-tram-turnlite-02 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-wang-tram-turnlite-02 Abstract: This document proposes a new relay-based NAT traversal architecture called TURN-Lite which could simplify the data communication process between two hosts that locates behind some non-BEHAVE compliant [RFC4787] [RFC5382] NAT devices. The key mechanism in TURN-Lite is the newly defined "Couple" operation (using STUN [RFC5389] message format) which allows the TURN-Lite servers to be easily incorporated into existing CGN devices/CDN nodes which are already deployed within the network in a distributed manner. = =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. The IETF Secretariat From nobody Wed Mar 11 00:40:06 2015 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 D2B1A1A8925; Tue, 10 Mar 2015 13:00:48 -0700 (PDT) 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 TiE_UWUgDKxo; Tue, 10 Mar 2015 13:00:46 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C78031A890D; Tue, 10 Mar 2015 13:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13664; q=dns/txt; s=iport; t=1426017647; x=1427227247; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Bp8hdaXXC2IjkLzgtThe3Qq7bne9+xHLGXrN9j+g+i8=; b=Tz7GSJRgiOBt1SspWEa7JfQmxkYzh1E635XztOv7vbqEflruD1pwfHUU 3lFywF5AGrcTopw4d0DUowabtxJENOy/8XZUdBAbPDdc+4451OVAcUTUb kvGQXjRdYaCVB+cuFf9CoNhkqnxpBdNTCS4NKWkUfP/xi85CuTmIx7BXi o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A6DQCdTP9U/5NdJa1WBoMGUlUFBIMGvWuCNoUnSQIcgR1NAQEBAQEBfIQPAQEBBCMRPgUOBAIBCBEEAQEBAgIVDgMCAgIfERQBCAgCBAEJCQmIEgMRCAWpeJY7DYUoAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiXaCRIFZAQEMEBgiBoJigUUFkA+DZIQngUiBGjmCb4hTTIJRg0IjggIcgVBvAWQFGgcXBhx/AQEB X-IronPort-AV: E=Sophos;i="5.11,376,1422921600"; d="scan'208";a="130723663" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-5.cisco.com with ESMTP; 10 Mar 2015 20:00:46 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t2AK0iWl003664 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Mar 2015 20:00:44 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.249]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Tue, 10 Mar 2015 15:00:44 -0500 From: "Prashanth Patil (praspati)" To: Stephen Farrell , Gonzalo Camarillo , "Tirumaleswar Reddy (tireddy)" , "tram-chairs@ietf.org" , "tram@ietf.org" , "draft-ietf-tram-turn-third-party-authz@ietf.org" , "draft-ietf-tram-turn-third-party-authz.ad@ietf.org" , "draft-ietf-tram-turn-third-party-authz.shepherd@ietf.org" , "spencerdawkins.ietf@gmail.com" , "rlb@ipv.sx" , IESG Thread-Topic: New Version Notification - draft-ietf-tram-turn-third-party-authz-13.txt Thread-Index: AQHQWL4tvjFUyNS0DUyqeV8g7tF1BZ0R1CcAgARDXwA= Date: Tue, 10 Mar 2015 20:00:43 +0000 Message-ID: References: <913383AAA69FF945B8F946018B75898A366AA244@xmb-rcd-x10.cisco.com> <54F98585.7070203@ericsson.com> <54F9CBDF.7010705@cs.tcd.ie> <54FACD4E.8030706@ericsson.com> <54FB5778.2030405@cs.tcd.ie> In-Reply-To: <54FB5778.2030405@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.154.176.29] Content-Type: text/plain; charset="utf-8" Content-ID: <205456B22A110846B2C3BA388F1EA936@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 11 Mar 2015 00:40:04 -0700 Subject: Re: [tram] New Version Notification - draft-ietf-tram-turn-third-party-authz-13.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, 10 Mar 2015 20:00:49 -0000 SGkgU3RlcGhlbiwNCg0KT24gMy83LzE1LCAxMTo1NCBBTSwgIlN0ZXBoZW4gRmFycmVsbCIgPHN0 ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+IHdyb3RlOg0KDQo+DQo+DQo+T24gMDcvMDMvMTUgMTA6 MDUsIEdvbnphbG8gQ2FtYXJpbGxvIHdyb3RlOg0KPj4gSGksDQo+PiANCj4+IEkgYW0gYWRkaW5n IHRoZSBJRVNHIGxpc3QgdG8gdGhlIGNjOiBzbyB0aGF0IGV2ZXJ5b25lIGNhbiBmb2xsb3cgdGhl c2UNCj4+IGRpc2N1c3Npb25zLg0KPg0KPlRoYW5rcy4gQW5kIHNvcnJ5IGZvciBtaXNzaW5nIHRo aXMgYW5kIG5vdCByZXNwb25kaW5nIGJlZm9yZS4NCj4NCj4+IA0KPj4gQ2hlZXJzLA0KPj4gDQo+ PiBHb256YWxvDQo+PiANCj4+IE9uIDA2LzAzLzIwMTUgMTA6MTMgUE0sIFByYXNoYW50aCBQYXRp bCAocHJhc3BhdGkpIHdyb3RlOg0KPj4+IEhpIFN0ZXBoZW4sDQo+Pj4gV2UgZGlkIHJlc3BvbmQg dG8geW91ciBkaXNjdXNzaW9uIHBvaW50cy4gSW4gYW55IGNhc2UsIHJlc3BvbnNlcyBwYXN0ZWQN Cj4+PiBiZWxvdzoNCj4+Pg0KPj4+ICgxKSBNYWtpbmcgbm9uZSBvZiA0LjEueCBtYW5kYXRvcnkg dG8gaW1wbGVtZW50IHdpbGwNCj4+PiByZXN1bHQgaW4gYSBsYWNrIG9mIGludGVyb3AuIFdoYXQg aXMgdGhlIGRldmVsb3Blcg0KPj4+IHN1cHBvc2VkIHRvIGltcGxlbWVudD8gV2h5IGlzIGl0IG9r IHRvIG5vdCBzYXk/ICAoRm9yDQo+Pj4gZXhhbXBsZSwgZGVmaW5pbmcgNC4xLjEgYW5kIDQuMS4y IHNpbXBseSBzbyBhcyB0byBhcHBlYXINCj4+PiAibW9yZSBzZWN1cmUiIHdoaWxzdCByZWFsbHkg ZXhwZWN0aW5nIDQuMS4zIHRvIGJlIHVzZWQsDQo+Pj4gYnV0IG5vdCBzYXlpbmcgc28sIHdvdWxk IHNlZW0gbGlrZSBhIGJhZCBwbGFuIHRvIG1lLikNCj4+Pg0KPj4+ICANCj4+PiBSZXNwb25zZT4g U2VjdGlvbnMgNC4xLnggYXJlIG9ubHkgbWVhbnQgdG8gYmUgZXhhbXBsZXMgb2YgbWVjaGFuaXNt cw0KPj4+dGhhdA0KPj4+IGNvdWxkIGJlIHBvdGVudGlhbGx5IHVzZWQuIFRoZSBhdXRob3JzIGRv bsK5dCBoYXZlIGEgcHJlZmVyZW5jZSBvZiBvbmUNCj4+Pm92ZXINCj4+PiB0aGUgb3RoZXJzLCAN Cj4NCj5UaGF0J3Mgbm90IGdvaW5nIHRvIGdldCB1cyBpbnRlcm9wIHRob3VnaCBpcyBpdD8gQW5k IGludGVyb3AgaXMNCj5uZWVkZWQgaGVyZSAtIHdlIGhhdmUgdGhlIGJyb3dzZXIsIHRoZSB3ZWIt c2l0ZSBhbmQgdGhlIFRVUk4vU1RVTg0KPnNlcnZlciBhbGwgaW52b2x2ZWQuIEkgdGhpbmsgeW91 IG5lZWQgb25lIG1lY2hhbmlzbSB0aGF0IGlzIE1USQ0KPmFuZCB0aGF0IGlzIFJFQ09NTUVOREVE IHRvIHVzZSBmb3IgdGhpcyB0byBiZSB1c2VmdWwuDQoNCldlIGNhbiBjZXJ0YWlubHkgUkVDT01N RU5EIDQuMS4yIChSRVNUKS4gSG93ZXZlciwgdGhlIHN1Z2dlc3Rpb24gZnJvbQ0KT0FVVEcgV0cg aXMgdG8gbm90IG1hbmRhdGUgb25lDQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93 ZWIvb2F1dGgvY3VycmVudC9tc2cxNDMyNS5odG1sLg0KDQpTZWN0aW9uIDQgd2FzIG9yaWdpbmFs bHkgbWVhbnQgdG8gcHJvdmlkZSBleGFtcGxlcyBmb3Iga2V5IGVzdGFibGlzaG1lbnQuDQpUVVJO IHN0YW5kYXJkaXphdGlvbiBoYXMgbm8gZGVwZW5kZW5jeSBvbiB0aGUgZXN0YWJsaXNobWVudCBw cm9jZWR1cmUuIEluDQp3b3VsZCBzZWVtIHRoYXQgYSByZWxheSBzZXJ2aWNlIHByb3ZpZGVyIHdp bGwgcHJvYmFibHkgdXNlIHdoaWNoZXZlcg0KbWV0aG9kKHMpIGZvciBrZXkgZXhjaGFuZ2UgdGhl aXIgY3VzdG9tZXJzIGFyZQ0Kd2lsbGluZyB0byBhY2NlcHQuDQoNCldlIGNvdWxkIGVpdGhlciBy ZW1vdmUgdGhpcyBjb21wbGV0ZWx5LCBvciBtb3ZlIHRoaXMgc2VjdGlvbiB0byBhcHBlbmRpeCwN CmlmIHRoYXQgaGVscHMuDQoNCg0KPg0KPj4+IDQuMS4yIChSRVNUKSBjb3VsZCBiZSBzb21ldGhp bmcgdGhhdCBjYW4gYmUgcmVjb21tZW5kZWQgdG8gYmUNCj4+PiBpbXBsZW1lbnRlZCAoZWFzeSB0 byBkZXZlbG9wIGFuZCBwcm92aWRlcyBhbGdvcml0aG0gYWdpbGl0eSkuDQo+Pj4NCj4+PiAoMikg V2hhdCBpcyB0aGUgc3RhdHVzIG9mIEFwcGVuZGl4IEI/IEFtIEkgc3VwcG9zZWQgdG8NCj4+PiBp bXBsZW1lbnQgdGhhdD8gV2hhdCBkb2VzICJDbGllbnQgY291bGQuLi4iIG1lYW4/DQo+Pj4NCj4+ PiAgDQo+Pj4gUmVzcG9uc2U+IEFwcGVuZGl4IEIgaXMgb25seSBtZWFudCB0byBiZSBwcm92aWRl IGFuIGlsbHVzdHJhdGlvbiBvZg0KPj4+IGludGVyYWN0aW9uIGJldHdlZW4gdGhlIFdlYlJUQyBj bGllbnQgYW5kIGF1dGhvcml6YXRpb24gc2VydmVyIChXZWJSVEMNCj4+PiBzZXJ2ZXIpLiANCj4N Cj5UaGUgdXNlIG9mIHRoZSBBUyB0ZXJtIGluIFdlYlJUQyBpcyB1bnVzdWFsLiBTdWZmaWNpZW50 bHkgc28gYXMgdG8NCj5iZSBhIGJhZCBpZGVhIEkgdGhpbmsuIChBbmQgb25lIGNvdWxkIHdvbmRl ciBhYm91dCB3aG8gaXMgdGhlIHJlYWwNCj5yZXNvdXJjZSBvd25lciBpbiBXZWJSVEMgLSBJIGRv bid0IHRoaW5rIGl0J3MgdGhlIHdlYiBzaXRlIHRoYXQgc2V0cw0KPnVwIHRoZSBjYWxscyBteXNl bGYuKQ0KDQpUaGUgcmVzb3VyY2Ugc2VydmVyIGlzIHRoZSBUVVJOIHNlcnZlciwgb3duZWQgYnkg dGhlIFdlYlJUQyBzZXJ2aWNlIChvcg0KdGhlIFRVUk4gYW5kIFdlYlJUQyBzZXJ2aWNlIHByb3Zp ZGVycyBjb3VsZCBoYXZlIGEgYnVzaW5lc3MgcmVsYXRpb25zaGlwLikNCg0KDQo+DQo+Pj4gUGxl YXNlIG5vdGUgdGhhdCB0aGUgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIHRoZSB0d28gaXMNCj4+PiBw cm9wcmlldGFyeSwgV2ViUlRDIGRvZXMgbm90IG1hbmRhdGUgYW55IHNpZ25hbGluZyBwcm90b2Nv bC4NCj4NCj5IbW0uIEknbSBub3Qgc3VyZSBJIHNlZSB0aGUgYmVuZWZpdCBvZiBpbmNsdWRpbmcg dGhhdCwgaWYgeW91J3JlDQo+cmlnaHQgYWJvdmUuDQo+DQo+Pj4NCj4+PiAoMykgSW4gdGhlIHNl Y2RpciByZXZpZXcgWzFdIGRpc2N1c3Npb24sIEkgc2VlIHRoZSBhdXRob3JzDQo+Pj4gbWVudGlv biBhZGRpbmcgRUNDLCBidXQgSSBzZWUgbm90aGluZyBpbiB0aGUgZHJhZnQuIEkNCj4+PiBkb24n dCBiZWxpZXZlIHRoYXQgdGhhdCBkaXNjdXNzaW9uIGhhcyByZWFsbHkgZW5kZWQgYW5kDQo+Pj4g d291bGQgbGlrZSB0byBjb250aW51ZSBpdC4gV2h5IGlzIHRoZSBXZWJSVEMgc2VydmVyIG5vdA0K Pj4+IHNpbXBseSBzaWduaW5nIHNvbWV0aGluZyBmb3IgdGhlIFNUVU4gc2VydmVyIHRvIHZlcmlm eT8NCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NlY2Rpci9jdXJy ZW50L21zZzA1NDI1Lmh0bWwNCj4+Pg0KPj4+ICANCj4+PiBSZXNwb25zZT4gV2UgZGlkIGhhdmUg YW4gb2ZmbGluZSBkaXNjdXNzaW9uIHdpdGggWWFyb24gU2hlZmZlciAod2hvIGhhZA0KPj4+IHN1 Z2dlc3RlZCBFQ0MpLiBFQ0RILUVTIGNhbiBiZSB1c2VkIHRvIGFncmVlIHVwb24gYSBzeW1tZXRy aWMga2V5IGZvcg0KPj4+IGVuY3J5cHRpbmcvZGVjcnlwdGluZyB0aGUgdG9rZW4gYW5kIEVDRFNB IHRvIGdlbmVyYXRlIGRpZ2l0YWwgc2lnbmF0dXJlDQo+Pj4gZm9yIHRoZSB0b2tlbi4gQnV0IHRo aXMgd291bGQgcmVzdWx0IGluIGEgc3ltbWV0cmljIGtleSwganVzdCBsaWtlIHRoZQ0KPj4+IGFw cHJvYWNoZXMgZGVzY3JpYmVkIGluIDQuMS4xIGFuZCA0LjEuMi4gV2XCuXZlIGhlbmNlIGRlY2lk ZWQgbm90IHRvDQo+Pj4gaW5jbHVkZSBhbnkgZGV0YWlscyBwZXJ0YWluaW5nIHRvIEVDQy4NCj4N Cj5FQ0RTQSBpcyBhIHNpZ25hdHVyZSBzY2hlbWUuIE5vIHN5bW1ldHJpYyBrZXkgd291bGQgYmUg bmVlZGVkLiBTbw0KPkknbSBub3QgZm9sbG93aW5nIHlvdXIgbG9naWMgdGhlcmUgdGJoLiBBdCBs ZWFzdCBhdCBhIGhpZ2ggbGV2ZWwsDQo+YSBzaWduYXR1cmUgc2NoZW1lIG1ha2VzIGEgbG90IG9m IHNlbnNlIGluIHRoaXMgY2FzZS4NCg0KVGhlIHRva2VuIG5lZWRzIHRvIGJlIGVuY3J5cHRlZCBh bmQgYXV0aGVudGljYXRlZC4gRUNEU0Egb25seSBnZW5lcmF0ZXMNCnNpZ25hdHVyZSBmb3IgdGhl IHRva2VuLiBXZSBuZWVkIEVDREggdG8gYWdyZWUgdXBvbiBhIHN5bW1ldHJpYyBrZXkgZm9yDQpl bmNyeXB0aW5nL2RlY3J5cHRpb24uIFN5bW1ldHJpYyBrZXlzIHdvdWxkIHJlc3VsdCBpbiBhcHBy b2FjaGVzIHZlcnkNCnNpbWlsYXIgdG8gdGhlIG9uZXMgZGVzY3JpYmVkIGluIDQuMS4xIGFuZCA0 LjEuMi4NCg0KLVByYXNoYW50aA0KDQoNCg0KPg0KPkNoZWVycywNCj5TLg0KPg0KPlBTOiBXZSBj YW4gY292ZXIgdGhlIGNvbW1lbnRzIGJlbG93IGxhdGVyLCB3aGVuIHRoZSBkaXNjdXNzIHBvaW50 cw0KPmFyZSBzb3J0ZWQuDQo+DQo+Pj4NCj4+PiAgDQo+Pj4gSW50cm86ICJpbXBvc3NpYmxlIGlu IHdlYiBhcHBsaWNhdGlvbnMiIGlzbid0IHJlYWxseQ0KPj4+IHRydWUgaW4gcHJpbmNpcGxlLCBi dXQgaW1wb3NzaWJsZSBpbiBXZWJSVEMgYXMgaXQgdXNlcyBKUw0KPj4+IGlzIHRydWUuIA0KPj4+ DQo+Pj4gUmVzcG9uc2U+IFllcy4gSXQgaXMgbm90IHBvc3NpYmxlIGZvciBXZWJSVEMgYXMgaXQg dXNlcyBKUy4gV2XCuWxsDQo+Pj5jb3JyZWN0DQo+Pj4gaXQuDQo+Pj4gIA0KPj4+IE5FVzoNCj4+ PiAiSG93ZXZlciwgaW4gd2ViIGFwcGxpY2F0aW9ucyBsaWtlIFdlYlJUQyBbSS1ELmlldGYtcnRj d2ViLW92ZXJ2aWV3XQ0KPj4+d2hlcmUNCj4+PiBKYXZhU2NyaXB0IHVzZXMgdGhlIGJyb3dzZXIg ZnVuY3Rpb25hbGl0eSB0byBtYWtlIHJlYWwtdGltZSBhdWRpbw0KPj4+YW5kL29yDQo+Pj4gdmlk ZW8gY2FsbHMsIFdlYiBjb25mZXJlbmNpbmcsIGFuZCBkaXJlY3QgZGF0YSB0cmFuc2ZlciwgZW5z dXJpbmcgdGhpcw0KPj4+IHNlY3JlY3kgaXMgdHlwaWNhbGx5IG5vdCBwb3NzaWJsZS4iDQo+Pj4N Cj4+PiAtIDQuMS4yIC0gd2hpY2ggInR3byBzZXJ2ZXJzIj8gV2ViUlRDIGNhbiBoYXZlIG1vcmUN Cj4+PiBzZXJ2ZXJzIHRoYW4gdGhhdC4NCj4+Pg0KPj4+ICANCj4+PiBSZXNwb25zZT4gVGhlIFNU VU4gc2VydmVyIGFuZCB0aGUgQVMuIEFzIGZhciBhcyB0aGUgU1RVTiBzZXJ2ZXIgaXMNCj4+PiBj b25jZXJuZWQsIGl0IG9ubHkgZGVhbHMgd2l0aCB0aGUgQVMgb2YgaW50ZXJlc3QgZm9yIGtleSBl c3RhYmxpc2htZW50Lg0KPj4+IFRoZSBBUyBjb3VsZCBiZSB0aGUgYXBwbGljYXRpb24gc2VydmVy IGl0c2VsZiBvciBjb3VsZCBiZSBhIEtleQ0KPj4+bWFuYWdlbWVudA0KPj4+IGZ1bmN0aW9uIHN5 bmNpbmcgdGhlIGtleWluZyBtYXRlcmlhbCB0byB0aGUgV2ViUlRDIHNlcnZlcnMuDQo+Pj4NCj4+ PiAtIDQuMS4yIC0gbm93IHdlJ3JlIHVzaW5nIFRMUyBtdXR1YWwgYXV0aD8gQW5kIGhvdyBkb2Vz DQo+Pj4gdGhlIFRMUyBjbGllbnQga25vdyB3aGljaCBDQSB0byB1c2UgdGhhdCdsbCB3b3JrIHdp dGggdGhlDQo+Pj4gVExTIHNlcnZlciBoZXJlPyBJIGRvbid0IHRoaW5rIHRoYXQnbGwgc2NhbGUg d2lsbCBpdD8NCj4+Pg0KPj4+ICANCj4+PiBSZXNwb25zZT4gV2UgcHJlc3VtZSB0aGUgdHdvIHBh cnRpZXMgaW52b2x2ZWQga25vdyB3aGF0IENBIHRvIGNvbnNpZGVyDQo+Pj4gd2hlbiB1c2luZyB0 aGUgUkVTVCBBUElzIMKtIHRoZXkgd291bGQgaGF2ZSB0byBkbyB0aGlzIHRvIHRydXN0IGVhY2gN Cj4+Pm90aGVyLg0KPj4+IFBsZWFzZSBub3RlIHRoYXQgdGhlIEFTIGlzIGFsbG9jYXRpbmcgc3lt bWV0cmljIGtleXMgbWVhbnQgZXhjbHVzaXZlbHkNCj4+PmZvcg0KPj4+IHRoYXQgU1RVTiBTZXJ2 ZXIsIHNvIHNvbWUgbGV2ZWwgb2YgY28tb3JkaW5hdGlvbiBpcyBhbHJlYWR5IGludm9sdmVkLg0K Pj4+DQo+Pj4gLSA0LjEuMyAtIHRoaXMgbG9va3MgbGlrZSB3aGF0IHRoZSBXRy9hdXRob3JzIHJl YWxseSB3YW50LA0KPj4+IHdvdWxkIHRoYXQgYmUgYSBmYWlyIHN0YXRlbWVudD8NCj4+Pg0KPj4+ ICANCj4+PiBSZXNwb25zZT4gTm8uIFRoZSDFkk5vdGU6wrkgYXQgdGhlIGVuZCBvZiB0aGUgc2Vj dGlvbiBpcyBwcm9iYWJseQ0KPj4+IG1pc2xlYWRpbmcsIHdpbGwgdXBkYXRlIGl0Lg0KPj4+ICAN Cj4+PiBORVc6DQo+Pj4gIk5vdGUgOiBUaGUgbWVjaGFuaXNtIHNwZWNpZmllZCBpbiBTZWN0aW9u IDQuMS4zIGxhY2tzIGVuY3J5cHRpb24gYW5kDQo+Pj5ITUFDDQo+Pj4gYWxnb3JpdGhtIGFnaWxp dHkuIg0KPj4+DQo+Pj4gLSA5OiBGaWd1cmUgMiBzaG91bGQgYmUgd2F5IHVwIGF0IHRoZSB0b3Ag b2YgdGhlIGRvY3VtZW50DQo+Pj4gYW5kIG5vdCBoZXJlDQo+Pj4NCj4+PiAgDQo+Pj4gUmVzcG9u c2U+IEluIHRoZSBwcmV2aW91cyB2ZXJzaW9ucyBpdCB3YXMgaW4gdGhlIHRvcCBvZiB0aGUgZG9j dW1lbnQNCj4+PmJ1dA0KPj4+IG1vdmVkIGRvd24gYWZ0ZXIgY29tbWVudHMgcmVjZWl2ZWQgZnJv bSB0aGUgV0cgdGhhdCBXZWJSVEMgaXMgb25seSBhbg0KPj4+IGV4YW1wbGUgdXNhZ2Ugb2YgdGhp cmQgcGFydHkgYXV0aG9yaXphdGlvbi4NCj4+Pg0KPj4+IC0gOTogV2h5IDUgc2Vjb25kcz8NCj4+ Pg0KPj4+ICANCj4+PiBSZXNwb25zZT4gU1RVTiBtZXNzYWdlcyBjYW4gYmUgc2VudCBvdmVyIFVE UCwgNSBzZWNvbmRzIGlzIHRvDQo+Pj5hY2NvbW1vZGF0ZQ0KPj4+IHBhY2tldCBsb3NzIGFuZCBS VE8gaW50ZXJ2YWwuDQo+Pj4NCj4+PiAgDQo+Pj4gLSBBc3N1bWluZyB0aGUgQVMgdGhhdCBjYW4g YXV0aG9yaXplIHRoZSB1c2VyIHNoYXJlcyBhDQo+Pj4gc2VjcmV0IHdpdGggdGhlIFNUVU4gc2Vy dmVyIGNob3NlbiBieSB0aGUgV2ViUlRDIHNlcnZlcg0KPj4+IHNlZW1zIHZlcnkgYnJpdHRsZS4g V2h5IHdvdWxkIHRoYXQgYmUgdHJ1ZSBpbiBnZW5lcmFsPw0KPj4+DQo+Pj4gIA0KPj4+IFJlc3Bv bnNlPiBUaGUgQVMgYW5kIFdlYlJUQyBzZXJ2ZXIgYXJlIGluIHRoZSBzYW1lIGFkbWluaXN0cmF0 aXZlDQo+Pj5kb21haW4NCj4+PiBvZiB0aGUgYXBwbGljYXRpb24gcHJvdmlkZXIuIFRoZSB1c2Vy IG5ldmVyIHNlbmRzIHRoZSBzZXNzaW9uIGtleQ0KPj4+bGVhcm5lZA0KPj4+IGZyb20gdGhlIEFT IHRvIHRoZSBTVFVOIHNlcnZlciBpdCBvbmx5IHVzZXMgdGhlIHNlc3Npb24ga2V5IHRvIGNvbXB1 dGUNCj4+PiBtZXNzYWdlIGludGVncml0eSBvZiBTVFVOIHJlcXVlc3QgYW5kIHRvIHZhbGlkYXRl IHRoZSBtZXNzYWdlDQo+Pj5pbnRlZ3JpdHkgb2YNCj4+PiB0aGUgU1RVTiByZXNwb25zZS4gVGhl IFNUVU4gc2VydmVyIHdpbGwgb25seSBrbm93IHRoZSBzZXNzaW9uIGtleSBpZiBpdA0KPj4+IGNh biBkZWNyeXB0IHRoZSB0b2tlbi4NCj4+Pg0KPj4+DQo+Pj4gLVByYXNoYW50aA0KPj4+DQo+Pj4g T24gMy82LzE1LCA3OjQ2IEFNLCAiU3RlcGhlbiBGYXJyZWxsIiA8c3RlcGhlbi5mYXJyZWxsQGNz LnRjZC5pZT4NCj4+Pndyb3RlOg0KPj4+DQo+Pj4+DQo+Pj4+IEhleSwNCj4+Pj4NCj4+Pj4gIzEg LSBub3BlLCB0aGF0IHZlcnNpb24gZG9lc24ndCBhZGRyZXNzIHRoaW5ncyB0aGF0IEkgY2FuIHNl ZQ0KPj4+PiAoYW5kIEkndmUgbm90IHNlZW4gYSBkaXJlY3QgcmVzcG9uc2UgdG8gbXkgZGlzY3Vz cyBwb2ludHMgdGhhdA0KPj4+PiBJIHJlY2FsbCkNCj4+Pj4NCj4+Pj4gIzIgLSBJIHNlbnQgYW4g YXNrIHRvIHRoZSBzYWFnIGxpc3QganVzdCBub3csIChhdHRhY2hlZCkgd2lsbA0KPj4+PiBsZXQg eW91IGtub3cgaWYgSSBnZXQgb2ZmZXJzLiBQbGVhc2UgYWxzbyBwaW5nIG1lIGlmIHlvdSBnZXQN Cj4+Pj4gYW55IGRpcmVjdCwganVzdCBzbydzIHdlIGRvbid0IGNyb3NzIHN0cmVhbXMuDQo+Pj4+ DQo+Pj4+IFMuDQo+Pj4+DQo+Pj4+IE9uIDA2LzAzLzE1IDEwOjQ2LCBHb256YWxvIENhbWFyaWxs byB3cm90ZToNCj4+Pj4+IFN0ZXBoZW4sIFJpY2hhcmQsDQo+Pj4+Pg0KPj4+Pj4geW91IGhhdmUg ZGlzY3Vzc2VzIG9uIHRoaXMgZHJhZnQ6DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IA0KPj4+Pj5odHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1w YXJ0eS1hdXRoDQo+Pj4+PnovYg0KPj4+Pj4gYWxsb3QvDQo+Pj4+Pg0KPj4+Pj4gQ291bGQgeW91 IHBsZWFzZSBsb29rIGF0IHRoZSBuZXcgcmV2aXNpb24gVGlydSBoYXMgcHV0IHRvZ2V0aGVyIGFu ZA0KPj4+Pj5sZXQNCj4+Pj4+IGhpbSBrbm93IGlmIHlvdSBhcmUgaGFwcHkgd2l0aCBpdD8NCj4+ Pj4+DQo+Pj4+PiBUaGFua3MsDQo+Pj4+Pg0KPj4+Pj4gR29uemFsbw0KPj4+Pj4NCj4+Pj4+IE9u IDI4LzAyLzIwMTUgNToxMCBBTSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSB3cm90ZToN Cj4+Pj4+PiBXZSBoYXZlIHJlc3BvbmRlZCB0byBjb21tZW50cyBmcm9tIElTRUcgYW5kIHB1Ymxp c2hlZCB1cGRhdGVkIGRyYWZ0Lg0KPj4+Pj4+DQo+Pj4+Pj4gLVRpcnUNCj4+Pj4+Pg0KPj4+Pj4+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+PiBGcm9tOiBpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+Pj4+Pj4+IFNl bnQ6IFRodXJzZGF5LCBGZWJydWFyeSAyNiwgMjAxNSAxMDoyNiBBTQ0KPj4+Pj4+PiBUbzogdHJh bS1jaGFpcnNAaWV0Zi5vcmc7IHRyYW1AaWV0Zi5vcmc7DQo+Pj4+Pj4+IGRyYWZ0LWlldGYtdHJh bS10dXJuLXRoaXJkLXBhcnR5LQ0KPj4+Pj4+PiBhdXRoekBpZXRmLm9yZzsgZ29uemFsby5jYW1h cmlsbG9AZXJpY3Nzb24uY29tOw0KPj4+Pj4+PiBkcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC0N Cj4+Pj4+Pj4gcGFydHktYXV0aHouYWRAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtdHJhbS10dXJuLXRo aXJkLXBhcnR5LQ0KPj4+Pj4+PiBhdXRoei5zaGVwaGVyZEBpZXRmLm9yZzsgc3BlbmNlcmRhd2tp bnMuaWV0ZkBnbWFpbC5jb207IHJsYkBpcHYuc3g7DQo+Pj4+Pj4+IHN0ZXBoZW4uZmFycmVsbEBj cy50Y2QuaWUNCj4+Pj4+Pj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIC0NCj4+ Pj4+Pj4gZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHotDQo+Pj4+Pj4+IDEz LnR4dA0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiBBIG5ldyB2ZXJzaW9uICgtMTMpIGhhcyBi ZWVuIHN1Ym1pdHRlZCBmb3INCj4+Pj4+Pj4gZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFy dHktDQo+Pj4+Pj4+IGF1dGh6Og0KPj4+Pj4+Pg0KPj4+Pj4+PiANCj4+Pj4+Pj5odHRwOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0 eQ0KPj4+Pj4+Pi1hdQ0KPj4+Pj4+PiB0aHotDQo+Pj4+Pj4+IDEzLnR4dA0KPj4+Pj4+Pg0KPj4+ Pj4+PiBTdWIgc3RhdGUgaGFzIGJlZW4gY2hhbmdlZCB0byBBRCBGb2xsb3d1cCBmcm9tIFJldmlz ZWQgSUQgTmVlZGVkDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IFRoZSBJRVRGIGRhdGF0cmFj a2VyIHBhZ2UgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6DQo+Pj4+Pj4+DQo+Pj4+Pj4+IA0K Pj4+Pj4+Pmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHJhbS10 dXJuLXRoaXJkLXBhcnR5LWF1DQo+Pj4+Pj4+dGh6DQo+Pj4+Pj4+IC8NCj4+Pj4+Pj4NCj4+Pj4+ Pj4gRGlmZiBmcm9tIHByZXZpb3VzIHZlcnNpb246DQo+Pj4+Pj4+DQo+Pj4+Pj4+IA0KPj4+Pj4+ Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdHJhbS10dXJuLXRo aXJkLXBhcnR5LWF1DQo+Pj4+Pj4+dGh6DQo+Pj4+Pj4+IC0xMw0KPj4+Pj4+Pg0KPj4+Pj4+PiBQ bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg dGltZSBvZg0KPj4+Pj4+PiBzdWJtaXNzaW9uDQo+Pj4+Pj4+IHVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCj4+Pj4+Pj50b29scy5pZXRmLm9yZy4N Cj4+Pj4+Pj4NCj4+Pj4+Pj4gSUVURiBTZWNyZXRhcmlhdC4NCj4+Pj4+Pg0KPj4+Pj4NCj4+Pg0K Pj4gDQoNCg== From nobody Wed Mar 11 00:40:07 2015 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 724C11A89A3; Tue, 10 Mar 2015 13:40:55 -0700 (PDT) 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 QyDDxo8vUaMF; Tue, 10 Mar 2015 13:40:52 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87E601A899D; Tue, 10 Mar 2015 13:40:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2BEE3BEA4; Tue, 10 Mar 2015 20:40:51 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzo8noSr6cq1; Tue, 10 Mar 2015 20:40:48 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.46.19.44]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5F678BEA1; Tue, 10 Mar 2015 20:40:48 +0000 (GMT) Message-ID: <54FF56D0.80306@cs.tcd.ie> Date: Tue, 10 Mar 2015 20:40:48 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Prashanth Patil (praspati)" , Gonzalo Camarillo , "Tirumaleswar Reddy (tireddy)" , "tram-chairs@ietf.org" , "tram@ietf.org" , "draft-ietf-tram-turn-third-party-authz@ietf.org" , "draft-ietf-tram-turn-third-party-authz.ad@ietf.org" , "draft-ietf-tram-turn-third-party-authz.shepherd@ietf.org" , "spencerdawkins.ietf@gmail.com" , "rlb@ipv.sx" , IESG References: <913383AAA69FF945B8F946018B75898A366AA244@xmb-rcd-x10.cisco.com> <54F98585.7070203@ericsson.com> <54F9CBDF.7010705@cs.tcd.ie> <54FACD4E.8030706@ericsson.com> <54FB5778.2030405@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Wed, 11 Mar 2015 00:40:04 -0700 Subject: Re: [tram] New Version Notification - draft-ietf-tram-turn-third-party-authz-13.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, 10 Mar 2015 20:40:55 -0000 Hiya, On 10/03/15 20:00, Prashanth Patil (praspati) wrote: > Hi Stephen, > > On 3/7/15, 11:54 AM, "Stephen Farrell" wrote: > >> >> >> On 07/03/15 10:05, Gonzalo Camarillo wrote: >>> Hi, >>> >>> I am adding the IESG list to the cc: so that everyone can follow these >>> discussions. >> >> Thanks. And sorry for missing this and not responding before. >> >>> >>> Cheers, >>> >>> Gonzalo >>> >>> On 06/03/2015 10:13 PM, Prashanth Patil (praspati) wrote: >>>> Hi Stephen, >>>> We did respond to your discussion points. In any case, responses pasted >>>> below: >>>> >>>> (1) Making none of 4.1.x mandatory to implement will >>>> result in a lack of interop. What is the developer >>>> supposed to implement? Why is it ok to not say? (For >>>> example, defining 4.1.1 and 4.1.2 simply so as to appear >>>> "more secure" whilst really expecting 4.1.3 to be used, >>>> but not saying so, would seem like a bad plan to me.) >>>> >>>> >>>> Response> Sections 4.1.x are only meant to be examples of mechanisms >>>> that >>>> could be potentially used. The authors don¹t have a preference of one >>>> over >>>> the others, >> >> That's not going to get us interop though is it? And interop is >> needed here - we have the browser, the web-site and the TURN/STUN >> server all involved. I think you need one mechanism that is MTI >> and that is RECOMMENDED to use for this to be useful. > > We can certainly RECOMMEND 4.1.2 (REST). However, the suggestion from > OAUTG WG is to not mandate one > http://www.ietf.org/mail-archive/web/oauth/current/msg14325.html. Yes, I saw that. And it's a bogus suggestion. OAuth may be a framework but WebRTC is not and nor is the STUN/TURN part of WebRTC. I think you need to pick one (or more) MTI scheme. And one that provides better security than we have today with STUN/TURN. The only answer I can think of for that is a signature based scheme to be honest. > > Section 4 was originally meant to provide examples for key establishment. > TURN standardization has no dependency on the establishment procedure. In > would seem that a relay service provider will probably use whichever > method(s) for key exchange their customers are > willing to accept. Sorry - are you assuming some particular business model? I'm not sure that's a valid assumption for WebRTC, nor for STUN/TURN in general. > > We could either remove this completely, or move this section to appendix, > if that helps. > > >> >>>> 4.1.2 (REST) could be something that can be recommended to be >>>> implemented (easy to develop and provides algorithm agility). >>>> >>>> (2) What is the status of Appendix B? Am I supposed to >>>> implement that? What does "Client could..." mean? >>>> >>>> >>>> Response> Appendix B is only meant to be provide an illustration of >>>> interaction between the WebRTC client and authorization server (WebRTC >>>> server). >> >> The use of the AS term in WebRTC is unusual. Sufficiently so as to >> be a bad idea I think. (And one could wonder about who is the real >> resource owner in WebRTC - I don't think it's the web site that sets >> up the calls myself.) > > The resource server is the TURN server, owned by the WebRTC service (or > the TURN and WebRTC service providers could have a business relationship.) > > >> >>>> Please note that the communication between the two is >>>> proprietary, WebRTC does not mandate any signaling protocol. >> >> Hmm. I'm not sure I see the benefit of including that, if you're >> right above. >> >>>> >>>> (3) In the secdir review [1] discussion, I see the authors >>>> mention adding ECC, but I see nothing in the draft. I >>>> don't believe that that discussion has really ended and >>>> would like to continue it. Why is the WebRTC server not >>>> simply signing something for the STUN server to verify? >>>> https://www.ietf.org/mail-archive/web/secdir/current/msg05425.html >>>> >>>> >>>> Response> We did have an offline discussion with Yaron Sheffer (who had >>>> suggested ECC). ECDH-ES can be used to agree upon a symmetric key for >>>> encrypting/decrypting the token and ECDSA to generate digital signature >>>> for the token. But this would result in a symmetric key, just like the >>>> approaches described in 4.1.1 and 4.1.2. We¹ve hence decided not to >>>> include any details pertaining to ECC. >> >> ECDSA is a signature scheme. No symmetric key would be needed. So >> I'm not following your logic there tbh. At least at a high level, >> a signature scheme makes a lot of sense in this case. > > The token needs to be encrypted and authenticated. Why encrypted? What needs confidentiality? Ta, S. > ECDSA only generates > signature for the token. We need ECDH to agree upon a symmetric key for > encrypting/decryption. Symmetric keys would result in approaches very > similar to the ones described in 4.1.1 and 4.1.2. > > -Prashanth > > > >> >> Cheers, >> S. >> >> PS: We can cover the comments below later, when the discuss points >> are sorted. >> >>>> >>>> >>>> Intro: "impossible in web applications" isn't really >>>> true in principle, but impossible in WebRTC as it uses JS >>>> is true. >>>> >>>> Response> Yes. It is not possible for WebRTC as it uses JS. We¹ll >>>> correct >>>> it. >>>> >>>> NEW: >>>> "However, in web applications like WebRTC [I-D.ietf-rtcweb-overview] >>>> where >>>> JavaScript uses the browser functionality to make real-time audio >>>> and/or >>>> video calls, Web conferencing, and direct data transfer, ensuring this >>>> secrecy is typically not possible." >>>> >>>> - 4.1.2 - which "two servers"? WebRTC can have more >>>> servers than that. >>>> >>>> >>>> Response> The STUN server and the AS. As far as the STUN server is >>>> concerned, it only deals with the AS of interest for key establishment. >>>> The AS could be the application server itself or could be a Key >>>> management >>>> function syncing the keying material to the WebRTC servers. >>>> >>>> - 4.1.2 - now we're using TLS mutual auth? And how does >>>> the TLS client know which CA to use that'll work with the >>>> TLS server here? I don't think that'll scale will it? >>>> >>>> >>>> Response> We presume the two parties involved know what CA to consider >>>> when using the REST APIs ­ they would have to do this to trust each >>>> other. >>>> Please note that the AS is allocating symmetric keys meant exclusively >>>> for >>>> that STUN Server, so some level of co-ordination is already involved. >>>> >>>> - 4.1.3 - this looks like what the WG/authors really want, >>>> would that be a fair statement? >>>> >>>> >>>> Response> No. The Å’Note:¹ at the end of the section is probably >>>> misleading, will update it. >>>> >>>> NEW: >>>> "Note : The mechanism specified in Section 4.1.3 lacks encryption and >>>> HMAC >>>> algorithm agility." >>>> >>>> - 9: Figure 2 should be way up at the top of the document >>>> and not here >>>> >>>> >>>> Response> In the previous versions it was in the top of the document >>>> but >>>> moved down after comments received from the WG that WebRTC is only an >>>> example usage of third party authorization. >>>> >>>> - 9: Why 5 seconds? >>>> >>>> >>>> Response> STUN messages can be sent over UDP, 5 seconds is to >>>> accommodate >>>> packet loss and RTO interval. >>>> >>>> >>>> - Assuming the AS that can authorize the user shares a >>>> secret with the STUN server chosen by the WebRTC server >>>> seems very brittle. Why would that be true in general? >>>> >>>> >>>> Response> The AS and WebRTC server are in the same administrative >>>> domain >>>> of the application provider. The user never sends the session key >>>> learned >>>> from the AS to the STUN server it only uses the session key to compute >>>> message integrity of STUN request and to validate the message >>>> integrity of >>>> the STUN response. The STUN server will only know the session key if it >>>> can decrypt the token. >>>> >>>> >>>> -Prashanth >>>> >>>> On 3/6/15, 7:46 AM, "Stephen Farrell" >>>> wrote: >>>> >>>>> >>>>> Hey, >>>>> >>>>> #1 - nope, that version doesn't address things that I can see >>>>> (and I've not seen a direct response to my discuss points that >>>>> I recall) >>>>> >>>>> #2 - I sent an ask to the saag list just now, (attached) will >>>>> let you know if I get offers. Please also ping me if you get >>>>> any direct, just so's we don't cross streams. >>>>> >>>>> S. >>>>> >>>>> On 06/03/15 10:46, Gonzalo Camarillo wrote: >>>>>> Stephen, Richard, >>>>>> >>>>>> you have discusses on this draft: >>>>>> >>>>>> >>>>>> >>>>>> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-auth >>>>>> z/b >>>>>> allot/ >>>>>> >>>>>> Could you please look at the new revision Tiru has put together and >>>>>> let >>>>>> him know if you are happy with it? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Gonzalo >>>>>> >>>>>> On 28/02/2015 5:10 AM, Tirumaleswar Reddy (tireddy) wrote: >>>>>>> We have responded to comments from ISEG and published updated draft. >>>>>>> >>>>>>> -Tiru >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>>>>>> Sent: Thursday, February 26, 2015 10:26 AM >>>>>>>> To: tram-chairs@ietf.org; tram@ietf.org; >>>>>>>> draft-ietf-tram-turn-third-party- >>>>>>>> authz@ietf.org; gonzalo.camarillo@ericsson.com; >>>>>>>> draft-ietf-tram-turn-third- >>>>>>>> party-authz.ad@ietf.org; draft-ietf-tram-turn-third-party- >>>>>>>> authz.shepherd@ietf.org; spencerdawkins.ietf@gmail.com; rlb@ipv.sx; >>>>>>>> stephen.farrell@cs.tcd.ie >>>>>>>> Subject: New Version Notification - >>>>>>>> draft-ietf-tram-turn-third-party-authz- >>>>>>>> 13.txt >>>>>>>> >>>>>>>> >>>>>>>> A new version (-13) has been submitted for >>>>>>>> draft-ietf-tram-turn-third-party- >>>>>>>> authz: >>>>>>>> >>>>>>>> >>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-tram-turn-third-party >>>>>>>> -au >>>>>>>> thz- >>>>>>>> 13.txt >>>>>>>> >>>>>>>> Sub state has been changed to AD Followup from Revised ID Needed >>>>>>>> >>>>>>>> >>>>>>>> The IETF datatracker page for this Internet-Draft is: >>>>>>>> >>>>>>>> >>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-au >>>>>>>> thz >>>>>>>> / >>>>>>>> >>>>>>>> Diff from previous version: >>>>>>>> >>>>>>>> >>>>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-third-party-au >>>>>>>> thz >>>>>>>> -13 >>>>>>>> >>>>>>>> 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. >>>>>>>> >>>>>>>> IETF Secretariat. >>>>>>> >>>>>> >>>> >>> > From nobody Wed Mar 11 00:40:08 2015 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 EC1781A8A4B; Tue, 10 Mar 2015 14:22:01 -0700 (PDT) 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 mOMQ8iVpw2nS; Tue, 10 Mar 2015 14:21:59 -0700 (PDT) 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 A0BFB1A8A49; Tue, 10 Mar 2015 14:21:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16286; q=dns/txt; s=iport; t=1426022519; x=1427232119; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=8HkWbMFAjIbZ2Rv99tkDLUmCi06a9HfIIR0zLP8838s=; b=URxAi9sw6viloNrrOySIxcSoQ9snvvjRc8sVIhiRrjkJETQsJj3Oi/Mu rZh7YrxX2sMp7YmjrRlMqIttogJsdsXaviy9BVfGhziPxK5TB0zchbv1j Vw/8G/rKjKcK5Ov3t8VLkerEg+a7TVCi+5Rt59z8jTol6ba+nAyxNolXS M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DGCQBrX/9U/4oNJK1WBoMGUlUFBIMGvW+CN4UnSQIcgRRNAQEBAQEBfIQPAQEBBCMRPgUOBAIBCBEEAQEBAgIVDgMCAgIfERQBCAgCBAEJCQmIEgMRCAWqO5YMDYUoAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiXaCRIFZAQEMEBgWDAaCYoFFBZAZg2eEKoFKgRo5gm+IVkuCUYNDI4ICHIFQbwFkBRoHFwYcfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,377,1422921600"; d="scan'208";a="130751055" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-4.cisco.com with ESMTP; 10 Mar 2015 21:21:57 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t2ALLvbj001197 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Mar 2015 21:21:57 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.249]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Tue, 10 Mar 2015 16:21:56 -0500 From: "Prashanth Patil (praspati)" To: Stephen Farrell , Gonzalo Camarillo , "Tirumaleswar Reddy (tireddy)" , "tram-chairs@ietf.org" , "tram@ietf.org" , "draft-ietf-tram-turn-third-party-authz@ietf.org" , "draft-ietf-tram-turn-third-party-authz.ad@ietf.org" , "draft-ietf-tram-turn-third-party-authz.shepherd@ietf.org" , "spencerdawkins.ietf@gmail.com" , "rlb@ipv.sx" , IESG Thread-Topic: New Version Notification - draft-ietf-tram-turn-third-party-authz-13.txt Thread-Index: AQHQWL4tvjFUyNS0DUyqeV8g7tF1BZ0R1CcAgARfYET///qugA== Date: Tue, 10 Mar 2015 21:21:55 +0000 Message-ID: References: <913383AAA69FF945B8F946018B75898A366AA244@xmb-rcd-x10.cisco.com> <54F98585.7070203@ericsson.com> <54F9CBDF.7010705@cs.tcd.ie> <54FACD4E.8030706@ericsson.com> <54FB5778.2030405@cs.tcd.ie> <54FF56D0.80306@cs.tcd.ie> In-Reply-To: <54FF56D0.80306@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.154.176.29] Content-Type: text/plain; charset="utf-8" Content-ID: <512A775974BB8E4AB879279FAD45C355@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 11 Mar 2015 00:40:04 -0700 Subject: Re: [tram] New Version Notification - draft-ietf-tram-turn-third-party-authz-13.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, 10 Mar 2015 21:22:02 -0000 SGkgU3RlcGhlbiwNCg0KT24gMy8xMC8xNSwgMTo0MCBQTSwgIlN0ZXBoZW4gRmFycmVsbCIgPHN0 ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+IHdyb3RlOg0KDQo+DQo+SGl5YSwNCj4NCj5PbiAxMC8w My8xNSAyMDowMCwgUHJhc2hhbnRoIFBhdGlsIChwcmFzcGF0aSkgd3JvdGU6DQo+PiBIaSBTdGVw aGVuLA0KPj4gDQo+PiBPbiAzLzcvMTUsIDExOjU0IEFNLCAiU3RlcGhlbiBGYXJyZWxsIiA8c3Rl cGhlbi5mYXJyZWxsQGNzLnRjZC5pZT4NCj4+d3JvdGU6DQo+PiANCj4+Pg0KPj4+DQo+Pj4gT24g MDcvMDMvMTUgMTA6MDUsIEdvbnphbG8gQ2FtYXJpbGxvIHdyb3RlOg0KPj4+PiBIaSwNCj4+Pj4N Cj4+Pj4gSSBhbSBhZGRpbmcgdGhlIElFU0cgbGlzdCB0byB0aGUgY2M6IHNvIHRoYXQgZXZlcnlv bmUgY2FuIGZvbGxvdyB0aGVzZQ0KPj4+PiBkaXNjdXNzaW9ucy4NCj4+Pg0KPj4+IFRoYW5rcy4g QW5kIHNvcnJ5IGZvciBtaXNzaW5nIHRoaXMgYW5kIG5vdCByZXNwb25kaW5nIGJlZm9yZS4NCj4+ Pg0KPj4+Pg0KPj4+PiBDaGVlcnMsDQo+Pj4+DQo+Pj4+IEdvbnphbG8NCj4+Pj4NCj4+Pj4gT24g MDYvMDMvMjAxNSAxMDoxMyBQTSwgUHJhc2hhbnRoIFBhdGlsIChwcmFzcGF0aSkgd3JvdGU6DQo+ Pj4+PiBIaSBTdGVwaGVuLA0KPj4+Pj4gV2UgZGlkIHJlc3BvbmQgdG8geW91ciBkaXNjdXNzaW9u IHBvaW50cy4gSW4gYW55IGNhc2UsIHJlc3BvbnNlcw0KPj4+Pj5wYXN0ZWQNCj4+Pj4+IGJlbG93 Og0KPj4+Pj4NCj4+Pj4+ICgxKSBNYWtpbmcgbm9uZSBvZiA0LjEueCBtYW5kYXRvcnkgdG8gaW1w bGVtZW50IHdpbGwNCj4+Pj4+IHJlc3VsdCBpbiBhIGxhY2sgb2YgaW50ZXJvcC4gV2hhdCBpcyB0 aGUgZGV2ZWxvcGVyDQo+Pj4+PiBzdXBwb3NlZCB0byBpbXBsZW1lbnQ/IFdoeSBpcyBpdCBvayB0 byBub3Qgc2F5PyAgKEZvcg0KPj4+Pj4gZXhhbXBsZSwgZGVmaW5pbmcgNC4xLjEgYW5kIDQuMS4y IHNpbXBseSBzbyBhcyB0byBhcHBlYXINCj4+Pj4+ICJtb3JlIHNlY3VyZSIgd2hpbHN0IHJlYWxs eSBleHBlY3RpbmcgNC4xLjMgdG8gYmUgdXNlZCwNCj4+Pj4+IGJ1dCBub3Qgc2F5aW5nIHNvLCB3 b3VsZCBzZWVtIGxpa2UgYSBiYWQgcGxhbiB0byBtZS4pDQo+Pj4+Pg0KPj4+Pj4gIA0KPj4+Pj4g UmVzcG9uc2U+IFNlY3Rpb25zIDQuMS54IGFyZSBvbmx5IG1lYW50IHRvIGJlIGV4YW1wbGVzIG9m IG1lY2hhbmlzbXMNCj4+Pj4+IHRoYXQNCj4+Pj4+IGNvdWxkIGJlIHBvdGVudGlhbGx5IHVzZWQu IFRoZSBhdXRob3JzIGRvbsK5dCBoYXZlIGEgcHJlZmVyZW5jZSBvZiBvbmUNCj4+Pj4+IG92ZXIN Cj4+Pj4+IHRoZSBvdGhlcnMsIA0KPj4+DQo+Pj4gVGhhdCdzIG5vdCBnb2luZyB0byBnZXQgdXMg aW50ZXJvcCB0aG91Z2ggaXMgaXQ/IEFuZCBpbnRlcm9wIGlzDQo+Pj4gbmVlZGVkIGhlcmUgLSB3 ZSBoYXZlIHRoZSBicm93c2VyLCB0aGUgd2ViLXNpdGUgYW5kIHRoZSBUVVJOL1NUVU4NCj4+PiBz ZXJ2ZXIgYWxsIGludm9sdmVkLiBJIHRoaW5rIHlvdSBuZWVkIG9uZSBtZWNoYW5pc20gdGhhdCBp cyBNVEkNCj4+PiBhbmQgdGhhdCBpcyBSRUNPTU1FTkRFRCB0byB1c2UgZm9yIHRoaXMgdG8gYmUg dXNlZnVsLg0KPj4gDQo+PiBXZSBjYW4gY2VydGFpbmx5IFJFQ09NTUVORCA0LjEuMiAoUkVTVCku IEhvd2V2ZXIsIHRoZSBzdWdnZXN0aW9uIGZyb20NCj4+IE9BVVRHIFdHIGlzIHRvIG5vdCBtYW5k YXRlIG9uZQ0KPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1 cnJlbnQvbXNnMTQzMjUuaHRtbC4NCj4NCj5ZZXMsIEkgc2F3IHRoYXQuIEFuZCBpdCdzIGEgYm9n dXMgc3VnZ2VzdGlvbi4gT0F1dGggbWF5IGJlIGEgZnJhbWV3b3JrDQo+YnV0IFdlYlJUQyBpcyBu b3QgYW5kIG5vciBpcyB0aGUgU1RVTi9UVVJOIHBhcnQgb2YgV2ViUlRDLg0KPg0KPkkgdGhpbmsg eW91IG5lZWQgdG8gcGljayBvbmUgKG9yIG1vcmUpIE1USSBzY2hlbWUuIEFuZCBvbmUgdGhhdA0K PnByb3ZpZGVzIGJldHRlciBzZWN1cml0eSB0aGFuIHdlIGhhdmUgdG9kYXkgd2l0aCBTVFVOL1RV Uk4uDQo+DQo+VGhlIG9ubHkgYW5zd2VyIEkgY2FuIHRoaW5rIG9mIGZvciB0aGF0IGlzIGEgc2ln bmF0dXJlIGJhc2VkDQo+c2NoZW1lIHRvIGJlIGhvbmVzdC4NCg0KU3VyZSwgd2XigJlsbCBuZWVk IFdHIGZlZWRiYWNrIG9uIHRoaXMuIFRoZSBmZWVkYmFjayBmcm9tIHRoZSBXRyB3YXMgdG8gbm90 DQptYW5kYXRlIG9uZSBhcyB3ZWxsLg0KDQo+DQo+PiANCj4+IFNlY3Rpb24gNCB3YXMgb3JpZ2lu YWxseSBtZWFudCB0byBwcm92aWRlIGV4YW1wbGVzIGZvciBrZXkNCj4+ZXN0YWJsaXNobWVudC4N Cj4+IFRVUk4gc3RhbmRhcmRpemF0aW9uIGhhcyBubyBkZXBlbmRlbmN5IG9uIHRoZSBlc3RhYmxp c2htZW50IHByb2NlZHVyZS4NCj4+SW4NCj4+IHdvdWxkIHNlZW0gdGhhdCBhIHJlbGF5IHNlcnZp Y2UgcHJvdmlkZXIgd2lsbCBwcm9iYWJseSB1c2Ugd2hpY2hldmVyDQo+PiBtZXRob2QocykgZm9y IGtleSBleGNoYW5nZSB0aGVpciBjdXN0b21lcnMgYXJlDQo+PiB3aWxsaW5nIHRvIGFjY2VwdC4N Cj4NCj5Tb3JyeSAtIGFyZSB5b3UgYXNzdW1pbmcgc29tZSBwYXJ0aWN1bGFyIGJ1c2luZXNzIG1v ZGVsPyBJJ20gbm90IHN1cmUNCj50aGF0J3MgYSB2YWxpZCBhc3N1bXB0aW9uIGZvciBXZWJSVEMs IG5vciBmb3IgU1RVTi9UVVJOIGluIGdlbmVyYWwuDQo+DQo+PiANCj4+IFdlIGNvdWxkIGVpdGhl ciByZW1vdmUgdGhpcyBjb21wbGV0ZWx5LCBvciBtb3ZlIHRoaXMgc2VjdGlvbiB0bw0KPj5hcHBl bmRpeCwNCj4+IGlmIHRoYXQgaGVscHMuDQo+PiANCj4+IA0KPj4+DQo+Pj4+PiA0LjEuMiAoUkVT VCkgY291bGQgYmUgc29tZXRoaW5nIHRoYXQgY2FuIGJlIHJlY29tbWVuZGVkIHRvIGJlDQo+Pj4+ PiBpbXBsZW1lbnRlZCAoZWFzeSB0byBkZXZlbG9wIGFuZCBwcm92aWRlcyBhbGdvcml0aG0gYWdp bGl0eSkuDQo+Pj4+Pg0KPj4+Pj4gKDIpIFdoYXQgaXMgdGhlIHN0YXR1cyBvZiBBcHBlbmRpeCBC PyBBbSBJIHN1cHBvc2VkIHRvDQo+Pj4+PiBpbXBsZW1lbnQgdGhhdD8gV2hhdCBkb2VzICJDbGll bnQgY291bGQuLi4iIG1lYW4/DQo+Pj4+Pg0KPj4+Pj4gIA0KPj4+Pj4gUmVzcG9uc2U+IEFwcGVu ZGl4IEIgaXMgb25seSBtZWFudCB0byBiZSBwcm92aWRlIGFuIGlsbHVzdHJhdGlvbiBvZg0KPj4+ Pj4gaW50ZXJhY3Rpb24gYmV0d2VlbiB0aGUgV2ViUlRDIGNsaWVudCBhbmQgYXV0aG9yaXphdGlv biBzZXJ2ZXINCj4+Pj4+KFdlYlJUQw0KPj4+Pj4gc2VydmVyKS4gDQo+Pj4NCj4+PiBUaGUgdXNl IG9mIHRoZSBBUyB0ZXJtIGluIFdlYlJUQyBpcyB1bnVzdWFsLiBTdWZmaWNpZW50bHkgc28gYXMg dG8NCj4+PiBiZSBhIGJhZCBpZGVhIEkgdGhpbmsuIChBbmQgb25lIGNvdWxkIHdvbmRlciBhYm91 dCB3aG8gaXMgdGhlIHJlYWwNCj4+PiByZXNvdXJjZSBvd25lciBpbiBXZWJSVEMgLSBJIGRvbid0 IHRoaW5rIGl0J3MgdGhlIHdlYiBzaXRlIHRoYXQgc2V0cw0KPj4+IHVwIHRoZSBjYWxscyBteXNl bGYuKQ0KPj4gDQo+PiBUaGUgcmVzb3VyY2Ugc2VydmVyIGlzIHRoZSBUVVJOIHNlcnZlciwgb3du ZWQgYnkgdGhlIFdlYlJUQyBzZXJ2aWNlIChvcg0KPj4gdGhlIFRVUk4gYW5kIFdlYlJUQyBzZXJ2 aWNlIHByb3ZpZGVycyBjb3VsZCBoYXZlIGEgYnVzaW5lc3MNCj4+cmVsYXRpb25zaGlwLikNCj4+ IA0KPj4gDQo+Pj4NCj4+Pj4+IFBsZWFzZSBub3RlIHRoYXQgdGhlIGNvbW11bmljYXRpb24gYmV0 d2VlbiB0aGUgdHdvIGlzDQo+Pj4+PiBwcm9wcmlldGFyeSwgV2ViUlRDIGRvZXMgbm90IG1hbmRh dGUgYW55IHNpZ25hbGluZyBwcm90b2NvbC4NCj4+Pg0KPj4+IEhtbS4gSSdtIG5vdCBzdXJlIEkg c2VlIHRoZSBiZW5lZml0IG9mIGluY2x1ZGluZyB0aGF0LCBpZiB5b3UncmUNCj4+PiByaWdodCBh Ym92ZS4NCj4+Pg0KPj4+Pj4NCj4+Pj4+ICgzKSBJbiB0aGUgc2VjZGlyIHJldmlldyBbMV0gZGlz Y3Vzc2lvbiwgSSBzZWUgdGhlIGF1dGhvcnMNCj4+Pj4+IG1lbnRpb24gYWRkaW5nIEVDQywgYnV0 IEkgc2VlIG5vdGhpbmcgaW4gdGhlIGRyYWZ0LiBJDQo+Pj4+PiBkb24ndCBiZWxpZXZlIHRoYXQg dGhhdCBkaXNjdXNzaW9uIGhhcyByZWFsbHkgZW5kZWQgYW5kDQo+Pj4+PiB3b3VsZCBsaWtlIHRv IGNvbnRpbnVlIGl0LiBXaHkgaXMgdGhlIFdlYlJUQyBzZXJ2ZXIgbm90DQo+Pj4+PiBzaW1wbHkg c2lnbmluZyBzb21ldGhpbmcgZm9yIHRoZSBTVFVOIHNlcnZlciB0byB2ZXJpZnk/DQo+Pj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NlY2Rpci9jdXJyZW50L21zZzA1 NDI1Lmh0bWwNCj4+Pj4+DQo+Pj4+PiAgDQo+Pj4+PiBSZXNwb25zZT4gV2UgZGlkIGhhdmUgYW4g b2ZmbGluZSBkaXNjdXNzaW9uIHdpdGggWWFyb24gU2hlZmZlciAod2hvDQo+Pj4+PmhhZA0KPj4+ Pj4gc3VnZ2VzdGVkIEVDQykuIEVDREgtRVMgY2FuIGJlIHVzZWQgdG8gYWdyZWUgdXBvbiBhIHN5 bW1ldHJpYyBrZXkgZm9yDQo+Pj4+PiBlbmNyeXB0aW5nL2RlY3J5cHRpbmcgdGhlIHRva2VuIGFu ZCBFQ0RTQSB0byBnZW5lcmF0ZSBkaWdpdGFsDQo+Pj4+PnNpZ25hdHVyZQ0KPj4+Pj4gZm9yIHRo ZSB0b2tlbi4gQnV0IHRoaXMgd291bGQgcmVzdWx0IGluIGEgc3ltbWV0cmljIGtleSwganVzdCBs aWtlDQo+Pj4+PnRoZQ0KPj4+Pj4gYXBwcm9hY2hlcyBkZXNjcmliZWQgaW4gNC4xLjEgYW5kIDQu MS4yLiBXZcK5dmUgaGVuY2UgZGVjaWRlZCBub3QgdG8NCj4+Pj4+IGluY2x1ZGUgYW55IGRldGFp bHMgcGVydGFpbmluZyB0byBFQ0MuDQo+Pj4NCj4+PiBFQ0RTQSBpcyBhIHNpZ25hdHVyZSBzY2hl bWUuIE5vIHN5bW1ldHJpYyBrZXkgd291bGQgYmUgbmVlZGVkLiBTbw0KPj4+IEknbSBub3QgZm9s bG93aW5nIHlvdXIgbG9naWMgdGhlcmUgdGJoLiBBdCBsZWFzdCBhdCBhIGhpZ2ggbGV2ZWwsDQo+ Pj4gYSBzaWduYXR1cmUgc2NoZW1lIG1ha2VzIGEgbG90IG9mIHNlbnNlIGluIHRoaXMgY2FzZS4N Cj4+IA0KPj4gVGhlIHRva2VuIG5lZWRzIHRvIGJlIGVuY3J5cHRlZCBhbmQgYXV0aGVudGljYXRl ZC4NCj4NCj5XaHkgZW5jcnlwdGVkPyBXaGF0IG5lZWRzIGNvbmZpZGVudGlhbGl0eT8NCg0KVGhl IFRva2VuLCB3aGljaCBpcyBzZWxmIGNvbnRhaW5lZCwgaXMgZW5jcnlwdGVkIHNvIGFzIHRvIG1h a2UgaXQgb3BhcXVlDQp0byB0aGUgY2xpZW50LiBBbGwgdGhlIGluZm9ybWF0aW9uIG5lY2Vzc2Fy eSB0byBhdXRoZW50aWNhdGUgdGhlIHZhbGlkaXR5DQpvZiB0aGUgdG9rZW4gaXMgY29udGFpbmVk IHdpdGhpbiB0aGUgdG9rZW4gaXRzZWxmLg0KDQotUHJhc2hhbnRoDQoNCj4NCj5UYSwNCj5TLg0K Pg0KPj4gRUNEU0Egb25seSBnZW5lcmF0ZXMNCj4+IHNpZ25hdHVyZSBmb3IgdGhlIHRva2VuLiBX ZSBuZWVkIEVDREggdG8gYWdyZWUgdXBvbiBhIHN5bW1ldHJpYyBrZXkgZm9yDQo+PiBlbmNyeXB0 aW5nL2RlY3J5cHRpb24uIFN5bW1ldHJpYyBrZXlzIHdvdWxkIHJlc3VsdCBpbiBhcHByb2FjaGVz IHZlcnkNCj4+IHNpbWlsYXIgdG8gdGhlIG9uZXMgZGVzY3JpYmVkIGluIDQuMS4xIGFuZCA0LjEu Mi4NCj4+IA0KPj4gLVByYXNoYW50aA0KPj4gDQo+PiANCj4+IA0KPj4+DQo+Pj4gQ2hlZXJzLA0K Pj4+IFMuDQo+Pj4NCj4+PiBQUzogV2UgY2FuIGNvdmVyIHRoZSBjb21tZW50cyBiZWxvdyBsYXRl ciwgd2hlbiB0aGUgZGlzY3VzcyBwb2ludHMNCj4+PiBhcmUgc29ydGVkLg0KPj4+DQo+Pj4+Pg0K Pj4+Pj4gIA0KPj4+Pj4gSW50cm86ICJpbXBvc3NpYmxlIGluIHdlYiBhcHBsaWNhdGlvbnMiIGlz bid0IHJlYWxseQ0KPj4+Pj4gdHJ1ZSBpbiBwcmluY2lwbGUsIGJ1dCBpbXBvc3NpYmxlIGluIFdl YlJUQyBhcyBpdCB1c2VzIEpTDQo+Pj4+PiBpcyB0cnVlLiANCj4+Pj4+DQo+Pj4+PiBSZXNwb25z ZT4gWWVzLiBJdCBpcyBub3QgcG9zc2libGUgZm9yIFdlYlJUQyBhcyBpdCB1c2VzIEpTLiBXZcK5 bGwNCj4+Pj4+IGNvcnJlY3QNCj4+Pj4+IGl0Lg0KPj4+Pj4gIA0KPj4+Pj4gTkVXOg0KPj4+Pj4g Ikhvd2V2ZXIsIGluIHdlYiBhcHBsaWNhdGlvbnMgbGlrZSBXZWJSVEMgW0ktRC5pZXRmLXJ0Y3dl Yi1vdmVydmlld10NCj4+Pj4+IHdoZXJlDQo+Pj4+PiBKYXZhU2NyaXB0IHVzZXMgdGhlIGJyb3dz ZXIgZnVuY3Rpb25hbGl0eSB0byBtYWtlIHJlYWwtdGltZSBhdWRpbw0KPj4+Pj4gYW5kL29yDQo+ Pj4+PiB2aWRlbyBjYWxscywgV2ViIGNvbmZlcmVuY2luZywgYW5kIGRpcmVjdCBkYXRhIHRyYW5z ZmVyLCBlbnN1cmluZw0KPj4+Pj50aGlzDQo+Pj4+PiBzZWNyZWN5IGlzIHR5cGljYWxseSBub3Qg cG9zc2libGUuIg0KPj4+Pj4NCj4+Pj4+IC0gNC4xLjIgLSB3aGljaCAidHdvIHNlcnZlcnMiPyBX ZWJSVEMgY2FuIGhhdmUgbW9yZQ0KPj4+Pj4gc2VydmVycyB0aGFuIHRoYXQuDQo+Pj4+Pg0KPj4+ Pj4gIA0KPj4+Pj4gUmVzcG9uc2U+IFRoZSBTVFVOIHNlcnZlciBhbmQgdGhlIEFTLiBBcyBmYXIg YXMgdGhlIFNUVU4gc2VydmVyIGlzDQo+Pj4+PiBjb25jZXJuZWQsIGl0IG9ubHkgZGVhbHMgd2l0 aCB0aGUgQVMgb2YgaW50ZXJlc3QgZm9yIGtleQ0KPj4+Pj5lc3RhYmxpc2htZW50Lg0KPj4+Pj4g VGhlIEFTIGNvdWxkIGJlIHRoZSBhcHBsaWNhdGlvbiBzZXJ2ZXIgaXRzZWxmIG9yIGNvdWxkIGJl IGEgS2V5DQo+Pj4+PiBtYW5hZ2VtZW50DQo+Pj4+PiBmdW5jdGlvbiBzeW5jaW5nIHRoZSBrZXlp bmcgbWF0ZXJpYWwgdG8gdGhlIFdlYlJUQyBzZXJ2ZXJzLg0KPj4+Pj4NCj4+Pj4+IC0gNC4xLjIg LSBub3cgd2UncmUgdXNpbmcgVExTIG11dHVhbCBhdXRoPyBBbmQgaG93IGRvZXMNCj4+Pj4+IHRo ZSBUTFMgY2xpZW50IGtub3cgd2hpY2ggQ0EgdG8gdXNlIHRoYXQnbGwgd29yayB3aXRoIHRoZQ0K Pj4+Pj4gVExTIHNlcnZlciBoZXJlPyBJIGRvbid0IHRoaW5rIHRoYXQnbGwgc2NhbGUgd2lsbCBp dD8NCj4+Pj4+DQo+Pj4+PiAgDQo+Pj4+PiBSZXNwb25zZT4gV2UgcHJlc3VtZSB0aGUgdHdvIHBh cnRpZXMgaW52b2x2ZWQga25vdyB3aGF0IENBIHRvDQo+Pj4+PmNvbnNpZGVyDQo+Pj4+PiB3aGVu IHVzaW5nIHRoZSBSRVNUIEFQSXMgwq0gdGhleSB3b3VsZCBoYXZlIHRvIGRvIHRoaXMgdG8gdHJ1 c3QgZWFjaA0KPj4+Pj4gb3RoZXIuDQo+Pj4+PiBQbGVhc2Ugbm90ZSB0aGF0IHRoZSBBUyBpcyBh bGxvY2F0aW5nIHN5bW1ldHJpYyBrZXlzIG1lYW50DQo+Pj4+PmV4Y2x1c2l2ZWx5DQo+Pj4+PiBm b3INCj4+Pj4+IHRoYXQgU1RVTiBTZXJ2ZXIsIHNvIHNvbWUgbGV2ZWwgb2YgY28tb3JkaW5hdGlv biBpcyBhbHJlYWR5IGludm9sdmVkLg0KPj4+Pj4NCj4+Pj4+IC0gNC4xLjMgLSB0aGlzIGxvb2tz IGxpa2Ugd2hhdCB0aGUgV0cvYXV0aG9ycyByZWFsbHkgd2FudCwNCj4+Pj4+IHdvdWxkIHRoYXQg YmUgYSBmYWlyIHN0YXRlbWVudD8NCj4+Pj4+DQo+Pj4+PiAgDQo+Pj4+PiBSZXNwb25zZT4gTm8u IFRoZSDFkk5vdGU6wrkgYXQgdGhlIGVuZCBvZiB0aGUgc2VjdGlvbiBpcyBwcm9iYWJseQ0KPj4+ Pj4gbWlzbGVhZGluZywgd2lsbCB1cGRhdGUgaXQuDQo+Pj4+PiAgDQo+Pj4+PiBORVc6DQo+Pj4+ PiAiTm90ZSA6IFRoZSBtZWNoYW5pc20gc3BlY2lmaWVkIGluIFNlY3Rpb24gNC4xLjMgbGFja3Mg ZW5jcnlwdGlvbiBhbmQNCj4+Pj4+IEhNQUMNCj4+Pj4+IGFsZ29yaXRobSBhZ2lsaXR5LiINCj4+ Pj4+DQo+Pj4+PiAtIDk6IEZpZ3VyZSAyIHNob3VsZCBiZSB3YXkgdXAgYXQgdGhlIHRvcCBvZiB0 aGUgZG9jdW1lbnQNCj4+Pj4+IGFuZCBub3QgaGVyZQ0KPj4+Pj4NCj4+Pj4+ICANCj4+Pj4+IFJl c3BvbnNlPiBJbiB0aGUgcHJldmlvdXMgdmVyc2lvbnMgaXQgd2FzIGluIHRoZSB0b3Agb2YgdGhl IGRvY3VtZW50DQo+Pj4+PiBidXQNCj4+Pj4+IG1vdmVkIGRvd24gYWZ0ZXIgY29tbWVudHMgcmVj ZWl2ZWQgZnJvbSB0aGUgV0cgdGhhdCBXZWJSVEMgaXMgb25seSBhbg0KPj4+Pj4gZXhhbXBsZSB1 c2FnZSBvZiB0aGlyZCBwYXJ0eSBhdXRob3JpemF0aW9uLg0KPj4+Pj4NCj4+Pj4+IC0gOTogV2h5 IDUgc2Vjb25kcz8NCj4+Pj4+DQo+Pj4+PiAgDQo+Pj4+PiBSZXNwb25zZT4gU1RVTiBtZXNzYWdl cyBjYW4gYmUgc2VudCBvdmVyIFVEUCwgNSBzZWNvbmRzIGlzIHRvDQo+Pj4+PiBhY2NvbW1vZGF0 ZQ0KPj4+Pj4gcGFja2V0IGxvc3MgYW5kIFJUTyBpbnRlcnZhbC4NCj4+Pj4+DQo+Pj4+PiAgDQo+ Pj4+PiAtIEFzc3VtaW5nIHRoZSBBUyB0aGF0IGNhbiBhdXRob3JpemUgdGhlIHVzZXIgc2hhcmVz IGENCj4+Pj4+IHNlY3JldCB3aXRoIHRoZSBTVFVOIHNlcnZlciBjaG9zZW4gYnkgdGhlIFdlYlJU QyBzZXJ2ZXINCj4+Pj4+IHNlZW1zIHZlcnkgYnJpdHRsZS4gV2h5IHdvdWxkIHRoYXQgYmUgdHJ1 ZSBpbiBnZW5lcmFsPw0KPj4+Pj4NCj4+Pj4+ICANCj4+Pj4+IFJlc3BvbnNlPiBUaGUgQVMgYW5k IFdlYlJUQyBzZXJ2ZXIgYXJlIGluIHRoZSBzYW1lIGFkbWluaXN0cmF0aXZlDQo+Pj4+PiBkb21h aW4NCj4+Pj4+IG9mIHRoZSBhcHBsaWNhdGlvbiBwcm92aWRlci4gVGhlIHVzZXIgbmV2ZXIgc2Vu ZHMgdGhlIHNlc3Npb24ga2V5DQo+Pj4+PiBsZWFybmVkDQo+Pj4+PiBmcm9tIHRoZSBBUyB0byB0 aGUgU1RVTiBzZXJ2ZXIgaXQgb25seSB1c2VzIHRoZSBzZXNzaW9uIGtleSB0bw0KPj4+Pj5jb21w dXRlDQo+Pj4+PiBtZXNzYWdlIGludGVncml0eSBvZiBTVFVOIHJlcXVlc3QgYW5kIHRvIHZhbGlk YXRlIHRoZSBtZXNzYWdlDQo+Pj4+PiBpbnRlZ3JpdHkgb2YNCj4+Pj4+IHRoZSBTVFVOIHJlc3Bv bnNlLiBUaGUgU1RVTiBzZXJ2ZXIgd2lsbCBvbmx5IGtub3cgdGhlIHNlc3Npb24ga2V5IGlmDQo+ Pj4+Pml0DQo+Pj4+PiBjYW4gZGVjcnlwdCB0aGUgdG9rZW4uDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+ IC1QcmFzaGFudGgNCj4+Pj4+DQo+Pj4+PiBPbiAzLzYvMTUsIDc6NDYgQU0sICJTdGVwaGVuIEZh cnJlbGwiIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPg0KPj4+Pj4gd3JvdGU6DQo+Pj4+Pg0K Pj4+Pj4+DQo+Pj4+Pj4gSGV5LA0KPj4+Pj4+DQo+Pj4+Pj4gIzEgLSBub3BlLCB0aGF0IHZlcnNp b24gZG9lc24ndCBhZGRyZXNzIHRoaW5ncyB0aGF0IEkgY2FuIHNlZQ0KPj4+Pj4+IChhbmQgSSd2 ZSBub3Qgc2VlbiBhIGRpcmVjdCByZXNwb25zZSB0byBteSBkaXNjdXNzIHBvaW50cyB0aGF0DQo+ Pj4+Pj4gSSByZWNhbGwpDQo+Pj4+Pj4NCj4+Pj4+PiAjMiAtIEkgc2VudCBhbiBhc2sgdG8gdGhl IHNhYWcgbGlzdCBqdXN0IG5vdywgKGF0dGFjaGVkKSB3aWxsDQo+Pj4+Pj4gbGV0IHlvdSBrbm93 IGlmIEkgZ2V0IG9mZmVycy4gUGxlYXNlIGFsc28gcGluZyBtZSBpZiB5b3UgZ2V0DQo+Pj4+Pj4g YW55IGRpcmVjdCwganVzdCBzbydzIHdlIGRvbid0IGNyb3NzIHN0cmVhbXMuDQo+Pj4+Pj4NCj4+ Pj4+PiBTLg0KPj4+Pj4+DQo+Pj4+Pj4gT24gMDYvMDMvMTUgMTA6NDYsIEdvbnphbG8gQ2FtYXJp bGxvIHdyb3RlOg0KPj4+Pj4+PiBTdGVwaGVuLCBSaWNoYXJkLA0KPj4+Pj4+Pg0KPj4+Pj4+PiB5 b3UgaGF2ZSBkaXNjdXNzZXMgb24gdGhpcyBkcmFmdDoNCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+ Pj4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHktYXUNCj4+Pj4+Pj50aA0KPj4+Pj4+PiB6L2IN Cj4+Pj4+Pj4gYWxsb3QvDQo+Pj4+Pj4+DQo+Pj4+Pj4+IENvdWxkIHlvdSBwbGVhc2UgbG9vayBh dCB0aGUgbmV3IHJldmlzaW9uIFRpcnUgaGFzIHB1dCB0b2dldGhlciBhbmQNCj4+Pj4+Pj4gbGV0 DQo+Pj4+Pj4+IGhpbSBrbm93IGlmIHlvdSBhcmUgaGFwcHkgd2l0aCBpdD8NCj4+Pj4+Pj4NCj4+ Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+Pg0KPj4+Pj4+PiBHb256YWxvDQo+Pj4+Pj4+DQo+Pj4+Pj4+ IE9uIDI4LzAyLzIwMTUgNToxMCBBTSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSB3cm90 ZToNCj4+Pj4+Pj4+IFdlIGhhdmUgcmVzcG9uZGVkIHRvIGNvbW1lbnRzIGZyb20gSVNFRyBhbmQg cHVibGlzaGVkIHVwZGF0ZWQNCj4+Pj4+Pj4+ZHJhZnQuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gLVRp cnUNCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+ Pj4+PiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmddDQo+Pj4+Pj4+Pj4gU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDI2LCAyMDE1 IDEwOjI2IEFNDQo+Pj4+Pj4+Pj4gVG86IHRyYW0tY2hhaXJzQGlldGYub3JnOyB0cmFtQGlldGYu b3JnOw0KPj4+Pj4+Pj4+IGRyYWZ0LWlldGYtdHJhbS10dXJuLXRoaXJkLXBhcnR5LQ0KPj4+Pj4+ Pj4+IGF1dGh6QGlldGYub3JnOyBnb256YWxvLmNhbWFyaWxsb0Blcmljc3Nvbi5jb207DQo+Pj4+ Pj4+Pj4gZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtDQo+Pj4+Pj4+Pj4gcGFydHktYXV0aHou YWRAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtdHJhbS10dXJuLXRoaXJkLXBhcnR5LQ0KPj4+Pj4+Pj4+ IGF1dGh6LnNoZXBoZXJkQGlldGYub3JnOyBzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbTsN Cj4+Pj4+Pj4+PnJsYkBpcHYuc3g7DQo+Pj4+Pj4+Pj4gc3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5p ZQ0KPj4+Pj4+Pj4+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiAtDQo+Pj4+Pj4+ Pj4gZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHotDQo+Pj4+Pj4+Pj4gMTMu dHh0DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEEgbmV3IHZlcnNpb24gKC0xMykg aGFzIGJlZW4gc3VibWl0dGVkIGZvcg0KPj4+Pj4+Pj4+IGRyYWZ0LWlldGYtdHJhbS10dXJuLXRo aXJkLXBhcnR5LQ0KPj4+Pj4+Pj4+IGF1dGh6Og0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+PiANCj4+Pj4+Pj4+Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWlldGYtdHJhbS10dXJuLXRoaXJkLXBhcg0KPj4+Pj4+Pj4+dHkNCj4+Pj4+Pj4+PiAtYXUNCj4+ Pj4+Pj4+PiB0aHotDQo+Pj4+Pj4+Pj4gMTMudHh0DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBTdWIg c3RhdGUgaGFzIGJlZW4gY2hhbmdlZCB0byBBRCBGb2xsb3d1cCBmcm9tIFJldmlzZWQgSUQgTmVl ZGVkDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFRoZSBJRVRGIGRhdGF0cmFja2Vy IHBhZ2UgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHktDQo+Pj4+Pj4+Pj5hdQ0KPj4+Pj4+Pj4+IHRo eg0KPj4+Pj4+Pj4+IC8NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IERpZmYgZnJvbSBwcmV2aW91cyB2 ZXJzaW9uOg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pmh0dHA6 Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdHJhbS10dXJuLXRoaXJkLXBh cnR5LQ0KPj4+Pj4+Pj4+YXUNCj4+Pj4+Pj4+PiB0aHoNCj4+Pj4+Pj4+PiAtMTMNCj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+Pj4+Pj4+Pj4gc3VibWlzc2lvbg0KPj4+Pj4+Pj4+IHVu dGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCj4+Pj4+ Pj4+PiB0b29scy5pZXRmLm9yZy4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IElFVEYgU2VjcmV0YXJp YXQuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4NCj4+Pj4NCj4+IA0KDQo= From nobody Wed Mar 11 00:40:10 2015 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 9FF9A1A8A8C; Tue, 10 Mar 2015 14:29:34 -0700 (PDT) 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 fskDRbiRwHds; Tue, 10 Mar 2015 14:29:33 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB2B81A8A75; Tue, 10 Mar 2015 14:29:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9FC10BEB2; Tue, 10 Mar 2015 21:29:31 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDORHMcbARfB; Tue, 10 Mar 2015 21:29:30 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.46.19.44]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 51E0FBEB1; Tue, 10 Mar 2015 21:29:30 +0000 (GMT) Message-ID: <54FF623A.4000501@cs.tcd.ie> Date: Tue, 10 Mar 2015 21:29:30 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Prashanth Patil (praspati)" , Gonzalo Camarillo , "Tirumaleswar Reddy (tireddy)" , "tram-chairs@ietf.org" , "tram@ietf.org" , "draft-ietf-tram-turn-third-party-authz@ietf.org" , "draft-ietf-tram-turn-third-party-authz.ad@ietf.org" , "draft-ietf-tram-turn-third-party-authz.shepherd@ietf.org" , "spencerdawkins.ietf@gmail.com" , "rlb@ipv.sx" , IESG References: <913383AAA69FF945B8F946018B75898A366AA244@xmb-rcd-x10.cisco.com> <54F98585.7070203@ericsson.com> <54F9CBDF.7010705@cs.tcd.ie> <54FACD4E.8030706@ericsson.com> <54FB5778.2030405@cs.tcd.ie> <54FF56D0.80306@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Wed, 11 Mar 2015 00:40:04 -0700 Subject: Re: [tram] New Version Notification - draft-ietf-tram-turn-third-party-authz-13.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, 10 Mar 2015 21:29:34 -0000 Hiya, On 10/03/15 21:21, Prashanth Patil (praspati) wrote: > The Token, which is self contained, is encrypted so as to make it opaque > to the client. All the information necessary to authenticate the validity > of the token is contained within the token itself. Sorry I'm still not getting it. Exactly what information needs to be confidential between which endpoints? When I think of the STUN/TURN problem in WebRTC, it's a pure question of permission and accountability. Today, the web site hands out a username/secret for use of STURN or TURN, which is bad, But why not have the web site sign a token that says "web site says it's ok for whoever presents this to get STUN/TURN service" with whatever timestamps or other controls are needed. I don't see anything that needs to be inside that token that's not immediately obvious from just watching the (ciphertext) packets flow. So I don't see anything that needs encrypting between the web site and the STUN/TURN servers. Cheers, S. From nobody Wed Mar 11 00:40:17 2015 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 3315E1A0263; Tue, 10 Mar 2015 21:26:20 -0700 (PDT) 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 mzhtpccpNLyM; Tue, 10 Mar 2015 21:26:18 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E8591A0250; Tue, 10 Mar 2015 21:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1671; q=dns/txt; s=iport; t=1426047978; x=1427257578; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=4fLISGj/Kwnc8y9WzjbYcCG56wVgiKJP90zRHtH1jhg=; b=VX0GW9z9EiahipPfH1EIAeu0Y1pMHIxYFXdfo/vTVLmiCGtpQzMCit0q 74gu8XUL1MOsrjDgSXpJGWh4qfYDd004zFRroG2fQ49hsrsfm51XMOq3m NlmIb491dP3XFwmfhEinMMECspmxB/YDgKA+3dsxxbjlTt23EQsb8uTld g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C7CQBDw/9U/5RdJa1cgwNSWgTAe4I3hXACgTRNAQEBAQEBfIQQAQEEOi0QEgIBCBIGHhAyFw4CBAESiC8NxlYBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIsXhHWELQEEkBmDZ4V0k3cjg25vgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,379,1422921600"; d="scan'208";a="130848059" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-7.cisco.com with ESMTP; 11 Mar 2015 04:26:16 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t2B4QGB6023916 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Mar 2015 04:26:16 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.249]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Tue, 10 Mar 2015 23:26:15 -0500 From: "Prashanth Patil (praspati)" To: Stephen Farrell , Gonzalo Camarillo , "Tirumaleswar Reddy (tireddy)" , "tram-chairs@ietf.org" , "tram@ietf.org" , "draft-ietf-tram-turn-third-party-authz@ietf.org" , "draft-ietf-tram-turn-third-party-authz.ad@ietf.org" , "draft-ietf-tram-turn-third-party-authz.shepherd@ietf.org" , "spencerdawkins.ietf@gmail.com" , "rlb@ipv.sx" , IESG Thread-Topic: New Version Notification - draft-ietf-tram-turn-third-party-authz-13.txt Thread-Index: AQHQWL4tvjFUyNS0DUyqeV8g7tF1BZ0R1CcAgARfYESAAA2YdoAAY6SA Date: Wed, 11 Mar 2015 04:26:14 +0000 Message-ID: References: <913383AAA69FF945B8F946018B75898A366AA244@xmb-rcd-x10.cisco.com> <54F98585.7070203@ericsson.com> <54F9CBDF.7010705@cs.tcd.ie> <54FACD4E.8030706@ericsson.com> <54FB5778.2030405@cs.tcd.ie> <54FF56D0.80306@cs.tcd.ie> <54FF623A.4000501@cs.tcd.ie> In-Reply-To: <54FF623A.4000501@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.24.74.43] Content-Type: text/plain; charset="us-ascii" Content-ID: <250A50D7A5214046A6CEA961A0780D5F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 11 Mar 2015 00:40:04 -0700 Subject: Re: [tram] New Version Notification - draft-ietf-tram-turn-third-party-authz-13.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, 11 Mar 2015 04:26:20 -0000 Hi Stephen, The token carries the key used to generate message integrity for the STUN message. It was designed to be inline with the proof-of-possesion security mechanism discussed in https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01. STUN messages have to be signed to prove that it was indeed the TURN client that was authorized to use the token, and similarly the TURN server needs to prove to the TURN client that it was the server authorized by the WebRTC server and not a rouge TURN server. -Prashanth On 3/10/15, 2:29 PM, "Stephen Farrell" wrote: > >Hiya, > >On 10/03/15 21:21, Prashanth Patil (praspati) wrote: >> The Token, which is self contained, is encrypted so as to make it opaque >> to the client. All the information necessary to authenticate the >>validity >> of the token is contained within the token itself. > >Sorry I'm still not getting it. Exactly what information needs to be >confidential between which endpoints? > >When I think of the STUN/TURN problem in WebRTC, it's a pure question >of permission and accountability. > >Today, the web site hands out a username/secret for use of STURN or >TURN, which is bad, > >But why not have the web site sign a token that says "web site > says it's ok for whoever presents this to get STUN/TURN service" >with whatever timestamps or other controls are needed. I don't see >anything that needs to be inside that token that's not immediately >obvious from just watching the (ciphertext) packets flow. So I >don't see anything that needs encrypting between the web site and >the STUN/TURN servers. > >Cheers, >S. From nobody Wed Mar 11 00:40:18 2015 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 A365F1A00E5; Tue, 10 Mar 2015 21:27:49 -0700 (PDT) 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 OO64Bx4-pU7R; Tue, 10 Mar 2015 21:27:47 -0700 (PDT) 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 5DF711A008F; Tue, 10 Mar 2015 21:27:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1890; q=dns/txt; s=iport; t=1426048068; x=1427257668; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=aqTF6SEbABmqqxahkv7iWoGfs97AMj4rDfjs8NGcnLE=; b=buU/3Tz4fThPH02w2uUVLWw35aRmO1C1Zg9AMO0xMDKzUUKbnVOg4gH7 V9Pzaq+u/68IEB72LzuhHekn39C1NH4+a/Tvy9JEe1CUm4aNWCA3LcouM L6WxasWREgvzGMSvVdGXQC4Uq6WeI+p4NYmgwOB8kKSqyeNIkze0KKZZy 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C6CQByw/9U/49dJa1cgwOBMIMGvXWIJwIcgRhNAQEBAQEBfIQPAQEBAwEjETMQEgIBCBoCBiACAgIwFRACBAEaiB8IqzabLwEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYl2hD04gmgvgRYBBJAZnVIjg26CM38BAQE X-IronPort-AV: E=Sophos;i="5.11,379,1422921600"; d="scan'208";a="130849788" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-2.cisco.com with ESMTP; 11 Mar 2015 04:27:47 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t2B4RkQL026438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Mar 2015 04:27:46 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Tue, 10 Mar 2015 23:27:46 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Prashanth Patil (praspati)" , Stephen Farrell , Gonzalo Camarillo , "tram-chairs@ietf.org" , "tram@ietf.org" , "draft-ietf-tram-turn-third-party-authz@ietf.org" , "draft-ietf-tram-turn-third-party-authz.ad@ietf.org" , "draft-ietf-tram-turn-third-party-authz.shepherd@ietf.org" , "spencerdawkins.ietf@gmail.com" , "rlb@ipv.sx" , IESG Thread-Topic: New Version Notification - draft-ietf-tram-turn-third-party-authz-13.txt Thread-Index: AdBTBA4y4KcyM1WqQy+n0K4q1vICBAFKQmeAAAp7s4AACVE6AAAdCxYAABSWigAAlP6ngAABZl8AAAFvnYAAAyOPcA== Date: Wed, 11 Mar 2015 04:27:45 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A366B3348@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A366AA244@xmb-rcd-x10.cisco.com> <54F98585.7070203@ericsson.com> <54F9CBDF.7010705@cs.tcd.ie> <54FACD4E.8030706@ericsson.com> <54FB5778.2030405@cs.tcd.ie> <54FF56D0.80306@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.77.198] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 11 Mar 2015 00:40:04 -0700 Subject: Re: [tram] New Version Notification - draft-ietf-tram-turn-third-party-authz-13.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, 11 Mar 2015 04:27:49 -0000 PiA+DQo+ID5JIHRoaW5rIHlvdSBuZWVkIHRvIHBpY2sgb25lIChvciBtb3JlKSBNVEkgc2NoZW1l LiBBbmQgb25lIHRoYXQNCj4gPnByb3ZpZGVzIGJldHRlciBzZWN1cml0eSB0aGFuIHdlIGhhdmUg dG9kYXkgd2l0aCBTVFVOL1RVUk4uDQoNClRoZSBTVFVOL1RVUk4gU2VydmVyIGFuZCBXZWJSVEMg c2VydmVyIGNvdWxkIGJlIG9wZXJhdGVkIGJ5IHRoZSBzYW1lIHByb3ZpZGVyICh0aWdodGx5LWNv dXBsZWQpIGFuZCBpbiB0aGlzIGNhc2UgaXQgdGhleSBjYW4gY2hvb3NlIHRvIHBpY2sgd2hhdGV2 ZXIgbWVjaGFuaXNtIHN1aXRlcyBpdCBmb3IgZXN0YWJsaXNoaW5nIHRoZSBsb25nLXRlcm0ga2V5 LiBFdmVuIGluIHRoZSBzY2VuYXJpbyB3aGVyZSBTVFVOL1RVUk4gc2VydmVyIGFuZCBXZWJSVEMg c2VydmVyIGFyZSBvcGVyYXRlZCBieSBkaWZmZXJlbnQgcHJvdmlkZXJzIChsb29zZWx5LWNvdXBs ZWQpLCB0aGV5IG5lZWQgcHJpb3IgYnVzaW5lc3MgdGllLXVwIHRvIHV0aWxpemUgdGhlIFRVUk4v U1RVTiByZXNvdXJjZSBmb3IgV2ViUlRDIGNhbGxzIGFuZCB0aGV5IGNhbiBkZWNpZGUgb24gYW55 IGtleSBlc3RhYmxpc2htZW50IG1lY2hhbmlzbS4NCg0KPiA+DQo+ID5UaGUgb25seSBhbnN3ZXIg SSBjYW4gdGhpbmsgb2YgZm9yIHRoYXQgaXMgYSBzaWduYXR1cmUgYmFzZWQgc2NoZW1lIHRvDQo+ ID5iZSBob25lc3QuDQoNClRoZSB0b2tlbiBjYXJyaWVzIHNlc3Npb24ga2V5IHdoaWNoIGlzIHVz ZWQgZm9yIGdlbmVyYXRpbmcgbWVzc2FnZSBpbnRlZ3JpdHkgZm9yIFNUVU4gbWVzc2FnZXMsIGhl bmNlIHRoZSB0b2tlbiBuZWVkcyBib3RoIGVuY3J5cHRpb24gYW5kIHNpZ25hdHVyZS4gVGhlcmUg YXJlIG11bHRpcGxlIGtleXMgaW52b2x2ZWQgaW4gdGhpcyBtZWNoYW5pc20gWzFdIEtleXMgZm9y IGVuY3J5cHRpbmcgYW5kIGdlbmVyYXRpbmcgbWVzc2FnZSBpbnRlZ3JpdHkgb2YgdGhlIHRva2Vu IFsyXSBrZXkgZm9yIGdlbmVyYXRpbmcgbWVzc2FnZSBpbnRlZ3JpdHkgb2YgdGhlIFNUVU4gbWVz c2FnZS4NCg0KPiANCj4gU3VyZSwgd2XigJlsbCBuZWVkIFdHIGZlZWRiYWNrIG9uIHRoaXMuIFRo ZSBmZWVkYmFjayBmcm9tIHRoZSBXRyB3YXMgdG8gbm90DQo+IG1hbmRhdGUgb25lIGFzIHdlbGwu DQoNCkkgdGhpbmsgaXQgd2FzIGRpc2N1c3NlZCBpbiB0aGUgV0cgYW5kIHRoZSBkZWNpc2lvbiB3 YXMgbm90IHRvIG1hbmRhdGUgYW55IGtleSBlc3RhYmxpc2htZW50IHByb2NlZHVyZSwgSWYgdGhl cmUgaXMgbm8gb2JqZWN0aW9uIGZyb20gdGhlIFdHIHdlIHdpbGwgYWRkIHJlY29tbWVuZGF0aW9u IHRvIHVzZSBtZWNoYW5pc20gc3BlY2lmaWVkIGluIHNlY3Rpb24gNC4xLjIuDQoNCi1UaXJ1DQoN Cj4gDQo+ID4NCg== From nobody Wed Mar 11 00:40:20 2015 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 3CE7F1A01D5; Tue, 10 Mar 2015 21:39:24 -0700 (PDT) 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 RXLFA7DkVHJ8; Tue, 10 Mar 2015 21:39:22 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EF531A008F; Tue, 10 Mar 2015 21:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6870; q=dns/txt; s=iport; t=1426048761; x=1427258361; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=NWqEZyqEUUYdIX0oA6tNSqW1Hd5Kb0fs9kIDtxSME4o=; b=WXPI2Wxc8JY5GQRB/AaCIkz9ESAWSmpY3rFasOF8X++s7/mi/vyqruqI KXUv2ae7sg8o1WIeTHFZD9kc1+bZpM1bJcDN3b+5MSiISEOFK3RYzh7xH 7Lazq1fza6Q7VXgtqM8yTpvBzQCDD/5nwJ3hOcpZ6JXrEhSJ7H+ow5aiM c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DECQC3xv9U/5JdJa1cgwNSVQUEgwa9dYI5hW4CHIEXTQEBAQEBAXyEDwEBAQQjEUMOBAIBCBEEAQEBAgIGHQMCAgIfERQBCAgBAQQBEggBiBIDEQgFqyyVeg2FKAEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYl2gkSBeRYiBoJiL4EWBYYAihmDZ4QqgmQ5gm+JIYJRg0MjggIcgVBvAYFDfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,379,1422921600"; d="scan'208";a="130850788" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-7.cisco.com with ESMTP; 11 Mar 2015 04:39:13 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t2B4dDDe028042 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Mar 2015 04:39:13 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Tue, 10 Mar 2015 23:39:12 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Gonzalo Camarillo , "tram-chairs@ietf.org" , "tram@ietf.org" , "draft-ietf-tram-turn-third-party-authz@ietf.org" , "draft-ietf-tram-turn-third-party-authz.ad@ietf.org" , "draft-ietf-tram-turn-third-party-authz.shepherd@ietf.org" , "spencerdawkins.ietf@gmail.com" , "rlb@ipv.sx" , "stephen.farrell@cs.tcd.ie" , "The IESG (iesg@ietf.org)" Thread-Topic: New Version Notification - draft-ietf-tram-turn-third-party-authz-13.txt Thread-Index: AdBTBA4y4KcyM1WqQy+n0K4q1vICBAFKQmeAAOHNCsA= Date: Wed, 11 Mar 2015 04:39:11 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A366B3375@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A366AA244@xmb-rcd-x10.cisco.com> <54F98585.7070203@ericsson.com> In-Reply-To: <54F98585.7070203@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.77.198] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 11 Mar 2015 00:40:04 -0700 Subject: Re: [tram] New Version Notification - draft-ietf-tram-turn-third-party-authz-13.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, 11 Mar 2015 04:39:24 -0000 SGkgUmljaGFyZCwNCg0KUmVzZW5kaW5nIG91ciByZXNwb25zZXMgdG8gZGlzY3Vzc2lvbiBwb2lu dHMsIFBsZWFzZSBoYXZlIGEgbG9vay4NCg0KTGV0J3MgdGFsayBhYm91dCBTZWN0aW9uIDYuMiBh bmQgY3VzdG9tIGNyeXB0by4NCg0KKDEpIFlvdSBoYXZlIHRyaWVkIHRvIGludmVudCB5b3VyIG93 biBhdXRoZW50aWNhdGVkIGVuY3J5cHRpb24sIGFuZCBmYWxsZW4gaW50byB0aGUgdHJhcCBvZiBF bmNyeXB0LVRoZW4tTUFDIFswXS4gDQoNCltUUl0gTm8sIHRoZSBhdXRoZW50aWNhdGVkIGVuY3J5 cHRpb24gYWxnb3JpdGhtcyBhcmUgYWxyZWFkeSBjb3ZlcmVkIGluIGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0aG1zLTQwI3NlY3Rpb24t NS4xLg0KDQooRURJVDogQWN0dWFsbHksIGl0J3MgTUFDLXRoZW4tRW5jcnlwdCB0aGF0J3MgYmFk LiAgU2VlIHdoeSB5b3Ugc2hvdWxkIGp1c3QgdXNlIEFFQUQ/KSAgUGxlYXNlIHVzZSBhIHJlYWwg QUVBRCBtb2RlLCBzdWNoIGFzIEFFUy1HQ00gWzFdLiAgVGhhdCB3aWxsIGFsc28gcmVtb3ZlIHRo ZSBuZWVkIGZvciBwYWRkaW5nLCB3aGljaCBpcyBmcmF1Z2h0IHdpdGggcGVyaWwgYXMgd2VsbCBb Ml0uDQoNCltUUl0gUGFkZGluZyBhdHRhY2sgYXMgZGlzY3Vzc2VkIGluIFsyXSBpcyBwcmV2ZW50 ZWQgYnkgYXBwZW5kaW5nIEhNQUMgdG8gdGhlIGNpcGhlci10ZXh0LiBUaGUgZW5jcnlwdGVkX2Js b2NrIGluIHRoZSB0b2tlbiBpcyBpbnRlZ3JpdHkgcHJvdGVjdGVkIHVzaW5nIEhNQUMuDQoNCigy KSBJdCdzIGEgYmFkIGlkZWEgdG8gaGFyZC13aXJlIGNyeXB0b2dyYXBoaWMgYWxnb3JpdGhtcyBp bnRvIHByb3RvY29scywgYmVjYXVzZSB0aGV5IGluZXZpdGFibHkgZ28gYmFkIFszXS4gIA0KDQpb VFJdIFRoZSBjcnlwdG9ncmFwaGljIGFsZ29yaXRobXMgYXJlIG5vdCBoYXJkLWNvZGVkLCB0aGV5 IGNhbiBiZSBuZWdvdGlhdGVkIGIvdyB0aGUgU1RVTiBzZXJ2ZXIgYW5kIEF1dGhvcml6YXRpb24g c2VydmVyIHVzaW5nIHRoZSBtZWNoYW5pc21zIGluIA0KU2VjdGlvbiA0LjEuMTsgNC4xLjIgYWxs b3dzIEF1dGhvcml6YXRpb24gc2VydmVyIHRvIGNvbnZleSBhbnkgYWxnb3JpdGhtIG9mIGNob2lj ZTsgNC4xLjMgYWxsb3dzIGFueSBudW1iZXIgb2YgYWxnb3JpdGhtcyB0byBiZSBjb25maWd1cmVk IG9uIHRoZSBTVFVOIHNlcnZlciBhbmQgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIHRoZSBhbGdvcml0 aG0gcGlja2VkIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpcyBkZXRlcm1pbmVkIGJ5IHRo ZSBTVFVOIHNlcnZlciB1c2luZyB0aGUga2lkIGNvbnZleWVkIGluIHRoZSBTVFVOIHJlcXVlc3Qu DQoNCihTVFVOIGl0c2VsZiBpcyBhbiBhbnRpLXBhdHRlcm4gaGVyZS4pICBQbGVhc2UgYWRkIGFu IGFsZ29yaXRobSBpbmRpY2F0b3IgdG8gdGhlIHRvcCBvZiB5b3VyIHRva2VuIHN0cnVjdHVyZS4g IFlvdSBkb24ndCBuZWVkIHRvIGNyZWF0ZSBhIHJlZ2lzdHJ5IG5vdywgc2luY2UgeW91J3ZlIG9u bHkgZ290IG9uZSB2YWx1ZS4NCg0KVGhhdCBnaXZlcyB5b3Ugc29tZXRoaW5nIGxpa2UgdGhlIGZv bGxvd2luZywgbXVjaCBzaW1wbGVyIHN0cnVjdHVyZToNCg0Kc3RydWN0IHsNCiAgdWludDhfdCBh bGdvcml0aG07DQogIHVpbnQxNl90IGxlbmd0aDsNCiAgb3BhcXVlIGVuY3J5cHRlZF9ibG9ja1ts ZW5ndGhdOw0KfQ0KDQpzdHJ1Y3Qgew0KICB1aW50MTZfdCBrZXlfbGVuZ3RoOw0KICBvcGFxdWUg bWFjX2tleVtrZXlfbGVuZ3RoXTsNCiAgdWludDY0X3QgdGltZXN0YW1wOw0KICB1aW50MzJfdCBs aWZldGltZTsNCn0NCg0KSXQgYWxzbyBtZWFucyB0aGF0IHlvdSBjYW4gc2ltcGxpZnkgdGhlIGtl eSBtYW5hZ2VtZW50IHJvdXRpbmVzIGluIFNlY3Rpb24gNC4xLCBzaW5jZSB5b3Ugb25seSBuZWVk IG9uZSBrZXkuDQoNCigzKSBTZWN0aW9uIDUgc2hvdWxkIGJlIG1vcmUgY2xlYXIgYWJvdXQgaG93 IHRoaXMgbWVjaGFuaXNtIGNoYW5nZXMgU1RVTiBwcm9jZXNzaW5nLiAgTmFtZWx5LCBpdCBhZGRz IGEgdGhpcmQgcGFyYWxsZWwgbWV0aG9kIG9mIGNvbXB1dGluZyB0aGUgbWVzc2FnZSBpbnRlZ3Jp dHkgdmFsdWUsIHdoaWNoIHRoZSBzZXJ2ZXIgTVVTVCB1c2UgaWYgYW4gQUNDRVNTLVRPS0VOIGF0 dHJpYnV0ZSBpcyBwcmVzZW50LiAgDQoNCltUUl0gVGhlIGNsaWVudCBpcyB1bmF3YXJlIG9mIHRo ZSB0ZWNobmlxdWUgdXNlZCB0byBlbmNyeXB0IGFuZCBpbnRlZ3JpdHkgcHJvdGVjdCB0aGUgc2Vs Zi1jb250YWluZWQgdG9rZW4uIEl0IGp1c3QgdXNlcyB0aGUgbWFjX2tleSBwcm92aWRlZCBieSB0 aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8gY29tcHV0ZSB0aGUgbWVzc2FnZSBpbnRlZ3JpdHkg b2YgdGhlIFNUVU4gcmVxdWVzdC4NCg0KQ2hlZXJzLA0KLVRpcnUNCg0KWzBdIGh0dHBzOi8vZXBy aW50LmlhY3Iub3JnLzIwMDEvMDQ1DQpbMV0gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NTExNg0KWzJdIGh0dHA6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvUGFkZGluZ19vcmFjbGVfYXR0 YWNrDQpbM10gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhvdXNsZXktY3J5cHRv LWFsZy1hZ2lsaXR5LTAwDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog R29uemFsbyBDYW1hcmlsbG8gW21haWx0bzpHb256YWxvLkNhbWFyaWxsb0Blcmljc3Nvbi5jb21d DQo+IFNlbnQ6IEZyaWRheSwgTWFyY2ggMDYsIDIwMTUgNDoxNiBQTQ0KPiBUbzogVGlydW1hbGVz d2FyIFJlZGR5ICh0aXJlZGR5KTsgdHJhbS1jaGFpcnNAaWV0Zi5vcmc7IHRyYW1AaWV0Zi5vcmc7 IGRyYWZ0LQ0KPiBpZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRoekBpZXRmLm9yZzsgZHJh ZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHktDQo+IGF1dGh6LmFkQGlldGYub3JnOyBkcmFm dC1pZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRoei5zaGVwaGVyZEBpZXRmLm9yZzsNCj4g c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb207IHJsYkBpcHYuc3g7IHN0ZXBoZW4uZmFycmVs bEBjcy50Y2QuaWUNCj4gU3ViamVjdDogUmU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiAtIGRy YWZ0LWlldGYtdHJhbS10dXJuLXRoaXJkLXBhcnR5LWF1dGh6LQ0KPiAxMy50eHQNCj4gDQo+IFN0 ZXBoZW4sIFJpY2hhcmQsDQo+IA0KPiB5b3UgaGF2ZSBkaXNjdXNzZXMgb24gdGhpcyBkcmFmdDoN Cj4gDQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHJhbS10 dXJuLXRoaXJkLXBhcnR5LWF1dGh6L2JhbGxvdC8NCj4gDQo+IENvdWxkIHlvdSBwbGVhc2UgbG9v ayBhdCB0aGUgbmV3IHJldmlzaW9uIFRpcnUgaGFzIHB1dCB0b2dldGhlciBhbmQgbGV0IGhpbSBr bm93DQo+IGlmIHlvdSBhcmUgaGFwcHkgd2l0aCBpdD8NCj4gDQo+IFRoYW5rcywNCj4gDQo+IEdv bnphbG8NCj4gDQo+IE9uIDI4LzAyLzIwMTUgNToxMCBBTSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0 aXJlZGR5KSB3cm90ZToNCj4gPiBXZSBoYXZlIHJlc3BvbmRlZCB0byBjb21tZW50cyBmcm9tIElT RUcgYW5kIHB1Ymxpc2hlZCB1cGRhdGVkIGRyYWZ0Lg0KPiA+DQo+ID4gLVRpcnUNCj4gPg0KPiA+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+ID4+IFNlbnQ6IFRo dXJzZGF5LCBGZWJydWFyeSAyNiwgMjAxNSAxMDoyNiBBTQ0KPiA+PiBUbzogdHJhbS1jaGFpcnNA aWV0Zi5vcmc7IHRyYW1AaWV0Zi5vcmc7DQo+ID4+IGRyYWZ0LWlldGYtdHJhbS10dXJuLXRoaXJk LXBhcnR5LSBhdXRoekBpZXRmLm9yZzsNCj4gPj4gZ29uemFsby5jYW1hcmlsbG9AZXJpY3Nzb24u Y29tOyBkcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC0NCj4gPj4gcGFydHktYXV0aHouYWRAaWV0 Zi5vcmc7IGRyYWZ0LWlldGYtdHJhbS10dXJuLXRoaXJkLXBhcnR5LQ0KPiA+PiBhdXRoei5zaGVw aGVyZEBpZXRmLm9yZzsgc3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb207IHJsYkBpcHYuc3g7 DQo+ID4+IHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWUNCj4gPj4gU3ViamVjdDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIC0NCj4gPj4gZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHkt YXV0aHotDQo+ID4+IDEzLnR4dA0KPiA+Pg0KPiA+Pg0KPiA+PiBBIG5ldyB2ZXJzaW9uICgtMTMp IGhhcyBiZWVuIHN1Ym1pdHRlZCBmb3INCj4gPj4gZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQt cGFydHktDQo+ID4+IGF1dGh6Og0KPiA+PiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0eS0NCj4gPj4gYXV0aHotDQo+ID4+ IDEzLnR4dA0KPiA+Pg0KPiA+PiBTdWIgc3RhdGUgaGFzIGJlZW4gY2hhbmdlZCB0byBBRCBGb2xs b3d1cCBmcm9tIFJldmlzZWQgSUQgTmVlZGVkDQo+ID4+DQo+ID4+DQo+ID4+IFRoZSBJRVRGIGRh dGF0cmFja2VyIHBhZ2UgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6DQo+ID4+IGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHJhbS10dXJuLXRoaXJkLXBhcnR5 LWF1dA0KPiA+PiBoei8NCj4gPj4NCj4gPj4gRGlmZiBmcm9tIHByZXZpb3VzIHZlcnNpb246DQo+ ID4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdHJhbS10dXJu LXRoaXJkLXBhcnR5LWF1dA0KPiA+PiBoei0xMw0KPiA+Pg0KPiA+PiBQbGVhc2Ugbm90ZSB0aGF0 IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPiA+PiBz dWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFi bGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+ID4+DQo+ID4+IElFVEYgU2VjcmV0YXJpYXQuDQo+ID4N Cg0K From nobody Wed Mar 11 08:53:27 2015 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 BD5A11ACCE4; Wed, 11 Mar 2015 03:08:41 -0700 (PDT) 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 I05hh-5LKHIX; Wed, 11 Mar 2015 03:08:40 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13F141ACC83; Wed, 11 Mar 2015 03:08:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CDB98BEB1; Wed, 11 Mar 2015 10:08:38 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54VmC1wTylMM; Wed, 11 Mar 2015 10:08:38 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9CA77BE8A; Wed, 11 Mar 2015 10:08:38 +0000 (GMT) Message-ID: <55001427.2020201@cs.tcd.ie> Date: Wed, 11 Mar 2015 10:08:39 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Prashanth Patil (praspati)" , Gonzalo Camarillo , "Tirumaleswar Reddy (tireddy)" , "tram-chairs@ietf.org" , "tram@ietf.org" , "draft-ietf-tram-turn-third-party-authz@ietf.org" , "draft-ietf-tram-turn-third-party-authz.ad@ietf.org" , "draft-ietf-tram-turn-third-party-authz.shepherd@ietf.org" , "spencerdawkins.ietf@gmail.com" , "rlb@ipv.sx" , IESG References: <913383AAA69FF945B8F946018B75898A366AA244@xmb-rcd-x10.cisco.com> <54F98585.7070203@ericsson.com> <54F9CBDF.7010705@cs.tcd.ie> <54FACD4E.8030706@ericsson.com> <54FB5778.2030405@cs.tcd.ie> <54FF56D0.80306@cs.tcd.ie> <54FF623A.4000501@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Wed, 11 Mar 2015 08:53:25 -0700 Subject: Re: [tram] New Version Notification - draft-ietf-tram-turn-third-party-authz-13.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, 11 Mar 2015 10:08:41 -0000 So I think someone needs to draw me a picture at a whiteboard, which we can do in Dallas maybe, since I'm not getting the rationale behind the design here. S. On 11/03/15 04:26, Prashanth Patil (praspati) wrote: > Hi Stephen, > The token carries the key used to generate message integrity for the STUN > message. It was designed to be inline with the proof-of-possesion security > mechanism discussed in > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01. STUN > messages have to be signed to prove that it was indeed the TURN client > that was authorized to use the token, and similarly the TURN server needs > to prove to the TURN client that it was the server authorized by the > WebRTC server and not a rouge TURN server. > > -Prashanth > > On 3/10/15, 2:29 PM, "Stephen Farrell" wrote: > >> >> Hiya, >> >> On 10/03/15 21:21, Prashanth Patil (praspati) wrote: >>> The Token, which is self contained, is encrypted so as to make it opaque >>> to the client. All the information necessary to authenticate the >>> validity >>> of the token is contained within the token itself. >> >> Sorry I'm still not getting it. Exactly what information needs to be >> confidential between which endpoints? >> >> When I think of the STUN/TURN problem in WebRTC, it's a pure question >> of permission and accountability. >> >> Today, the web site hands out a username/secret for use of STURN or >> TURN, which is bad, >> >> But why not have the web site sign a token that says "web site >> says it's ok for whoever presents this to get STUN/TURN service" >> with whatever timestamps or other controls are needed. I don't see >> anything that needs to be inside that token that's not immediately >> obvious from just watching the (ciphertext) packets flow. So I >> don't see anything that needs encrypting between the web site and >> the STUN/TURN servers. >> >> Cheers, >> S. > From nobody Thu Mar 12 08:58:03 2015 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 27ED41A8892 for ; Thu, 12 Mar 2015 08:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4AgWDJCkwTGp for ; Thu, 12 Mar 2015 08:58:01 -0700 (PDT) Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE7401A885E for ; Thu, 12 Mar 2015 08:58:00 -0700 (PDT) Received: by obcuy5 with SMTP id uy5so14815924obc.11 for ; Thu, 12 Mar 2015 08:58:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=THCCx0ONmlz+heIrVc6ypYMmH5fqRdNnGX5dhti4j0E=; b=XJrq8sSoRE0WIrMrU4CslVmXVtECFu+ZUbHD1szmO8XRMmQUzjiwKprRu38MVC7Gwx zGVDlPO3oBVGWg8tK2Ka0/FOfCqE4hQPcad58I2klPSkxvLwP9WNN01ZcPMJk8M8xxi+ pJQrzIRu0Wn1FBK7bTS60zXY+3jrZLF+HV0q5VC7GjKAXcaFRiFWORzafgA/JYV1/UpH BiQ7IZsYNOTnkA9HCC0DVORT5yQCOpCX72DQcxaGhfNePblQkwKJ3+iYysQ2axugbzGp z6gtHTtalleeKhTlKxdirpy12bEOMUqDNQgCHZhXnzhZg2/0AsxeEqzPi2mQdiTC2zeY SCjg== X-Gm-Message-State: ALoCoQn9cMdUCkhSr0R38TvtdV7v1+rYmc1kkdkr6rdWAdRSk6aTrG0feviyGtwfod/wGCPCU0/q X-Received: by 10.202.181.136 with SMTP id e130mr32610877oif.53.1426175880172; Thu, 12 Mar 2015 08:58:00 -0700 (PDT) Received: from [192.168.1.43] (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id rt10sm4792265obb.7.2015.03.12.08.57.58 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Mar 2015 08:57:59 -0700 (PDT) Message-ID: <5501B785.9040608@jive.com> Date: Thu, 12 Mar 2015 11:57:57 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "tram@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [tram] TRAM slot has moved 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, 12 Mar 2015 15:58:02 -0000 Good news everyone! TRAM will get two hours instead of just one. Our slot has moved from Wednesday 15:20-16:20 to Thursday 15:20-17:20. Updated agenda: http://www.ietf.org/proceedings/92/agenda/agenda-92-tram Simon From nobody Thu Mar 12 11:56:10 2015 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 913971A1B49 for ; Thu, 12 Mar 2015 11:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 xgUG3ZmHFDo3 for ; Thu, 12 Mar 2015 11:56:07 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 50BDA1A1B4B for ; Thu, 12 Mar 2015 11:56:06 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 23A2F476CB; Thu, 12 Mar 2015 18:56:05 +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 17F7C476C9; Thu, 12 Mar 2015 18:56:05 +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 055E2202C; Thu, 12 Mar 2015 18:56:05 +0000 (GMT) Message-ID: <5501E144.6050709@akamai.com> Date: Thu, 12 Mar 2015 14:56:04 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Simon Perreault , "tram@ietf.org" References: <5501B785.9040608@jive.com> In-Reply-To: <5501B785.9040608@jive.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tram] TRAM slot has moved 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, 12 Mar 2015 18:56:09 -0000 Hi Simon, With the extended schedule, it would be great if I could get a short slot to go over the changes to the peer redirect draft and gauge WG interest in adopting the draft. 5-10 minutes would be enough if you think it could be carved out somewhere, though I can see that it might be difficult. Thanks, --Brandon On 03/12/2015 11:57 AM, Simon Perreault wrote: > Good news everyone! TRAM will get two hours instead of just one. Our > slot has moved from Wednesday 15:20-16:20 to Thursday 15:20-17:20. > > Updated agenda: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_proceedings_92_agenda_agenda-2D92-2Dtram&d=AwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=VppCfx4Qp0gueWFv8IBwiNDjUJPago6Csw_WUsHUOJk&s=fGYNEkFYd__TSOdFV0MEnPloJzy3Fn-156_-vhiNZa8&e= > > Simon > > _______________________________________________ > tram mailing list > tram@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=AwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=VppCfx4Qp0gueWFv8IBwiNDjUJPago6Csw_WUsHUOJk&s=_lVT5RET5Sp2TVjAb4xtFrZ6lF9QaWKrA_fzIcpWRHY&e= > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Thu Mar 12 14:23:30 2015 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 16B531A9238 for ; Thu, 12 Mar 2015 14:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DUq6_FU2e1pc for ; Thu, 12 Mar 2015 14:23:26 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEBF31A9177 for ; Thu, 12 Mar 2015 14:23:25 -0700 (PDT) Received: by iegc3 with SMTP id c3so63602649ieg.3 for ; Thu, 12 Mar 2015 14:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=44WAAE8KI2qNARYhWCgnwyfiYKuEg9sCFTKLeSNgenc=; b=b5mN0PVseg6zyFAgzRbxRW0fCUDtNBs7rqIQhEmGa93yrzK0N12Qh1Npi2kDgIMkUx OZKDuCIX8jf0VZmbrG8xhydC84EvxJwWTs9kiFUjp6O9ZAHUW0oxTLUcyICwjB2Aff6Y bcBtUqcqkrkKAEthiiKz0CgFgpl+9HOf+GadsmcBokJHJEYARjSi4ENhh7+do5g3BiIM eatwd86OVMVKKToW7VLbsbEtvVxDw1c86WdacJfgGz41xhXN952jz8njHyifVYVZ89hS hKNett8DS/dKU7xrAmpJO6unF5tpCxj/RlJU++8Vws1jgu1Y8/wfY6gPg6ZJyXMEpboq Fmfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=44WAAE8KI2qNARYhWCgnwyfiYKuEg9sCFTKLeSNgenc=; b=EcJefGj2deeCMcZ9XBtjJu4IIYvIfdBxmsdjEhYalacQ0VUqn3OFOngobQrUrF1AbU Pa4e9Ywn8fMiC7nU0SnxDFy2hnE41GLTqwfozO4/xqVPn5dahlxRQguT+J64g5G3NSFV F3tRsmobjmzSoXvSj7bWZXdhim7614wm2okul7M5zSM21nRj50cDetYdWoBlKHliVPNL f56y/S6eTYbC2aqHL9htKncZHnJ3pyaisDS578btsNzuDZN7w1k77je0fHnJph4I905i DY8g6TqlOSMvfo/USS3MewosWk9t7A2x9o9vApe95n77cbFTWoUGESjX04d73dT4i/yK /NUg== X-Gm-Message-State: ALoCoQkiB+VFa2/uVHKSSgHKmLOc2+AYGWIifnBkndXIXrsaoBKMYKcF9qsCAozvzCVxGegXaQQw X-Received: by 10.107.157.195 with SMTP id g186mr79459725ioe.72.1426195398272; Thu, 12 Mar 2015 14:23:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.64.42 with HTTP; Thu, 12 Mar 2015 14:22:58 -0700 (PDT) From: Justin Uberti Date: Thu, 12 Mar 2015 14:22:58 -0700 Message-ID: To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=001a11409acc18576105111dfe32 Archived-At: Cc: Marc Petit-Huguenin , Benjamin Schwartz , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: [tram] STUN fragmentation [Was: I-D Action: draft-ietf-tram-stunbis-01.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, 12 Mar 2015 21:23:30 -0000 --001a11409acc18576105111dfe32 Content-Type: text/plain; charset=UTF-8 > > > > > > > Section 6.1: > > > > "If a STUN client needs to send requests that are larger than the MTU, > > or if an application envisions that a response would be larger then > > the MTU, then it MUST use SCTP-over-UDP or SCTP-over-DTLS-over-UDP as > > transport, unless the purpose of sending an oversized packet is to > > probe for MTU characteristics (see [RFC5780])." > > So, SCTP is used here purely as a tool to solve the fragmentation > problem ? Right ? > I understand the intent here, but this seems like a very heavyweight solution to what seems like an edge case. Is anyone planning to actually implement this, and if so, could you describe the situation where this is actually encountered? --001a11409acc18576105111dfe32 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


>
> Section 6.1:
>
> "If a STUN client needs to send requests that are larger than the= MTU,
>=C2=A0 or if an application envisions that a response would be larger t= hen
>=C2=A0 the MTU, then it MUST use SCTP-over-UDP or SCTP-over-DTLS-over-U= DP as
>=C2=A0 transport, unless the purpose of sending an oversized packet is = to
>=C2=A0 probe for MTU characteristics (see [RFC5780])."

So, SCTP is used here purely as a tool to solve the fragmentation problem ? Right ?

I understand the inte= nt here, but this seems like a very heavyweight solution to what seems like= an edge case. Is anyone planning to actually implement this, and if so, co= uld you describe the situation where this is actually encountered?=C2=A0
--001a11409acc18576105111dfe32-- From nobody Thu Mar 12 14:26:04 2015 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 31BB71A92AD for ; Thu, 12 Mar 2015 14:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1dsHTz0hhdZX for ; Thu, 12 Mar 2015 14:26:01 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5550E1A92B6 for ; Thu, 12 Mar 2015 14:26:01 -0700 (PDT) Received: by iecsl2 with SMTP id sl2so61464938iec.1 for ; Thu, 12 Mar 2015 14:26:00 -0700 (PDT) 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=zD6aHJRinycIdbAJuo+2e/3qcOBxVS14UhomAcvI+DE=; b=aFZ7mlapR0MAmbxgf0ALcG/g/xSbap80WS/rpV30c3/Nwgna4Hvo0zwOg4Et9G4NPU +qD2sU+7otEAydN/KQIPllwPmhyOTYT6SbfZVHKf4xFdf7l1BD4VLrAJYsWnXoz+bEDV c/i0C/KVvGl3ZhfANnkBSNfps5EIA5yVZQH9EVS5+Ti4laAQM3nNkoJPYiM42SU/18Sv NmN1de4wSp0zqP6fvnTrS8PXi8Z8BbBrx2O6Gvb+LXUMu76CcouQI7c6aLIkIk2EMjrG 8zNY45iCyycdMBCyVtnPizfk4GuLf7ig15UaHnIkS3Pww/2TYWJ2L+S32BoqRXxvkQcV G9bA== 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=zD6aHJRinycIdbAJuo+2e/3qcOBxVS14UhomAcvI+DE=; b=K5WTscAOoPsafPOsDkhD6BgLTwnqDv3TnnJGYLT6bGphdUaRnGvCvTXcmZpBJgRPB1 IACi6S9yVEwRN3Y3OcSr4aBqKBxI1Ef+p9oDyu9vQESppx8Ad23YwNn2reuVwyo+f/eP xRAGG+uIcB0LUn0LGCKTAi4nrSRRwpYk6zYtWcR+4CHHS5Oxw+0GMo7G0krm0yTc5K2I RTIwrWZighDZy/fHftVgPu8E+CqLv5pJEITK0ffSM3PYQbuvbrlUmido5oriGg1qRETh Ywx8qXvJ8sz2+c27I70miLOOZvLeNFDf7yepuT3rPmZhGjvL28vLs+gI3JY7Q0x5pZ7y 22Bg== X-Gm-Message-State: ALoCoQn7NS/mDYd0lL4padsYjc7Sf4AH8LX6NQSXI5RKzykWu/Jtw6mXiO8XzoMZ/zD0batpHg2F X-Received: by 10.50.28.8 with SMTP id x8mr78180072igg.19.1426195551659; Thu, 12 Mar 2015 14:25:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.64.42 with HTTP; Thu, 12 Mar 2015 14:25:31 -0700 (PDT) In-Reply-To: <54FD645B.9000905@acm.org> References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> <54EF3616.4040704@acm.org> <54FD645B.9000905@acm.org> From: Justin Uberti Date: Thu, 12 Mar 2015 14:25:31 -0700 Message-ID: To: Marc Petit-Huguenin Content-Type: multipart/alternative; boundary=089e015386d63cd83d05111e0774 Archived-At: Cc: Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.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, 12 Mar 2015 21:26:03 -0000 --089e015386d63cd83d05111e0774 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 9, 2015 at 2:14 AM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 02/26/2015 09:56 AM, Oleg Moskalenko wrote: > > On Thu, Feb 26, 2015 at 7:04 AM, Marc Petit-Huguenin > wrote: > > > >>> There is a well-defined association between the hash length and the > >>> algorithm. SHA-1 produce 20 bytes, SHA-256 produce 32 bytes, SHA-384 > >>> produce 48 bytes and SHA-512 produce 64 bytes. Why we cannot use the > >>> MESSAGE-INTEGRITY length to determine the algorithm that the peer is > >>> using ? > >> > >> Does not work with SHA-3. > >> > > > > If there is a requirement to support wide multiplicity of algorithms, > > even SHA-3, then I see two clear choices: > > > > 1) Leave the algorithm negotiation to the out-of-bound communication > > channel between the client and the server. They can negotiate what > > kind of hash is used, and what is the size of the MESSAGE-INTEGRITY to > > be. > > 2) Implement a usual negotiation scheme, like in TLS. We can introduce > > a new attribute that contains "algorithm ID" and optionally "algorithm > > attribute(s)" (specific to algorithm). The client sends a number of > > supported algorithm attributes to the server, server either rejects or > > picks one and sends back authenticated response with the chosen > > algorithm attribute. If no attribute is included in the client or > > server message, that means default "SHA-1, 160 bits". If a variable > > length hash algorithm chosen, then that's fine, the message recipient > > will just use the MESSAGE-INTEGRITY attribute length (given they > > already agree on a particular algorithm). > > > > I'd vote for the second approach. That way, we introduce no extra > > round trips, we cover multiple algorithms (including the future ones), > > and we have full backward compatibility. > > We do not vote here. You will have to build a consensus for your solution > of choice, and as co-editor I will modify the draft to follow this > consensus. > > As an individual, I support neither of the solutions you proposed for the > following reasons: > > - - HMAC-SHA is not broken but going to HMAC-SHA256 is a cautious step I > (reluctantly) agree with. > - - Negotiation is more often used to decrease security than to increase > it so let's not unless we have no choice (as for the password hash, that is > broken). > - - Adding negotiation means that short-term authentication may get an > additional round-trip for each ICE's connectivity check. > - - The solution proposed in the draft follows what the authors of RFC > 5389 suggested in section 16.3. > > MESSAGE-INTEGRITY is not a critical part of the overall application security. +1 to keeping it simple. --089e015386d63cd83d05111e0774 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 9, 2015 at 2:14 AM, Marc Petit-Huguenin &= lt;petithug@acm.org> wrote:
---= --BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/26/2015 09:56 AM, Oleg Moskalenko wrote= :
> On Thu, Feb 26, 2015 at 7:04 AM, Marc Petit-Huguenin <petithug@acm.org> wrote:
>
>>> There is a well-defined association between the hash length an= d the
>>> algorithm. SHA-1 produce 20 bytes, SHA-256 produce 32 bytes, S= HA-384
>>> produce 48 bytes and SHA-512 produce 64 bytes. Why we cannot u= se the
>>> MESSAGE-INTEGRITY length to determine the algorithm that the p= eer is
>>> using ?
>>
>> Does not work with SHA-3.
>>
>
> If there is a requirement to support wide multiplicity of algorithms,<= br> > even SHA-3, then I see two clear choices:
>
> 1) Leave the algorithm negotiation to the out-of-bound communication > channel between the client and the server. They can negotiate what
> kind of hash is used, and what is the size of the MESSAGE-INTEGRITY to=
> be.
> 2) Implement a usual negotiation scheme, like in TLS. We can introduce=
> a new attribute that contains "algorithm ID" and optionally = "algorithm
> attribute(s)" (specific to algorithm). The client sends a number = of
> supported algorithm attributes to the server, server either rejects or=
> picks one and sends back authenticated response with the chosen
> algorithm attribute. If no attribute is included in the client or
> server message, that means default "SHA-1, 160 bits". If a v= ariable
> length hash algorithm chosen, then that's fine, the message recipi= ent
> will just use the MESSAGE-INTEGRITY attribute length (given they
> already agree on a particular algorithm).
>
> I'd vote for the second approach. That way, we introduce no extra<= br> > round trips, we cover multiple algorithms (including the future ones),=
> and we have full backward compatibility.

We do not vote here.=C2=A0 You will have to build a consensus f= or your solution of choice, and as co-editor I will modify the draft to fol= low this consensus.

As an individual, I support neither of the solutions you proposed for the f= ollowing reasons:

- - HMAC-SHA is not broken but going to HMAC-SHA256 is a cautious step I (r= eluctantly) agree with.
- - Negotiation is more often used to decrease security than to increase it= so let's not unless we have no choice (as for the password hash, that = is broken).
- - Adding negotiation means that short-term authentication may get an addi= tional round-trip for each ICE's connectivity check.
- - The solution proposed in the draft follows what the authors of RFC 5389= suggested in section 16.3.


MESSAGE-INTEGR= ITY is not a critical part of the overall application security. +1 to keepi= ng it simple.=C2=A0
--089e015386d63cd83d05111e0774-- From nobody Thu Mar 12 20:14:38 2015 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 1055B1AC3BE for ; Thu, 12 Mar 2015 20:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.242 X-Spam-Level: X-Spam-Status: No, score=-0.242 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, RCVD_IN_BL_SPAMCOP_NET=1.347] 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 r5-zj3Bpm8yc for ; Thu, 12 Mar 2015 20:14:34 -0700 (PDT) Received: from tsinghua.org.cn (mail.alumail.com [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id D666E1A89A3 for ; Thu, 12 Mar 2015 20:14:33 -0700 (PDT) Received: from ctbriwangaij (unknown [124.127.116.138]) by app1 (Coremail) with SMTP id Z0GX06Br4QEjPQJVnBiYAw==.61602S2; Fri, 13 Mar 2015 09:28:18 +0800 (CST) From: "Aijun Wang" To: References: <000701d05acc$fe283320$fa789960$@org.cn> In-Reply-To: <000701d05acc$fe283320$fa789960$@org.cn> Date: Fri, 13 Mar 2015 11:14:14 +0800 Message-ID: <00b301d05d3b$d1b8d7b0$752a8710$@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: AdBaFySvUDON/DiqRAuuWLj5RsBGZQAs2NYgAJt4sOA= Content-Language: zh-cn X-CM-TRANSID: Z0GX06Br4QEjPQJVnBiYAw==.61602S2 X-Coremail-Antispam: 1U3129KBjvJXoWxWw1UZr45uw13Zr1xAF4fKrg_yoW5Zw4rpa yrWr4Yg3yktr97Can7Gw47uF1rurykWrZ7Ary5Gr1jka98Aa42qry7tF1rury8WrWrGr98 Xr4a9F15Ca1rXrJanT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjBvb7 Iv0xC_Jr1l5I8CrVACY4xI64kE6c02F40Ex7xfM7kC6x804xWl14x267AKxVWUJVW8JwAF xVCF77xC6IxKo4kEV4yl1I0EscIYIxCEI4klw4CSwwAv7VCjz48v1sIEY20_GF1lx4CE17 CEb7AF67AKxVWUJVWUXjIFyTuYvjfUojjgDUUUU Archived-At: Subject: [tram] Is there any example that TURN servers deployed in distributed manner by one third party now? 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, 13 Mar 2015 03:14:36 -0000 Hi, all: Here I want to know whether anyone has deployed or know others have deployed the TURN services for the third party in real world? If so, how many TURN servers are deployed within their domain? How many customers are they servicing now? we are also appreciate for other useful references for such information. Best Regards. Aijun Wang. -----Original Message----- From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Tuesday, March 10, 2015 8:56 AM To: tram@ietf.org Cc: 'Liubing (Leo)' Subject: [tram] FW: New Version Notification for draft-wang-tram-turnlite-02.txt Hi All Tramer: We updated one new version about TURNLite(lightweight TURN) architecture and its solution to the host-to-host communication via the relay devices. This draft summarizes also all the discussions about current TURN solution in the TRAM mailing list, gives the main procedures of TURNLite and two detail examples for IPv4/IPv4(under Non-BEHAVE compliant NAT environment) and IPv4/IPv6 communication. The purpose of this draft is to design one simplified relay solution that can easily incorporated into some distributed deployed network devices, for example CGN devices or CDN nodes within ISP's network. Any comments for this draft are welcome, we can also discuss it with all the Tramers in the coming IETF meeting. The URL of this update draft is here: http://datatracker.ietf.org/doc/draft-wang-tram-turnlite/ Best Regards. Aijun Wang. -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, March 09, 2015 11:14 AM To: Aijun Wang; Bing Liu; Aijun Wang; Bing Liu Subject: New Version Notification for draft-wang-tram-turnlite-02.txt A new version of I-D, draft-wang-tram-turnlite-02.txt has been successfully submitted by Bing Liu and posted to the IETF repository. Name: draft-wang-tram-turnlite Revision: 02 Title: A Lightweight TURN Architecture and Specification (TURN-Lite) Document date: 2015-03-09 Group: Individual Submission Pages: 17 URL: http://www.ietf.org/internet-drafts/draft-wang-tram-turnlite-02.txt Status: https://datatracker.ietf.org/doc/draft-wang-tram-turnlite/ Htmlized: http://tools.ietf.org/html/draft-wang-tram-turnlite-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-wang-tram-turnlite-02 Abstract: This document proposes a new relay-based NAT traversal architecture called TURN-Lite which could simplify the data communication process between two hosts that locates behind some non-BEHAVE compliant [RFC4787] [RFC5382] NAT devices. The key mechanism in TURN-Lite is the newly defined "Couple" operation (using STUN [RFC5389] message format) which allows the TURN-Lite servers to be easily incorporated into existing CGN devices/CDN nodes which are already deployed within the network in a distributed manner. 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 Thu Mar 12 23:43:03 2015 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 4B92C1A8A7F for ; Thu, 12 Mar 2015 23:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, 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 If1NDutYyDql for ; Thu, 12 Mar 2015 23:43:01 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1F941A8A79 for ; Thu, 12 Mar 2015 23:43:00 -0700 (PDT) Received: by wesx3 with SMTP id x3so21207578wes.1 for ; Thu, 12 Mar 2015 23:42:59 -0700 (PDT) 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=LE6NTYN3CAxJU383eo4/MyZ27sl2m9TaYRxYas24ANk=; b=kOxILsdrvXEXRh+rbxLHg2Y+HTeaZQTolrfYmM41TYtw+7NtOipIm34OZ0ooDoJCnJ Py2EQoyy1v4GqS/iOR7cFX83ugxTlr2/fsgd3oYYukfiXgMt937Jam5C6mQLKwA09Vaz Hac9941D8REKdIE3lPiW/SgtoeScRPR2hcBd0wQD9B9JUHYj+lxGLiDbrNfp0Eqx3MT0 dMNgmvsuzDLGjJ+5ANX4hiK2g31Acko/sQFj8CI2l+MHC8jNb3nbzBVaF5KBe8aNMN8Q Gn6blzosmFd+UE03WbciyTMjb20jHOk90zx67S4zVeh0Q4LWEFJhA6sXNq+AX2rl7Yjg 3e6Q== MIME-Version: 1.0 X-Received: by 10.194.159.105 with SMTP id xb9mr42060685wjb.156.1426228979430; Thu, 12 Mar 2015 23:42:59 -0700 (PDT) Received: by 10.194.190.18 with HTTP; Thu, 12 Mar 2015 23:42:59 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Mar 2015 23:42:59 -0700 Message-ID: From: Oleg Moskalenko To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Marc Petit-Huguenin , Benjamin Schwartz , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] STUN fragmentation [Was: I-D Action: draft-ietf-tram-stunbis-01.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, 13 Mar 2015 06:43:02 -0000 On Thu, Mar 12, 2015 at 2:22 PM, Justin Uberti wrote: >> >> >> > >> > Section 6.1: >> > >> > "If a STUN client needs to send requests that are larger than the MTU, >> > or if an application envisions that a response would be larger then >> > the MTU, then it MUST use SCTP-over-UDP or SCTP-over-DTLS-over-UDP as >> > transport, unless the purpose of sending an oversized packet is to >> > probe for MTU characteristics (see [RFC5780])." >> >> So, SCTP is used here purely as a tool to solve the fragmentation >> problem ? Right ? > > > I understand the intent here, but this seems like a very heavyweight > solution to what seems like an edge case. Is anyone planning to actually > implement this, and if so, could you describe the situation where this is > actually encountered? > I agree that this solution sounds like an overkill. I am not sure about a potential implementation. Implementing SCTP-over-UDP may not be that easy. I am still researching but it seems like the standard Linux and FreeBSD network library suite does not have off-the-shelf "tunnelling" SCTP-inside-something solution (I may be wrong). The available headers and libraries are mostly for the "native" SCTP networking. Definitely, that complicates the implementation and adds extra dependencies on the third-party libraries (if there are any available). Oleg From nobody Fri Mar 13 01:36:42 2015 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 9D53F1A1A9D for ; Fri, 13 Mar 2015 01:36:41 -0700 (PDT) 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 GrQHiiguEFSn for ; Fri, 13 Mar 2015 01:36:39 -0700 (PDT) Received: from smtpcmd01217.aruba.it (smtpcmd01217.aruba.it [62.149.158.217]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF791A0026 for ; Fri, 13 Mar 2015 01:36:39 -0700 (PDT) Received: from lminiero ([87.17.153.66]) by smtpcmd01.ad.aruba.it with bizsmtp id 2wc31q00y1SCooP01wc9Sw; Fri, 13 Mar 2015 09:36:37 +0100 Date: Fri, 13 Mar 2015 09:35:55 +0100 From: Lorenzo Miniero To: Oleg Moskalenko Message-ID: <20150313093555.6b92a339@lminiero> In-Reply-To: References: 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=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: Marc Petit-Huguenin , Benjamin Schwartz , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" , Justin Uberti Subject: Re: [tram] STUN fragmentation [Was: I-D Action: draft-ietf-tram-stunbis-01.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, 13 Mar 2015 08:36:41 -0000 On Thu, 12 Mar 2015 23:42:59 -0700 Oleg Moskalenko wrote: > On Thu, Mar 12, 2015 at 2:22 PM, Justin Uberti > wrote: > >> > >> > >> > > >> > Section 6.1: > >> > > >> > "If a STUN client needs to send requests that are larger than > >> > the MTU, or if an application envisions that a response would be > >> > larger then the MTU, then it MUST use SCTP-over-UDP or > >> > SCTP-over-DTLS-over-UDP as transport, unless the purpose of > >> > sending an oversized packet is to probe for MTU characteristics > >> > (see [RFC5780])." > >> > >> So, SCTP is used here purely as a tool to solve the fragmentation > >> problem ? Right ? > > > > > > I understand the intent here, but this seems like a very heavyweight > > solution to what seems like an edge case. Is anyone planning to > > actually implement this, and if so, could you describe the > > situation where this is actually encountered? > > > > I agree that this solution sounds like an overkill. > > I am not sure about a potential implementation. Implementing > SCTP-over-UDP may not be that easy. I am still researching but it > seems like the standard Linux and FreeBSD network library suite does > not have off-the-shelf "tunnelling" SCTP-inside-something solution (I > may be wrong). The available headers and libraries are mostly for the > "native" SCTP networking. Definitely, that complicates the > implementation and adds extra dependencies on the third-party > libraries (if there are any available). > Hi Oleg, there is indeed a third-party library available that can be used for the purpose, the user-space usrsctp code that can be found here: https://code.google.com/p/sctp-refimpl/ Lorenzo > Oleg > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Fri Mar 13 05:35:38 2015 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 2C9301A037A; Fri, 13 Mar 2015 05:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QngCh8v3vCIq; Fri, 13 Mar 2015 05:33:48 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D7391A0AF8; Fri, 13 Mar 2015 05:33:47 -0700 (PDT) X-AuditID: c1b4fb30-f79996d000006ebb-b2-5502d929e78e Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 5A.CC.28347.929D2055; Fri, 13 Mar 2015 13:33:45 +0100 (CET) Received: from [147.214.22.90] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.3.210.2; Fri, 13 Mar 2015 13:33:44 +0100 Message-ID: <5502D928.7010205@ericsson.com> Date: Fri, 13 Mar 2015 13:33:44 +0100 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Stephen Farrell , "Prashanth Patil (praspati)" , "Tirumaleswar Reddy (tireddy)" , "tram-chairs@ietf.org" , "tram@ietf.org" , "draft-ietf-tram-turn-third-party-authz@ietf.org" , "draft-ietf-tram-turn-third-party-authz.ad@ietf.org" , "draft-ietf-tram-turn-third-party-authz.shepherd@ietf.org" , "spencerdawkins.ietf@gmail.com" , "rlb@ipv.sx" , IESG References: <913383AAA69FF945B8F946018B75898A366AA244@xmb-rcd-x10.cisco.com> <54F98585.7070203@ericsson.com> <54F9CBDF.7010705@cs.tcd.ie> <54FACD4E.8030706@ericsson.com> <54FB5778.2030405@cs.tcd.ie> <54FF56D0.80306@cs.tcd.ie> <54FF623A.4000501@cs.tcd.ie> <55001427.2020201@cs.tcd.ie> In-Reply-To: <55001427.2020201@cs.tcd.ie> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+Jvja7mTaZQg+WXVSwez+lnt9i19QOT RfulJywWM/5MZLbo3nmU0WJqn63Fsil7mC2m773GbnFi9zZGi+U/V7JZfFh7gc2B22PK742s Hmu7r7J57Jx1l91jyZKfTB6TN85iCWCN4rJJSc3JLEst0rdL4MpofhtScE2w4trLpcwNjJP5 uhg5OSQETCT+/H/PDGGLSVy4t54NxBYSOMIo8XoKUJwLyF7NKDHt9i9GkASvgLbEhy8dYDaL gKpE9+p9rCA2m4CFxJZb91lAbFGBKInZ5x+wQtQLSpyc+YQFZJCIwGZWieYbz8GKhAVCJV58 PMUKtYFZYur1frAEp4CmRMuVtUBncHAwA9nrd+mDhJkF5CW2v53DDHGdtsTyZy0sExgFZiHZ MQuhYxaSjgWMzKsYRYtTi5Ny042M9FKLMpOLi/Pz9PJSSzYxAmPh4JbfBjsYXz53PMQowMGo xMP7oYspVIg1say4MvcQozQHi5I4r53xoRAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjOLx Pfse/dzBZ/zx7Pbz/7Wk3J7Zh/tVzBWwWn9ecK6o0f0bJn9Xrgg8LXzl/8msO5e2ip1ZIzNV VWFRAG+Iy57kuknnbTZu/n9K33hv8ZmrD5Vmcrf5hp++cHuL4bVLWu9/qxwysg9d12W89vfC lHDmD2eLdMyf8eY1HcgS/3D93b2TYvyvBG8qsRRnJBpqMRcVJwIAXrDPU2YCAAA= Archived-At: X-Mailman-Approved-At: Fri, 13 Mar 2015 05:35:37 -0700 Subject: Re: [tram] New Version Notification - draft-ietf-tram-turn-third-party-authz-13.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, 13 Mar 2015 12:33:53 -0000 Hi Spencer, could you please propose a timeslot that works for both you and Stephen so that we can move this forward during the upcoming meeting in Dallas? Thanks, Gonzalo On 11/03/2015 11:08 AM, Stephen Farrell wrote: > > So I think someone needs to draw me a picture at a whiteboard, which > we can do in Dallas maybe, since I'm not getting the rationale behind > the design here. > > S. > > On 11/03/15 04:26, Prashanth Patil (praspati) wrote: >> Hi Stephen, >> The token carries the key used to generate message integrity for the STUN >> message. It was designed to be inline with the proof-of-possesion security >> mechanism discussed in >> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01. STUN >> messages have to be signed to prove that it was indeed the TURN client >> that was authorized to use the token, and similarly the TURN server needs >> to prove to the TURN client that it was the server authorized by the >> WebRTC server and not a rouge TURN server. >> >> -Prashanth >> >> On 3/10/15, 2:29 PM, "Stephen Farrell" wrote: >> >>> >>> Hiya, >>> >>> On 10/03/15 21:21, Prashanth Patil (praspati) wrote: >>>> The Token, which is self contained, is encrypted so as to make it opaque >>>> to the client. All the information necessary to authenticate the >>>> validity >>>> of the token is contained within the token itself. >>> >>> Sorry I'm still not getting it. Exactly what information needs to be >>> confidential between which endpoints? >>> >>> When I think of the STUN/TURN problem in WebRTC, it's a pure question >>> of permission and accountability. >>> >>> Today, the web site hands out a username/secret for use of STURN or >>> TURN, which is bad, >>> >>> But why not have the web site sign a token that says "web site >>> says it's ok for whoever presents this to get STUN/TURN service" >>> with whatever timestamps or other controls are needed. I don't see >>> anything that needs to be inside that token that's not immediately >>> obvious from just watching the (ciphertext) packets flow. So I >>> don't see anything that needs encrypting between the web site and >>> the STUN/TURN servers. >>> >>> Cheers, >>> S. >> From nobody Fri Mar 13 08:50:45 2015 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 3D3E81A8A9E for ; Fri, 13 Mar 2015 08:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, 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 bLN_tkZ19Pw7 for ; Fri, 13 Mar 2015 08:50:43 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C3541A8A93 for ; Fri, 13 Mar 2015 08:50:43 -0700 (PDT) Received: by padfb1 with SMTP id fb1so30416551pad.7 for ; Fri, 13 Mar 2015 08:50:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Xwcwci8dNdi8fGFerC3a1bhK0cWO6mdFvNRf5xTSTk8=; b=0CwlAiOh2+kLD4oUpmCsoGODIaF9AZ52k0qztQP9oO0yEqNbXPiyZMCoN62vziBY7+ TH8Jrp1XA+kgQ8f2tx+cfHW1M5pwG26Xpgj84/1U0CyH8djOu5abPOkTwcWxHqu/Fh+Q RvV1UyOewWufEKLq25NVslF7N+VfCMQlm+khLK73ziTCuUQQ4GNmHrFcW0BBc1sI1Opx GK/mWMQRlPdesmdFsbjfjmtiLLZReL5jC4209F+xzSFojpwpOuJQC8a66v0+ELiMbDI+ sI80f+Xbamf0flCJO4AykLlG+6t16rH39+FXOyA+u1sd1Vy/xxAWSS8YWTZoFTcSmUoY h7Qg== X-Received: by 10.70.96.98 with SMTP id dr2mr18705624pdb.96.1426261842782; Fri, 13 Mar 2015 08:50:42 -0700 (PDT) Received: from [25.117.88.21] ([172.56.40.178]) by mx.google.com with ESMTPSA id uf4sm4178245pac.9.2015.03.13.08.50.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Mar 2015 08:50:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Oleg Moskalenko X-Mailer: iPhone Mail (12F39) In-Reply-To: <20150313093555.6b92a339@lminiero> Date: Fri, 13 Mar 2015 08:50:39 -0700 Content-Transfer-Encoding: 7bit Message-Id: <48647A00-F37F-4533-9AAB-0BD809EFBFD3@gmail.com> References: <20150313093555.6b92a339@lminiero> To: Lorenzo Miniero Archived-At: Cc: Marc Petit-Huguenin , Benjamin Schwartz , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" , Justin Uberti Subject: Re: [tram] STUN fragmentation [Was: I-D Action: draft-ietf-tram-stunbis-01.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, 13 Mar 2015 15:50:44 -0000 > On Mar 13, 2015, at 1:35 AM, Lorenzo Miniero wrote: > > On Thu, 12 Mar 2015 23:42:59 -0700 > Oleg Moskalenko wrote: > >> On Thu, Mar 12, 2015 at 2:22 PM, Justin Uberti >> wrote: >>>> >>>> >>>>> >>>>> Section 6.1: >>>>> >>>>> "If a STUN client needs to send requests that are larger than >>>>> the MTU, or if an application envisions that a response would be >>>>> larger then the MTU, then it MUST use SCTP-over-UDP or >>>>> SCTP-over-DTLS-over-UDP as transport, unless the purpose of >>>>> sending an oversized packet is to probe for MTU characteristics >>>>> (see [RFC5780])." >>>> >>>> So, SCTP is used here purely as a tool to solve the fragmentation >>>> problem ? Right ? >>> >>> >>> I understand the intent here, but this seems like a very heavyweight >>> solution to what seems like an edge case. Is anyone planning to >>> actually implement this, and if so, could you describe the >>> situation where this is actually encountered? >>> >> >> I agree that this solution sounds like an overkill. >> >> I am not sure about a potential implementation. Implementing >> SCTP-over-UDP may not be that easy. I am still researching but it >> seems like the standard Linux and FreeBSD network library suite does >> not have off-the-shelf "tunnelling" SCTP-inside-something solution (I >> may be wrong). The available headers and libraries are mostly for the >> "native" SCTP networking. Definitely, that complicates the >> implementation and adds extra dependencies on the third-party >> libraries (if there are any available). >> > > > Hi Oleg, > > there is indeed a third-party library available that can be used for > the purpose, the user-space usrsctp code that can be found here: > https://code.google.com/p/sctp-refimpl/ Lorenzo, thanks for the information, i'll check it. Oleg > > >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram > From nobody Fri Mar 13 09:09:54 2015 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 2BF2F1A8ADE for ; Fri, 13 Mar 2015 09:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 GtgpfI9H9oKQ for ; Fri, 13 Mar 2015 09:09:43 -0700 (PDT) Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com [209.85.218.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD5281A8AAF for ; Fri, 13 Mar 2015 09:09:42 -0700 (PDT) Received: by oiax69 with SMTP id x69so20504960oia.5 for ; Fri, 13 Mar 2015 09:09:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=V89HtLU19AvupkqqDlJVS5Gi5SK5tVj2qN6RpAQxIb8=; b=SrtzXrf+3CWg6zveAS64hgnZQl0jZgb4kOIl+PyXR7kKsRP3S7EV6x1e+Gbh0UFcw2 eeWgmg/s0AIwGYVJ75lVDmrWApfRFkjdnH6yA+Q3tOnHVQWX8bLEy0U9zU0bcqDb+6LK Aspw75JdSO/nZspC8iHBapkEMLtaHWuH/bVfyyDM8GzCcBKT7E2WjLgS4KjuUv9/wDeL r6BEV4Gjo1rSFaF3cDm3JU16W4cUyJ+jlyUMV3HZxvtdWV6uhRx7m2ZSMP9n0eZU5+PT HJS/k1H2r1M4BMm4Qrk8ol+QlLXSwDBJdGyab5JKI1I1Pc7+EIclPF1Qw5GunNkY7XL2 dnWQ== X-Gm-Message-State: ALoCoQks9UDdRFO+QkrnqAoLLnhm++LtCyzK4iN5IwiCZmywzv2p3+oesO6SvRX3FtXaHz938m20 X-Received: by 10.202.215.131 with SMTP id o125mr5432762oig.109.1426262982327; Fri, 13 Mar 2015 09:09:42 -0700 (PDT) Received: from Simons-MacBook-Air.local (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id m143sm1329538oig.3.2015.03.13.09.09.33 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Mar 2015 09:09:33 -0700 (PDT) Message-ID: <55030BBB.7090808@jive.com> Date: Fri, 13 Mar 2015 12:09:31 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Justin Uberti , Oleg Moskalenko References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: Marc Petit-Huguenin , Benjamin Schwartz , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] STUN fragmentation [Was: I-D Action: draft-ietf-tram-stunbis-01.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, 13 Mar 2015 16:09:53 -0000 Le 2015-03-12 17:22, Justin Uberti a écrit : > I understand the intent here, but this seems like a very heavyweight > solution to what seems like an edge case. Is anyone planning to actually > implement this, and if so, could you describe the situation where this > is actually encountered? I think the rationale is "If you care so much about MTU, then use SCTP. If not, then just limit the size of your packets like everybody else does." Personally I just limit the size of my packet and I sleep very well at night... Simon From nobody Fri Mar 13 09:39:09 2015 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 C367B1A0113 for ; Fri, 13 Mar 2015 09:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 cMZNRmeg7RIZ for ; Fri, 13 Mar 2015 09:38:57 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 639D31A8759 for ; Fri, 13 Mar 2015 09:38:55 -0700 (PDT) Received: by iecvj10 with SMTP id vj10so110616018iec.0 for ; Fri, 13 Mar 2015 09:38:54 -0700 (PDT) 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=urMreMGfWKZZh1JKI02n30IGCiYHexuCDFtRcsB1phc=; b=U54nppGvKHvDOquXB3OoLPsjksMBscO8iP/weIt0CoWGgIVSHct5AcDYKL7/pRptgt 3V2LHbIU0DVSN+eaPywKPIkUmYcCqGXKn3K7Y9hrcU+iOm3vFVa8ZdasonUZ7t30IhGR 4AxXQl/8qOwjRWYplx71ICZy1OcUb7eaPvPjIs8JxdcErzQPTVyyIfnfsLd79j3dzqhR rzJ1fDyt2XbqoCEE+1FNaK21mAVaAA+0m8wwsnsZgRFftf8zf61GFxnBmBVe/jvtUNJZ WZdmBj0cFptO8L6Tnz3KXpeP/to+2w637iOx5wPbE6hRTJtFdug2KPH3r8eD5caEiJQN UO1Q== 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=urMreMGfWKZZh1JKI02n30IGCiYHexuCDFtRcsB1phc=; b=H1AzuCNqhpkl6mJe5ELRq0e0LvNLOhKY88HFYpp+H10mNrEu31TL648pzr7O6HCDlk 9fJVz+uhvAS1jz/R0Rpry1JpyduLeAYI2Wc5LTe4xZ4vzs4+zXC5jTLAN/4fFJP+Qdjl ix8BtjbjngVPmDVzpemRzjFHJ4+eG26tsGlvXNEpb5Dhi9193lxzBDENeLdJU7ofQHFN WH0DERfzbVTejef/yPL8NSDT8GIx0j1sO0mwwgkiYUpSJ3saxi7zSl4WxdYXskOY+qEG BYtkF5ep1Ly66xp/Hq8W6kDg+V6z8CWOTzMK+D9e0aPnGr3EuE1x7SMV+SzKPxAeGEfs IXwg== X-Gm-Message-State: ALoCoQkTGSR6EJUtbk4hzNCV53TmaMV/RThdpgxP7sZ+548SKqEQ0DM+uzZGOQizHEU7Cwu23aP1 X-Received: by 10.50.20.228 with SMTP id q4mr65127586ige.1.1426264718647; Fri, 13 Mar 2015 09:38:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.64.42 with HTTP; Fri, 13 Mar 2015 09:38:18 -0700 (PDT) In-Reply-To: <55030BBB.7090808@jive.com> References: <55030BBB.7090808@jive.com> From: Justin Uberti Date: Fri, 13 Mar 2015 09:38:18 -0700 Message-ID: To: Simon Perreault Content-Type: multipart/alternative; boundary=047d7bd757c4e95b1105112e21bf Archived-At: Cc: Marc Petit-Huguenin , Oleg Moskalenko , Benjamin Schwartz , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] STUN fragmentation [Was: I-D Action: draft-ietf-tram-stunbis-01.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, 13 Mar 2015 16:39:07 -0000 --047d7bd757c4e95b1105112e21bf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Right, that was my reading as well. So my question is, who is being kept awake by this? On Fri, Mar 13, 2015 at 9:09 AM, Simon Perreault wrote: > Le 2015-03-12 17:22, Justin Uberti a =C3=A9crit : > > I understand the intent here, but this seems like a very heavyweight > > solution to what seems like an edge case. Is anyone planning to actuall= y > > implement this, and if so, could you describe the situation where this > > is actually encountered? > > I think the rationale is "If you care so much about MTU, then use SCTP. > If not, then just limit the size of your packets like everybody else does= ." > > Personally I just limit the size of my packet and I sleep very well at > night... > > Simon > --047d7bd757c4e95b1105112e21bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Right, that was my reading as well. So my question is, who= is being kept awake by this?

On Fri, Mar 13, 2015 at 9:09 AM, Simon Perreault <sper= reault@jive.com> wrote:
Le = 2015-03-12 17:22, Justin Uberti a =C3=A9crit :
> I understand the intent here, but this seems like a v= ery heavyweight
> solution to what seems like an edge case. Is anyone planning to actual= ly
> implement this, and if so, could you describe the situation where this=
> is actually encountered?

I think the rationale is "If you care so much about MTU, then u= se SCTP.
If not, then just limit the size of your packets like everybody else does.&= quot;

Personally I just limit the size of my packet and I sleep very well at
night...

Simon

--047d7bd757c4e95b1105112e21bf-- From nobody Fri Mar 13 09:44:22 2015 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 644531A87BD for ; Fri, 13 Mar 2015 09:44:21 -0700 (PDT) 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 6q5RGoDVpeud for ; Fri, 13 Mar 2015 09:44:20 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 01A0C1A006B for ; Fri, 13 Mar 2015 09:44:20 -0700 (PDT) Received: from [IPv6:2602:43:2da:6400:b963:4a21:4cbd:9b7b] (unknown [IPv6:2602:43:2da:6400:b963:4a21:4cbd:9b7b]) (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 D3CCB201B4; Fri, 13 Mar 2015 17:44:17 +0100 (CET) Message-ID: <550313E0.8020100@acm.org> Date: Fri, 13 Mar 2015 10:44:16 -0600 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 To: Justin Uberti , Simon Perreault References: <55030BBB.7090808@jive.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Oleg Moskalenko , Benjamin Schwartz , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] STUN fragmentation [Was: I-D Action: draft-ietf-tram-stunbis-01.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, 13 Mar 2015 16:44:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/13/2015 10:38 AM, Justin Uberti wrote: > Right, that was my reading as well. So my question is, who is being kept > awake by this? draft-ietf-tram-stun-origin > > On Fri, Mar 13, 2015 at 9:09 AM, Simon Perreault > wrote: > >> Le 2015-03-12 17:22, Justin Uberti a écrit : >>> I understand the intent here, but this seems like a very heavyweight >>> solution to what seems like an edge case. Is anyone planning to actually >>> implement this, and if so, could you describe the situation where this >>> is actually encountered? >> >> I think the rationale is "If you care so much about MTU, then use SCTP. >> If not, then just limit the size of your packets like everybody else does." >> >> Personally I just limit the size of my packet and I sleep very well at >> night... >> >> Simon >> > - -- 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 iQIcBAEBCAAGBQJVAxPfAAoJECnERZXWan7En2UP/ioFCFJaUtqBTx9hcudbJE24 kyqmNEvo6jemxCfaMTlP3gYDaFEC2Yd3Bdp2SGR+e4mvvfVGIxG4gMYWJrRN86Ni fy8m1b/xlxjrJhF3bG3E6m10CYZtWIi3sfaqP3EI3NFEvm3Z/+/4Oc91h4dBURpG xfKwgugvTDq6hP1+9WoQs7jMjQCMoh70Umk07R2tg5V+Ut7IQcpKf04IScy67PUp WcEnseOiyeqjawJ3THmx8eU7GlyKZ5gJ7J5h6I0xxRHqDmRQ/lpZFi6T1M8yib7u jd15nknaZMrSWVsWyrYwjKUo1FLMwJogWOZ+XRwtFF8/QvhcWYce2PyYEtG90a0v 0fAK0OnhLb0DdcdoAOljwmX5kk0QI2Ti5FlzLrpn3wzKkjYp9AsY5PqSM+bpGLo+ qr1IAcQ5bkZ1LLx66EyyaRFWWo5jUO6ZLkmGREK6qopN7oAggmZN7YLwna91I9iF VONblwac5Xa3XdKwJ9Fxb8jv0z1rqvQhN94UJ0Lov94JZjccbofFhl+G4fhfjH5f J9xFQHUJcGgl0vY4CIUEkfe8pU82B5EedTvyoeEkKPckRh7ZF9wz2AMcF61gYtOx iHan3o7nqdxgh6CO7nMVG8o1R1UwcInBxC0p2izd3ZpPAA3gTGkNTCNtIpKuYpcb ADOtDb6h5RLH5oO14TPS =00L/ -----END PGP SIGNATURE----- From nobody Fri Mar 13 09:55:16 2015 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 2423E1A8715 for ; Fri, 13 Mar 2015 09:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YNTV5DN1DMe5 for ; Fri, 13 Mar 2015 09:55:13 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A191E1A8892 for ; Fri, 13 Mar 2015 09:55:13 -0700 (PDT) Received: by ieclw3 with SMTP id lw3so115275745iec.2 for ; Fri, 13 Mar 2015 09:55:13 -0700 (PDT) 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=H2eVkg18CpbuAaKN0frFkTzSmxzNw+XuxoBsDJhlrE0=; b=UkowOxMZCTWRu+h06gQSBF0UyifWS5AOmEwzcK37cItKTxEVv3ollqULxu9zwqKQwa SOFRjmCKpGx8LGqmeSge146B7G3KoVqkYr/5+T00PAaLNJ9iu8gYLWvn28mJpXpqGBM4 7y/fQ14Oyu7Tt/HfOrKejS20kYDrczXugOz4N0dEAuMisSVD1UtfSg0SOTMupAIJGDMX taI0jpbiB3zmwtQfUDI3v6hx2daFxWB6QSunuRKroDZc9fl42bR7Pk9HZQwVIsX2oCmd RK8+EMrFzMd5rnAkLzWVs5sxHHTxnvapOku8lHP48ec8S6LWbdQOFcbMTmf4bewBbNyz TeBw== 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=H2eVkg18CpbuAaKN0frFkTzSmxzNw+XuxoBsDJhlrE0=; b=eagFusIQP4HzjwW7DI6VV5waKIoyHauq1WYqQ0rf24WlQ8NSSOYXJ4pXMfZSYqCJQu IOiJV61HY17UUtTPmQC0Om9r3mcCIiqGCf+9HR2jhZ85ptCXto86iermoPprHm8DKYOH CQUC3l9Vm6Uz7dQe5pg07i4tgbiCIBg4ccujM5A7g1HPOALtl0O+wGLq79FwsIIPH7IB y7omtSN09ipagoyH7amSFWs6pHIIbEBfCU/LmtJBT1OJlTihm8QWFkBbEXycgmCRcgdT eWFt/BgolC9Hk/JhFZLOuSJECQFfshiOMcjZRMbqV8F/ikWiyNlMpR29NxRvw3nRTSS1 x+QA== X-Gm-Message-State: ALoCoQnDBI5UlTpaIblcZ5jJ2Eq7hIQctEjF8wEPVYgLsB7KTqMkjPJh2DnwaU26PUfyAdKHCp1K X-Received: by 10.42.167.8 with SMTP id q8mr58812529icy.94.1426265698987; Fri, 13 Mar 2015 09:54:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.64.42 with HTTP; Fri, 13 Mar 2015 09:54:38 -0700 (PDT) In-Reply-To: <550313E0.8020100@acm.org> References: <55030BBB.7090808@jive.com> <550313E0.8020100@acm.org> From: Justin Uberti Date: Fri, 13 Mar 2015 09:54:38 -0700 Message-ID: To: Marc Petit-Huguenin Content-Type: multipart/alternative; boundary=90e6ba6e83c458162b05112e5c2c Archived-At: Cc: Simon Perreault , Oleg Moskalenko , Benjamin Schwartz , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] STUN fragmentation [Was: I-D Action: draft-ietf-tram-stunbis-01.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, 13 Mar 2015 16:55:15 -0000 --90e6ba6e83c458162b05112e5c2c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As an author on that document, I don't think there is any real-world situation where it causes MTU problems. On Fri, Mar 13, 2015 at 9:44 AM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 03/13/2015 10:38 AM, Justin Uberti wrote: > > Right, that was my reading as well. So my question is, who is being kep= t > > awake by this? > > draft-ietf-tram-stun-origin > > > > > On Fri, Mar 13, 2015 at 9:09 AM, Simon Perreault > > wrote: > > > >> Le 2015-03-12 17:22, Justin Uberti a =C3=A9crit : > >>> I understand the intent here, but this seems like a very heavyweight > >>> solution to what seems like an edge case. Is anyone planning to > actually > >>> implement this, and if so, could you describe the situation where thi= s > >>> is actually encountered? > >> > >> I think the rationale is "If you care so much about MTU, then use SCTP= . > >> If not, then just limit the size of your packets like everybody else > does." > >> > >> Personally I just limit the size of my packet and I sleep very well at > >> night... > >> > >> Simon > >> > > > > > - -- > 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 > > iQIcBAEBCAAGBQJVAxPfAAoJECnERZXWan7En2UP/ioFCFJaUtqBTx9hcudbJE24 > kyqmNEvo6jemxCfaMTlP3gYDaFEC2Yd3Bdp2SGR+e4mvvfVGIxG4gMYWJrRN86Ni > fy8m1b/xlxjrJhF3bG3E6m10CYZtWIi3sfaqP3EI3NFEvm3Z/+/4Oc91h4dBURpG > xfKwgugvTDq6hP1+9WoQs7jMjQCMoh70Umk07R2tg5V+Ut7IQcpKf04IScy67PUp > WcEnseOiyeqjawJ3THmx8eU7GlyKZ5gJ7J5h6I0xxRHqDmRQ/lpZFi6T1M8yib7u > jd15nknaZMrSWVsWyrYwjKUo1FLMwJogWOZ+XRwtFF8/QvhcWYce2PyYEtG90a0v > 0fAK0OnhLb0DdcdoAOljwmX5kk0QI2Ti5FlzLrpn3wzKkjYp9AsY5PqSM+bpGLo+ > qr1IAcQ5bkZ1LLx66EyyaRFWWo5jUO6ZLkmGREK6qopN7oAggmZN7YLwna91I9iF > VONblwac5Xa3XdKwJ9Fxb8jv0z1rqvQhN94UJ0Lov94JZjccbofFhl+G4fhfjH5f > J9xFQHUJcGgl0vY4CIUEkfe8pU82B5EedTvyoeEkKPckRh7ZF9wz2AMcF61gYtOx > iHan3o7nqdxgh6CO7nMVG8o1R1UwcInBxC0p2izd3ZpPAA3gTGkNTCNtIpKuYpcb > ADOtDb6h5RLH5oO14TPS > =3D00L/ > -----END PGP SIGNATURE----- > --90e6ba6e83c458162b05112e5c2c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As an author on that document, I don't think there is = any real-world situation where it causes MTU problems.

On Fri, Mar 13, 2015 at 9:44 AM, M= arc Petit-Huguenin <petithug@acm.org> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 03/13/2015 10:38 AM, Justin Uberti wrote:
> Right, that was my reading as well. So my question is, who is being ke= pt
> awake by this?

draft-ietf-tram-stun-origin

>
> On Fri, Mar 13, 2015 at 9:09 AM, Simon Perreault <sperreault@jive.com>
> wrote:
>
>> Le 2015-03-12 17:22, Justin Uberti a =C3=A9crit :
>>> I understand the intent here, but this seems like a very heavy= weight
>>> solution to what seems like an edge case. Is anyone planning t= o actually
>>> implement this, and if so, could you describe the situation wh= ere this
>>> is actually encountered?
>>
>> I think the rationale is "If you care so much about MTU, then= use SCTP.
>> If not, then just limit the size of your packets like everybody el= se does."
>>
>> Personally I just limit the size of my packet and I sleep very wel= l at
>> night...
>>
>> Simon
>>
>


- --
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: htt= p://blog.marc.petit-huguenin.org
Profile: = http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJVAxPfAAoJECnERZXWan7En2UP/ioFCFJaUtqBTx9hcudbJE24
kyqmNEvo6jemxCfaMTlP3gYDaFEC2Yd3Bdp2SGR+e4mvvfVGIxG4gMYWJrRN86Ni
fy8m1b/xlxjrJhF3bG3E6m10CYZtWIi3sfaqP3EI3NFEvm3Z/+/4Oc91h4dBURpG
xfKwgugvTDq6hP1+9WoQs7jMjQCMoh70Umk07R2tg5V+Ut7IQcpKf04IScy67PUp
WcEnseOiyeqjawJ3THmx8eU7GlyKZ5gJ7J5h6I0xxRHqDmRQ/lpZFi6T1M8yib7u
jd15nknaZMrSWVsWyrYwjKUo1FLMwJogWOZ+XRwtFF8/QvhcWYce2PyYEtG90a0v
0fAK0OnhLb0DdcdoAOljwmX5kk0QI2Ti5FlzLrpn3wzKkjYp9AsY5PqSM+bpGLo+
qr1IAcQ5bkZ1LLx66EyyaRFWWo5jUO6ZLkmGREK6qopN7oAggmZN7YLwna91I9iF
VONblwac5Xa3XdKwJ9Fxb8jv0z1rqvQhN94UJ0Lov94JZjccbofFhl+G4fhfjH5f
J9xFQHUJcGgl0vY4CIUEkfe8pU82B5EedTvyoeEkKPckRh7ZF9wz2AMcF61gYtOx
iHan3o7nqdxgh6CO7nMVG8o1R1UwcInBxC0p2izd3ZpPAA3gTGkNTCNtIpKuYpcb
ADOtDb6h5RLH5oO14TPS
=3D00L/
-----END PGP SIGNATURE-----

--90e6ba6e83c458162b05112e5c2c-- From nobody Fri Mar 13 09:58:50 2015 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 DE9FA1A8779 for ; Fri, 13 Mar 2015 09:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, 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 EX_1EwkQygWg for ; Fri, 13 Mar 2015 09:58:47 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9D2C1A8775 for ; Fri, 13 Mar 2015 09:58:46 -0700 (PDT) Received: by wesw55 with SMTP id w55so24641937wes.3 for ; Fri, 13 Mar 2015 09:58:45 -0700 (PDT) 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=K3bkLc/7r3VFjn6tltVekohCYQ/0rwUDAzMApDQAii8=; b=FLmTbZ8ic4FSO5NZ6QmfjGfIjnQ711ssWZXEvAhJWnTP1z3k6qHrPUOYIANb11Am9F X5/EsS4FE6yE+KefHY8g/O8R+WjHQp+xBVrsxTVQE9mrHvRIZ0o9E8oGPnjor8/VGmOk V8GJaSmvejXAw0h6CgpMORHfxYSuyfuFDMtukJqebXoSowXupM2fUeexNAV/qb5AaDdN Zn+kMz7miNi/rQ+wQJv/dIcXI1zbmDubE43BnjQ1rqPmiNtIl5n35pc+26RacjQSZiEg 7K+XK06UGnw1e9iV1d9CbSma/wrhzxa85vmNh+AY8NIwqOqsdMbV+e1rjetUc9TlN/xu 1KAA== MIME-Version: 1.0 X-Received: by 10.180.198.110 with SMTP id jb14mr98780304wic.57.1426265924751; Fri, 13 Mar 2015 09:58:44 -0700 (PDT) Received: by 10.194.190.18 with HTTP; Fri, 13 Mar 2015 09:58:44 -0700 (PDT) In-Reply-To: <550313E0.8020100@acm.org> References: <55030BBB.7090808@jive.com> <550313E0.8020100@acm.org> Date: Fri, 13 Mar 2015 09:58:44 -0700 Message-ID: From: Oleg Moskalenko To: Marc Petit-Huguenin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Simon Perreault , Benjamin Schwartz , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" , Justin Uberti Subject: Re: [tram] STUN fragmentation [Was: I-D Action: draft-ietf-tram-stunbis-01.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, 13 Mar 2015 16:58:49 -0000 On Fri, Mar 13, 2015 at 9:44 AM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 03/13/2015 10:38 AM, Justin Uberti wrote: >> Right, that was my reading as well. So my question is, who is being kept >> awake by this? > > draft-ietf-tram-stun-origin > that's just a few extra bytes in the ALLOCATE request From nobody Fri Mar 13 10:17:41 2015 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 14DB41A8A78 for ; Fri, 13 Mar 2015 10:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 yLCai0es8GJO for ; Fri, 13 Mar 2015 10:17:38 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id F42001A1A7E for ; Fri, 13 Mar 2015 10:17:37 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E4DD528578; Fri, 13 Mar 2015 17:17:36 +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 CFB6C2856D; Fri, 13 Mar 2015 17:17:36 +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 C591A2026; Fri, 13 Mar 2015 17:17:36 +0000 (GMT) Message-ID: <55031BB0.4070204@akamai.com> Date: Fri, 13 Mar 2015 13:17:36 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Simon Perreault , Justin Uberti , Oleg Moskalenko References: <55030BBB.7090808@jive.com> In-Reply-To: <55030BBB.7090808@jive.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Marc Petit-Huguenin , Benjamin Schwartz , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] STUN fragmentation [Was: I-D Action: draft-ietf-tram-stunbis-01.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, 13 Mar 2015 17:17:40 -0000 If the MTU problem is for data packets, then I agree that the approach you describe is reasonable. It's easy enough (by some definition of easy) to limit packet sizes for the data, and an application that can't do that needs some solution to the problem. It's not so easy to limit packet sizes for allocation requests when you think about all the new attributes that might get added to allocation requests. The problem I have with the SCTP approach is that it requires using SCTP for the whole session just to resolve some packet size issues for a very small number of control messages. It would be good to also define a solution that applies just to the control messages without requiring the data transport to be impacted. --Brandon On 03/13/2015 12:09 PM, Simon Perreault wrote: > Le 2015-03-12 17:22, Justin Uberti a écrit : >> I understand the intent here, but this seems like a very heavyweight >> solution to what seems like an edge case. Is anyone planning to actually >> implement this, and if so, could you describe the situation where this >> is actually encountered? > > I think the rationale is "If you care so much about MTU, then use SCTP. > If not, then just limit the size of your packets like everybody else does." > > Personally I just limit the size of my packet and I sleep very well at > night... > > Simon > > _______________________________________________ > tram mailing list > tram@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=AwIF-g&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=BS30IB4olekwhkm34WEi9ZeMFTC1tRBGAjKL0UDHYe4&s=0n9u1qdhlITCC2XUHi-tl5xKy74rseDmIodfCtXJ5bU&e= > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Fri Mar 13 10:25:35 2015 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 E4BE71A908E for ; Fri, 13 Mar 2015 10:25:34 -0700 (PDT) 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 B31qL_WY16fa for ; Fri, 13 Mar 2015 10:25:33 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 14E831A908B for ; Fri, 13 Mar 2015 10:25:33 -0700 (PDT) Received: from [IPv6:2602:43:2da:6400:b963:4a21:4cbd:9b7b] (unknown [IPv6:2602:43:2da:6400:b963:4a21:4cbd:9b7b]) (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 A85B9201B4; Fri, 13 Mar 2015 18:25:31 +0100 (CET) Message-ID: <55031D89.7020404@acm.org> Date: Fri, 13 Mar 2015 11:25:29 -0600 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 To: Brandon Williams , Simon Perreault , Justin Uberti , Oleg Moskalenko References: <55030BBB.7090808@jive.com> <55031BB0.4070204@akamai.com> In-Reply-To: <55031BB0.4070204@akamai.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Benjamin Schwartz , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] STUN fragmentation [Was: I-D Action: draft-ietf-tram-stunbis-01.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, 13 Mar 2015 17:25:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/13/2015 11:17 AM, Brandon Williams wrote: > If the MTU problem is for data packets, then I agree that the approach you describe is reasonable. It's easy enough (by some definition of easy) to limit packet sizes for the data, and an application that can't do that needs some solution to the problem. > > It's not so easy to limit packet sizes for allocation requests when you think about all the new attributes that might get added to allocation requests. The problem I have with the SCTP approach is that it requires using SCTP for the whole session just to resolve some packet size issues for a very small number of control messages. It would be good to also define a solution that applies just to the control messages without requiring the data transport to be impacted. That's a TURN problem, but I do not see any issue on having it saying that the packets sent over the TURN channels (which are not STUN based) are sent over [DTLS over] UDP. > > --Brandon > > On 03/13/2015 12:09 PM, Simon Perreault wrote: >> Le 2015-03-12 17:22, Justin Uberti a écrit : >>> I understand the intent here, but this seems like a very heavyweight >>> solution to what seems like an edge case. Is anyone planning to actually >>> implement this, and if so, could you describe the situation where this >>> is actually encountered? >> >> I think the rationale is "If you care so much about MTU, then use SCTP. >> If not, then just limit the size of your packets like everybody else does." >> >> Personally I just limit the size of my packet and I sleep very well at >> night... >> >> Simon >> - -- 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 iQIcBAEBCAAGBQJVAx2JAAoJECnERZXWan7EqvEP/RHtwJivSd4iMHIKfpMrFR9D 04Eo0H+fRSqBWjVXz+JUnT9H4IktGh1GHTTACzZUe70oEA8E3rFxRRhFgOyNtZgU F4rfVXvuP7gd/B6r9AVJ89sB7ackFbqMXMcBzcXk/gqXG+kizzR0GBfdQJC7wCoN D9ST01tB8a/O3l2rOCxFrZA9ish9lXaIZ/jdCyw6C+BIhL/E5+cSAgX/dxsDTSco WlbteB2Upkp/w/KWauzyzXGkbWVZSBmUew1IQrk6FPNVR+kfRyr0o9fg7QQbcnYd rLSNW/ZJ9Jec5JNzPNSXrpA0jwzwTSdflbCUo4GWpiZKzagEZodisLNTn+8F4cBE 36uflxO0mMDnO4wxnQk/34rFfaRzOSKtEzsJPEw/KKGwWfjWLfI1Vz7lgkS5H/up 3lT36LABSnOWoOpkBDPhX3wheQu11FDwnv+dXqf2doDNsRwBJOC03y3/VxXdJlsZ hhuke+DxnFbv1LoHl5A3vZNqPS7RDbxMUz3O1511kKrnjxuNA+rJED+FpAfuNtHF Ger5Yb3TQ5OCby/gFMnONjWu2Pg6siipPyM0PM7Sz1Rn9hiWUGHw6xDV4bDwTAOs liTd04aMlII2NGRch80Sn1LKEWoLW84qNW+j6lEFXSIXvywmtX+6PJzPbabn7Sgw fIHtT9rIzITbLqka5yuU =3JHG -----END PGP SIGNATURE----- From nobody Fri Mar 13 10:38:11 2015 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 013851A1B2C for ; Fri, 13 Mar 2015 10:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 wL729MPMHehU for ; Fri, 13 Mar 2015 10:38:08 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3C11A1A6A for ; Fri, 13 Mar 2015 10:38:05 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E7E6C2856F; Fri, 13 Mar 2015 17:38:04 +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 D53A12856D; Fri, 13 Mar 2015 17:38:04 +0000 (GMT) Received: from [172.28.115.172] (unknown [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id CE9798004E; Fri, 13 Mar 2015 17:38:04 +0000 (GMT) Message-ID: <5503207C.9000007@akamai.com> Date: Fri, 13 Mar 2015 13:38:04 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Oleg Moskalenko , Marc Petit-Huguenin References: <55030BBB.7090808@jive.com> <550313E0.8020100@acm.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Simon Perreault , Benjamin Schwartz , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" , Justin Uberti Subject: Re: [tram] STUN fragmentation [Was: I-D Action: draft-ietf-tram-stunbis-01.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, 13 Mar 2015 17:38:11 -0000 According to the current stunbis draft, it is still a requirement to keep your request down below 548 bytes for IPv4 if you don't know the real MTU and your request is not directly associated with MTU discovery. The value for the ORIGIN attribute could consume nearly half of that and the 3rd party auth token could consume nearly half of the remainder. If we don't think that 548 bytes is a reasonable requirement for the unknown MTU case, then the requirement should be removed from the spec. Regarding Justin's question about who is being kept awake by this ... I know that small MTUs occur in some parts of the Internet, even as low as the IPv4 minimum. I don't think this it's common, but I unfortunately don't have numbers to quantify the scope of the problem so my assessment is based on a faint memory from a few years ago where I had to allow packet fragmentation in these cases in order to avoid dropping the packets entirely. I would rather send fragments than drop the whole packet, at least for the applications that I support today, and again, I believe the issue to be rare. As per my previous e-mail, I'm more concerned about control messages than I am about data messages, since I think there's less flexibility around the message size. If the control message gets fragmented, on some paths it just won't get through. I would be happy enough with an solution for control messages, but even that I don't consider to be critical at the moment. --Brandon On 03/13/2015 12:58 PM, Oleg Moskalenko wrote: > On Fri, Mar 13, 2015 at 9:44 AM, Marc Petit-Huguenin wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> On 03/13/2015 10:38 AM, Justin Uberti wrote: >>> Right, that was my reading as well. So my question is, who is being kept >>> awake by this? >> >> draft-ietf-tram-stun-origin >> > > that's just a few extra bytes in the ALLOCATE request > > _______________________________________________ > 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 Fri Mar 13 10:44:09 2015 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 22A141A0024 for ; Fri, 13 Mar 2015 10:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 6CFAiuIuuXfw for ; Fri, 13 Mar 2015 10:44:04 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id CF1301A8857 for ; Fri, 13 Mar 2015 10:43:53 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 39503476FC; Fri, 13 Mar 2015 17:43:53 +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 1AA6C476F3; Fri, 13 Mar 2015 17:43:53 +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 12F82202C; Fri, 13 Mar 2015 17:43:53 +0000 (GMT) Message-ID: <550321D9.2040209@akamai.com> Date: Fri, 13 Mar 2015 13:43:53 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Marc Petit-Huguenin , Simon Perreault , Justin Uberti , Oleg Moskalenko References: <55030BBB.7090808@jive.com> <55031BB0.4070204@akamai.com> <55031D89.7020404@acm.org> In-Reply-To: <55031D89.7020404@acm.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Benjamin Schwartz , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] STUN fragmentation [Was: I-D Action: draft-ietf-tram-stunbis-01.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, 13 Mar 2015 17:44:07 -0000 Sure, turnbis could describe a split transport where control messages are sent using SCTP and data messages are sent without if the application can ensure the data messages don't exceed the MTU. I still think SCTP is a heavy weight solution to solve a STUN issue that only impacts a very small number of messages (perhaps just one or two in the whole session). Maybe I'm just over-estimating the level of complexity. --Brandon On 03/13/2015 01:25 PM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 03/13/2015 11:17 AM, Brandon Williams wrote: >> If the MTU problem is for data packets, then I agree that the approach you describe is reasonable. It's easy enough (by some definition of easy) to limit packet sizes for the data, and an application that can't do that needs some solution to the problem. >> >> It's not so easy to limit packet sizes for allocation requests when you think about all the new attributes that might get added to allocation requests. The problem I have with the SCTP approach is that it requires using SCTP for the whole session just to resolve some packet size issues for a very small number of control messages. It would be good to also define a solution that applies just to the control messages without requiring the data transport to be impacted. > > That's a TURN problem, but I do not see any issue on having it saying that the packets sent over the TURN channels (which are not STUN based) are sent over [DTLS over] UDP. > >> >> --Brandon >> >> On 03/13/2015 12:09 PM, Simon Perreault wrote: >>> Le 2015-03-12 17:22, Justin Uberti a écrit : >>>> I understand the intent here, but this seems like a very heavyweight >>>> solution to what seems like an edge case. Is anyone planning to actually >>>> implement this, and if so, could you describe the situation where this >>>> is actually encountered? >>> >>> I think the rationale is "If you care so much about MTU, then use SCTP. >>> If not, then just limit the size of your packets like everybody else does." >>> >>> Personally I just limit the size of my packet and I sleep very well at >>> night... >>> >>> Simon >>> > > - -- > 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 > > iQIcBAEBCAAGBQJVAx2JAAoJECnERZXWan7EqvEP/RHtwJivSd4iMHIKfpMrFR9D > 04Eo0H+fRSqBWjVXz+JUnT9H4IktGh1GHTTACzZUe70oEA8E3rFxRRhFgOyNtZgU > F4rfVXvuP7gd/B6r9AVJ89sB7ackFbqMXMcBzcXk/gqXG+kizzR0GBfdQJC7wCoN > D9ST01tB8a/O3l2rOCxFrZA9ish9lXaIZ/jdCyw6C+BIhL/E5+cSAgX/dxsDTSco > WlbteB2Upkp/w/KWauzyzXGkbWVZSBmUew1IQrk6FPNVR+kfRyr0o9fg7QQbcnYd > rLSNW/ZJ9Jec5JNzPNSXrpA0jwzwTSdflbCUo4GWpiZKzagEZodisLNTn+8F4cBE > 36uflxO0mMDnO4wxnQk/34rFfaRzOSKtEzsJPEw/KKGwWfjWLfI1Vz7lgkS5H/up > 3lT36LABSnOWoOpkBDPhX3wheQu11FDwnv+dXqf2doDNsRwBJOC03y3/VxXdJlsZ > hhuke+DxnFbv1LoHl5A3vZNqPS7RDbxMUz3O1511kKrnjxuNA+rJED+FpAfuNtHF > Ger5Yb3TQ5OCby/gFMnONjWu2Pg6siipPyM0PM7Sz1Rn9hiWUGHw6xDV4bDwTAOs > liTd04aMlII2NGRch80Sn1LKEWoLW84qNW+j6lEFXSIXvywmtX+6PJzPbabn7Sgw > fIHtT9rIzITbLqka5yuU > =3JHG > -----END PGP SIGNATURE----- > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Fri Mar 13 11:56:01 2015 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 4EB391A8ACC for ; Fri, 13 Mar 2015 11:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 yADrRyO9i2PV for ; Fri, 13 Mar 2015 11:55:58 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62B111A8AB6 for ; Fri, 13 Mar 2015 11:55:58 -0700 (PDT) Received: by iecsl2 with SMTP id sl2so119954341iec.1 for ; Fri, 13 Mar 2015 11:55:57 -0700 (PDT) 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=OmQ2WK3cB6Zy0wh0I+H86XbswHPRgieF2Q493eCtVS4=; b=KrwZs9iVgY3++ukMZB46ZlZXp/nzfJVvmHlSS+4DXLwLxSxWuqtyfi1Rmwir6U99HN qzUai28BO3uGaJpOyMkQJRM21WP9LC+X1oeiHxl5DAwU4rsEHll4aIPHOkeXGaVjDKeC pC4hGJT31RefGbez9egoQwUetq/EF7uhlMGeq9srRKPM4GyMZroau/+BgxEeM/ECOloN 4sQudhtjbBj4ScTozarFcXHnqvzo2C0r4PdCkd0noTYEXauVlbv16OxZF17/WyAIACCy 1iFjkwd9Yq4Gn6Vg97Xomp5ZLEUSxgEPfksrnmtHYJI9QkBYJxaKtmX424RXcFjVaK+p yQ2w== 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=OmQ2WK3cB6Zy0wh0I+H86XbswHPRgieF2Q493eCtVS4=; b=KiN0r3oEj/RHWE6dyr2Ig/KvCvwPtKRZrEMaHk0s2iRkxqoSu/xjjuLbR/V/6rAcEh UT07WuXYQbjdPZHsGIMAtkKLClBhEdHTun58ghKqOF6n2FjjZyNt+H0x4uTC+MQK+S+m pBKvXi+j0K2paPvG/QDXUMJgIBlHRL4Hi++WyXpeCM3kp/bS6tMlNJmeKsu9xlEQVRzr fMltKeEzkZnHxbrNvNnA4Okbt8NKjRC6MppUZ6E8tXyV+syOYqNdkByhbd19ilNygOJ3 1SbHKqbiEPgVSc9ySTdERZ1O8bYbC9QnpHR0cPzGbcQtHsnEWmIwVFabuoli7i6opZ6Z UoVQ== X-Gm-Message-State: ALoCoQl1ThP1jV855kD+Xfb1bCZRhHCe6cmAvrXNFvnL6xoPvcr75SjsvqHwpS0KhF8cYukkRXrw X-Received: by 10.50.118.97 with SMTP id kl1mr52385437igb.23.1426272458435; Fri, 13 Mar 2015 11:47:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.64.42 with HTTP; Fri, 13 Mar 2015 11:47:18 -0700 (PDT) In-Reply-To: <5503207C.9000007@akamai.com> References: <55030BBB.7090808@jive.com> <550313E0.8020100@acm.org> <5503207C.9000007@akamai.com> From: Justin Uberti Date: Fri, 13 Mar 2015 11:47:18 -0700 Message-ID: To: Brandon Williams Content-Type: multipart/alternative; boundary=089e013a11183d1ee305112fef9e Archived-At: Cc: Marc Petit-Huguenin , Oleg Moskalenko , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" , Simon Perreault , Benjamin Schwartz Subject: Re: [tram] STUN fragmentation [Was: I-D Action: draft-ietf-tram-stunbis-01.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, 13 Mar 2015 18:56:00 -0000 --089e013a11183d1ee305112fef9e Content-Type: text/plain; charset=UTF-8 On Fri, Mar 13, 2015 at 10:38 AM, Brandon Williams < brandon.williams@akamai.com> wrote: > According to the current stunbis draft, it is still a requirement to keep > your request down below 548 bytes for IPv4 if you don't know the real MTU > and your request is not directly associated with MTU discovery. The value > for the ORIGIN attribute could consume nearly half of that and the 3rd > party auth token could consume nearly half of the remainder. If we don't > think that 548 bytes is a reasonable requirement for the unknown MTU case, > then the requirement should be removed from the spec. > The ORIGIN will only be that large in extreme, likely pathological cases. Based on a median DNS name length of 12 bytes, the median median ORIGIN value is 24 bytes, including attribute header. ( http://datagenetics.com/blog/march22012/) > > Regarding Justin's question about who is being kept awake by this ... I > know that small MTUs occur in some parts of the Internet, even as low as > the IPv4 minimum. I don't think this it's common, but I unfortunately don't > have numbers to quantify the scope of the problem so my assessment is based > on a faint memory from a few years ago where I had to allow packet > fragmentation in these cases in order to avoid dropping the packets > entirely. I would rather send fragments than drop the whole packet, at > least for the applications that I support today, and again, I believe the > issue to be rare. > Recall that the IPv6 minimum is 1280 bytes, so hopefully by the time we have enough attributes for this to be a real-world problem this 548 byte limit will have been increased substantially. > > As per my previous e-mail, I'm more concerned about control messages than > I am about data messages, since I think there's less flexibility around the > message size. If the control message gets fragmented, on some paths it just > won't get through. I would be happy enough with an solution for control > messages, but even that I don't consider to be critical at the moment. > I agree, and I think that taking on a complex solution like SCTP to solve what appears to be a non-critical problem is not a wise path. > > --Brandon > > > On 03/13/2015 12:58 PM, Oleg Moskalenko wrote: > >> On Fri, Mar 13, 2015 at 9:44 AM, Marc Petit-Huguenin >> wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA256 >>> >>> On 03/13/2015 10:38 AM, Justin Uberti wrote: >>> >>>> Right, that was my reading as well. So my question is, who is being kept >>>> awake by this? >>>> >>> >>> draft-ietf-tram-stun-origin >>> >>> >> that's just a few extra bytes in the ALLOCATE request >> >> _______________________________________________ >> 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. > --089e013a11183d1ee305112fef9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 13, 2015 at 10:38 AM, Brandon Williams &l= t;brandon.= williams@akamai.com> wrote:
According to = the current stunbis draft, it is still a requirement to keep your request d= own below 548 bytes for IPv4 if you don't know the real MTU and your re= quest is not directly associated with MTU discovery. The value for the ORIG= IN attribute could consume nearly half of that and the 3rd party auth token= could consume nearly half of the remainder. If we don't think that 548= bytes is a reasonable requirement for the unknown MTU case, then the requi= rement should be removed from the spec.

The ORIGIN will only be that large in extreme, likely pathological cases. = Based on a median DNS name length of 12 bytes, the median median ORIGIN val= ue is 24 bytes, including attribute header. (http://datagenetics.com/blog/march22012/)=C2=A0<= /div>

Regarding Justin's question about who is being kept awake by this ... I= know that small MTUs occur in some parts of the Internet, even as low as t= he IPv4 minimum. I don't think this it's common, but I unfortunatel= y don't have numbers to quantify the scope of the problem so my assessm= ent is based on a faint memory from a few years ago where I had to allow pa= cket fragmentation in these cases in order to avoid dropping the packets en= tirely. I would rather send fragments than drop the whole packet, at least = for the applications that I support today, and again, I believe the issue t= o be rare.

Recall that the IPv6 minimum= is 1280 bytes, so hopefully by the time we have enough attributes for this= to be a real-world problem this 548 byte limit will have been increased su= bstantially.

As per my previous e-mail, I'm more concerned about control messages th= an I am about data messages, since I think there's less flexibility aro= und the message size. If the control message gets fragmented, on some paths= it just won't get through. I would be happy enough with an solution fo= r control messages, but even that I don't consider to be critical at th= e moment.

I agree, and I think that tak= ing on a complex solution like SCTP to solve what appears to be a non-criti= cal problem is not a wise path.=C2=A0

--Brandon


On 03/13/2015 12:58 PM, Oleg Moskalenko wrote:
On Fri, Mar 13, 2015 at 9:44 AM, Marc Petit-Huguenin <petithug@acm.org> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 03/13/2015 10:38 AM, Justin Uberti wrote:
Right, that was my reading as well. So my question is, who is being kept awake by this?

draft-ietf-tram-stun-origin


that's just a few extra bytes in the ALLOCATE request

_______________________________________________
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.

--089e013a11183d1ee305112fef9e-- From nobody Fri Mar 13 13:22:29 2015 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 C787C1A1B34 for ; Fri, 13 Mar 2015 13:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 7DCWZly5OcMS for ; Fri, 13 Mar 2015 13:22:25 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7A61A3B9B for ; Fri, 13 Mar 2015 13:22:09 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8B04F28580; Fri, 13 Mar 2015 20:22:08 +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 76E0E28579; Fri, 13 Mar 2015 20:22:08 +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 6EBD12026; Fri, 13 Mar 2015 20:22:08 +0000 (GMT) Message-ID: <550346F0.2070507@akamai.com> Date: Fri, 13 Mar 2015 16:22:08 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Justin Uberti References: <55030BBB.7090808@jive.com> <550313E0.8020100@acm.org> <5503207C.9000007@akamai.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Marc Petit-Huguenin , Oleg Moskalenko , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" , Simon Perreault , Benjamin Schwartz Subject: Re: [tram] STUN fragmentation [Was: I-D Action: draft-ietf-tram-stunbis-01.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, 13 Mar 2015 20:22:28 -0000 I think we're pretty much on the same page on this one. I'm just exploring whether the current requirement in the text is a reasonable approach to the pathological case. Is it better to do what the current text requires (drop the packet)? Or is it better to relax the wording in recognition of the fact that the problem case is pathological and that a fragmented packet is more likely to get through than a dropped packet? I would rather relax the requirement than do a bunch of work, though I'd be willing to do a little work if we come up with a low impact fix. --Brandon PS: Really? Hopefully we can rely on IPv6 deployment? :-) On 03/13/2015 02:47 PM, Justin Uberti wrote: > > > On Fri, Mar 13, 2015 at 10:38 AM, Brandon Williams > > wrote: > > According to the current stunbis draft, it is still a requirement to > keep your request down below 548 bytes for IPv4 if you don't know > the real MTU and your request is not directly associated with MTU > discovery. The value for the ORIGIN attribute could consume nearly > half of that and the 3rd party auth token could consume nearly half > of the remainder. If we don't think that 548 bytes is a reasonable > requirement for the unknown MTU case, then the requirement should be > removed from the spec. > > > The ORIGIN will only be that large in extreme, likely pathological > cases. Based on a median DNS name length of 12 bytes, the median median > ORIGIN value is 24 bytes, including attribute header. > (http://datagenetics.com/blog/march22012/) > > > Regarding Justin's question about who is being kept awake by this > ... I know that small MTUs occur in some parts of the Internet, even > as low as the IPv4 minimum. I don't think this it's common, but I > unfortunately don't have numbers to quantify the scope of the > problem so my assessment is based on a faint memory from a few years > ago where I had to allow packet fragmentation in these cases in > order to avoid dropping the packets entirely. I would rather send > fragments than drop the whole packet, at least for the applications > that I support today, and again, I believe the issue to be rare. > > > Recall that the IPv6 minimum is 1280 bytes, so hopefully by the time we > have enough attributes for this to be a real-world problem this 548 byte > limit will have been increased substantially. > > > As per my previous e-mail, I'm more concerned about control messages > than I am about data messages, since I think there's less > flexibility around the message size. If the control message gets > fragmented, on some paths it just won't get through. I would be > happy enough with an solution for control messages, but even that I > don't consider to be critical at the moment. > > > I agree, and I think that taking on a complex solution like SCTP to > solve what appears to be a non-critical problem is not a wise path. > > > --Brandon > > > On 03/13/2015 12:58 PM, Oleg Moskalenko wrote: > > On Fri, Mar 13, 2015 at 9:44 AM, Marc Petit-Huguenin > > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 03/13/2015 10:38 AM, Justin Uberti wrote: > > Right, that was my reading as well. So my question is, > who is being kept > awake by this? > > > draft-ietf-tram-stun-origin > > > that's just a few extra bytes in the ALLOCATE request > > _________________________________________________ > 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 Fri Mar 13 16:24:14 2015 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 B65E11A875A for ; Fri, 13 Mar 2015 16:24:12 -0700 (PDT) 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 m9DsXCrWCAps for ; Fri, 13 Mar 2015 16:24:11 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5BE31A876B for ; Fri, 13 Mar 2015 16:24:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1746; q=dns/txt; s=iport; t=1426289051; x=1427498651; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=QeRMROL2ZPBiDI7Lcb8iINXTW4cWHayemX+chh6dfpU=; b=JRUV7I69NPoR2ZdCt0e12IY1Or4JyLTul9ee+5A3oVZX1G53E2MB95AU 6WbVYBNPuQWwdWBu5eJe/q0b/KHmmgGkLkVW9yVsmDlZzEw+Hicpfxe9h RxHbapHuNEMKYzma0RBW6pdmkHwRO8FrWVLr/7eRSpsNsUOliCX4HBxHF w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DpCAAvcQNV/5RdJa1bgwZSWgS9eoNIgjuFcgKBKkwBAQEBAQF9hBABAQMBgQkCAQgOODIlAgQBEognCA3OSgEBAQEBAQEBAQEBAQEBAQEBARYEixeEeIQtBYpRhWSDaoV7lA8jg25vgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,397,1422921600"; d="scan'208";a="403887894" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-2.cisco.com with ESMTP; 13 Mar 2015 23:24:10 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t2DNOA3X015831 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Mar 2015 23:24:10 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.249]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Fri, 13 Mar 2015 18:24:09 -0500 From: "Prashanth Patil (praspati)" To: Simon Perreault , "tram@ietf.org" Thread-Topic: [tram] TURN Server Discovery - WG feedback Thread-Index: AQHQWmbBerl+Kpxhek+6UZ7ekaEKBJ0bBAmA Date: Fri, 13 Mar 2015 23:24:08 +0000 Message-ID: References: <54FD95A2.2040407@jive.com> In-Reply-To: <54FD95A2.2040407@jive.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.24.34.20] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <33626C9A01245C46838F1AC506C6FDF2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tram] TURN Server Discovery - WG feedback 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, 13 Mar 2015 23:24:12 -0000 Hi Simon, On 3/9/15, 5:44 AM, "Simon Perreault" wrote: >Le 2015-03-08 22:19, Prashanth Patil (praspati) a =E9crit : >> 1. Reverse PTR lookup on the client=B9s public IP address to determine >> the domain-name >> =20 >>(https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-01#sec >>tion-4.1.2) >> - Using RFC7216 to achieve this has dependencies on STUN server >> discovery, which is a concern. Given this, we=B9re considering >> removing sections pertaining to resolution using IP address >> (Sections 4.1.2 & 4.2.1). > >I'm OK with removing this based on Adam's comments, but I truly don't >understand the rationale above. The draft suggests that one of the discovery mechanisms be Service Resolution, as per RFC 5928 - an NAPTR lookup for RELAY application service within the given 'domain=B9. We=B9ve explained 3 possible means a client could use to retrieve domain names. One of the means is to derive the domain name from the client=B9s IP address i.e. reverse PTR lookup. To discover a TURN server provided by the ISP, given that a client is almost certainly going to be behind a NAT, the client would have to determine it=B9s public IP address. As Adam has rightly points out, the client would have to use a STUN server to do this. This would mean the client has to discover a STUN server, which has the same problems as TURN discovery. Given these problems, we were considering removing sections that describe domain lookup using IP address. -Prashanth=20 > >> 2. DNS Service Discovery - Is there interest in the WG to include this >> mechanism in the draft? > >I say if Adam thinks this can work, let's give it a shot. > >Simon From nobody Sat Mar 14 18:19:33 2015 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 B7AA91A066C for ; Sat, 14 Mar 2015 18:19:31 -0700 (PDT) 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_64=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 OT5g6PTWlP8y for ; Sat, 14 Mar 2015 18:19:29 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1CC31A046D for ; Sat, 14 Mar 2015 18:19:29 -0700 (PDT) Received: by oiaz123 with SMTP id z123so13144975oia.3 for ; Sat, 14 Mar 2015 18:19:29 -0700 (PDT) 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=F3JF1w4f/GTM9OzcXyc/Y8dRqwFaDdIGqJbU/RX0LO4=; b=BKYuRVtl3gBa/ew3wVHVqzatMXcRRmFZzhLkQ6QtdqOVn5WmqnlTjiZisq0pqmnxiR na/uHVyNQAYa+g3p+iQbk8n6r+6jXz8sD+y23VCjZiM1mUB+7kBIRDrBZpPJBRmtn1Uk 6sdpdxC1j3kriC3PAKa+IwYmaPa1NKpm5O+/V2Uc7910Mp/E0yvgGfRWXDd5ObYgdedo caKWJhP7w1K27VVKaiQ7CgaeJKYyuNjP0XaCPahq6HusDWJ66c7micqWP34OK4gh5bo3 5W/EJcqCD0I8hyYEJQT8c7Fz8HbGfd0QjzJO7l8XIZW3kAIO/kODVeo/+yTgt2seB4KC DY3g== MIME-Version: 1.0 X-Received: by 10.182.128.199 with SMTP id nq7mr20316003obb.47.1426382369286; Sat, 14 Mar 2015 18:19:29 -0700 (PDT) Received: by 10.202.86.20 with HTTP; Sat, 14 Mar 2015 18:19:29 -0700 (PDT) Received: by 10.202.86.20 with HTTP; Sat, 14 Mar 2015 18:19:29 -0700 (PDT) In-Reply-To: References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> <54EF3616.4040704@acm.org> <54FD645B.9000905@acm.org> Date: Sat, 14 Mar 2015 18:19:29 -0700 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: multipart/alternative; boundary=089e01537e766f70f5051149868a Archived-At: Cc: Marc Petit-Huguenin , Oleg Moskalenko , tram@ietf.org Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.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: Sun, 15 Mar 2015 01:19:31 -0000 --089e01537e766f70f5051149868a Content-Type: text/plain; charset=UTF-8 I agree with Justin&Marc. Negotiation is too much. It might be nice to signal a preference for sha256, to allow dropping the sha1. maybe in a=ice-options (once we dispense with aggressive nomination perhaps). But the extra bytes aren't going to hurt that much. On Mar 12, 2015 2:26 PM, "Justin Uberti" wrote: > > > On Mon, Mar 9, 2015 at 2:14 AM, Marc Petit-Huguenin > wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> On 02/26/2015 09:56 AM, Oleg Moskalenko wrote: >> > On Thu, Feb 26, 2015 at 7:04 AM, Marc Petit-Huguenin >> wrote: >> > >> >>> There is a well-defined association between the hash length and the >> >>> algorithm. SHA-1 produce 20 bytes, SHA-256 produce 32 bytes, SHA-384 >> >>> produce 48 bytes and SHA-512 produce 64 bytes. Why we cannot use the >> >>> MESSAGE-INTEGRITY length to determine the algorithm that the peer is >> >>> using ? >> >> >> >> Does not work with SHA-3. >> >> >> > >> > If there is a requirement to support wide multiplicity of algorithms, >> > even SHA-3, then I see two clear choices: >> > >> > 1) Leave the algorithm negotiation to the out-of-bound communication >> > channel between the client and the server. They can negotiate what >> > kind of hash is used, and what is the size of the MESSAGE-INTEGRITY to >> > be. >> > 2) Implement a usual negotiation scheme, like in TLS. We can introduce >> > a new attribute that contains "algorithm ID" and optionally "algorithm >> > attribute(s)" (specific to algorithm). The client sends a number of >> > supported algorithm attributes to the server, server either rejects or >> > picks one and sends back authenticated response with the chosen >> > algorithm attribute. If no attribute is included in the client or >> > server message, that means default "SHA-1, 160 bits". If a variable >> > length hash algorithm chosen, then that's fine, the message recipient >> > will just use the MESSAGE-INTEGRITY attribute length (given they >> > already agree on a particular algorithm). >> > >> > I'd vote for the second approach. That way, we introduce no extra >> > round trips, we cover multiple algorithms (including the future ones), >> > and we have full backward compatibility. >> >> We do not vote here. You will have to build a consensus for your >> solution of choice, and as co-editor I will modify the draft to follow this >> consensus. >> >> As an individual, I support neither of the solutions you proposed for the >> following reasons: >> >> - - HMAC-SHA is not broken but going to HMAC-SHA256 is a cautious step I >> (reluctantly) agree with. >> - - Negotiation is more often used to decrease security than to increase >> it so let's not unless we have no choice (as for the password hash, that is >> broken). >> - - Adding negotiation means that short-term authentication may get an >> additional round-trip for each ICE's connectivity check. >> - - The solution proposed in the draft follows what the authors of RFC >> 5389 suggested in section 16.3. >> >> > MESSAGE-INTEGRITY is not a critical part of the overall application > security. +1 to keeping it simple. > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > --089e01537e766f70f5051149868a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I agree with Justin&Marc. Negotiation is too much.

It might be nice to signal a preference for sha256, to allow= dropping the sha1. maybe in a=3Dice-options (once we dispense with aggress= ive nomination perhaps). But the extra bytes aren't going to hurt that = much.

On Mar 12, 2015 2:26 PM, "Justin Uberti&quo= t; <juberti@google.com> wro= te:


On Mon, Mar = 9, 2015 at 2:14 AM, Marc Petit-Huguenin <petithug@acm.org> wr= ote:
-----BEGIN PGP SIGNED MESSAGE-= ----
Hash: SHA256

On 02/26/2015 09:56 AM, Oleg Moskalenko wrote:
> On Thu, Feb 26, 2015 at 7:04 AM, Marc Petit-Huguenin <petithug@acm.org> wrote: >
>>> There is a well-defined association between the hash length an= d the
>>> algorithm. SHA-1 produce 20 bytes, SHA-256 produce 32 bytes, S= HA-384
>>> produce 48 bytes and SHA-512 produce 64 bytes. Why we cannot u= se the
>>> MESSAGE-INTEGRITY length to determine the algorithm that the p= eer is
>>> using ?
>>
>> Does not work with SHA-3.
>>
>
> If there is a requirement to support wide multiplicity of algorithms,<= br> > even SHA-3, then I see two clear choices:
>
> 1) Leave the algorithm negotiation to the out-of-bound communication > channel between the client and the server. They can negotiate what
> kind of hash is used, and what is the size of the MESSAGE-INTEGRITY to=
> be.
> 2) Implement a usual negotiation scheme, like in TLS. We can introduce=
> a new attribute that contains "algorithm ID" and optionally = "algorithm
> attribute(s)" (specific to algorithm). The client sends a number = of
> supported algorithm attributes to the server, server either rejects or=
> picks one and sends back authenticated response with the chosen
> algorithm attribute. If no attribute is included in the client or
> server message, that means default "SHA-1, 160 bits". If a v= ariable
> length hash algorithm chosen, then that's fine, the message recipi= ent
> will just use the MESSAGE-INTEGRITY attribute length (given they
> already agree on a particular algorithm).
>
> I'd vote for the second approach. That way, we introduce no extra<= br> > round trips, we cover multiple algorithms (including the future ones),=
> and we have full backward compatibility.

We do not vote here.=C2=A0 You will have to build a consensus f= or your solution of choice, and as co-editor I will modify the draft to fol= low this consensus.

As an individual, I support neither of the solutions you proposed for the f= ollowing reasons:

- - HMAC-SHA is not broken but going to HMAC-SHA256 is a cautious step I (r= eluctantly) agree with.
- - Negotiation is more often used to decrease security than to increase it= so let's not unless we have no choice (as for the password hash, that = is broken).
- - Adding negotiation means that short-term authentication may get an addi= tional round-trip for each ICE's connectivity check.
- - The solution proposed in the draft follows what the authors of RFC 5389= suggested in section 16.3.


MESSAGE-INTEGRITY is not = a critical part of the overall application security. +1 to keeping it simpl= e.=C2=A0

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

--089e01537e766f70f5051149868a-- From nobody Sat Mar 14 18:48:05 2015 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 45FB21A0687 for ; Sat, 14 Mar 2015 18:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, 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 W-USGgZOu9FE for ; Sat, 14 Mar 2015 18:48:02 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EFC81A064C for ; Sat, 14 Mar 2015 18:48:02 -0700 (PDT) Received: by wgra20 with SMTP id a20so14570416wgr.3 for ; Sat, 14 Mar 2015 18:48:01 -0700 (PDT) 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=tA0H4ndl1ANA54auYkTHdDQA4Rq+jnxkBKQ1tSlqSMw=; b=wE6s849RjTWlQsARf7KlYB3nSgNC7BlEEaFiu4Dw0EP4njSMiZz1xEckUgcKaXwj+m S4PVtqb5zixb05IlY0D5hM76y84jBCcbQbUdDCCo+10f40WTd8dphA00dxp4uoidl1S5 ONzo6oQbE7YDhh2DmXbhX2Do6G9eRa3LXTyTozOxv3+xixEHMiYFRj8Zy3zwBilm7H64 P2fgCLvUiwags11o8+WDtxP+Ne83QBW1/GGJ5XUtTvRPXu41b8kYc7I0PQFvgm5uRza1 P60dU9evpOxr9r6SbTbspKmhiGohpV+VKU0L+gvHDj8ijlYgNLM2T/CvbVvWrUrNZH9/ De3w== MIME-Version: 1.0 X-Received: by 10.181.5.43 with SMTP id cj11mr149881173wid.61.1426384081217; Sat, 14 Mar 2015 18:48:01 -0700 (PDT) Received: by 10.194.190.18 with HTTP; Sat, 14 Mar 2015 18:48:01 -0700 (PDT) In-Reply-To: <550346F0.2070507@akamai.com> References: <55030BBB.7090808@jive.com> <550313E0.8020100@acm.org> <5503207C.9000007@akamai.com> <550346F0.2070507@akamai.com> Date: Sat, 14 Mar 2015 18:48:01 -0700 Message-ID: From: Oleg Moskalenko To: Brandon Williams Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Marc Petit-Huguenin , "tram@ietf.org" , Justin Uberti , "Tirumaleswar Reddy \(tireddy\)" , Simon Perreault , Benjamin Schwartz Subject: Re: [tram] STUN fragmentation [Was: I-D Action: draft-ietf-tram-stunbis-01.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: Sun, 15 Mar 2015 01:48:04 -0000 It would be tempting just to add the 'native' SCTP support to STUN, for the sake of efficient data delivery and easy implementation, but it may contradict the original STUN intention - the NAT traversal aid. On Fri, Mar 13, 2015 at 1:22 PM, Brandon Williams wrote: > I think we're pretty much on the same page on this one. I'm just exploring > whether the current requirement in the text is a reasonable approach to the > pathological case. Is it better to do what the current text requires (drop > the packet)? Or is it better to relax the wording in recognition of the fact > that the problem case is pathological and that a fragmented packet is more > likely to get through than a dropped packet? I would rather relax the > requirement than do a bunch of work, though I'd be willing to do a little > work if we come up with a low impact fix. > > --Brandon > > PS: Really? Hopefully we can rely on IPv6 deployment? :-) > > On 03/13/2015 02:47 PM, Justin Uberti wrote: >> >> >> >> On Fri, Mar 13, 2015 at 10:38 AM, Brandon Williams >> > wrote: >> >> According to the current stunbis draft, it is still a requirement to >> keep your request down below 548 bytes for IPv4 if you don't know >> the real MTU and your request is not directly associated with MTU >> discovery. The value for the ORIGIN attribute could consume nearly >> half of that and the 3rd party auth token could consume nearly half >> of the remainder. If we don't think that 548 bytes is a reasonable >> requirement for the unknown MTU case, then the requirement should be >> removed from the spec. >> >> >> The ORIGIN will only be that large in extreme, likely pathological >> cases. Based on a median DNS name length of 12 bytes, the median median >> ORIGIN value is 24 bytes, including attribute header. >> (http://datagenetics.com/blog/march22012/) >> >> >> Regarding Justin's question about who is being kept awake by this >> ... I know that small MTUs occur in some parts of the Internet, even >> as low as the IPv4 minimum. I don't think this it's common, but I >> unfortunately don't have numbers to quantify the scope of the >> problem so my assessment is based on a faint memory from a few years >> ago where I had to allow packet fragmentation in these cases in >> order to avoid dropping the packets entirely. I would rather send >> fragments than drop the whole packet, at least for the applications >> that I support today, and again, I believe the issue to be rare. >> >> >> Recall that the IPv6 minimum is 1280 bytes, so hopefully by the time we >> have enough attributes for this to be a real-world problem this 548 byte >> limit will have been increased substantially. >> >> >> As per my previous e-mail, I'm more concerned about control messages >> than I am about data messages, since I think there's less >> flexibility around the message size. If the control message gets >> fragmented, on some paths it just won't get through. I would be >> happy enough with an solution for control messages, but even that I >> don't consider to be critical at the moment. >> >> >> I agree, and I think that taking on a complex solution like SCTP to >> solve what appears to be a non-critical problem is not a wise path. >> >> >> --Brandon >> >> >> On 03/13/2015 12:58 PM, Oleg Moskalenko wrote: >> >> On Fri, Mar 13, 2015 at 9:44 AM, Marc Petit-Huguenin >> > wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> On 03/13/2015 10:38 AM, Justin Uberti wrote: >> >> Right, that was my reading as well. So my question is, >> who is being kept >> awake by this? >> >> >> draft-ietf-tram-stun-origin >> >> >> that's just a few extra bytes in the ALLOCATE request >> >> _________________________________________________ >> 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 Mon Mar 16 05:14:21 2015 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 E348C1A8701 for ; Mon, 16 Mar 2015 05:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 iv8DmnkIm8kV for ; Mon, 16 Mar 2015 05:14:18 -0700 (PDT) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69B721A86FA for ; Mon, 16 Mar 2015 05:14:18 -0700 (PDT) Received: by qgh62 with SMTP id 62so37614272qgh.1 for ; Mon, 16 Mar 2015 05:14:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=VvcqWPNXvISpS3MC7rvGif1rH82YqzyF9hJazJo+8VQ=; b=LtAwPfOY0uI/P9Bgejm4tM3iQQVeBq6MWMnBVhGbCY3dCrk+gKojTdPDkCWC+LZmkB kLGbSMZO1JKAahXiRcC37nM3L+HQA1ALc9+TnQ4gzpDtrA8pFVDk19d9rZj89JekauWa 1Pomz9tAGKMzpcqwbbe0vZqqqEi+oDeNsQvjfMf7XI1GeiQrkmOuCp2hRN8UxyVZ4MSY z67CI4Cw87fO4qZryVnbv4tF40MdQvmITFRhthlShVYTIi9jy/SsOoZ3I6cQFd5fLxTD oMPj2a6414xObq1n4HobgPwKis/IXqOHP2wf6o2kaWvbla5xTNvAhd4MLq7gljTEBuUr x6jw== X-Gm-Message-State: ALoCoQlUWIFEMksClxbdSlSA38TKXbGFjX0mKhoXBgU1zvW50ZZFLhypvKn5IPCiCHi2vKTbj7C5 X-Received: by 10.55.25.38 with SMTP id k38mr115603505qkh.48.1426508057714; Mon, 16 Mar 2015 05:14:17 -0700 (PDT) Received: from [192.168.1.43] (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id 74sm7353917qgp.9.2015.03.16.05.14.16 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Mar 2015 05:14:16 -0700 (PDT) Message-ID: <5506C917.8080102@jive.com> Date: Mon, 16 Mar 2015 08:14:15 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Prashanth Patil (praspati)" , "tram@ietf.org" References: <54FD95A2.2040407@jive.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tram] TURN Server Discovery - WG feedback 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, 16 Mar 2015 12:14:20 -0000 Le 2015-03-13 19:24, Prashanth Patil (praspati) a écrit : > On 3/9/15, 5:44 AM, "Simon Perreault" wrote: > >> >Le 2015-03-08 22:19, Prashanth Patil (praspati) a écrit : >>> >> 1. Reverse PTR lookup on the client¹s public IP address to determine >>> >> the domain-name >>> >> >>> >>(https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-01#sec >>> >>tion-4.1.2) >>> >> - Using RFC7216 to achieve this has dependencies on STUN server >>> >> discovery, which is a concern. Given this, we¹re considering >>> >> removing sections pertaining to resolution using IP address >>> >> (Sections 4.1.2 & 4.2.1). >> > >> >I'm OK with removing this based on Adam's comments, but I truly don't >> >understand the rationale above. > The draft suggests that one of the discovery mechanisms be Service > Resolution, as per RFC 5928 - an NAPTR lookup for RELAY application > service within the given 'domain¹. We¹ve explained 3 possible means a > client could use to retrieve domain names. One of the means is to derive > the domain name from the client¹s IP address i.e. reverse PTR lookup. To > discover a TURN server provided by the ISP, given that a client is almost > certainly going to be behind a NAT, the client would have to determine > it¹s public IP address. No. If I'm on a private network, I want to fetch the PTR record corresponding to my private IP address. That's the one the network administrator would use to configure the TURN server's location. This relies on a split-view DNS server populated with PTR records for the network's private address range. That is common practice in enterprise networks. Simon > As Adam has rightly points out, the client would > have to use a STUN server to do this. This would mean the client has to > discover a STUN server, which has the same problems as TURN discovery. > Given these problems, we were considering removing sections that describe > domain lookup using IP address. From nobody Mon Mar 16 08:53:54 2015 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 42A1E1A887A for ; Mon, 16 Mar 2015 08:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 JGS1xoR42m5B for ; Mon, 16 Mar 2015 08:53:49 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id BB3431A8879 for ; Mon, 16 Mar 2015 08:53:49 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C3607476F5; Mon, 16 Mar 2015 15:53:48 +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 ABEDD4766F; Mon, 16 Mar 2015 15:53:48 +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 A79638004E; Mon, 16 Mar 2015 15:53:48 +0000 (GMT) Message-ID: <5506FC8C.1070501@akamai.com> Date: Mon, 16 Mar 2015 11:53:48 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Martin Thomson , Justin Uberti References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> <54EF3616.4040704@acm.org> <54FD645B.9000905@acm.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Marc Petit-Huguenin , Oleg Moskalenko , tram@ietf.org Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.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, 16 Mar 2015 15:53:52 -0000 +1 for keeping it simple In the TURN context, can the client's inclusion of MI2 be treated as a preference? IOW, SHOULD|MUST the server respond with MI2 if the client sent it? On a related note, the current section 15.3 text indicates that the client will always send both MI and MI2 in its requests and indications. Is it OK for the client to stop sending both for a specific session after the first response from the server, which will contain only one or the other? With the lack of explicit negotiation, I think either stunbis or 3rd party auth needs to define what the OAuth server and client should do to support transition to SHA256. I think it's probably as simple as: * OAuth server produces a key big enough for SHA256 * client always produces both MI and MI2, using the standard mechanism to reduce the SHA256 key for use in SHA1. * the relay server picks MI or MI2 as it normally would. Alternatively, the 3rd party auth draft could simply require that all three parties support SHA256 and require the client to only send MI2. That would be simpler, but would not allow SHA1 for clients/servers that wish to use it, so I think it can probably be ruled out. --Brandon On 03/14/2015 09:19 PM, Martin Thomson wrote: > I agree with Justin&Marc. Negotiation is too much. > > It might be nice to signal a preference for sha256, to allow dropping > the sha1. maybe in a=ice-options (once we dispense with aggressive > nomination perhaps). But the extra bytes aren't going to hurt that much. > > On Mar 12, 2015 2:26 PM, "Justin Uberti" > wrote: > > > > On Mon, Mar 9, 2015 at 2:14 AM, Marc Petit-Huguenin > > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 02/26/2015 09:56 AM, Oleg Moskalenko wrote: > > On Thu, Feb 26, 2015 at 7:04 AM, Marc Petit-Huguenin > > wrote: > > > >>> There is a well-defined association between the hash length > and the > >>> algorithm. SHA-1 produce 20 bytes, SHA-256 produce 32 > bytes, SHA-384 > >>> produce 48 bytes and SHA-512 produce 64 bytes. Why we > cannot use the > >>> MESSAGE-INTEGRITY length to determine the algorithm that > the peer is > >>> using ? > >> > >> Does not work with SHA-3. > >> > > > > If there is a requirement to support wide multiplicity of > algorithms, > > even SHA-3, then I see two clear choices: > > > > 1) Leave the algorithm negotiation to the out-of-bound > communication > > channel between the client and the server. They can negotiate > what > > kind of hash is used, and what is the size of the > MESSAGE-INTEGRITY to > > be. > > 2) Implement a usual negotiation scheme, like in TLS. We can > introduce > > a new attribute that contains "algorithm ID" and optionally > "algorithm > > attribute(s)" (specific to algorithm). The client sends a > number of > > supported algorithm attributes to the server, server either > rejects or > > picks one and sends back authenticated response with the chosen > > algorithm attribute. If no attribute is included in the client or > > server message, that means default "SHA-1, 160 bits". If a > variable > > length hash algorithm chosen, then that's fine, the message > recipient > > will just use the MESSAGE-INTEGRITY attribute length (given they > > already agree on a particular algorithm). > > > > I'd vote for the second approach. That way, we introduce no extra > > round trips, we cover multiple algorithms (including the > future ones), > > and we have full backward compatibility. > > We do not vote here. You will have to build a consensus for > your solution of choice, and as co-editor I will modify the > draft to follow this consensus. > > As an individual, I support neither of the solutions you > proposed for the following reasons: > > - - HMAC-SHA is not broken but going to HMAC-SHA256 is a > cautious step I (reluctantly) agree with. > - - Negotiation is more often used to decrease security than to > increase it so let's not unless we have no choice (as for the > password hash, that is broken). > - - Adding negotiation means that short-term authentication may > get an additional round-trip for each ICE's connectivity check. > - - The solution proposed in the draft follows what the authors > of RFC 5389 suggested in section 16.3. > > > MESSAGE-INTEGRITY is not a critical part of the overall application > security. +1 to keeping it simple. > > _______________________________________________ > 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 Mar 16 10:38:12 2015 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 0FDAC1A8919 for ; Mon, 16 Mar 2015 10:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, 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 cIV8On4uevGF for ; Mon, 16 Mar 2015 10:38:10 -0700 (PDT) Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com [209.85.218.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD3281A88F1 for ; Mon, 16 Mar 2015 10:38:10 -0700 (PDT) Received: by oigv203 with SMTP id v203so9828846oig.3 for ; Mon, 16 Mar 2015 10:38:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=MjXQGxD1REBZTHhHwBtahkxK83EsQ53h0rJGXKmmm34=; b=O8PoRIqMueYn5GVArwzPBI43/q3UjQmCG1io3O/wP1M1vSztcMyhOEUSlj6xVUE+6t 0A//FE/Tm9MrMeaogPOBTVh2eHiX1HlA6Rmgm2ykVhdKmjCDBflny+Hw/IKczeyMThpv tsAsKbKizXTF5jUUKWjqBsNl6Q6LB/Izln03QQl+FNPRh8IVHYw356xfRhpL4d3nKKGA AkB+TwTOQ5TclYbiRBiRJr6R/Aogj4hJNaI+6mHKgCBjfztf/E3qQPpaXzp+C+LKXhBU KcZcu5OTWfdXj1P3+MXnfY+JW9bHsa0eMgKYuV13tMBgZ/nF1BlxjLQimk8XjPspFyQd AxkA== X-Gm-Message-State: ALoCoQknW1IZQfWOeTrpEDUKBsP619Sl57+7qIZEh1mcCl8SxzUIrm3PtFiKoZwswhPOTHxbJ8nh X-Received: by 10.202.180.87 with SMTP id d84mr33380188oif.0.1426527490262; Mon, 16 Mar 2015 10:38:10 -0700 (PDT) Received: from Simons-MacBook-Air.local (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id e17sm7470119oic.9.2015.03.16.10.38.08 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Mar 2015 10:38:09 -0700 (PDT) Message-ID: <550714FF.2020506@jive.com> Date: Mon, 16 Mar 2015 13:38:07 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Brandon Williams , Martin Thomson , Justin Uberti References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> <54EF3616.4040704@acm.org> <54FD645B.9000905@acm.org> <5506FC8C.1070501@akamai.com> In-Reply-To: <5506FC8C.1070501@akamai.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: Marc Petit-Huguenin , Oleg Moskalenko , tram@ietf.org Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.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, 16 Mar 2015 17:38:12 -0000 Le 2015-03-16 11:53, Brandon Williams a écrit : > +1 for keeping it simple > > In the TURN context, can the client's inclusion of MI2 be treated as a > preference? IOW, SHOULD|MUST the server respond with MI2 if the client > sent it? I think it should be a MUST on both ends. The client MUST send MI2, and the server MUST send MI2 if the client sent it. > On a related note, the current section 15.3 text indicates that the > client will always send both MI and MI2 in its requests and indications. > Is it OK for the client to stop sending both for a specific session > after the first response from the server, which will contain only one or > the other? Maybe this could be tied to the NONCE attribute. Initially you send both, discover what the server supports, and get a nonce. As long as you're using that nonce, you can use just MI or MI2 (depending on what the server supports). When the nonce expires you need to send both to re-discover what the server supports (in case it changed), and then you can go back to sending just one. Simon From nobody Mon Mar 16 11:13:49 2015 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 3D0461A89E1 for ; Mon, 16 Mar 2015 11:13:48 -0700 (PDT) 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 SRtQBNaTLWwU for ; Mon, 16 Mar 2015 11:13:47 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 019C81A89C4 for ; Mon, 16 Mar 2015 11:13:46 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t2GIDhhV029198 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Mar 2015 13:13:43 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <55071D56.8050106@nostrum.com> Date: Mon, 16 Mar 2015 13:13:42 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Simon Perreault , "Prashanth Patil (praspati)" , "tram@ietf.org" References: <54FD95A2.2040407@jive.com> <5506C917.8080102@jive.com> In-Reply-To: <5506C917.8080102@jive.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tram] TURN Server Discovery - WG feedback 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, 16 Mar 2015 18:13:48 -0000 On 3/16/15 07:14, Simon Perreault wrote: > If I'm on a private network, I want to fetch the PTR record > corresponding to my private IP address. That's the one the network > administrator would use to configure the TURN server's location. This > relies on a split-view DNS server populated with PTR records for the > network's private address range. That is common practice in enterprise > networks. That seems downright Rube Goldberg-esque compared to the more direct approach of asking for the address of the TURN server via mDNS. /a From nobody Mon Mar 16 11:17:37 2015 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 9A85C1A89F1 for ; Mon, 16 Mar 2015 11:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 N6lh2tsOoQCh for ; Mon, 16 Mar 2015 11:17:35 -0700 (PDT) Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com [209.85.218.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EE511A89AA for ; Mon, 16 Mar 2015 11:17:35 -0700 (PDT) Received: by oier21 with SMTP id r21so45224572oie.1 for ; Mon, 16 Mar 2015 11:17:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=VwVvSHTwMpf+svhSspS4T6uQU9g0qIMAw34ksT/LJ4s=; b=WJoUX27mu1otPCru6PexJfnKbKdkCEeV7owl9I4MyHo0ezfJMJ+HoPaIm9FfhtRVEh Wqydx8+ADv7RUlkviVk54zcaPgXqrFdaNeeFShREm63pbpj2BZn4nVDVTEcxBPb578za SyMvHqwePHoaDsS4fEFbmab4CJ5XOD+QxzF9L/yiDCOMXbFDyck/uwfXiqwMXCqQ+8wz XyNdOFsIo86pyivr49RulFBmwpu2LQ/01gKlHbeZFqH1aDj2BzGitV66wKRZhuGjlb7Z +cY1xVhR/xSI38D2Zwy0BXCOo8GjRL6zMspvc0ufqysULPRaj/GXQG/0yamLudkQplgz wJJw== X-Gm-Message-State: ALoCoQlqiOLvVE6HTt0hmOr8jO2X+8V0qsE7vF9d5c8XiI9z92vg0cDdMaXOdhbhO1iZFLFgpfz4 X-Received: by 10.202.69.67 with SMTP id s64mr3048876oia.134.1426529854515; Mon, 16 Mar 2015 11:17:34 -0700 (PDT) Received: from Simons-MacBook-Air.local (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id r83sm7515118oif.28.2015.03.16.11.17.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Mar 2015 11:17:33 -0700 (PDT) Message-ID: <55071E3B.1070107@jive.com> Date: Mon, 16 Mar 2015 14:17:31 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Adam Roach , "Prashanth Patil (praspati)" , "tram@ietf.org" References: <54FD95A2.2040407@jive.com> <5506C917.8080102@jive.com> <55071D56.8050106@nostrum.com> In-Reply-To: <55071D56.8050106@nostrum.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tram] TURN Server Discovery - WG feedback 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, 16 Mar 2015 18:17:36 -0000 Le 2015-03-16 14:13, Adam Roach a écrit : > On 3/16/15 07:14, Simon Perreault wrote: >> If I'm on a private network, I want to fetch the PTR record >> corresponding to my private IP address. That's the one the network >> administrator would use to configure the TURN server's location. This >> relies on a split-view DNS server populated with PTR records for the >> network's private address range. That is common practice in enterprise >> networks. > > That seems downright Rube Goldberg-esque compared to the more direct > approach of asking for the address of the TURN server via mDNS. Agreed. I'm not suggesting that it's better than mDNS. I'm just pointing out that the "recursive discovery" rationale for rejecting the PTR method doesn't make sense. Simon From nobody Mon Mar 16 13:08:06 2015 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 29E0C1A90AB for ; Mon, 16 Mar 2015 13:08:04 -0700 (PDT) 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 Ks6IHN46l9Jq for ; Mon, 16 Mar 2015 13:08:02 -0700 (PDT) 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 3161E1A90A4 for ; Mon, 16 Mar 2015 13:08:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1200; q=dns/txt; s=iport; t=1426536482; x=1427746082; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Wn8Z9BpRTJqhlQ50Oc9557sOs+lP7+Eef3yIni9UZy8=; b=Fank41FHQVIOd2+Z3U+2AWndi7MkuLvWMQJE4aSFpFb2Fu+DPqL0+cSB 7RRyTSLTASwteGz7UVp8jIYai8hcwojypAwHKbwbvxtvvHklVVbYQyI2S 6Fcqr00LoraAQTifEnnhRfwvhfl4nxbxpVKtz+MWGb7EdbzW4VkLGXgPd w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CwBQAYNwdV/4wNJK1bgwZSWgTCPoIvCoV0AoE3TAEBAQEBAX2EEAEBBAEBAWsbAgEIDgouJwslAgQBEogvDcgMAQEBAQEBAQEBAQEBAQEBAQEBARUEixeEeIQtBYpVhWWJZpQUI4F9gXFvgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,411,1422921600"; d="scan'208";a="132542316" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-2.cisco.com with ESMTP; 16 Mar 2015 20:08:01 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t2GK81sY028900 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Mar 2015 20:08:01 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.249]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Mon, 16 Mar 2015 15:08:01 -0500 From: "Prashanth Patil (praspati)" To: Simon Perreault , Adam Roach , "tram@ietf.org" Thread-Topic: [tram] TURN Server Discovery - WG feedback Thread-Index: AQHQWmbBerl+Kpxhek+6UZ7ekaEKBJ0fEKfegAC4OwCAAAERgP//ukWA Date: Mon, 16 Mar 2015 20:08:00 +0000 Message-ID: References: <54FD95A2.2040407@jive.com> <5506C917.8080102@jive.com> <55071D56.8050106@nostrum.com> <55071E3B.1070107@jive.com> In-Reply-To: <55071E3B.1070107@jive.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.155.208.183] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <231046C3139A0949AE1D4D33E56E9A80@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tram] TURN Server Discovery - WG feedback 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, 16 Mar 2015 20:08:04 -0000 On 3/16/15, 11:17 AM, "Simon Perreault" wrote: >Le 2015-03-16 14:13, Adam Roach a =E9crit : >> On 3/16/15 07:14, Simon Perreault wrote: >>> If I'm on a private network, I want to fetch the PTR record >>> corresponding to my private IP address. That's the one the network >>> administrator would use to configure the TURN server's location. This >>> relies on a split-view DNS server populated with PTR records for the >>> network's private address range. That is common practice in enterprise >>> networks. >>=20 >> That seems downright Rube Goldberg-esque compared to the more direct >> approach of asking for the address of the TURN server via mDNS. > >Agreed. I'm not suggesting that it's better than mDNS. I'm just pointing >out that the "recursive discovery" rationale for rejecting the PTR >method doesn't make sense. If we=B9re fine with recommending the PTR method to the private network, we can retain some of the text. But if included DNS-SD, the PTR method may not be necessary. -Prashanth > >Simon > >_______________________________________________ >tram mailing list >tram@ietf.org >https://www.ietf.org/mailman/listinfo/tram From nobody Mon Mar 16 19:05:29 2015 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 D55E41A8A92 for ; Mon, 16 Mar 2015 19:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_64=0.6, 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 znC3YUxv6Aey for ; Mon, 16 Mar 2015 19:05:24 -0700 (PDT) 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 5E63F1AC3AB for ; Mon, 16 Mar 2015 19:05:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1708; q=dns/txt; s=iport; t=1426557924; x=1427767524; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jiQHA5PpRyJXjHxikrlf8o7IcRyX7ik36ExAzsKrGH0=; b=cE3DM0cfl3VGlutWVuSdkcxzhM78DhRmUGQQZN9RDc49cB/5tE8C98P/ yTlOOvCE0ttLyZ82lezfhHgX6Zg0Vmo/sThZiHJRfEIv503qJ3lKcc+Qz NBb9p995XLzb/M7Nnr18Grsmti958o6nOOQ+0p6mmzmM6C76afvm43pFp 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BABQCHigdV/5tdJa1bgwZSXsIxaYE9CoVwAoE6OBQBAQEBAQEBfIQPAQEBAwEBAQFrCwwEAgEIDgMEAQELHQcnCxQJCAIEAQ0FCIgfCA3HLwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEixKEPTEHBoMRgRQBBIoshUqdGiODbm+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.11,412,1422921600"; d="scan'208";a="132531697" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP; 17 Mar 2015 02:05:23 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t2H25Nsx007150 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Mar 2015 02:05:23 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.80]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Mon, 16 Mar 2015 21:05:23 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault , Brandon Williams , Martin Thomson , Justin Uberti Thread-Topic: [tram] I-D Action: draft-ietf-tram-stunbis-01.txt Thread-Index: AQHQSs9eowAbQmERAkOzA1uv2nxY/J0CL+wAgAFKMQCAAB8jAIAQt7iAgAWDXYCAA2YIgIAChp0AgAAdJYCAADjW8A== Date: Tue, 17 Mar 2015 02:05:22 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A366CA5E4@xmb-rcd-x10.cisco.com> References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> <54EF3616.4040704@acm.org> <54FD645B.9000905@acm.org> <5506FC8C.1070501@akamai.com> <550714FF.2020506@jive.com> In-Reply-To: <550714FF.2020506@jive.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.54.29] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Marc Petit-Huguenin , Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.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, 17 Mar 2015 02:05:28 -0000 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Simon Perreault > Sent: Monday, March 16, 2015 11:08 PM > To: Brandon Williams; Martin Thomson; Justin Uberti > Cc: Marc Petit-Huguenin; Oleg Moskalenko; tram@ietf.org > Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.txt >=20 > Le 2015-03-16 11:53, Brandon Williams a =E9crit : > > +1 for keeping it simple > > > > In the TURN context, can the client's inclusion of MI2 be treated as a > > preference? IOW, SHOULD|MUST the server respond with MI2 if the client > > sent it? >=20 > I think it should be a MUST on both ends. The client MUST send MI2, and > the server MUST send MI2 if the client sent it. The algorithm support can be conveyed in SDP, so the client can pick MI1 or= MI2. -Tiru >=20 > > On a related note, the current section 15.3 text indicates that the > > client will always send both MI and MI2 in its requests and indications= . > > Is it OK for the client to stop sending both for a specific session > > after the first response from the server, which will contain only one o= r > > the other? >=20 > Maybe this could be tied to the NONCE attribute. Initially you send > both, discover what the server supports, and get a nonce. As long as > you're using that nonce, you can use just MI or MI2 (depending on what > the server supports). When the nonce expires you need to send both to > re-discover what the server supports (in case it changed), and then you > can go back to sending just one. >=20 > Simon >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Mon Mar 16 19:12:50 2015 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 F32581ACDE2 for ; Mon, 16 Mar 2015 19:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_64=0.6, 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 STV4DbuyH4e8 for ; Mon, 16 Mar 2015 19:12:47 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACC1B1ACDE0 for ; Mon, 16 Mar 2015 19:12:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6547; q=dns/txt; s=iport; t=1426558367; x=1427767967; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=V0wRzb7mNANm85a6/JRSiMo8wCnKAWGRctywTQzq0vw=; b=TWTV1xJ8gQPc/atE5302PY7DGo4YSMd+aLcKMrnekYQSPXvVxbbli9BQ BMxphjcVrkRj7hEJyWQyGq6E1gFBYebNXt5cO/MPiWwr3mseS+5UNQteR 6N1zXPGawlmLGQ/3+cdb2D40ilXdVwzEPZjCj7s6CJGun2drZR3U93cb1 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DqBgBzjAdV/4kNJK1aAYMGUloEwmSCLwqFdQKBOkwBAQEBAQF9hA8BAQEDAQEBATc0CwwEAgEIEQQBAQEKDgECAwkHJwsUCQgCBAENBQgTiAwIDckzAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLF4RAMQcGEg8Bgm+BFgWQOosBjzKDRyOBfwIdgVBvgQIHO38BAQE X-IronPort-AV: E=Sophos;i="5.11,413,1422921600"; d="scan'208";a="404540641" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-2.cisco.com with ESMTP; 17 Mar 2015 02:12:46 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t2H2CknG002167 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Mar 2015 02:12:46 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.80]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Mon, 16 Mar 2015 21:12:46 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , Martin Thomson , Justin Uberti Thread-Topic: [tram] I-D Action: draft-ietf-tram-stunbis-01.txt Thread-Index: AQHQSs9eowAbQmERAkOzA1uv2nxY/J0CL+wAgAFKMQCAAB8jAIAQt7iAgAWDXYCAA2YIgIAChp0AgABX/wA= Date: Tue, 17 Mar 2015 02:12:46 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A366CA610@xmb-rcd-x10.cisco.com> References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> <54EF3616.4040704@acm.org> <54FD645B.9000905@acm.org> <5506FC8C.1070501@akamai.com> In-Reply-To: <5506FC8C.1070501@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.54.29] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Marc Petit-Huguenin , Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.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, 17 Mar 2015 02:12:50 -0000 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams > Sent: Monday, March 16, 2015 9:24 PM > To: Martin Thomson; Justin Uberti > Cc: Marc Petit-Huguenin; Oleg Moskalenko; tram@ietf.org > Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.txt >=20 > +1 for keeping it simple >=20 > In the TURN context, can the client's inclusion of MI2 be treated as a > preference? IOW, SHOULD|MUST the server respond with MI2 if the client se= nt > it ? Why can't the TURN server send the algorithms it supports along with the 40= 1 error response and the client picks one of the algorithms it supports (wi= th higher preference for MI2) ? -Tiru >=20 > On a related note, the current section 15.3 text indicates that the clien= t will > always send both MI and MI2 in its requests and indications. > Is it OK for the client to stop sending both for a specific session after= the first > response from the server, which will contain only one or the other? >=20 > With the lack of explicit negotiation, I think either stunbis or 3rd part= y auth > needs to define what the OAuth server and client should do to support tra= nsition > to SHA256. I think it's probably as simple as: > * OAuth server produces a key big enough for SHA256 > * client always produces both MI and MI2, using the standard mechanism to > reduce the SHA256 key for use in SHA1. > * the relay server picks MI or MI2 as it normally would. >=20 > Alternatively, the 3rd party auth draft could simply require that all thr= ee parties > support SHA256 and require the client to only send MI2. > That would be simpler, but would not allow SHA1 for clients/servers that = wish to > use it, so I think it can probably be ruled out. >=20 > --Brandon >=20 > On 03/14/2015 09:19 PM, Martin Thomson wrote: > > I agree with Justin&Marc. Negotiation is too much. > > > > It might be nice to signal a preference for sha256, to allow dropping > > the sha1. maybe in a=3Dice-options (once we dispense with aggressive > > nomination perhaps). But the extra bytes aren't going to hurt that much= . > > > > On Mar 12, 2015 2:26 PM, "Justin Uberti" > > wrote: > > > > > > > > On Mon, Mar 9, 2015 at 2:14 AM, Marc Petit-Huguenin > > > wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > On 02/26/2015 09:56 AM, Oleg Moskalenko wrote: > > > On Thu, Feb 26, 2015 at 7:04 AM, Marc Petit-Huguenin > > > wrote: > > > > > >>> There is a well-defined association between the hash lengt= h > > and the > > >>> algorithm. SHA-1 produce 20 bytes, SHA-256 produce 32 > > bytes, SHA-384 > > >>> produce 48 bytes and SHA-512 produce 64 bytes. Why we > > cannot use the > > >>> MESSAGE-INTEGRITY length to determine the algorithm that > > the peer is > > >>> using ? > > >> > > >> Does not work with SHA-3. > > >> > > > > > > If there is a requirement to support wide multiplicity of > > algorithms, > > > even SHA-3, then I see two clear choices: > > > > > > 1) Leave the algorithm negotiation to the out-of-bound > > communication > > > channel between the client and the server. They can negotiat= e > > what > > > kind of hash is used, and what is the size of the > > MESSAGE-INTEGRITY to > > > be. > > > 2) Implement a usual negotiation scheme, like in TLS. We can > > introduce > > > a new attribute that contains "algorithm ID" and optionally > > "algorithm > > > attribute(s)" (specific to algorithm). The client sends a > > number of > > > supported algorithm attributes to the server, server either > > rejects or > > > picks one and sends back authenticated response with the cho= sen > > > algorithm attribute. If no attribute is included in the clie= nt or > > > server message, that means default "SHA-1, 160 bits". If a > > variable > > > length hash algorithm chosen, then that's fine, the message > > recipient > > > will just use the MESSAGE-INTEGRITY attribute length (given = they > > > already agree on a particular algorithm). > > > > > > I'd vote for the second approach. That way, we introduce no = extra > > > round trips, we cover multiple algorithms (including the > > future ones), > > > and we have full backward compatibility. > > > > We do not vote here. You will have to build a consensus for > > your solution of choice, and as co-editor I will modify the > > draft to follow this consensus. > > > > As an individual, I support neither of the solutions you > > proposed for the following reasons: > > > > - - HMAC-SHA is not broken but going to HMAC-SHA256 is a > > cautious step I (reluctantly) agree with. > > - - Negotiation is more often used to decrease security than to > > increase it so let's not unless we have no choice (as for the > > password hash, that is broken). > > - - Adding negotiation means that short-term authentication may > > get an additional round-trip for each ICE's connectivity check. > > - - The solution proposed in the draft follows what the authors > > of RFC 5389 suggested in section 16.3. > > > > > > MESSAGE-INTEGRITY is not a critical part of the overall application > > security. +1 to keeping it simple. > > > > _______________________________________________ > > 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 > > >=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 Mar 17 06:06:59 2015 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 ECBFC1A03F9 for ; Tue, 17 Mar 2015 06:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, 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 vr6Un7pxijX3 for ; Tue, 17 Mar 2015 06:06:55 -0700 (PDT) Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 369171A040B for ; Tue, 17 Mar 2015 06:06:50 -0700 (PDT) Received: by qgez64 with SMTP id z64so6920229qge.2 for ; Tue, 17 Mar 2015 06:06:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yScyxMZAQeRAyNgeG7V+51HB4jEVaEN568PiMowANdc=; b=QT4ShSmM+ApvIJ/myd8+kdiDx5zL9Za3ZHFH9Iai3rv8FF2CmEZdJIvmu6rK3O7UKq 5/VRd8IJJEHQMmJQrfXHU6+J2ZWBST00V8qCeV3VPkD7bisKETVJW8mBG1nwNgHz7BwD At7U/y9NS3H54XaqmpoQEDg4rrCd9CfsWy8jcuKi3NxgJ9oPwD86oTGQKstcE3vUP0Lf hjZznv8a+kQSwXHm0YHZWnoFYWiOfPtgkATs1931FdUwZ5o7ju7qRbeRXkAVn7hCS2ST 5zgleueL8rABggduyRcCANs3EO765Umg5kERtRbjeuhp5JcVDeRn4Kqy49yVXesLpHE2 NonQ== X-Gm-Message-State: ALoCoQmxPpHWFxxmQ1+6W5OC2GgCQa0o8wuioNR9z2QlLH567WI48IhcKYi0pc+tUSab1VPc60n4 X-Received: by 10.140.88.80 with SMTP id s74mr75673617qgd.59.1426597608904; Tue, 17 Mar 2015 06:06:48 -0700 (PDT) Received: from [192.168.1.43] (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id 131sm9517138qhh.48.2015.03.17.06.06.47 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Mar 2015 06:06:47 -0700 (PDT) Message-ID: <550826E6.90101@jive.com> Date: Tue, 17 Mar 2015 09:06:46 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , Brandon Williams , Martin Thomson , Justin Uberti References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> <54EF3616.4040704@acm.org> <54FD645B.9000905@acm.org> <5506FC8C.1070501@akamai.com> <550714FF.2020506@jive.com> <913383AAA69FF945B8F946018B75898A366CA5E4@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A366CA5E4@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: Marc Petit-Huguenin , Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.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, 17 Mar 2015 13:06:57 -0000 Le 2015-03-16 22:05, Tirumaleswar Reddy (tireddy) a écrit : >>> +1 for keeping it simple >>> >>> In the TURN context, can the client's inclusion of MI2 be treated as a >>> preference? IOW, SHOULD|MUST the server respond with MI2 if the client >>> sent it? >> >> I think it should be a MUST on both ends. The client MUST send MI2, and >> the server MUST send MI2 if the client sent it. > > The algorithm support can be conveyed in SDP, so the client can pick MI1 or MI2. Any particular reason why adding such complexity would be necessary? Simon From nobody Tue Mar 17 06:16:16 2015 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 5EEE11A049A for ; Tue, 17 Mar 2015 06:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8BJApqnClCEU for ; Tue, 17 Mar 2015 06:16:11 -0700 (PDT) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9E501A0470 for ; Tue, 17 Mar 2015 06:16:10 -0700 (PDT) Received: by qgez64 with SMTP id z64so7179605qge.2 for ; Tue, 17 Mar 2015 06:16:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EHREkj6h5dNLn4RKbPcmC2x4h25tt13hHdvP0P+7PXQ=; b=YDICHOye38oB/evz1H3QcbygeCDl2gRGwCJ1ThCd5LatbYZbxsJeD7ufkabGZkz2GD 1lJ5sc+vvJvbsEfIVzU1vKfc9EwD9hiNNMcSWWOckQcwf/0jbPbXYMUW8DmSMbJMeM5N 6ksjsPy9P6GFlk1GoBmwJ2OsHHJNBtPppIEfmrM4agiWZ/52pHMmNKhq3nnCh/I+1LxJ t4MQOG9hg/xXdN2FQX3Hd1xk0JKMb9I1E4ED3zIAM/o6IVyo+9a3c3Aw4i2UTN6ikhL3 Yfzrh6ICVoxDlYBDA+WJMijkJMoAZZPerh9pwc7PlYmrQU07PW7PfoJonr08D6i7pi/4 Fc5Q== X-Gm-Message-State: ALoCoQmmwz7jFUeHWsAfpOflD9CrdWknwcF779J0G97613ARQHr+WNrHIwjgGLypFIC3CE3kVYLG X-Received: by 10.55.23.210 with SMTP id 79mr72666609qkx.72.1426598170172; Tue, 17 Mar 2015 06:16:10 -0700 (PDT) Received: from [192.168.1.43] (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id f102sm9572685qki.1.2015.03.17.06.16.03 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Mar 2015 06:16:09 -0700 (PDT) Message-ID: <55082912.6020001@jive.com> Date: Tue, 17 Mar 2015 09:16:02 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , Brandon Williams , Martin Thomson , Justin Uberti References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> <54EF3616.4040704@acm.org> <54FD645B.9000905@acm.org> <5506FC8C.1070501@akamai.com> <913383AAA69FF945B8F946018B75898A366CA610@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A366CA610@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: Marc Petit-Huguenin , Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.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, 17 Mar 2015 13:16:12 -0000 Le 2015-03-16 22:12, Tirumaleswar Reddy (tireddy) a écrit : > Why can't the TURN server send the algorithms it supports along with > the 401 error response and the client picks one of the algorithms it > supports (with higher preference for MI2) ? Two reasons: - This would leave us open to a downgrade attack. Unauthenticated information about the server not supporting MI2 cannot be trusted by the client. - There's no reason to have any kind of "preference". If the server supports MI2, the client MUST use MI2. (Well I guess you could call that "preference", but we need to be clear.) Simon From nobody Tue Mar 17 06:25:41 2015 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 2343B1A0A6A for ; Tue, 17 Mar 2015 06:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 KkSPnCmz6Nfn for ; Tue, 17 Mar 2015 06:25:33 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 701C11A0AF8 for ; Tue, 17 Mar 2015 06:25:31 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A2A5247659; Tue, 17 Mar 2015 13:25:30 +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 8AE5947658; Tue, 17 Mar 2015 13:25:30 +0000 (GMT) Received: from [172.28.115.172] (unknown [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 82A7180051; Tue, 17 Mar 2015 13:25:30 +0000 (GMT) Message-ID: <55082B4A.5010302@akamai.com> Date: Tue, 17 Mar 2015 09:25:30 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , Martin Thomson , Justin Uberti References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> <54EF3616.4040704@acm.org> <54FD645B.9000905@acm.org> <5506FC8C.1070501@akamai.com> <913383AAA69FF945B8F946018B75898A366CA610@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A366CA610@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Marc Petit-Huguenin , Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.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, 17 Mar 2015 13:25:41 -0000 On 03/16/2015 10:12 PM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams >> Sent: Monday, March 16, 2015 9:24 PM >> To: Martin Thomson; Justin Uberti >> Cc: Marc Petit-Huguenin; Oleg Moskalenko; tram@ietf.org >> Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.txt >> >> +1 for keeping it simple >> >> In the TURN context, can the client's inclusion of MI2 be treated as a >> preference? IOW, SHOULD|MUST the server respond with MI2 if the client sent >> it ? > > Why can't the TURN server send the algorithms it supports along with the 401 error response and the client picks one of the algorithms it supports (with higher preference for MI2) ? If the server understands MI2, then it must by definition support SHA256. It's not a question of whether it supports SHA256, but rather of whether it should follow the client's preference. If the client prefers not to use SHA256, it just won't send MI2. --Brandon > > -Tiru > >> >> On a related note, the current section 15.3 text indicates that the client will >> always send both MI and MI2 in its requests and indications. >> Is it OK for the client to stop sending both for a specific session after the first >> response from the server, which will contain only one or the other? >> >> With the lack of explicit negotiation, I think either stunbis or 3rd party auth >> needs to define what the OAuth server and client should do to support transition >> to SHA256. I think it's probably as simple as: >> * OAuth server produces a key big enough for SHA256 >> * client always produces both MI and MI2, using the standard mechanism to >> reduce the SHA256 key for use in SHA1. >> * the relay server picks MI or MI2 as it normally would. >> >> Alternatively, the 3rd party auth draft could simply require that all three parties >> support SHA256 and require the client to only send MI2. >> That would be simpler, but would not allow SHA1 for clients/servers that wish to >> use it, so I think it can probably be ruled out. >> >> --Brandon >> >> On 03/14/2015 09:19 PM, Martin Thomson wrote: >>> I agree with Justin&Marc. Negotiation is too much. >>> >>> It might be nice to signal a preference for sha256, to allow dropping >>> the sha1. maybe in a=ice-options (once we dispense with aggressive >>> nomination perhaps). But the extra bytes aren't going to hurt that much. >>> >>> On Mar 12, 2015 2:26 PM, "Justin Uberti" >> > wrote: >>> >>> >>> >>> On Mon, Mar 9, 2015 at 2:14 AM, Marc Petit-Huguenin >>> > wrote: >>> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA256 >>> >>> On 02/26/2015 09:56 AM, Oleg Moskalenko wrote: >>> > On Thu, Feb 26, 2015 at 7:04 AM, Marc Petit-Huguenin >>> > wrote: >>> > >>> >>> There is a well-defined association between the hash length >>> and the >>> >>> algorithm. SHA-1 produce 20 bytes, SHA-256 produce 32 >>> bytes, SHA-384 >>> >>> produce 48 bytes and SHA-512 produce 64 bytes. Why we >>> cannot use the >>> >>> MESSAGE-INTEGRITY length to determine the algorithm that >>> the peer is >>> >>> using ? >>> >> >>> >> Does not work with SHA-3. >>> >> >>> > >>> > If there is a requirement to support wide multiplicity of >>> algorithms, >>> > even SHA-3, then I see two clear choices: >>> > >>> > 1) Leave the algorithm negotiation to the out-of-bound >>> communication >>> > channel between the client and the server. They can negotiate >>> what >>> > kind of hash is used, and what is the size of the >>> MESSAGE-INTEGRITY to >>> > be. >>> > 2) Implement a usual negotiation scheme, like in TLS. We can >>> introduce >>> > a new attribute that contains "algorithm ID" and optionally >>> "algorithm >>> > attribute(s)" (specific to algorithm). The client sends a >>> number of >>> > supported algorithm attributes to the server, server either >>> rejects or >>> > picks one and sends back authenticated response with the chosen >>> > algorithm attribute. If no attribute is included in the client or >>> > server message, that means default "SHA-1, 160 bits". If a >>> variable >>> > length hash algorithm chosen, then that's fine, the message >>> recipient >>> > will just use the MESSAGE-INTEGRITY attribute length (given they >>> > already agree on a particular algorithm). >>> > >>> > I'd vote for the second approach. That way, we introduce no extra >>> > round trips, we cover multiple algorithms (including the >>> future ones), >>> > and we have full backward compatibility. >>> >>> We do not vote here. You will have to build a consensus for >>> your solution of choice, and as co-editor I will modify the >>> draft to follow this consensus. >>> >>> As an individual, I support neither of the solutions you >>> proposed for the following reasons: >>> >>> - - HMAC-SHA is not broken but going to HMAC-SHA256 is a >>> cautious step I (reluctantly) agree with. >>> - - Negotiation is more often used to decrease security than to >>> increase it so let's not unless we have no choice (as for the >>> password hash, that is broken). >>> - - Adding negotiation means that short-term authentication may >>> get an additional round-trip for each ICE's connectivity check. >>> - - The solution proposed in the draft follows what the authors >>> of RFC 5389 suggested in section 16.3. >>> >>> >>> MESSAGE-INTEGRITY is not a critical part of the overall application >>> security. +1 to keeping it simple. >>> >>> _______________________________________________ >>> 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. >> >> _______________________________________________ >> 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 Tue Mar 17 07:12:15 2015 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 25E591A1A63 for ; Tue, 17 Mar 2015 07:12:14 -0700 (PDT) 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 ZNboA9L8v6OI for ; Tue, 17 Mar 2015 07:12:07 -0700 (PDT) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E834F1A03A3 for ; Tue, 17 Mar 2015 07:11:58 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id im6so2401639vcb.4 for ; Tue, 17 Mar 2015 07:11:58 -0700 (PDT) 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=AiOF3dapE/zSHzCH7rA0HJlcwhFfimP5W7pI65yvTaY=; b=t2w4y2hVOVi3hNEBWo3y2mI80dXu9gwZxdHIsiD7xFnp7uopWYx8uUceSUv6Q14HkG 1u+ZbKdgLAkLPp5qH666j+egYHRSQzkTVJYAYssiheBW2DSw2x/9Sv9eqSOh1MWCfMea klVm6uXRVfIsJCuvWRgVBgAyAkhsUvDXkr6H0f+e9EnB17u2KDGhSORkIdXjEeh1uXYZ SgprTS2eS+1Ud2vMtrF13c6BKEx9Qap/pOopxVsBWERII5xOHnQ4W1/2tWDxTXKoTTjB ycUEJderZnX3nIYwTRymP6IWgrC8NzhB5IdgXv6jtNE/3QEI7N4vWQ+2+zw/FOedHmrZ IFqA== MIME-Version: 1.0 X-Received: by 10.52.7.228 with SMTP id m4mr69935901vda.31.1426601518100; Tue, 17 Mar 2015 07:11:58 -0700 (PDT) Received: by 10.52.121.111 with HTTP; Tue, 17 Mar 2015 07:11:58 -0700 (PDT) Date: Tue, 17 Mar 2015 09:11:58 -0500 Message-ID: From: Alan Johnston To: "tram@ietf.org" Content-Type: multipart/alternative; boundary=20cf3033449db8f60d05117c8c7d Archived-At: Subject: [tram] Comments on draft-ietf-tram-stun-bis-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: Tue, 17 Mar 2015 14:12:14 -0000 --20cf3033449db8f60d05117c8c7d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable All, Here are some comments on STUNbis. Minor comments are listed below, but the most important one is listed here: Does the use of salted SHA256 for passwords match up with what is planned for SIP? See: https://tools.ietf.org/html/draft-yusef-sipcore-digest-scheme Does H(A1) match up? Also, I'm not aware if this draft is moving forward: https://tools.ietf.org/html/draft-veltri-sip-alt-auth while the other one is under active discussion in SIPCORE and HTTPAUTH - see https://tools.ietf.org/html/draft-ietf-httpauth-digest-update I think it is important that STUNbis is aligned with the changes to digest being worked on in SIP and HTTP. - Alan - Shouldn't STUNbis reference ICEbis instead of ICE? I presume "obMatJos2" is just a random string used to indicate support for STUNbis - it might be worth stating this in 9.2.3. Section 11 Backwards Compatibility with RFC 3489: do we really need to still be backwards compatible? Is anyone still using RFC 3489 that hasn't upgraded? Do we leave ourselves open to any downgrade attacks by doing so? Section 14 says only first of multiple attributes are processed. (=E2=80=9C= Any attribute type MAY appear more than once in a STUN message. Unless specified otherwise, the order of appearance is significant: only the first occurrence needs to be processed by a receiver, and any duplicates MAY be ignored by a receiver.=E2=80=9D) I guess this rules out multiple ORIGIN attributes, which is fine since we had chosen that path forward. However, this means that no future STUN attributes can really appear more than once. Do we need to emphasize this more? In Section 14.2 what are the x's in |x x x x x x x x|? The text in Section 15.3. Hash Agility Plan seems to be out of date now. Section 17.5 says =E2=80=9CThe UDP port is not currently defined; however, = it is reserved for future use.=E2=80=9D What port? The change log says that STUNbis normatively references draft-ietf-tram-stun-origin, but I don't see it listed in the references. Perhaps a mention of ORIGIN in section 9.2 or 9.2.3 would be good, too. --20cf3033449db8f60d05117c8c7d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

Here are some comments on STUNbis.= =C2=A0 Minor comments are listed below, but the most important one is liste= d here:

Does the use of salted SHA256 for password= s match up with what is planned for SIP?=C2=A0 See:

=C2=A0 =C2=A0 https://tools.ietf.org/html/draft-yusef-sipcore-digest-schem= e=C2=A0

Does H(A1) match up?=C2=A0 Also, I'= ;m not aware if this draft is moving forward:


while the other one is under active discussion in SIPCORE a= nd HTTPAUTH - see=C2=A0https://tools.ietf.org/html/draft-ietf-httpauth-diges= t-update=C2=A0

I think it is important tha= t STUNbis is aligned with the changes to digest being worked on in SIP and = HTTP.

- Alan -

Shouldn= 9;t STUNbis reference ICEbis instead of ICE?

I= presume "obMatJos2" is just a random string used to indicate sup= port for STUNbis - it might be worth stating this in 9.2.3.
<= br>
Section 11 Backwards Compatibility with RFC 3489: do we = really need to still be backwards compatible?=C2=A0 Is anyone still using R= FC 3489 that hasn't upgraded?=C2=A0 Do we leave ourselves open to any d= owngrade attacks by doing so?

Section 14 says only= first of multiple attributes are processed. (=E2=80=9CAny attribute type M= AY appear more than once in a STUN message. Unless specified otherwise, the= order of appearance is significant: only the first occurrence needs to be = processed by a receiver, and any duplicates MAY be ignored by a receiver.= =E2=80=9D) =C2=A0I guess this rules out multiple ORIGIN attributes, which i= s fine since we had chosen that path forward.=C2=A0 However, this means tha= t no future STUN attributes can really appear more than once.=C2=A0 Do we n= eed to emphasize this more?

In Section 14.2 what a= re the x's in =C2=A0 |x x x x x x x x|?

The te= xt in Section 15.3. Hash Agility Plan seems to be out of date now.

Section 17.5 says =E2=80=9CThe UDP port is not currently d= efined; however, it is reserved for future use.=E2=80=9D =C2=A0What port?

The change log says that STUNbis normatively = references draft-ietf-tram-stun-origin, but I don't see it listed in th= e references.=C2=A0 Perhaps a mention of ORIGIN in section 9.2 or 9.2.3 wou= ld be good, too.
--20cf3033449db8f60d05117c8c7d-- From nobody Tue Mar 17 07:51:11 2015 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 25CC41A1B1C for ; Tue, 17 Mar 2015 07:51:02 -0700 (PDT) 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 viKtC0IIaCp8 for ; Tue, 17 Mar 2015 07:50:55 -0700 (PDT) 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 1BB161A1AE8 for ; Tue, 17 Mar 2015 07:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1232; q=dns/txt; s=iport; t=1426603855; x=1427813455; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=dbc1rmHf8FFag4YBD0BPSz810CUdNitFM8/jnA3yqbw=; b=iBOl8Z2/LepAEJkgRCU+ClDVhXLija5E5k/Jay2evXBKulXXy1IrRlxz vf2GfNgidBnxOQdLoP1hpozJvgn3nrK3hgft4Y1yy2LgTC0QFti0BoyId Jfmtpl7LIv8cfORYfvdwJiHlncKkzFXP7KPHZVCVm7DYJeJBuaaQO3bxR 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DCBwDZPghV/5NdJa1bgwaBLATDQIgtAoE1TAEBAQEBAX2EDwEBAQMBeQwEAgEIDgMEAQELHQcyFAkIAgQBDQUIiB8IyjEBAQEBAQEBAQEBAQEBAQEBAQEBAQEXixeEQDEHBoMRgRYBBIpXg12CCp4DI4Nub4ECBzt/AQEB X-IronPort-AV: E=Sophos;i="5.11,416,1422921600"; d="scan'208";a="132749987" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-1.cisco.com with ESMTP; 17 Mar 2015 14:50:54 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t2HEosR8013733 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Mar 2015 14:50:54 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.80]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Tue, 17 Mar 2015 09:50:53 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault , Brandon Williams , Martin Thomson , Justin Uberti Thread-Topic: [tram] I-D Action: draft-ietf-tram-stunbis-01.txt Thread-Index: AQHQSs9eowAbQmERAkOzA1uv2nxY/J0CL+wAgAFKMQCAAB8jAIAQt7iAgAWDXYCAA2YIgIAChp0AgABX/wCAAQ5CAP//xUUQ Date: Tue, 17 Mar 2015 14:50:52 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A366CAE85@xmb-rcd-x10.cisco.com> References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> <54EF3616.4040704@acm.org> <54FD645B.9000905@acm.org> <5506FC8C.1070501@akamai.com> <913383AAA69FF945B8F946018B75898A366CA610@xmb-rcd-x10.cisco.com> <55082912.6020001@jive.com> In-Reply-To: <55082912.6020001@jive.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.41.27] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Marc Petit-Huguenin , Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.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, 17 Mar 2015 14:51:02 -0000 > -----Original Message----- > From: Simon Perreault [mailto:sperreault@jive.com] > Sent: Tuesday, March 17, 2015 6:46 PM > To: Tirumaleswar Reddy (tireddy); Brandon Williams; Martin Thomson; Justi= n > Uberti > Cc: Marc Petit-Huguenin; Oleg Moskalenko; tram@ietf.org > Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.txt >=20 > Le 2015-03-16 22:12, Tirumaleswar Reddy (tireddy) a =E9crit : > > Why can't the TURN server send the algorithms it supports along with > > the 401 error response and the client picks one of the algorithms it > > supports (with higher preference for MI2) ? >=20 > Two reasons: >=20 > - This would leave us open to a downgrade attack. Unauthenticated informa= tion > about the server not supporting MI2 cannot be trusted by the client. Client signals back the algorithms received from the server. Server checks = the algorithms conveyed by the client matches the set it had initially sent= to detect algorithm downgrade attack. >=20 > - There's no reason to have any kind of "preference". If the server suppo= rts MI2, > the client MUST use MI2. (Well I guess you could call that "preference", = but we > need to be clear.) Agreed. -Tiru >=20 > Simon From nobody Tue Mar 17 07:59:37 2015 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 6E7441A1B22 for ; Tue, 17 Mar 2015 07:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_64=0.6, 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 PtAY7LLUBR6o for ; Tue, 17 Mar 2015 07:59:34 -0700 (PDT) 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 193DC1A1B17 for ; Tue, 17 Mar 2015 07:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1167; q=dns/txt; s=iport; t=1426604374; x=1427813974; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=h6rat7DiorZ6WUx6dv7FmHNoSwATogK2qQdZfFNQC+A=; b=k7wqy/T6eL9TLY8FIre4WZNsuq/48u7NjmGQUURONsppwG45mL1jBSB0 SQkQviHgH9bFFYCqwJuzLywRngRfnxTYONi1KADmXuLwq6jYhLE0j0G0R mMtb4AkpZukHwcivH70E7h6mk95byY2sPqBNfBU3aW8smSyqVgoT8Bfo1 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DCBwDRQAhV/5BdJa1bgwaBLATDQIgtAoE2TAEBAQEBAX2EDwEBAQMBeQwEAgEIDgMEAQELHQcyFAkIAgQBDQUIiB8IyjABAQEBAQEBAQEBAQEBAQEBAQEBAQEXixeEQDEHBoMRgRYBBIpXhWeeAyODbm+BBCQcfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,416,1422921600"; d="scan'208";a="132810131" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-4.cisco.com with ESMTP; 17 Mar 2015 14:59:33 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t2HExXxD028380 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Mar 2015 14:59:33 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.80]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Tue, 17 Mar 2015 09:59:32 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault , Brandon Williams , Martin Thomson , Justin Uberti Thread-Topic: [tram] I-D Action: draft-ietf-tram-stunbis-01.txt Thread-Index: AQHQSs9eowAbQmERAkOzA1uv2nxY/J0CL+wAgAFKMQCAAB8jAIAQt7iAgAWDXYCAA2YIgIAChp0AgAAdJYCAADjW8IABDa8A///JvqA= Date: Tue, 17 Mar 2015 14:59:32 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A366CAEA5@xmb-rcd-x10.cisco.com> References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> <54EF3616.4040704@acm.org> <54FD645B.9000905@acm.org> <5506FC8C.1070501@akamai.com> <550714FF.2020506@jive.com> <913383AAA69FF945B8F946018B75898A366CA5E4@xmb-rcd-x10.cisco.com> <550826E6.90101@jive.com> In-Reply-To: <550826E6.90101@jive.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.41.27] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Marc Petit-Huguenin , Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.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, 17 Mar 2015 14:59:35 -0000 > -----Original Message----- > From: Simon Perreault [mailto:sperreault@jive.com] > Sent: Tuesday, March 17, 2015 6:37 PM > To: Tirumaleswar Reddy (tireddy); Brandon Williams; Martin Thomson; Justi= n > Uberti > Cc: Marc Petit-Huguenin; Oleg Moskalenko; tram@ietf.org > Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.txt >=20 > Le 2015-03-16 22:05, Tirumaleswar Reddy (tireddy) a =E9crit : > >>> +1 for keeping it simple > >>> > >>> In the TURN context, can the client's inclusion of MI2 be treated as > >>> a preference? IOW, SHOULD|MUST the server respond with MI2 if the > >>> client sent it? > >> > >> I think it should be a MUST on both ends. The client MUST send MI2, > >> and the server MUST send MI2 if the client sent it. > > > > The algorithm support can be conveyed in SDP, so the client can pick MI= 1 or > MI2. >=20 > Any particular reason why adding such complexity would be necessary ? It is not complex compared to the client and server logic to deal with both= MI1 and M12 for every message, handling error cases like validation of MI1= succeeds but MI2 fails or vice-versa etc. -Tiru >=20 > Simon From nobody Tue Mar 17 08:19:24 2015 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 2CB581A1C04 for ; Tue, 17 Mar 2015 08:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9smP1wq_daRo for ; Tue, 17 Mar 2015 08:19:15 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C2131A1BFC for ; Tue, 17 Mar 2015 08:19:15 -0700 (PDT) Received: by qcyi15 with SMTP id i15so11462550qcy.0 for ; Tue, 17 Mar 2015 08:19:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0KNZMexEK6yNZNaC+b1m0wLZW0SwkeZWOV4nSf6PCdI=; b=LrpEhCYgoYd4MwDCGG+Zwf5pOQMY3VohcxqpyNXGxvmnbeWVnxhntK4sxln4mj83Sk OEven8IkLgwwKEmRuDtlWfeXVJuF6QXtIdyn1IDDHw+hZNZDaj4LU4D7G1iXq+hfmGRb YKB2GI9Cfi+LqwJyB2siud9lRZPRNDUPQAcEPiUshvtcNR77u8a/yVjHRZQQ3f8aNUiP t98ohBUhgK65BcB5it4hAgOVcp0vBAVQnBfH0wIKjxh1JbpueZHKuWfk8/asxBFUoDH2 bAFVt07rqzteKzTG67VQHfb3jTlDL92z/3SR+TwlH++2i8QjJdwPzty3awCD09AmJ7En B90Q== X-Gm-Message-State: ALoCoQmd2pHaVxDawxJZIn1jVKYs/LYm1kkJpo59Gz9y38zlKHXwbm4bospoQwkEY+7mpGwu8QQO X-Received: by 10.140.202.209 with SMTP id x200mr73731054qha.44.1426605554449; Tue, 17 Mar 2015 08:19:14 -0700 (PDT) Received: from [192.168.1.43] (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id g34sm9850533qgd.0.2015.03.17.08.19.12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Mar 2015 08:19:13 -0700 (PDT) Message-ID: <550845EF.7060908@jive.com> Date: Tue, 17 Mar 2015 11:19:11 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , Brandon Williams , Martin Thomson , Justin Uberti References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> <54EF3616.4040704@acm.org> <54FD645B.9000905@acm.org> <5506FC8C.1070501@akamai.com> <913383AAA69FF945B8F946018B75898A366CA610@xmb-rcd-x10.cisco.com> <55082912.6020001@jive.com> <913383AAA69FF945B8F946018B75898A366CAE85@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A366CAE85@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: Marc Petit-Huguenin , Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.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, 17 Mar 2015 15:19:23 -0000 Le 2015-03-17 10:50, Tirumaleswar Reddy (tireddy) a écrit : >>> Why can't the TURN server send the algorithms it supports along with >>> the 401 error response and the client picks one of the algorithms it >>> supports (with higher preference for MI2) ? >> >> Two reasons: >> >> - This would leave us open to a downgrade attack. Unauthenticated information >> about the server not supporting MI2 cannot be trusted by the client. > > Client signals back the algorithms received from the server. Server checks the algorithms conveyed by the client matches the set it had initially sent to detect algorithm downgrade attack. Not backwards compatible with current TURN clients. In summary, I think there are three possibilities: a) We accept downgrade attacks as a fact of life. Use whatever works. b) We give up backwards compatibility and always use MI2 without fallback to MI. c) We signal support for MI2 in a separate channel (e.g., SDP). Simon From nobody Tue Mar 17 09:15:42 2015 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 BCE5D1A872A for ; Tue, 17 Mar 2015 09:15:40 -0700 (PDT) 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 vWmXnaauiWGp for ; Tue, 17 Mar 2015 09:15:39 -0700 (PDT) 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 3DED21A8723 for ; Tue, 17 Mar 2015 09:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1599; q=dns/txt; s=iport; t=1426608939; x=1427818539; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+xCnWVkTf3EsGKFfscq2fLGNWiF1sYGhwXbgUiteD20=; b=I+GtCRb6RuZvLLIsjy6GSpRQG3jov56i8rsJiRL3cT8b18HqGPSAuRR8 oPt+Jo8JP6ioty4m1g8js7tMZ0tZMM0Kk/0PIcl/oRqmzGBquFjThmNlD FzaBC2++qCyHBL2RtDWESTPmO+g8nLWAajDuVWpeMWJg1j9ELjBSMPq+C Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DCBwC3UghV/49dJa1bgwaBLATDQ4gtAoE7TAEBAQEBAX2EDwEBAQMBeQwEAgEIDgMEAQELHQcyFAkIAgQBDQUIEYgOCMpZAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sXhEAxBwaDEYEWAQSKV4VnngMjg25vgQIHO38BAQE X-IronPort-AV: E=Sophos;i="5.11,417,1422921600"; d="scan'208";a="404353625" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-5.cisco.com with ESMTP; 17 Mar 2015 16:15:38 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t2HGFcPE015087 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Mar 2015 16:15:38 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.80]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Tue, 17 Mar 2015 11:15:38 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault , Brandon Williams , Martin Thomson , Justin Uberti Thread-Topic: [tram] I-D Action: draft-ietf-tram-stunbis-01.txt Thread-Index: AQHQSs9eowAbQmERAkOzA1uv2nxY/J0CL+wAgAFKMQCAAB8jAIAQt7iAgAWDXYCAA2YIgIAChp0AgABX/wCAAQ5CAP//xUUQgABdI4D//7o4sA== Date: Tue, 17 Mar 2015 16:15:37 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A366CAF33@xmb-rcd-x10.cisco.com> References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> <54EF3616.4040704@acm.org> <54FD645B.9000905@acm.org> <5506FC8C.1070501@akamai.com> <913383AAA69FF945B8F946018B75898A366CA610@xmb-rcd-x10.cisco.com> <55082912.6020001@jive.com> <913383AAA69FF945B8F946018B75898A366CAE85@xmb-rcd-x10.cisco.com> <550845EF.7060908@jive.com> In-Reply-To: <550845EF.7060908@jive.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.41.27] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Marc Petit-Huguenin , Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.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, 17 Mar 2015 16:15:40 -0000 > -----Original Message----- > From: Simon Perreault [mailto:sperreault@jive.com] > Sent: Tuesday, March 17, 2015 8:49 PM > To: Tirumaleswar Reddy (tireddy); Brandon Williams; Martin Thomson; Justi= n > Uberti > Cc: Marc Petit-Huguenin; Oleg Moskalenko; tram@ietf.org > Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.txt >=20 > Le 2015-03-17 10:50, Tirumaleswar Reddy (tireddy) a =E9crit : > >>> Why can't the TURN server send the algorithms it supports along with > >>> the 401 error response and the client picks one of the algorithms it > >>> supports (with higher preference for MI2) ? > >> > >> Two reasons: > >> > >> - This would leave us open to a downgrade attack. Unauthenticated > >> information about the server not supporting MI2 cannot be trusted by t= he > client. > > > > Client signals back the algorithms received from the server. Server che= cks the > algorithms conveyed by the client matches the set it had initially sent t= o detect > algorithm downgrade attack. >=20 > Not backwards compatible with current TURN clients. >=20 > In summary, I think there are three possibilities: >=20 > a) We accept downgrade attacks as a fact of life. Use whatever works. MIM device can cause downgrade attack even by removing MI2 and thus force t= he client/server to use MI1. Downgrade attacks can be mitigated either usin= g (D)TLS or option c). -Tiru >=20 > b) We give up backwards compatibility and always use MI2 without fallback= to > MI. >=20 > c) We signal support for MI2 in a separate channel (e.g., SDP). >=20 > Simon From nobody Tue Mar 17 09:21:30 2015 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 834801A872D for ; Tue, 17 Mar 2015 09:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Tl9gQgw__5SK for ; Tue, 17 Mar 2015 09:21:28 -0700 (PDT) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E92D1A8752 for ; Tue, 17 Mar 2015 09:21:28 -0700 (PDT) Received: by obdfc2 with SMTP id fc2so11270155obd.3 for ; Tue, 17 Mar 2015 09:21:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BL2jB3k4Zwr5ook6BTzuyzvdHWhekb1/1QCjgnX9kng=; b=P01nkMDRvvdbaDEmLOEEsB0wZY6PPdldE49Zws362/T5vY7IxYescif2sNLfFF/paY lh/jQOQxat2HXM1OYZkr8aEns5LB88igWdIwwKV7zhH0GncGM4YeB5IeZH+b235Yiy/5 8y2421Ql4W6mnnvYZMiGTFGY5gfaMJoVy2NSxiLDqZRkFADXJfbnkEOLXT2kpZ9D/73o DNj3u1MhobUcaKziRAggx6zlrm0oko/7bmovKVzvCr7wjNjSYMHQn5vTzpNFwpQ7rLfU uv4XHe5KE4BdBqL+kmnRLUD30MZokCZ4+iNeQkT8w6MV/nwgXmpolXspossNCYShJCKH aAWw== X-Gm-Message-State: ALoCoQmFzHoppdFp0vCaiXjjeAI2ChYwdODbMh7KkbCD9cc6APats3Owje+7G0FtwQ66Krp4ZJnv X-Received: by 10.60.57.9 with SMTP id e9mr27113257oeq.24.1426609287656; Tue, 17 Mar 2015 09:21:27 -0700 (PDT) Received: from [192.168.1.43] (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id q2sm9353774obq.14.2015.03.17.09.21.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Mar 2015 09:21:26 -0700 (PDT) Message-ID: <55085484.4030906@jive.com> Date: Tue, 17 Mar 2015 12:21:24 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , Brandon Williams , Martin Thomson , Justin Uberti References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> <54EF3616.4040704@acm.org> <54FD645B.9000905@acm.org> <5506FC8C.1070501@akamai.com> <913383AAA69FF945B8F946018B75898A366CA610@xmb-rcd-x10.cisco.com> <55082912.6020001@jive.com> <913383AAA69FF945B8F946018B75898A366CAE85@xmb-rcd-x10.cisco.com> <550845EF.7060908@jive.com> <913383AAA69FF945B8F946018B75898A366CAF33@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A366CAF33@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: Marc Petit-Huguenin , Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.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, 17 Mar 2015 16:21:29 -0000 Le 2015-03-17 12:15, Tirumaleswar Reddy (tireddy) a écrit : >> a) We accept downgrade attacks as a fact of life. Use whatever works. > MIM device can cause downgrade attack even by removing MI2 and thus force the client/server to use MI1. Downgrade attacks can be mitigated either using (D)TLS or option c). I know what you mean, but just to be clear: - Option b) implies that that the server refuses to process requests without MI2 so there can't be a downgrade attack. - Option c) gives SDP as an example, but DTLS would also be considered a "separate channel". Simon >> > b) We give up backwards compatibility and always use MI2 without fallback to >> > MI. >> > >> > c) We signal support for MI2 in a separate channel (e.g., SDP). From nobody Tue Mar 17 09:26:27 2015 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 5279C1A8767 for ; Tue, 17 Mar 2015 09:26:25 -0700 (PDT) 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 glWB_sFUvM6C for ; Tue, 17 Mar 2015 09:26:18 -0700 (PDT) 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 017681A872C for ; Tue, 17 Mar 2015 09:26:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1369; q=dns/txt; s=iport; t=1426609578; x=1427819178; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wCo9MymQNSFc9iGh3avwYXC2NgEdiIB1ue2ib51TlfE=; b=dZRK0h6L7zm58V/+IrUOtUX+Z2Xn2TO40ynYJ7MOpJjpSxoxYWxWbp4V fBuMWp1Y6BBpsqH1XIF8NSYotRqDuOxvm29JisK7VfGZkYtEi50+Nzysr lNmECMnDZSSQyK4Jlgzcv5qW7lUFCwP5kjdw/wQdQwSaL/on68JG0O033 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DHBwDEVAhV/4YNJK1bgwZSWgTDQ4IuCoV1AoE7TAEBAQEBAX2EDwEBAQMBAQEBawsMBAIBCA4DBAEBCx0HJwsUCQgCBAENBQgRiA4IDcpSAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLF4RAMQcGgxGBFgEEileFZ54DI4Nub4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,417,1422921600"; d="scan'208";a="132842180" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-4.cisco.com with ESMTP; 17 Mar 2015 16:26:17 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t2HGQHcx013068 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Mar 2015 16:26:17 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.80]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Tue, 17 Mar 2015 11:26:17 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault , Brandon Williams , Martin Thomson , Justin Uberti Thread-Topic: [tram] I-D Action: draft-ietf-tram-stunbis-01.txt Thread-Index: AQHQSs9eowAbQmERAkOzA1uv2nxY/J0CL+wAgAFKMQCAAB8jAIAQt7iAgAWDXYCAA2YIgIAChp0AgABX/wCAAQ5CAP//xUUQgABdI4D//7o4sIAAVyoA//+tJ3A= Date: Tue, 17 Mar 2015 16:26:16 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A366CAF7E@xmb-rcd-x10.cisco.com> References: <20150217163243.15358.60553.idtracker@ietfa.amsl.com> <54EF3616.4040704@acm.org> <54FD645B.9000905@acm.org> <5506FC8C.1070501@akamai.com> <913383AAA69FF945B8F946018B75898A366CA610@xmb-rcd-x10.cisco.com> <55082912.6020001@jive.com> <913383AAA69FF945B8F946018B75898A366CAE85@xmb-rcd-x10.cisco.com> <550845EF.7060908@jive.com> <913383AAA69FF945B8F946018B75898A366CAF33@xmb-rcd-x10.cisco.com> <55085484.4030906@jive.com> In-Reply-To: <55085484.4030906@jive.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.41.27] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Marc Petit-Huguenin , Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.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, 17 Mar 2015 16:26:25 -0000 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Simon Perreault > Sent: Tuesday, March 17, 2015 9:51 PM > To: Tirumaleswar Reddy (tireddy); Brandon Williams; Martin Thomson; Justi= n > Uberti > Cc: Marc Petit-Huguenin; Oleg Moskalenko; tram@ietf.org > Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.txt >=20 > Le 2015-03-17 12:15, Tirumaleswar Reddy (tireddy) a =E9crit : > >> a) We accept downgrade attacks as a fact of life. Use whatever works. > > MIM device can cause downgrade attack even by removing MI2 and thus for= ce > the client/server to use MI1. Downgrade attacks can be mitigated either u= sing > (D)TLS or option c). >=20 > I know what you mean, but just to be clear: >=20 > - Option b) implies that that the server refuses to process requests with= out MI2 > so there can't be a downgrade attack. >=20 > - Option c) gives SDP as an example, but DTLS would also be considered a > "separate channel". Yes, We are in agreement. -Tiru >=20 > Simon >=20 > >> > b) We give up backwards compatibility and always use MI2 without > >> > fallback to MI. > >> > > >> > c) We signal support for MI2 in a separate channel (e.g., SDP). >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Tue Mar 17 13:30:13 2015 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 8537F1A88E9 for ; Tue, 17 Mar 2015 13:30:12 -0700 (PDT) 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 iAnEMqeJNkBc for ; Tue, 17 Mar 2015 13:30:10 -0700 (PDT) Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F2451A88E7 for ; Tue, 17 Mar 2015 13:30:10 -0700 (PDT) Received: by qgez64 with SMTP id z64so19644285qge.2 for ; Tue, 17 Mar 2015 13:30:09 -0700 (PDT) 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=KMyUi04Bhyl/2r4RRLjGE94kuBOh8oHWXOA3JX8WfUc=; b=GMkgrDjgrIrnW9p3OK/3ylX7vWKgPoZ3N9mEdp46OwYtLFLvZrXAOwh+ntYyZEm4lz 5D2AMobO/TmaTVCq7+1awMPYFB+34zjI8Oihzqyq/U52KoHRojYREBTh9iKb8hwMswuK ZsioO9Z2P8DMws/1adbNPvXtZW21c4PFrIswMtSt5bVinttJWRnF7aMwDfGVL6Pp1uUG SjoE7zyDRBnjaWttr0P2b7bNgF3CB3a6YksYwRBziZ55JqP73iclyhARWEtHmXnvJVbv QM9/AMH6UZIVSa0k9w7gNI9ZRMPzF/pHQgowHQKPzGgWw0xu/Duq7sHUjEJUJeEl6UTH WewQ== X-Gm-Message-State: ALoCoQm3Tlz8P/Y/MFIPxXKI9eJuNQFWMEfEp+lKedh2YKygpsf+r3XVt8ALw9VYvOQM7eaN8iXd X-Received: by 10.55.21.152 with SMTP id 24mr78836913qkv.40.1426624209706; Tue, 17 Mar 2015 13:30:09 -0700 (PDT) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com. [209.85.216.180]) by mx.google.com with ESMTPSA id f125sm10326013qhe.47.2015.03.17.13.30.08 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Mar 2015 13:30:08 -0700 (PDT) Received: by qcyi15 with SMTP id i15so20573821qcy.0 for ; Tue, 17 Mar 2015 13:30:08 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.91.71 with SMTP id y65mr82196531qgd.90.1426624208212; Tue, 17 Mar 2015 13:30:08 -0700 (PDT) Received: by 10.229.140.4 with HTTP; Tue, 17 Mar 2015 13:30:08 -0700 (PDT) In-Reply-To: <54FDD7A0.4010308@jive.com> References: <20150305201507.6192.13143.idtracker@ietfa.amsl.com> <35F68F75-51A0-48BD-B5D0-DE0A6600F13D@vidyo.com> <54FA2954.2060400@jive.com> <54FD8DAB.10807@jive.com> <525817F6-4E8F-4052-BB13-27B1F332756B@vidyo.com> <54FDD7A0.4010308@jive.com> Date: Tue, 17 Mar 2015 16:30:08 -0400 Message-ID: From: Benjamin Schwartz To: Simon Perreault Content-Type: multipart/alternative; boundary=001a113a335e28d7e1051181d5f1 Archived-At: Cc: Jonathan Lennox , "tram@ietf.org" , Justin Uberti Subject: Re: [tram] New Version Notification for draft-schwartz-tram-turnbyname-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, 17 Mar 2015 20:30:12 -0000 --001a113a335e28d7e1051181d5f1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Looks like this didn't get a response. Suppose that the RTT to the TURN server is very low. Then the client will assume the request has failed if it doesn't get a response quickly. Therefore, the client will not be able to connect to names that are even a little bit slow to resolve. In the extreme case (RTT near zero), connection to DNS servers won't work at all. Therefore, we should prefer a design that allows the effective timeout to be independent of RTT. That could work by just specifying a minimum timeout for this request-response, or it could work by choosing a design that uses a different sequence of messages. On Mon, Mar 9, 2015 at 1:25 PM, Simon Perreault wrote= : > Le 2015-03-09 09:59, Jonathan Lennox a =C3=A9crit : > > On Mar 9, 2015, at 8:10 AM, Simon Perreault wrote= : > > > >> > Le 2015-03-06 19:34, Justin Uberti a =C3=A9crit : > >>> >> The problem is that the STUN timeout is on the client, whereas the > DNS > >>> >> timeout is on the server, so the client needs to somehow be aware > of the > >>> >> DNS timeout in its STUN calculations. > >> > > >> > Why? From the client's point of view, the server is just taking > longer than usual to process the request. > >> > > >>> >> Generally I think that we could just say that if DNS doesn't > respond in > >>> >> X seconds (e.g. 5), the server MUST consider the lookup to have > failed > >>> >> and return a 4YY error code. > > According to the STUN spec (section 7.2.1 in RFC 5389, 6.2.1 in the > stun-bis draft), over unreliable channels, a STUN client will consider a > transaction to have failed if it gets no response after > (2^(Rc-1)-1+Rm)*RTT, i.e. 79*RTT for the default values of Rc (7) and Rm > (16). For short RTTs (between the client and the TURN server) that=E2=80= =99ll > likely be shorter than the DNS timeout. > > So what? Why does DNS timeout need to be shorter than STUN timeout? > > Simon > --001a113a335e28d7e1051181d5f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Looks like this didn't get a response.

<= div>Suppose that the RTT to the TURN server is very low.=C2=A0 Then the cli= ent will assume the request has failed if it doesn't get a response qui= ckly.=C2=A0 Therefore, the client will not be able to connect to names that= are even a little bit slow to resolve.=C2=A0 In the extreme case (RTT near= zero), connection to DNS servers won't work at all.

Therefore, we should prefer a design that allows the effective timeo= ut to be independent of RTT.=C2=A0 That could work by just specifying a min= imum timeout for this request-response, or it could work by choosing a desi= gn that uses a different sequence of messages.

On Mon, Mar 9, 2015 at 1:25 PM, Si= mon Perreault <sperreault@jive.com> wrote:
Le 2015-03-09 09:59, Jonathan Lennox a =C3=A9crit :
> On Mar 9, 2015, at 8:10 AM, Simon Perreault <sperreault@jive.com> wrote:
>
>> > Le 2015-03-06 19:34, Justin Uberti a =C3=A9crit :
>>> >> The problem is that the STUN timeout is on the client= , whereas the DNS
>>> >> timeout is on the server, so the client needs to some= how be aware of the
>>> >> DNS timeout in its STUN calculations.
>> >
>> > Why? From the client's point of view, the server is just = taking longer than usual to process the request.
>> >
>>> >> Generally I think that we could just say that if DNS = doesn't respond in
>>> >> X seconds (e.g. 5), the server MUST consider the look= up to have failed
>>> >> and return a 4YY error code.
> According to the STUN spec (section 7.2.1 in RFC 5389, 6.2.1 in the st= un-bis draft), over unreliable channels, a STUN client will consider a tran= saction to have failed if it gets no response after (2^(Rc-1)-1+Rm)*RTT, i.= e. 79*RTT for the default values of Rc (7) and Rm (16).=C2=A0 For short RTT= s (between the client and the TURN server) that=E2=80=99ll likely be shorte= r than the DNS timeout.

So what? Why does DNS timeout need to be shorter than STUN timeout?<= br>
Simon

--001a113a335e28d7e1051181d5f1-- From nobody Tue Mar 17 13:58:47 2015 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 1176F1A88EA for ; Tue, 17 Mar 2015 13:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 bu5RMuKR9tvF for ; Tue, 17 Mar 2015 13:58:43 -0700 (PDT) Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFE3F1A88E7 for ; Tue, 17 Mar 2015 13:58:43 -0700 (PDT) Received: by obbgg8 with SMTP id gg8so17464029obb.1 for ; Tue, 17 Mar 2015 13:58:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=S77Nn6xXJD3LLubvimc2V5bn1s2CRF6zrfhfhzb1j68=; b=BenNQcBLwKRH8AFlRk2Aigq6+OPUB0SYSHPsDX6r9y8RJRioA50lJ8WBP4uSfXylUg N7WO/dq2RayAuBiW3VJE0ZueCZQWXjXzO0y1w6H1039RC4txwPVqhchYsUG60EYuwSKt 04hdtVeGxEEQ1xyWxu13dRMLMvijJ7NpR2NyxWIZltP2+taVaw43Q/EXRg4z5APqD7hb tE5vX5Cbk2BtO82W8AmFbMhZdzV+LrHk27kpmTB9MQe+qIoKToxbZxdx/QGcKjYEwhpP 8i+ShekXyx1225JP+H3p8fTZQXLq9LbR4Sv4/DJwPypEVlCw9XSGu4GZZoMuiapz5ff9 4dIQ== X-Gm-Message-State: ALoCoQlBmbORBTlbjmuJiSBnFipVCMeUGv9WTVoC3ehRQlPGNxlc4TekemSfr705C4rmjazXkrUy X-Received: by 10.202.203.6 with SMTP id b6mr9288640oig.82.1426625923212; Tue, 17 Mar 2015 13:58:43 -0700 (PDT) Received: from Simons-MacBook-Air.local (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id iy5sm9822859obb.19.2015.03.17.13.58.41 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Mar 2015 13:58:42 -0700 (PDT) Message-ID: <55089580.3000803@jive.com> Date: Tue, 17 Mar 2015 16:58:40 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Benjamin Schwartz References: <20150305201507.6192.13143.idtracker@ietfa.amsl.com> <35F68F75-51A0-48BD-B5D0-DE0A6600F13D@vidyo.com> <54FA2954.2060400@jive.com> <54FD8DAB.10807@jive.com> <525817F6-4E8F-4052-BB13-27B1F332756B@vidyo.com> <54FDD7A0.4010308@jive.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Jonathan Lennox , "tram@ietf.org" , Justin Uberti Subject: Re: [tram] New Version Notification for draft-schwartz-tram-turnbyname-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, 17 Mar 2015 20:58:45 -0000 Le 2015-03-17 16:30, Benjamin Schwartz a écrit : > Looks like this didn't get a response. Thanks *a lot* for responding! > Suppose that the RTT to the TURN server is very low. Then the client > will assume the request has failed if it doesn't get a response > quickly. Therefore, the client will not be able to connect to names > that are even a little bit slow to resolve. In the extreme case (RTT > near zero), connection to DNS servers won't work at all. Understood! > Therefore, we should prefer a design that allows the effective timeout > to be independent of RTT. That could work by just specifying a minimum > timeout for this request-response, or it could work by choosing a design > that uses a different sequence of messages. Makes total sense! Thanks again, Simon From nobody Tue Mar 17 16:59:59 2015 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 CD2741A1BDE for ; Tue, 17 Mar 2015 16:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jbMido6F1ON5 for ; Tue, 17 Mar 2015 16:59:57 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A92981A1B96 for ; Tue, 17 Mar 2015 16:59:57 -0700 (PDT) Received: by iecvj10 with SMTP id vj10so25805678iec.0 for ; Tue, 17 Mar 2015 16:59:57 -0700 (PDT) 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=USMs//dNvAKSD6YNwUG8bRsv4d4OEP1PrFmCV3lBE+s=; b=fJ3eRmBpihswmUs8Ue72WWCdMvsGlm352z0avN31C9PW5JgAShuaSbdvpKYkSfqoVv i/kn9P5o/T7J5Qqk8F0Aasi1hmYwmLq+pcb0A36FwY9wVYOTXCY8HH5dD1mPLEQmB8BW WBmhk4uWWquTeXcByU/9NBM5UfBOfRAEJG2LL1C9DKUvnWHP2XCa3fbRTjUe5DC4+4Oo 4UDS7kG8yMflA3bcuSHvNJu61ZjGDnX3yWyp7BuDQ+FWKKJ3r342lZpq7tqIJZLPfodB BjmwQufvh/b2fh5ye54B8IR39EGSt07ca8GUOMOz05EuZJk3HWElTiVrSbzBLzax93HL 7D5Q== 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=USMs//dNvAKSD6YNwUG8bRsv4d4OEP1PrFmCV3lBE+s=; b=DICbkgJsK1pyMzE5BFlK7MGEccagwZ0cdUW6GPc1jgNBQzXWD2WyqygH0l7F2Aw0pB WG3ZAR17clI0CQ+7adgavkaPLOFqZUTOBgioAE91BP3XO46x9WiC6PqI8FJt0Hinqy7u e1cFwSzaXTfBMZDEgP1roVfaotolQ0TzDO2V+BisoXef9uVzSzDsgzFNxPy5gUgZ8ni+ HvNWXY2HwolhYyGu9fLjgV2UKUwa4ShPT91fKpi3cSeKyH0H+3xX0ZL7bihnXiiWkcnI jenr49W4EfNeLBQqTy9Vf1Y8I4m7s5lw0GxkhLRTIztTGLFnmw7il5wfSeXNrApvcMS6 I0lA== X-Gm-Message-State: ALoCoQlc2TvsX2zMbNgH8uC+ZIoR6pAmTAB+sEd4kSTRoVkHXZHRAkjBPBU1TOqioq2qV+Z7OVbZ X-Received: by 10.42.88.1 with SMTP id a1mr5369341icm.29.1426636797140; Tue, 17 Mar 2015 16:59:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.64.42 with HTTP; Tue, 17 Mar 2015 16:59:36 -0700 (PDT) In-Reply-To: <55089580.3000803@jive.com> References: <20150305201507.6192.13143.idtracker@ietfa.amsl.com> <35F68F75-51A0-48BD-B5D0-DE0A6600F13D@vidyo.com> <54FA2954.2060400@jive.com> <54FD8DAB.10807@jive.com> <525817F6-4E8F-4052-BB13-27B1F332756B@vidyo.com> <54FDD7A0.4010308@jive.com> <55089580.3000803@jive.com> From: Justin Uberti Date: Tue, 17 Mar 2015 16:59:36 -0700 Message-ID: To: Simon Perreault Content-Type: multipart/alternative; boundary=90e6ba3fcdc5849187051184c32a Archived-At: Cc: Jonathan Lennox , Benjamin Schwartz , "tram@ietf.org" Subject: Re: [tram] New Version Notification for draft-schwartz-tram-turnbyname-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, 17 Mar 2015 23:59:58 -0000 --90e6ba3fcdc5849187051184c32a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 17, 2015 at 1:58 PM, Simon Perreault wrote: > Le 2015-03-17 16:30, Benjamin Schwartz a =C3=A9crit : > > Looks like this didn't get a response. > > Thanks *a lot* for responding! > > > Suppose that the RTT to the TURN server is very low. Then the client > > will assume the request has failed if it doesn't get a response > > quickly. Therefore, the client will not be able to connect to names > > that are even a little bit slow to resolve. In the extreme case (RTT > > near zero), connection to DNS servers won't work at all. > > Understood! > > > Therefore, we should prefer a design that allows the effective timeout > > to be independent of RTT. That could work by just specifying a minimum > > timeout for this request-response, or it could work by choosing a desig= n > > that uses a different sequence of messages. > > Makes total sense! > I wonder if returning some sort of 3xx code "operation pending" would work here; the client would retry the request after some defined or supplied interval (which would then be cached at the server and could be returned instantly). --90e6ba3fcdc5849187051184c32a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 17, 2015 at 1:58 PM, Simon Perreault <= sperreault@jive.co= m> wrote:
Le 2015-03-17 16:= 30, Benjamin Schwartz a =C3=A9crit :
> Looks like this didn't get a response.

Thanks *a lot* for responding!

> Suppose that the RTT to the TURN server is very low.=C2=A0 Then the cl= ient
> will assume the request has failed if it doesn't get a response > quickly.=C2=A0 Therefore, the client will not be able to connect to na= mes
> that are even a little bit slow to resolve.=C2=A0 In the extreme case = (RTT
> near zero), connection to DNS servers won't work at all.

Understood!

> Therefore, we should prefer a design that allows the effective timeout=
> to be independent of RTT.=C2=A0 That could work by just specifying a m= inimum
> timeout for this request-response, or it could work by choosing a desi= gn
> that uses a different sequence of messages.

Makes total sense!

I wonder if r= eturning some sort of 3xx code "operation pending" would work her= e; the client would retry the request after some defined or supplied interv= al (which would then be cached at the server and could be returned instantl= y).=C2=A0
--90e6ba3fcdc5849187051184c32a-- From nobody Thu Mar 19 04:14:24 2015 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 BEC691A897D for ; Thu, 19 Mar 2015 04:14:23 -0700 (PDT) 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 dwJFm1nRSQhL for ; Thu, 19 Mar 2015 04:14:22 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id D139A1A8974 for ; Thu, 19 Mar 2015 04:14:21 -0700 (PDT) Received: from [IPv6:2602:43:2da:6400:f9c1:b626:6a91:92e2] (unknown [IPv6:2602:43:2da:6400:f9c1:b626:6a91:92e2]) (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 34F6B203C1; Thu, 19 Mar 2015 12:14:20 +0100 (CET) Message-ID: <550AAF8A.9080205@acm.org> Date: Thu, 19 Mar 2015 05:14:18 -0600 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 To: Alan Johnston , "tram@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tram] Comments on draft-ietf-tram-stun-bis-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: Thu, 19 Mar 2015 11:14:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Thank for the comments. See my answers inline. On 03/17/2015 08:11 AM, Alan Johnston wrote: > All, > > Here are some comments on STUNbis. Minor comments are listed below, but > the most important one is listed here: > > Does the use of salted SHA256 for passwords match up with what is planned > for SIP? See: > > https://tools.ietf.org/html/draft-yusef-sipcore-digest-scheme > > Does H(A1) match up? Also, I'm not aware if this draft is moving forward: > > https://tools.ietf.org/html/draft-veltri-sip-alt-auth It is not, which is sad because I find it better than draft-yusef-sipcore-digest-scheme. It also fits better with STUN where the hash algorithm (SHA-1 and now SHA256) has been split off the password hash algorithm (MD5) from the beginning. draft-yusef-sipcore-digest-scheme does not even talk about the password algorithm, continuing the (I think) rather bad idea of linking the two together. I put salted SHA256 as an example of the kind of password hash algorithm we could use, but I'll let the WG decide on what they prefer. > > while the other one is under active discussion in SIPCORE and HTTPAUTH - > see https://tools.ietf.org/html/draft-ietf-httpauth-digest-update > > I think it is important that STUNbis is aligned with the changes to digest > being worked on in SIP and HTTP. > > - Alan - > > Shouldn't STUNbis reference ICEbis instead of ICE? It's an informational reference, so I have no problem in referencing ICEbis. Will fix in -03. > > I presume "obMatJos2" is just a random string used to indicate support for > STUNbis - it might be worth stating this in 9.2.3. Generated with apg. I'll add some text. > > Section 11 Backwards Compatibility with RFC 3489: do we really need to > still be backwards compatible? Is anyone still using RFC 3489 that hasn't > upgraded? Do we leave ourselves open to any downgrade attacks by doing so? This has already be changed in -02 to "backwards compatibility with RFC 5389". > > Section 14 says only first of multiple attributes are processed. (“Any > attribute type MAY appear more than once in a STUN message. Unless > specified otherwise, the order of appearance is significant: only the first > occurrence needs to be processed by a receiver, and any duplicates MAY be > ignored by a receiver.â€) I guess this rules out multiple ORIGIN > attributes, which is fine since we had chosen that path forward. However, > this means that no future STUN attributes can really appear more than > once. Do we need to emphasize this more? I think that the intent was that a future attribute may be defined as supporting to be inserted multiple times, and this rule just makes parsing a STUN packet more resilient (i.e. do not reject a STUN packet because there is more than one instance of a specific attribute). I would leave the text as it is. > > In Section 14.2 what are the x's in |x x x x x x x x|? That's a good question. I supposed that should all 0's. Will change it in -03. > > The text in Section 15.3. Hash Agility Plan seems to be out of date now. Why? > > Section 17.5 says “The UDP port is not currently defined; however, it is > reserved for future use.†What port? The port is in fact allocated now. I will fix the text in -03. > > The change log says that STUNbis normatively references > draft-ietf-tram-stun-origin, but I don't see it listed in the references. > Perhaps a mention of ORIGIN in section 9.2 or 9.2.3 would be good, too. > Section 6.1 of -02. - -- 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 iQIcBAEBCAAGBQJVCq+JAAoJECnERZXWan7EjecQAL3y56oBKz88Ac34tPyG3VG3 jrsiCkzy5V8uAiK6/4xYM1SFSz7w7P0DkmVL0JexMroOhD44BeDIPmsXZQdbnwpI Uf7IFwrLUd2fF4OD9hgMEC8sXM50Uvs2JZp6XvJoT9tCbjlB7vQGF3h/l9R+29Rz y1UibiVHfTLs7X6uyKLHJdWqCItkkDJG5qNlRx6sRfofP9a/AkeRZ1KhXr0EqauG ZNOQ/U19ufKppp5QXWPS98UrpeIyAXrTY8M1Ar65Sm4Qpqo2BTgMZrN1jwyW1MiE rHU1gQ1tyQ1dXDsPbPJBINQC7IKq77aKO33qqd9QIYB/Fu7qj3pFuhwcpug7EqGF q7r4lc8H7jfmbmuFghnmTrfIpza/3uD1TW24gExTonUPzyYTVwYrxgJ7AkzgKcT8 W60kDpaYqKE9GK5To9BRG9iC6S2TzEGp98G5TDcudX4t2Cw0+YjgWr1vNEyOrN0g eYegQTusc5qqDoXgov2QKLmBM2huaqrOE3RSNtIJEN6fupyM2xSS+4m22F8cBzv4 hW1yZNhPvqGrlXMfxi6U1e3g3umkEw34nggQzBxkhpah3aTeEmlkqJo35RJt9jrf jFdRYWz4PbWyPnT+7quPMMsaNjVoOmsy8khcaVtsYaWk3rN+YuI8AK/70zJFGoFY 8IVBW1QuZIEVj38XX0Mn =93pO -----END PGP SIGNATURE----- From nobody Thu Mar 19 04:48:31 2015 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 1B2161A1ADA; Thu, 19 Mar 2015 04:48:28 -0700 (PDT) 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 rWKt13S5iVgI; Thu, 19 Mar 2015 04:48:27 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id ED3B61A0193; Thu, 19 Mar 2015 04:48:26 -0700 (PDT) Received: from [IPv6:2602:43:2da:6400:f9c1:b626:6a91:92e2] (unknown [IPv6:2602:43:2da:6400:f9c1:b626:6a91:92e2]) (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 0E000203C1; Thu, 19 Mar 2015 12:48:25 +0100 (CET) Message-ID: <550AB788.2040701@acm.org> Date: Thu, 19 Mar 2015 05:48:24 -0600 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 To: "tram@ietf.org" , tls@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [tram] rfc5764 design meeting 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, 19 Mar 2015 11:48:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 FYI, we will have a design meeting on Sunday around 9pm in Dallas to put together a proposal about the 5764 multiplexing scheme. The plan is to present this proposal in the avtcore WG session on Tuesday. Anybody with opinions on how to solve this problem should join us. I'll send another email when I know the place and exact time. Thanks. - -- 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 iQIcBAEBCAAGBQJVCreIAAoJECnERZXWan7E0i8P/2h5E6wxdCpvqbyy863TfXqa KwS7zb9LBvRWzHB0tEHm41NdCK+IAggRvNrDsJQKJIeddMwh+8vQWckpvk8t5M5f UCS286hkOUKAUF7I3Cl/qGstYu/TmxcjK7yzq5UUY98xl0D3U+d0mLJAc7ZuSthj VZ+9MVO+MmaAxqNZFKQpZzQZ1fNTo807tRwGUhXatJDj1lH4+SIQrftNpEk1UHm9 UH4Siv4y/kZonMK9mZc2IK4zNGSwYHv9jc5IjaPLzZLdNL6lP7gc177TWOYj6Axz W6JWX+17oTNEXRFQ4G+lAAaNw0C7zivsIs4M1rdtlGBArkfO5Nf4UuiewjATZGP0 JzMwh7FZNtufEy5PxavBoJ6kN/iQigP6xVKaQC+j3EkSzcksyEB2cj8BxOFvwrSL V68oyR/ohoGvK39yl+6K9RIcbYsvHzocJyj31LZHuhkctMNzR5HRVquvSoWW904i +N4aNI1Igl9rIY3keVdaAuhtya2ZS+yEeP+/O61UHRLcmOwOAlLHCcrqsbOFyrIO 7H+vZMjV8DnGwZrUeKbxim5iWxIWNP7tqsQ8nLiPdzaLzMxrGXdPFWacOcw8D5g3 b4SzHkdhXUAbtZMKY1f0FydvoUUuBchSDW9N2oGDRaEaVpsY9i16am2EoHMSrMXE AHHqU6Y199nz/e+0Jr66 =RAQh -----END PGP SIGNATURE----- From nobody Thu Mar 19 06:43:23 2015 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 D32581A8A7C for ; Thu, 19 Mar 2015 06:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7kbby3TW0y1S for ; Thu, 19 Mar 2015 06:43:20 -0700 (PDT) Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F6591A8A39 for ; Thu, 19 Mar 2015 06:43:20 -0700 (PDT) Received: by obbgg8 with SMTP id gg8so54523138obb.1 for ; Thu, 19 Mar 2015 06:43:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=nM38pZBSUPh98pnU117r8Kv2vS87oSBiGaIcm8ZHy+4=; b=G0FwCsP+2LtIK9yFa+/mM3p3EckxobvQlSUhPCwW4M8JsACXpww9u+dT6QZLs0DDoh DK9TbEeVMeDerdsEFZxKybH0BZpIvJOhTPpIOExCS5BfwEJzN6WiCcmP+eC/1TnXZpLE hJuRxwdScCK0a93dumGgDsNOfQVL2bMNX1iUhx0jjrJEClfRaHDzorQt0U+nqHwUjiyB BwNTwQcLv0SDbapXbipJvmzV/wQjsh6y1te35L4Szqfut3a9GZrjrKxWaNBZDo/J1I1B 02l8wqQ8Beedn4+Rs+pGmRZve1qflryToDyCTuGXn28HUA7ktTyLKKa98kh7PyfbEeMb 9Afg== X-Gm-Message-State: ALoCoQly8Wr4mJDsHO8TS7+PST9JH4Ik2On6aKzFGGhQxlwcT4jsnuAtwLdcam8zdWlo72PEBWDn X-Received: by 10.60.120.36 with SMTP id kz4mr61857327oeb.47.1426772599713; Thu, 19 Mar 2015 06:43:19 -0700 (PDT) Received: from Simons-MacBook-Air.local (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id t8sm697111oib.4.2015.03.19.06.43.18 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Mar 2015 06:43:18 -0700 (PDT) Message-ID: <550AD275.1010804@jive.com> Date: Thu, 19 Mar 2015 09:43:17 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Marc Petit-Huguenin , Alan Johnston , "tram@ietf.org" References: <550AAF8A.9080205@acm.org> In-Reply-To: <550AAF8A.9080205@acm.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [tram] Sync STUN and SIP auth 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, 19 Mar 2015 13:43:22 -0000 Le 2015-03-19 07:14, Marc Petit-Huguenin a écrit : > > Does the use of salted SHA256 for passwords match up with what is planned > > for SIP? See: > > > > https://tools.ietf.org/html/draft-yusef-sipcore-digest-scheme > > > > Does H(A1) match up? Also, I'm not aware if this draft is moving forward: > > > > https://tools.ietf.org/html/draft-veltri-sip-alt-auth > It is not, which is sad because I find it better than draft-yusef-sipcore-digest-scheme. It also fits better with STUN where the hash algorithm (SHA-1 and now SHA256) has been split off the password hash algorithm (MD5) from the beginning. draft-yusef-sipcore-digest-scheme does not even talk about the password algorithm, continuing the (I think) rather bad idea of linking the two together. What you're saying makes sense, yet does not bring us closer to syncing STUN and SIP auth. I don't know if it is a possible goal, but I feel it is our duty to at least explore the possibility. I note that the two drafts above are not working-group drafts. It would be good to have a chat with the sipcore chairs in Dallas and reach a common understanding of the situation... Simon From nobody Thu Mar 19 06:55:17 2015 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 EE3E51AC3F8 for ; Thu, 19 Mar 2015 06:55:14 -0700 (PDT) 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 BRFuBrhrNnyd for ; Thu, 19 Mar 2015 06:55:09 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 349B81AC3F7 for ; Thu, 19 Mar 2015 06:55:09 -0700 (PDT) Received: from [IPv6:2602:43:2da:6400:f9c1:b626:6a91:92e2] (unknown [IPv6:2602:43:2da:6400:f9c1:b626:6a91:92e2]) (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 EA6D4203C1; Thu, 19 Mar 2015 14:55:07 +0100 (CET) Message-ID: <550AD53A.6090007@acm.org> Date: Thu, 19 Mar 2015 07:55:06 -0600 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 To: Simon Perreault , Alan Johnston , "tram@ietf.org" References: <550AAF8A.9080205@acm.org> <550AD275.1010804@jive.com> In-Reply-To: <550AD275.1010804@jive.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tram] Sync STUN and SIP auth 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, 19 Mar 2015 13:55:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/19/2015 07:43 AM, Simon Perreault wrote: > Le 2015-03-19 07:14, Marc Petit-Huguenin a écrit : >>> Does the use of salted SHA256 for passwords match up with what is planned >>> for SIP? See: >>> >>> https://tools.ietf.org/html/draft-yusef-sipcore-digest-scheme >>> >>> Does H(A1) match up? Also, I'm not aware if this draft is moving forward: >>> >>> https://tools.ietf.org/html/draft-veltri-sip-alt-auth >> It is not, which is sad because I find it better than draft-yusef-sipcore-digest-scheme. It also fits better with STUN where the hash algorithm (SHA-1 and now SHA256) has been split off the password hash algorithm (MD5) from the beginning. draft-yusef-sipcore-digest-scheme does not even talk about the password algorithm, continuing the (I think) rather bad idea of linking the two together. > > What you're saying makes sense, yet does not bring us closer to syncing > STUN and SIP auth. I don't know if it is a possible goal, but I feel it > is our duty to at least explore the possibility. > > I note that the two drafts above are not working-group drafts. It would > be good to have a chat with the sipcore chairs in Dallas and reach a > common understanding of the situation... Let's do that, but I noticed that sipcore will not have a session in Dallas. > > Simon > - -- 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 iQIcBAEBCAAGBQJVCtU5AAoJECnERZXWan7EHyYP/1gnBqKC/J1zuPYg+M4Xg3qV tXFQwAcTv9CuF+/9j0+vkSyUluopXTPP4i9hf8Ms4PRZc6QT3ZkBqpDwkZZYuXQK zPyxT1o2D5XV1dnjYfZXZcN68Bf/5rR23EHYRdY1j/fMPrEJkVP7vtu3Sr3xfXA7 m4zcdKLA4u2OmK5aeDHP24+zcRAXOJ07WW6gudKSb3MAzOyn3sL4hC56tgQdJWNO wEyZXhIP4VdBjGy0Cs9wNrvZsgi7AR9J3HkOGZMv9gpH5ZI3yJYBHbyn3IuGa/ig u+rEXwXjdvBVPEmrNyd3PURop1V9szsHg2x86wn58DbH4YmRJeqXHT8uPiug+c7A 59rEPxiN3ajRQaN+KVEE7Zp5iQeFpPRKz6FJtd1261eMFawE0vMApGC4oaVZuEL8 KQIGu+trEixJG8SI29UwYq5YLOOQsDBLP+q6uV6nqYgz9G8I2d4MeTZpTHQxOoGl 3+8OFkUJzqiteo59PP281NW4GCwS63iuRNzGHkpdb14X9SA91MJ0EEU0tcfMbro7 u7APmH40ID8TqzfW2WQiL4ZlxxoyAIdMT4GkE13wAkxbJWQdEDJ19yfmMX6rtqnn lpMKsQFmZC3fyfZ43IuzJEziGcq+QDbltqetmef1kKnoDKTIHE3TX7FldUyIo7Ap P2FJWLCJksSm6yKh2O/2 =5Iz6 -----END PGP SIGNATURE----- From nobody Thu Mar 19 07:01:34 2015 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 839FE1AC3F3 for ; Thu, 19 Mar 2015 07:01:32 -0700 (PDT) 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 grAwF7n0Ecxh for ; Thu, 19 Mar 2015 07:01:30 -0700 (PDT) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFCC91A8A63 for ; Thu, 19 Mar 2015 07:01:29 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id la4so19280014vcb.10 for ; Thu, 19 Mar 2015 07:01:29 -0700 (PDT) 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=I5w4sQY8IChxQR4q/4VFdSws1lgEjMFfNGMK3kHyXi4=; b=v2kU/7WlFH+9LkyH4cUWGM4yXRe7K2PAK3fslAY95YhsuRifPlmCrMIQ6cFe5Rdap9 LUNiZtakIkePgrzByrUt/DVrGnSRqOjLlqStjzLGYuJFuKONz8CshGxf8v/7BkTcAeQc SX6aEFkAQQTjBhMhSrMm9GKRttJTF2G0JURY2YElFNNN/qAHlcZEi9HfzS2n8g/INkZi wylZWYHZ0Lar+G2PC3OpOgl7GZXxgICt4fIqkCcvEqzNF6QT2O3TA8z9Q9exCB57WOqA ALrLjNZvKPJ8z6AXo+Ab74pnhnZF11Hx4TBJYorSmI3xpOEY5EI1m8M2ygTmF27OiIqw 9NJQ== MIME-Version: 1.0 X-Received: by 10.52.139.16 with SMTP id qu16mr78316152vdb.43.1426773689132; Thu, 19 Mar 2015 07:01:29 -0700 (PDT) Received: by 10.52.121.111 with HTTP; Thu, 19 Mar 2015 07:01:29 -0700 (PDT) In-Reply-To: <550AD53A.6090007@acm.org> References: <550AAF8A.9080205@acm.org> <550AD275.1010804@jive.com> <550AD53A.6090007@acm.org> Date: Thu, 19 Mar 2015 09:01:29 -0500 Message-ID: From: Alan Johnston To: Marc Petit-Huguenin Content-Type: multipart/alternative; boundary=bcaec52c6389ea70520511a4a223 Archived-At: Cc: Simon Perreault , "tram@ietf.org" , Rifaat Shekh-Yusef Subject: Re: [tram] Sync STUN and SIP auth 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, 19 Mar 2015 14:01:32 -0000 --bcaec52c6389ea70520511a4a223 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Marc & Simon, Rifaat and many other SIPCORE folks will be in Dallas next week, so we should definitely meet up and figure out a solution. - Alan - On Thu, Mar 19, 2015 at 8:55 AM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 03/19/2015 07:43 AM, Simon Perreault wrote: > > Le 2015-03-19 07:14, Marc Petit-Huguenin a =C3=A9crit : > >>> Does the use of salted SHA256 for passwords match up with what is > planned > >>> for SIP? See: > >>> > >>> https://tools.ietf.org/html/draft-yusef-sipcore-digest-scheme > >>> > >>> Does H(A1) match up? Also, I'm not aware if this draft is moving > forward: > >>> > >>> https://tools.ietf.org/html/draft-veltri-sip-alt-auth > >> It is not, which is sad because I find it better than > draft-yusef-sipcore-digest-scheme. It also fits better with STUN where t= he > hash algorithm (SHA-1 and now SHA256) has been split off the password has= h > algorithm (MD5) from the beginning. draft-yusef-sipcore-digest-scheme do= es > not even talk about the password algorithm, continuing the (I think) rath= er > bad idea of linking the two together. > > > > What you're saying makes sense, yet does not bring us closer to syncing > > STUN and SIP auth. I don't know if it is a possible goal, but I feel it > > is our duty to at least explore the possibility. > > > > I note that the two drafts above are not working-group drafts. It would > > be good to have a chat with the sipcore chairs in Dallas and reach a > > common understanding of the situation... > > Let's do that, but I noticed that sipcore will not have a session in > Dallas. > > > > > Simon > > > > > - -- > 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 > > iQIcBAEBCAAGBQJVCtU5AAoJECnERZXWan7EHyYP/1gnBqKC/J1zuPYg+M4Xg3qV > tXFQwAcTv9CuF+/9j0+vkSyUluopXTPP4i9hf8Ms4PRZc6QT3ZkBqpDwkZZYuXQK > zPyxT1o2D5XV1dnjYfZXZcN68Bf/5rR23EHYRdY1j/fMPrEJkVP7vtu3Sr3xfXA7 > m4zcdKLA4u2OmK5aeDHP24+zcRAXOJ07WW6gudKSb3MAzOyn3sL4hC56tgQdJWNO > wEyZXhIP4VdBjGy0Cs9wNrvZsgi7AR9J3HkOGZMv9gpH5ZI3yJYBHbyn3IuGa/ig > u+rEXwXjdvBVPEmrNyd3PURop1V9szsHg2x86wn58DbH4YmRJeqXHT8uPiug+c7A > 59rEPxiN3ajRQaN+KVEE7Zp5iQeFpPRKz6FJtd1261eMFawE0vMApGC4oaVZuEL8 > KQIGu+trEixJG8SI29UwYq5YLOOQsDBLP+q6uV6nqYgz9G8I2d4MeTZpTHQxOoGl > 3+8OFkUJzqiteo59PP281NW4GCwS63iuRNzGHkpdb14X9SA91MJ0EEU0tcfMbro7 > u7APmH40ID8TqzfW2WQiL4ZlxxoyAIdMT4GkE13wAkxbJWQdEDJ19yfmMX6rtqnn > lpMKsQFmZC3fyfZ43IuzJEziGcq+QDbltqetmef1kKnoDKTIHE3TX7FldUyIo7Ap > P2FJWLCJksSm6yKh2O/2 > =3D5Iz6 > -----END PGP SIGNATURE----- > --bcaec52c6389ea70520511a4a223 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Marc & Simon,

Rifaat and= many other SIPCORE folks will be in Dallas next week, so we should definit= ely meet up and figure out a solution.

- Alan -


On Thu, Mar 19, 2015 at 8:55 AM, Marc Petit-Huguenin <= ;petithug@acm.org= > wrote:
-----BEGIN PGP SIGNED = MESSAGE-----
Hash: SHA256

On 03/19/2015 07:43 AM, Simon Perreault wrote:
> Le 2015-03-19 07:14, Marc Petit-Huguenin a =C3=A9crit :
>>> Does the use of salted SHA256 for passwords match up with what= is planned
>>> for SIP?=C2=A0 See:
>>>
>>>=C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/htm= l/draft-yusef-sipcore-digest-scheme
>>>
>>> Does H(A1) match up?=C2=A0 Also, I'm not aware if this dra= ft is moving forward:
>>>
>>>=C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-= veltri-sip-alt-auth
>> It is not, which is sad because I find it better than draft-yusef-= sipcore-digest-scheme.=C2=A0 It also fits better with STUN where the hash a= lgorithm (SHA-1 and now SHA256) has been split off the password hash algori= thm (MD5) from the beginning.=C2=A0 draft-yusef-sipcore-digest-scheme does = not even talk about the password algorithm, continuing the (I think) rather= bad idea of linking the two together.
>
> What you're saying makes sense, yet does not bring us closer to sy= ncing
> STUN and SIP auth. I don't know if it is a possible goal, but I fe= el it
> is our duty to at least explore the possibility.
>
> I note that the two drafts above are not working-group drafts. It woul= d
> be good to have a chat with the sipcore chairs in Dallas and reach a > common understanding of the situation...

Let's do that, but I noticed that sipcore will not have a session in Da= llas.

>
> Simon
>


- --
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: htt= p://blog.marc.petit-huguenin.org
Profile: = http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJVCtU5AAoJECnERZXWan7EHyYP/1gnBqKC/J1zuPYg+M4Xg3qV
tXFQwAcTv9CuF+/9j0+vkSyUluopXTPP4i9hf8Ms4PRZc6QT3ZkBqpDwkZZYuXQK
zPyxT1o2D5XV1dnjYfZXZcN68Bf/5rR23EHYRdY1j/fMPrEJkVP7vtu3Sr3xfXA7
m4zcdKLA4u2OmK5aeDHP24+zcRAXOJ07WW6gudKSb3MAzOyn3sL4hC56tgQdJWNO
wEyZXhIP4VdBjGy0Cs9wNrvZsgi7AR9J3HkOGZMv9gpH5ZI3yJYBHbyn3IuGa/ig
u+rEXwXjdvBVPEmrNyd3PURop1V9szsHg2x86wn58DbH4YmRJeqXHT8uPiug+c7A
59rEPxiN3ajRQaN+KVEE7Zp5iQeFpPRKz6FJtd1261eMFawE0vMApGC4oaVZuEL8
KQIGu+trEixJG8SI29UwYq5YLOOQsDBLP+q6uV6nqYgz9G8I2d4MeTZpTHQxOoGl
3+8OFkUJzqiteo59PP281NW4GCwS63iuRNzGHkpdb14X9SA91MJ0EEU0tcfMbro7
u7APmH40ID8TqzfW2WQiL4ZlxxoyAIdMT4GkE13wAkxbJWQdEDJ19yfmMX6rtqnn
lpMKsQFmZC3fyfZ43IuzJEziGcq+QDbltqetmef1kKnoDKTIHE3TX7FldUyIo7Ap
P2FJWLCJksSm6yKh2O/2
=3D5Iz6
-----END PGP SIGNATURE-----

--bcaec52c6389ea70520511a4a223-- From nobody Fri Mar 20 20:12:47 2015 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 AD1D91A8904; Fri, 20 Mar 2015 20:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-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 45VWdpTbs6SW; Fri, 20 Mar 2015 20:12:41 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03E591A8900; Fri, 20 Mar 2015 20:12:40 -0700 (PDT) Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t2L3CX1n021044 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 20 Mar 2015 23:12:36 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com t2L3CX1n021044 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1426907557; bh=PE0hOaJEYezvSzF2nygEXoFAvgM=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=YOA5YJ14/5NvUv2VsQ6y9boJLmXG4DQTF/r/Jn8B4MEP5nXNTU7Ahx/QvM6/ESAqG +QqtfCUpV60uHMjanZ1cqPZrmaXYhdyLDowzfMhmW8LUBqj/7NVGx6GbhjW0PMXZYO wb8LEY7Mp9ndRENYJJJ2u43Y7kpbENAd95U3vbwE= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com t2L3CX1n021044 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd05.lss.emc.com (RSA Interceptor); Fri, 20 Mar 2015 23:12:18 -0400 Received: from mxhub11.corp.emc.com (mxhub11.corp.emc.com [10.254.92.106]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t2L3CNVv003989 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Mar 2015 23:12:24 -0400 Received: from MXHUB203.corp.emc.com (10.253.68.29) by mxhub11.corp.emc.com (10.254.92.106) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 20 Mar 2015 23:12:23 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.93]) by MXHUB203.corp.emc.com ([10.253.68.29]) with mapi id 14.03.0224.002; Fri, 20 Mar 2015 23:12:23 -0400 From: "Black, David" To: "alan.b.johnston@gmail.com" , "justin@uberti.name" , "yoakum@avaya.com" , "General Area Review Team (gen-art@ietf.org)" Thread-Topic: Gen-ART review of draft-ietf-tram-stun-origin-05 Thread-Index: AdBjhNiYXvzTSPo6RjeFsz+Pyn+RaA== Date: Sat, 21 Mar 2015 03:12:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.250.48.35] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public, Resumes Archived-At: Cc: "Black, David" , "ietf@ietf.org" , "tram@ietf.org" Subject: [tram] Gen-ART review of draft-ietf-tram-stun-origin-05 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: Sat, 21 Mar 2015 03:12:42 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-tram-stun-origin-05 Reviewer: David L. Black Review Date: March 20, 2015 IETF LC End Date: March 17, 2015 Summary: This draft is on the right track, but has open issues described in the review. This draft describes the addition of a web origin attribute to STUN and usage of that attribute in several protocol contexts. The draft is well- written and easy to read. I found one minor issue which may be editorial. Major issues: None. Minor issues: Section 2.7 discusses use of multiple STUN origins with Web RTC and concludes by imposing a "MUST" requirement on use of multiple STUN origins with HTTP in general (use first origin, ignore others). While Web RTC may be the predominant or only current use of STUN and TURN with HTTP, this "MUST" could foreclose the use of STUN origins with other uses of HTTP. I'm not sure what those possible future uses might be, but at a minimum this draft ought to more tightly scope its discussion of use of STUN origins with HTTP to limit that usage to Web RTC. If there's a good way for a STUN or TURN server to detect Web RTC usage, requiring STUN and TURN servers to look for Web RTC as the use of HTTP, and only impose this "MUST" requirement if Web RTC is detected would better align that requirement with the discussion in this draft. Nits/editorial comments: idnits 2.13.01 turned up a reference problem: =3D=3D Unused Reference: 'RFC7350' is defined on line 490, but no explici= t reference was found in the text That RFC should be cited somewhere. In addition, there are no RFCs cited or referenced for TLS and DTLS - they should be added (I believe that RFC 5246 and RFC 6347 are appropriate, respectively).=20 Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From nobody Sun Mar 22 11:19:21 2015 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 DE52C1A0022; Sun, 22 Mar 2015 11:19:17 -0700 (PDT) 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 RREPA37HQq_l; Sun, 22 Mar 2015 11:19:16 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 938D91A001A; Sun, 22 Mar 2015 11:19:16 -0700 (PDT) Received: from [IPv6:2001:67c:370:136:c617:feff:feb6:86ed] (unknown [IPv6:2001:67c:370:136:c617:feff:feb6:86ed]) (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 4D2D8200C1; Sun, 22 Mar 2015 19:19:15 +0100 (CET) Message-ID: <550F07A1.7020403@acm.org> Date: Sun, 22 Mar 2015 12:19:13 -0600 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 To: "tram@ietf.org" , tls@ietf.org, AVT WG References: <550AB788.2040701@acm.org> In-Reply-To: <550AB788.2040701@acm.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tram] rfc5764 design meeting 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: Sun, 22 Mar 2015 18:19:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 We will meet tonight at 8:30pm in the bar located on the lobby level of the Fairmont Hotel. On 03/19/2015 05:48 AM, Marc Petit-Huguenin wrote: > FYI, we will have a design meeting on Sunday around 9pm in Dallas to put together a proposal about the 5764 multiplexing scheme. The plan is to present this proposal in the avtcore WG session on Tuesday. Anybody with opinions on how to solve this problem should join us. > > I'll send another email when I know the place and exact time. > > Thanks. > > - -- 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 iQIcBAEBCAAGBQJVDwehAAoJECnERZXWan7EN8sP/iyslm73K21+e/joKaskQhII qMPCnPlmufLVGQ/6aEFGuRmdysnb60PKNHkaWfF1XRAiKbgnsn1Su7W63jyJzjJ3 S7RcMg1CiGqJ9S9yif6IfH7oTPZYqrydPKqjWCtUy2c/ZCcyiL7nxpA2JT1Snf9H W3oZqSD4RaGyN0nT5sYxQmdoI+RN9SmM0ts0vmPodNlAIK2bxAjKQPGVEodMkGEi we8idoICBlP6gkUqNpA57BHxS+xse0co1BRhAoTjtVqVWuMK/POWDhzVI4SC0cw0 miRmg+L4cwExqpapsdeZ3DTX1fw9fb0JJBf6mBUKDyK2R8LNGw5B/SC7UfDrvSED DjcNo/KS67ljHXTxrmVi1v6trZS6q75zZstE1wlNEDHiv54Dz2ZT/kKHT56LZ8Ot 79SJve8xMdY/CySvOwYxA5yVxU212VPy5tOLpgqEzk13Qz9OvXlRiZcFfRc2h5BW 4kkj24LCxnIWC62lo8hEaeNpv1/WR4MiAxvYIq7B9ZfcxfOcxqJ28E47ggqR+3Y/ DrEJNU0ePntUlBSgXJLsgsgjS2rVt93NeNaHq4o0jgu5jYJIvjNOR0Qc/UPosqDT NzOuvUgis6cGjUKTH+XH9/WdAeKvmDd+jfZzcFxkoQwOPXNglqaesWhnF7miWtqx PLFKqdUpwWtNrszOlH6Z =KHNB -----END PGP SIGNATURE----- From nobody Sun Mar 22 14:37:22 2015 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 C55661A88C4; Fri, 20 Mar 2015 12:57:56 -0700 (PDT) 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 4XWpJififT-K; Fri, 20 Mar 2015 12:57:55 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB5DE1A8840; Fri, 20 Mar 2015 12:57:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A37D0BE50; Fri, 20 Mar 2015 19:57:53 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxNw2k3bK550; Fri, 20 Mar 2015 19:57:52 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.46.20.71]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C0537BE49; Fri, 20 Mar 2015 19:57:51 +0000 (GMT) Message-ID: <550C7BBF.8070502@cs.tcd.ie> Date: Fri, 20 Mar 2015 19:57:51 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Brandon Williams , Gonzalo Camarillo , "Prashanth Patil (praspati)" , "Tirumaleswar Reddy (tireddy)" , "tram-chairs@ietf.org" , "tram@ietf.org" , "draft-ietf-tram-turn-third-party-authz@ietf.org" , "draft-ietf-tram-turn-third-party-authz.ad@ietf.org" , "draft-ietf-tram-turn-third-party-authz.shepherd@ietf.org" , "spencerdawkins.ietf@gmail.com" , "rlb@ipv.sx" , IESG , "Salz, Rich" References: <913383AAA69FF945B8F946018B75898A366AA244@xmb-rcd-x10.cisco.com> <54F98585.7070203@ericsson.com> <54F9CBDF.7010705@cs.tcd.ie> <54FACD4E.8030706@ericsson.com> <54FB5778.2030405@cs.tcd.ie> <54FF56D0.80306@cs.tcd.ie> <54FF623A.4000501@cs.tcd.ie> <55001427.2020201@cs.tcd.ie> <5502D928.7010205@ericsson.com> <550C7AEE.7000109@akamai.com> In-Reply-To: <550C7AEE.7000109@akamai.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Sun, 22 Mar 2015 14:37:20 -0700 Subject: Re: [tram] New Version Notification - draft-ietf-tram-turn-third-party-authz-13.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, 20 Mar 2015 19:57:56 -0000 On 20/03/15 19:54, Brandon Williams wrote: > Hi all, > > Has a timeslot been proposed for this discussion? Please CC me if/when > it is. Rich Salz (a colleague of mine who focuses on security) and I > would like join the discussion if we can. I think we just got done agreeing on Friday 0850 @ noticeboard S > > Thanks, > --Brandon > > On 03/13/2015 08:33 AM, Gonzalo Camarillo wrote: >> Hi Spencer, >> >> could you please propose a timeslot that works for both you and Stephen >> so that we can move this forward during the upcoming meeting in Dallas? >> >> Thanks, >> >> Gonzalo >> >> On 11/03/2015 11:08 AM, Stephen Farrell wrote: >>> >>> So I think someone needs to draw me a picture at a whiteboard, which >>> we can do in Dallas maybe, since I'm not getting the rationale behind >>> the design here. >>> >>> S. >>> >>> On 11/03/15 04:26, Prashanth Patil (praspati) wrote: >>>> Hi Stephen, >>>> The token carries the key used to generate message integrity for the >>>> STUN >>>> message. It was designed to be inline with the proof-of-possesion >>>> security >>>> mechanism discussed in >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Doauth-2Dpop-2Darchitecture-2D01&d=AwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=nCIoBhgZ9Uqiw99NM5A0zgnl26IUiofXZMm0CxLDl3A&s=sqrlLUHPx0NZS-UmsqhWkTtXwzz_Zfa1Td0MYOlICPI&e= >>>> . STUN >>>> messages have to be signed to prove that it was indeed the TURN client >>>> that was authorized to use the token, and similarly the TURN server >>>> needs >>>> to prove to the TURN client that it was the server authorized by the >>>> WebRTC server and not a rouge TURN server. >>>> >>>> -Prashanth >>>> >>>> On 3/10/15, 2:29 PM, "Stephen Farrell" >>>> wrote: >>>> >>>>> >>>>> Hiya, >>>>> >>>>> On 10/03/15 21:21, Prashanth Patil (praspati) wrote: >>>>>> The Token, which is self contained, is encrypted so as to make it >>>>>> opaque >>>>>> to the client. All the information necessary to authenticate the >>>>>> validity >>>>>> of the token is contained within the token itself. >>>>> >>>>> Sorry I'm still not getting it. Exactly what information needs to be >>>>> confidential between which endpoints? >>>>> >>>>> When I think of the STUN/TURN problem in WebRTC, it's a pure question >>>>> of permission and accountability. >>>>> >>>>> Today, the web site hands out a username/secret for use of STURN or >>>>> TURN, which is bad, >>>>> >>>>> But why not have the web site sign a token that says "web site >>>>> says it's ok for whoever presents this to get STUN/TURN service" >>>>> with whatever timestamps or other controls are needed. I don't see >>>>> anything that needs to be inside that token that's not immediately >>>>> obvious from just watching the (ciphertext) packets flow. So I >>>>> don't see anything that needs encrypting between the web site and >>>>> the STUN/TURN servers. >>>>> >>>>> Cheers, >>>>> S. >>>> >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=AwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=nCIoBhgZ9Uqiw99NM5A0zgnl26IUiofXZMm0CxLDl3A&s=4n-Qc5o1pANLszaThuvMPkUsUFs8-8k7aK-ft6xMzn4&e= >> >> > From nobody Sun Mar 22 14:37:23 2015 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 E68BE1A886E; Fri, 20 Mar 2015 14:02:11 -0700 (PDT) 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 MMH0Ahewl-EE; Fri, 20 Mar 2015 14:02:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8D51A88C7; Fri, 20 Mar 2015 14:02:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150320210209.8093.71127.idtracker@ietfa.amsl.com> Date: Fri, 20 Mar 2015 14:02:09 -0700 Archived-At: X-Mailman-Approved-At: Sun, 22 Mar 2015 14:37:20 -0700 Cc: tram@ietf.org, mls.ietf@gmail.com, gonzalo.camarillo@ericsson.com, sperreault@jive.com, spencerdawkins.ietf@gmail.com, ipr-announce@ietf.org Subject: [tram] IPR Disclosure Avaya, Inc.'s Statement about IPR related to draft-ietf-tram-stun-origin X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 21:02:12 -0000 Dear Alan Johnston, Justin Uberti, John Yoakum, Kundan Singh: An IPR disclosure that pertains to your Internet-Draft entitled "An Origin Attribute for the STUN Protocol" (draft-ietf-tram-stun-origin) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2555/). The title of the IPR disclosure is "Avaya, Inc.'s Statement about IPR related to draft-ietf-tram-stun-origin" Thank you IETF Secretariat From nobody Wed Mar 25 18:37:50 2015 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 87ED21A8986 for ; Wed, 25 Mar 2015 18:37:49 -0700 (PDT) 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 Ra7ajSf7iShu for ; Wed, 25 Mar 2015 18:37:48 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20C151A1BC9 for ; Wed, 25 Mar 2015 18:37:48 -0700 (PDT) Received: by obcxo2 with SMTP id xo2so34558749obc.0 for ; Wed, 25 Mar 2015 18:37:47 -0700 (PDT) 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=ZS2soYpObircIbynW//fETDEfW0OCRFZcMv5IIa86C4=; b=IRhfoV9VpUj6v9uuy1RRe12w1CWa6+Lu5TXBkbzcdiywhBVsa1cwJfDdVSJcarZgI4 oX+JftZinvbqMbZdnEJJLpk31t/YxuM67DW0AjhYOfRu/P6jAHzyuA5G8MIMFMYkGMhK 9DtCq1eDN6hru3MuWoiNxtI//VfHTd6C7+m4BKTjgtWQfXE5e9vynh3rzuoQeehiJqwq robtizo6SxHVxTZI4mmO2RqEV2xJ2QPvSR99uYosvxHuvTXUO+GA/O3QWPyQArwd6nzt TIfQvHjcQttZggUSvGVjdu8nBYEZ8nQ6dACcL9xMMPwQWJjmWW7xfg5UzyA78tBUO37/ 88lQ== MIME-Version: 1.0 X-Received: by 10.202.86.150 with SMTP id k144mr9541962oib.42.1427333867577; Wed, 25 Mar 2015 18:37:47 -0700 (PDT) Received: by 10.202.93.69 with HTTP; Wed, 25 Mar 2015 18:37:47 -0700 (PDT) Date: Wed, 25 Mar 2015 20:37:47 -0500 Message-ID: From: Rifaat Shekh-Yusef To: tram@ietf.org Content-Type: multipart/alternative; boundary=001a113d85ba2727a7051227106b Archived-At: Subject: [tram] draft-ietf-tram-stunbis-02 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, 26 Mar 2015 01:37:49 -0000 --001a113d85ba2727a7051227106b Content-Type: text/plain; charset=ISO-8859-1 Hi, I was reading section 9.2 Long-Term Credential Mechanism of the draft-ietf-tram-stunbis-02 document, and I came a cross the following statement: "Note that the long-term credential mechanism cannot be used to protect indications, since indications cannot be challenged. Usages utilizing indications must either use a short-term credential or omit authentication and message integrity for them." I am not sure that I understand the reason for this statement. After the client is able to authenticate to the server and get the realm, nonce, and maybe the salt from the server, the client should be able to create the key that will be used with the HMAC function. At this stage either side should be able to create an HMAC for any request, including Indication. In the case that the receiving side failed to validate the HMAC for an Indication it should just drop it on the floor. Regards, Rifaat --001a113d85ba2727a7051227106b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I was reading section 9.= 2 Long-Term Credential Mechanism of the=A0
draft-ietf-tram-stunbi= s-02 document, and I came a cross the following=A0
statement:


=A0 "Note that the long-term cred= ential mechanism cannot be used to
=A0 =A0protect indications, si= nce indications cannot be challenged.=A0 Usages
=A0 =A0utilizing = indications must either use a short-term credential or omit
=A0 = =A0authentication and message integrity for them."


I am not sure that I understand the reason for this st= atement.

After the client is able to authenticate = to the server and get the realm,
nonce, and maybe the salt from t= he server, the client should be able to
create the key that will = be used with the HMAC function.

At this stage eith= er side should be able to create an HMAC for any request,
includi= ng Indication. In the case that the receiving side failed to=A0
v= alidate the HMAC for an Indication it should just drop it on the floor.

Regards,
=A0Rifaat

--001a113d85ba2727a7051227106b-- From nobody Wed Mar 25 20:43:53 2015 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 997801A7001 for ; Wed, 25 Mar 2015 20:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 BDCUl4cyQp8e for ; Wed, 25 Mar 2015 20:43:51 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 479151A6FFA for ; Wed, 25 Mar 2015 20:43:51 -0700 (PDT) Received: by igcau2 with SMTP id au2so6369606igc.1 for ; Wed, 25 Mar 2015 20:43:50 -0700 (PDT) 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=u0ucg3P5G6yfPS3bJgSZDNRdBLJrtS6c+3DjrqHeKr0=; b=l6NF6GY3D6pTITlxBgDIQUJH2jTsOesva9yKsOYymOenK6Lv1Ybvi5n4ZZ5fbuYzHz eheAHLJRsimRRcCLCbt4VAA2mO6zEz5r+w8SOJjROX038cVoEojrmes/+5L1LsNDTxBU qRrvBkH/NKoTIn4/mIHaSji7vAswqciy3C/RMFBJy2qfy4kDtrqBxEXrQ6YZyzvH2zhy JJUfFGGT0uZMBiAVAkUEXAr3p4gSADKhnUC2Ig28OO2i39pRz3U/FBDrVjXiiCMyRTn1 7PNTMEJVmzWXmAGQ3o3nIU4IqszTAlYliYhu52PO49q8uu3aIy1xxP46UsDAN4JgAeKS UyNQ== 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=u0ucg3P5G6yfPS3bJgSZDNRdBLJrtS6c+3DjrqHeKr0=; b=c6wlv/w8oyndAfiVYpT7VyZGvveRIb1hg2mMWhCoFMJPb4NGFmwKLXwBrxWgVHmMPs jdsJB1PM8BpvdfzMAT7sLGJYe3d0oMZYRDiWUZBMdI6nQY5KEawwngTYS8gqC6d8dYhm JB0yQCilulG3tAww3+0Wq6iXY4PdfzESELK07doBbNiR5QE4jVz2z+IQeg/AVFTqRKXF /mWALmwwmDZjS98ggQSvMDtYBXwDSCJAJT1eNRFIppnEbKpDrpytIzcvDonxJamG9D3S C/l6gsZFlC+BIHgJKm0fet0i/QRngsS1qLguIiaLxEn15KZzTGAfJBUh87nPyUrL7r/c hFRg== X-Gm-Message-State: ALoCoQm7vy1BtuOh5dWkKQwdxsDYorDE8x1Fdnunz9fHdwjtjvm7vXfihb0gc6buJS2xj6qyNQdp X-Received: by 10.50.43.138 with SMTP id w10mr33881594igl.19.1427341430383; Wed, 25 Mar 2015 20:43:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.64.42 with HTTP; Wed, 25 Mar 2015 20:43:30 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Wed, 25 Mar 2015 22:43:30 -0500 Message-ID: To: Rifaat Shekh-Yusef Content-Type: multipart/alternative; boundary=089e01176c7fee9a00051228d2a5 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] draft-ietf-tram-stunbis-02 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, 26 Mar 2015 03:43:52 -0000 --089e01176c7fee9a00051228d2a5 Content-Type: text/plain; charset=UTF-8 True, but that nonce may have expired by the time the indication is sent. On Wed, Mar 25, 2015 at 8:37 PM, Rifaat Shekh-Yusef wrote: > Hi, > > I was reading section 9.2 Long-Term Credential Mechanism of the > draft-ietf-tram-stunbis-02 document, and I came a cross the following > statement: > > > "Note that the long-term credential mechanism cannot be used to > protect indications, since indications cannot be challenged. Usages > utilizing indications must either use a short-term credential or omit > authentication and message integrity for them." > > > I am not sure that I understand the reason for this statement. > > After the client is able to authenticate to the server and get the realm, > nonce, and maybe the salt from the server, the client should be able to > create the key that will be used with the HMAC function. > > At this stage either side should be able to create an HMAC for any request, > including Indication. In the case that the receiving side failed to > validate the HMAC for an Indication it should just drop it on the floor. > > Regards, > Rifaat > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > --089e01176c7fee9a00051228d2a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
True, but that nonce may have expired by the time the indi= cation is sent.

On Wed, Mar 25, 2015 at 8:37 PM, Rifaat Shekh-Yusef &= lt;rifaat.ietf@g= mail.com> wrote:
Hi,

I was reading section 9.2 Long-T= erm Credential Mechanism of the=C2=A0
draft-ietf-tram-stunbis-02 = document, and I came a cross the following=C2=A0
statement:
=


=C2=A0 "Note that the long-term cre= dential mechanism cannot be used to
=C2=A0 =C2=A0protect indicati= ons, since indications cannot be challenged.=C2=A0 Usages
=C2=A0 = =C2=A0utilizing indications must either use a short-term credential or omit=
=C2=A0 =C2=A0authentication and message integrity for them."= ;


I am not sure that I understand t= he reason for this statement.

After the client is = able to authenticate to the server and get the realm,
nonce, and = maybe the salt from the server, the client should be able to
crea= te the key that will be used with the HMAC function.

At this stage either side should be able to create an HMAC for any reque= st,
including Indication. In the case that the receiving side fai= led to=C2=A0
validate the HMAC for an Indication it should just d= rop it on the floor.

Regards,
=C2=A0Rifa= at


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


--089e01176c7fee9a00051228d2a5-- From nobody Wed Mar 25 21:57:41 2015 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 8B23F1A92FF for ; Wed, 25 Mar 2015 21:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, 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 TM1i8jo55l9E for ; Wed, 25 Mar 2015 21:57:39 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06ED81A914F for ; Wed, 25 Mar 2015 21:57:39 -0700 (PDT) Received: by wibgn9 with SMTP id gn9so68754448wib.1 for ; Wed, 25 Mar 2015 21:57:37 -0700 (PDT) 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=rb7Qja0NrmoJBc5IiN4rTJk2OcAZcvsToP5mXrnBiu8=; b=FlQ9h/t0MuCKtPwT1vhg8mbQ5Qj80cpoR8GQQFkU5WZ14dFP+ox378pdgzTc7UXcrw l9GgIefJYbGhNfDyUSS5eokUZkPvGpuKKrcGZEEPy8pede7qVu8zbw4RvVRLTHTVPN6V qjLeZMhAZsZodHpRqkToh5yAOb4sC53pYCtGgqfffq4+IhamRgrlXqBz/Iu7tu+AjS3s Vc33fp6lJSaNAvw+hD0qtCaB/w1eMMDPE+mUstnNNWKTXQl6lXoiqEnfQBSpbTJUAsdO w+lewAN3A95q0ZdoIEM0SotpRAOi36Zcn26G/tDhfRMA76YWtngasveUrlgjodJZy7O9 OpTw== MIME-Version: 1.0 X-Received: by 10.180.75.243 with SMTP id f19mr43675709wiw.94.1427345857816; Wed, 25 Mar 2015 21:57:37 -0700 (PDT) Received: by 10.194.190.18 with HTTP; Wed, 25 Mar 2015 21:57:37 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 Mar 2015 21:57:37 -0700 Message-ID: From: Oleg Moskalenko To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Rifaat Shekh-Yusef , "tram@ietf.org" Subject: Re: [tram] draft-ietf-tram-stunbis-02 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, 26 Mar 2015 04:57:40 -0000 Another reason is that indications can be used for high-volume traffic (like data traffic) and we may not want to associate extra CPU load with each indication packet. The indications are usually used either over secure channel (TLS or DTLS) or contain secured payload (like SRTP). On Wed, Mar 25, 2015 at 8:43 PM, Justin Uberti wrote: > True, but that nonce may have expired by the time the indication is sent. > > On Wed, Mar 25, 2015 at 8:37 PM, Rifaat Shekh-Yusef > wrote: >> >> Hi, >> >> I was reading section 9.2 Long-Term Credential Mechanism of the >> draft-ietf-tram-stunbis-02 document, and I came a cross the following >> statement: >> >> >> "Note that the long-term credential mechanism cannot be used to >> protect indications, since indications cannot be challenged. Usages >> utilizing indications must either use a short-term credential or omit >> authentication and message integrity for them." >> >> >> I am not sure that I understand the reason for this statement. >> >> After the client is able to authenticate to the server and get the realm, >> nonce, and maybe the salt from the server, the client should be able to >> create the key that will be used with the HMAC function. >> >> At this stage either side should be able to create an HMAC for any >> request, >> including Indication. In the case that the receiving side failed to >> validate the HMAC for an Indication it should just drop it on the floor. >> >> Regards, >> Rifaat >> >> >> _______________________________________________ >> 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 Wed Mar 25 23:02:09 2015 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 69EF21B2BAE for ; Wed, 25 Mar 2015 23:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6OzXUwXBwV5l for ; Wed, 25 Mar 2015 23:02:06 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1CD51B2B9D for ; Wed, 25 Mar 2015 23:01:51 -0700 (PDT) Received: by ignm3 with SMTP id m3so7828987ign.0 for ; Wed, 25 Mar 2015 23:01:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=k1mN8IPA8yE10XnN0qSb05VmhJEMBeb7C8oSyF31M2I=; b=msPQ57Z6pvpaV1R3Eay68liZwuoRJd3if2xhZnbHFnDAeXJ91ZTrPj7G91S2sxXUSc fBEjoFyc0Ksr3a5I1NnRQXP3B5tuK6B2/WIO5rF40MZZGXz/GUyZynDyreXO2LMXNDSp 2f7r9e7KFN+hmLmAnqmmETB03QVa7WPa07ga+GG0sTP/hOZgFWpXzrJmt/16Z3UCDJM/ PdURf9quJ+2Qjq2VMJg7dBnULPW4S9+bp3PAhv0IKoXRbdruYNG6cNQ90DZWNeR/+UBV gAoncJl4fLibkNRC6UAOVBVEPhLmA6Bp4+q2gkX81yCK/8i9i7fkf3gXd7CQNF+lJIYC 6dOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=k1mN8IPA8yE10XnN0qSb05VmhJEMBeb7C8oSyF31M2I=; b=A31ByxL9NwoMWwV0C3LTRLQHL3XAhqf24r95rmkgu+NRW+I5DStmcRvymFR222dq4y ttfS6wDRwC/ID21x/nQBgMGXqxlPBRtGgS8Q6MpkKHEGbZGzQq6MZlWo1H6pd0IF1f3k M4VHak3Yr3cwXnmDnhPCyfRtQm0WqWoFRN1bABp9fau6hqY8Zg96ZyoV7X5pwGaqDqtb upt9oIuUBDO9S9h8qP1OC2mxobXMpICa+arrfl8f1lJruq5Kdt9IYTqO31Asf6VTLll9 4VtqX02PfcPvVuZPM9V1QfB8t/wZkLO/33Yw6sf+a6pbwyrRmGLtYvp4aD6j2Oevi4jZ an4g== X-Gm-Message-State: ALoCoQkBoHcRcmnHN0eticzjRNBaFBBc7CWgEAIn+GOpoOHLJSolA7ugugqv5sRpiZgi+M4Wrx9F X-Received: by 10.107.169.146 with SMTP id f18mr19288523ioj.6.1427349710892; Wed, 25 Mar 2015 23:01:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.64.42 with HTTP; Wed, 25 Mar 2015 23:01:30 -0700 (PDT) From: Justin Uberti Date: Thu, 26 Mar 2015 01:01:30 -0500 Message-ID: To: "tram@ietf.org" Content-Type: multipart/alternative; boundary=001a11426ae47d2bc505122ac060 Archived-At: Subject: [tram] Comments on draft-ietf-tram-turnbis-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: Thu, 26 Mar 2015 06:02:07 -0000 --001a11426ae47d2bc505122ac060 Content-Type: text/plain; charset=UTF-8 better late than never: S 6.1: I don't think that we need to forbid using RAF with AAF. It should be possible to do RAF(v4) with AAF(v6), RAF(v6) with AAF(v4), or AAF(v6) by itself, all with the same meaning. S 7.1: I think the client should include RAF for the bindings that it wants to keep, not AAF. AAF is only useful in the ALLOCATE, where the client doesn't know if the server supports AAF. S 9.1: I don't think we want to support CreatePermissions with multiple addresses. It doesn't save anything other than 2 packets and just makes life more complicated. S 11.1: How would you do a ChannelBind with multiple addresses? Sent packets go to both destinations? Again, this seems complex with no good reason. S 15.6/15.11: It would be good to separate the RAF/AAF payload definition out so that it doesn't need to be repeated in both sections. S 15.12: The error code field is too small to hold error codes (8 bits). I think this should use the same structure as ERROR-CODE from 5389, but use some of the reserved bits for family. --001a11426ae47d2bc505122ac060 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
better late than never:

S 6.1:
I don't think that we need to forbid using RAF with AAF. It should be= possible to do RAF(v4) with AAF(v6), RAF(v6) with AAF(v4), or AAF(v6) by i= tself, all with the same meaning.=C2=A0

S 7.1:
I think the client should include RAF for the bindings that it wants= to keep, not AAF. AAF is only useful in the ALLOCATE, where the client doe= sn't know if the server supports AAF.

S 9.1:
I don't think we want to support CreatePermissions with multip= le addresses. It doesn't save anything other than 2 packets and just ma= kes life more complicated.

S 11.1:
How w= ould you do a ChannelBind with multiple addresses? Sent packets go to both = destinations? Again, this seems complex with no good reason.

=
S 15.6/15.11:
It would be good to separate the RAF/AAF= payload definition out so that it doesn't need to be repeated in both = sections.

S 15.12:
The error code field = is too small to hold error codes (8 bits). I think this should use the same= structure as ERROR-CODE from 5389, but use some of the reserved bits for f= amily.

--001a11426ae47d2bc505122ac060-- From nobody Thu Mar 26 04:07:05 2015 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 67C341B2C66 for ; Thu, 26 Mar 2015 04:07:03 -0700 (PDT) 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 jYtUp10I80DN for ; Thu, 26 Mar 2015 04:06:59 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41E231B2C5E for ; Thu, 26 Mar 2015 04:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14582; q=dns/txt; s=iport; t=1427368019; x=1428577619; h=from:to:subject:date:message-id:mime-version; bh=Qe7coty0V/qkuTeQpvtp5WWy28RVqGfFqpx9gEeCy40=; b=WQ0cfMLkbWIrponWFI/ZHKlVoypPM3KJLlm+pM7KNPLJDJfuSfiffVjE EkPdmt7vtf4i917k+HOJY0Qg9JOk1Q4hMyTZgk+ZKV2Zb0aV1Rd4I7BFB JSr+JO1TeYYBuQ4fm4tOvhN+I/5BYzFbHXbpUm5TlPeScKXr/9yqH/6jG A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DACQD25hNV/4wNJK1cgkFDUloEgw6/U4gwAhyBQEwBAQEBAQF9hBQBAQEEIwoaRAEIDgMEAQELHQMCBDAUCQkBBAESCBGIFrAkhRaVCAEBAQEBAQEBAQEBAQEBAQEBAQEBAReLIYRFFiGCaS+BFgWQUIsKgzCPYSKDbm+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.11,471,1422921600"; d="scan'208,217";a="135581332" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-5.cisco.com with ESMTP; 26 Mar 2015 11:06:59 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t2QB6wM5026609 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Mar 2015 11:06:58 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.80]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Thu, 26 Mar 2015 06:06:58 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Justin Uberti , "tram@ietf.org" Thread-Topic: [tram] Comments on draft-ietf-tram-turnbis-01 Thread-Index: AdBntPY5ANaPCcypQFyW0ZUNvQto2Q== Date: Thu, 26 Mar 2015 11:06:58 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A366D0EDE@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.64.106] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A366D0EDExmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-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: Thu, 26 Mar 2015 11:07:03 -0000 --_000_913383AAA69FF945B8F946018B75898A366D0EDExmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSnVzdGluLA0KDQpUaGFua3MgZm9yIHRoZSBjb21tZW50cy4gUGxlYXNlIHNlZSBpbmxpbmUg W1RSXQ0KDQpGcm9tOiB0cmFtIFttYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgSnVzdGluIFViZXJ0aQ0KU2VudDogVGh1cnNkYXksIE1hcmNoIDI2LCAyMDE1IDExOjMy IEFNDQpUbzogdHJhbUBpZXRmLm9yZw0KU3ViamVjdDogW3RyYW1dIENvbW1lbnRzIG9uIGRyYWZ0 LWlldGYtdHJhbS10dXJuYmlzLTAxDQoNCmJldHRlciBsYXRlIHRoYW4gbmV2ZXI6DQoNClMgNi4x Og0KSSBkb24ndCB0aGluayB0aGF0IHdlIG5lZWQgdG8gZm9yYmlkIHVzaW5nIFJBRiB3aXRoIEFB Ri4gSXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIGRvIFJBRih2NCkgd2l0aCBBQUYodjYpLCBSQUYo djYpIHdpdGggQUFGKHY0KSwgb3IgQUFGKHY2KSBieSBpdHNlbGYsIGFsbCB3aXRoIHRoZSBzYW1l IG1lYW5pbmcuDQoNCltUUl0gUkFGIGlzICBjb21wcmVoZW5zaW9uLXJlcXVpcmVkIGF0dHJpYnV0 ZSB3aGVyZWFzIEFBRiBpcyBjb21wcmVoZW5zaW9uLW9wdGlvbmFsIGF0dHJpYnV0ZSwgSWYgY2xp ZW50IHVzZXMgYm90aCBSQUYgKyBBQUYgYW5kIHRoZSBzZXJ2ZXIgZG9lcyBub3QgdW5kZXJzdGFu ZCBSQUYgdGhlbiB0aGUgcmVxdWVzdCBjb3VsZCBmYWlsLiBJIGRvbuKAmXQgc2VlIGFueSBhZHZh bnRhZ2Ugb2YgdXNpbmcgYm90aCBSQUYgYW5kIEFBRiB0b2dldGhlci4NCg0KUyA3LjE6DQpJIHRo aW5rIHRoZSBjbGllbnQgc2hvdWxkIGluY2x1ZGUgUkFGIGZvciB0aGUgYmluZGluZ3MgdGhhdCBp dCB3YW50cyB0byBrZWVwLCBub3QgQUFGLiBBQUYgaXMgb25seSB1c2VmdWwgaW4gdGhlIEFMTE9D QVRFLCB3aGVyZSB0aGUgY2xpZW50IGRvZXNuJ3Qga25vdyBpZiB0aGUgc2VydmVyIHN1cHBvcnRz IEFBRi4NCg0KW1RSXSBJZiBBQUYgaXMgdXNlZCBmb3IgQWxsb2NhdGlvbiB0aGVuIHRoZXJlIGlz IG5vIHJlYXNvbiB3aHkgUkFGIHNob3VsZCBiZSB1c2VkIGZvciB0aGUgYmluZGluZyAoc2VydmVy IG1heSBub3Qgc3VwcG9ydCBSQUYgYW5kIGl0IHdpbGwgcmVzdWx0IGluIGZhaWx1cmUgdG8gcmVm cmVzaCkuDQoNClMgOS4xOg0KSSBkb24ndCB0aGluayB3ZSB3YW50IHRvIHN1cHBvcnQgQ3JlYXRl UGVybWlzc2lvbnMgd2l0aCBtdWx0aXBsZSBhZGRyZXNzZXMuIEl0IGRvZXNuJ3Qgc2F2ZSBhbnl0 aGluZyBvdGhlciB0aGFuIDIgcGFja2V0cyBhbmQganVzdCBtYWtlcyBsaWZlIG1vcmUgY29tcGxp Y2F0ZWQuDQoNCltUUl0gUGxlYXNlIGNsYXJpZnkgd2h5IGl0IGNvbXBsaWNhdGVzIGltcGxlbWVu dGF0aW9uID8NCg0KUyAxMS4xOg0KSG93IHdvdWxkIHlvdSBkbyBhIENoYW5uZWxCaW5kIHdpdGgg bXVsdGlwbGUgYWRkcmVzc2VzPyBTZW50IHBhY2tldHMgZ28gdG8gYm90aCBkZXN0aW5hdGlvbnM/ IEFnYWluLCB0aGlzIHNlZW1zIGNvbXBsZXggd2l0aCBubyBnb29kIHJlYXNvbi4NCg0KW1RSXSBB Z3JlZWQsIHdpbGwgZml4IGluIHRoZSBuZXh0IHJldmVyc2lvbi4NCg0KUyAxNS42LzE1LjExOg0K SXQgd291bGQgYmUgZ29vZCB0byBzZXBhcmF0ZSB0aGUgUkFGL0FBRiBwYXlsb2FkIGRlZmluaXRp b24gb3V0IHNvIHRoYXQgaXQgZG9lc24ndCBuZWVkIHRvIGJlIHJlcGVhdGVkIGluIGJvdGggc2Vj dGlvbnMuDQoNCltUUl0gVGhlIHBheWxvYWQgdGV4dCBpcyBub3QgbGFyZ2UgZW5vdWdoIGZvciBh IHNlcGFyYXRlIHNlY3Rpb24uDQoNClMgMTUuMTI6DQpUaGUgZXJyb3IgY29kZSBmaWVsZCBpcyB0 b28gc21hbGwgdG8gaG9sZCBlcnJvciBjb2RlcyAoOCBiaXRzKS4gSSB0aGluayB0aGlzIHNob3Vs ZCB1c2UgdGhlIHNhbWUgc3RydWN0dXJlIGFzIEVSUk9SLUNPREUgZnJvbSA1Mzg5LCBidXQgdXNl IHNvbWUgb2YgdGhlIHJlc2VydmVkIGJpdHMgZm9yIGZhbWlseS4NCg0KW1RSXSBZZXMsIHdpbGwg Zml4IHRoYXQgaW4gdGhlIG5leHQgcmV2aXNpb24uDQoNCi1UaXJ1DQoNCg0K --_000_913383AAA69FF945B8F946018B75898A366D0EDExmbrcdx10ciscoc_ 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 dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5I aSBKdXN0aW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHRoZSBjb21tZW50cy4gUGxlYXNlIHNlZSBp bmxpbmUgW1RSXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiB0 cmFtIFttYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5K dXN0aW4gVWJlcnRpPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBNYXJjaCAyNiwgMjAxNSAx MTozMiBBTTxicj4NCjxiPlRvOjwvYj4gdHJhbUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9i PiBbdHJhbV0gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDE8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YmV0dGVyIGxhdGUg dGhhbiBuZXZlcjo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlMgNi4xOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSBkb24ndCB0aGluayB0aGF0IHdlIG5lZWQgdG8gZm9yYmlkIHVzaW5nIFJBRiB3aXRoIEFB Ri4gSXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIGRvIFJBRih2NCkgd2l0aCBBQUYodjYpLCBSQUYo djYpIHdpdGggQUFGKHY0KSwgb3IgQUFGKHY2KSBieSBpdHNlbGYsIGFsbCB3aXRoIHRoZSBzYW1l IG1lYW5pbmcuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPltUUl0gUkFGIGlzJm5ic3A7IGNvbXByZWhlbnNpb24tcmVxdWly ZWQgYXR0cmlidXRlIHdoZXJlYXMgQUFGIGlzIGNvbXByZWhlbnNpb24tb3B0aW9uYWwgYXR0cmli dXRlLCBJZiBjbGllbnQgdXNlcyBib3RoIFJBRiAmIzQzOyBBQUYgYW5kIHRoZSBzZXJ2ZXIgZG9l cyBub3QgdW5kZXJzdGFuZA0KIFJBRiB0aGVuIHRoZSByZXF1ZXN0IGNvdWxkIGZhaWwuIEkgZG9u 4oCZdCBzZWUgYW55IGFkdmFudGFnZSBvZiB1c2luZyBib3RoIFJBRiBhbmQgQUFGIHRvZ2V0aGVy LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TIDcuMTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhlIGNs aWVudCBzaG91bGQgaW5jbHVkZSBSQUYgZm9yIHRoZSBiaW5kaW5ncyB0aGF0IGl0IHdhbnRzIHRv IGtlZXAsIG5vdCBBQUYuIEFBRiBpcyBvbmx5IHVzZWZ1bCBpbiB0aGUgQUxMT0NBVEUsIHdoZXJl IHRoZSBjbGllbnQgZG9lc24ndCBrbm93IGlmIHRoZSBzZXJ2ZXIgc3VwcG9ydHMgQUFGLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5b VFJdIElmIEFBRiBpcyB1c2VkIGZvciBBbGxvY2F0aW9uIHRoZW4gdGhlcmUgaXMgbm8gcmVhc29u IHdoeSBSQUYgc2hvdWxkIGJlIHVzZWQgZm9yIHRoZSBiaW5kaW5nIChzZXJ2ZXIgbWF5IG5vdCBz dXBwb3J0IFJBRiBhbmQgaXQgd2lsbCByZXN1bHQgaW4gZmFpbHVyZQ0KIHRvIHJlZnJlc2gpLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TIDkuMTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3QgdGhpbmsgd2Ug d2FudCB0byBzdXBwb3J0IENyZWF0ZVBlcm1pc3Npb25zIHdpdGggbXVsdGlwbGUgYWRkcmVzc2Vz LiBJdCBkb2Vzbid0IHNhdmUgYW55dGhpbmcgb3RoZXIgdGhhbiAyIHBhY2tldHMgYW5kIGp1c3Qg bWFrZXMgbGlmZSBtb3JlIGNvbXBsaWNhdGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bVFJdIFBsZWFzZSBjbGFyaWZ5IHdoeSBp dCBjb21wbGljYXRlcyBpbXBsZW1lbnRhdGlvbiA/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlMgMTEuMTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkhvdyB3b3VsZCB5b3UgZG8gYSBDaGFubmVsQmluZCB3aXRoIG11bHRp cGxlIGFkZHJlc3Nlcz8gU2VudCBwYWNrZXRzIGdvIHRvIGJvdGggZGVzdGluYXRpb25zPyBBZ2Fp biwgdGhpcyBzZWVtcyBjb21wbGV4IHdpdGggbm8gZ29vZCByZWFzb24uPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltUUl0gQWdyZWVk LCB3aWxsIGZpeCBpbiB0aGUgbmV4dCByZXZlcnNpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TIDE1LjYvMTUuMTE6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCB3b3VsZCBi ZSBnb29kIHRvIHNlcGFyYXRlIHRoZSBSQUYvQUFGIHBheWxvYWQgZGVmaW5pdGlvbiBvdXQgc28g dGhhdCBpdCBkb2Vzbid0IG5lZWQgdG8gYmUgcmVwZWF0ZWQgaW4gYm90aCBzZWN0aW9ucy48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ W1RSXSBUaGUgcGF5bG9hZCB0ZXh0IGlzIG5vdCBsYXJnZSBlbm91Z2ggZm9yIGEgc2VwYXJhdGUg c2VjdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlMgMTUuMTI6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGUgZXJyb3IgY29kZSBmaWVsZCBpcyB0b28gc21hbGwgdG8gaG9s ZCBlcnJvciBjb2RlcyAoOCBiaXRzKS4gSSB0aGluayB0aGlzIHNob3VsZCB1c2UgdGhlIHNhbWUg c3RydWN0dXJlIGFzIEVSUk9SLUNPREUgZnJvbSA1Mzg5LCBidXQgdXNlIHNvbWUgb2YgdGhlIHJl c2VydmVkIGJpdHMgZm9yIGZhbWlseS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1RSXSBZZXMsIHdpbGwgZml4IHRoYXQgaW4gdGhl IG5leHQgcmV2aXNpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tVGlydTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_913383AAA69FF945B8F946018B75898A366D0EDExmbrcdx10ciscoc_-- From nobody Thu Mar 26 04:47:36 2015 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 64F171B2C96 for ; Thu, 26 Mar 2015 04:47:35 -0700 (PDT) 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 BIpF7Zfjwwe4 for ; Thu, 26 Mar 2015 04:47:33 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9151C1B2C76 for ; Thu, 26 Mar 2015 04:47:33 -0700 (PDT) Received: by oigz129 with SMTP id z129so1782680oig.1 for ; Thu, 26 Mar 2015 04:47:33 -0700 (PDT) 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=SMtqaj/wA8chnsSWQ8csu9UpJRkCQ4+w9u/uCHo22E8=; b=o0JWBabVF1/u1Drepu4L28XCMXz59RoIIluoJ/CpnUrymtJQFphJevQ0P/E0azI4i3 /8kYYzfJKkGzzrobnLtJzp6Un04Z9RGtK3Vwz/sVe9nSQR3GQuHhqbCz9qBV5ThqN9Ot PFlPXLXqL69nRDTtCeIPW8dkTwcyoDc+fzTrSLxLWVODf0bxSEC/6c9dTzABd/BvF6KD ++RwUnVFw5utgZ/i/3Tu+vDEJTTJjqLv6XQlnqsU6KCUL4EVm/TkZncnQoQ0bq45/LhH CziGfgbbFLkHEuPVmhyt3/B3wkIxnQ7un10pFG/qYU7zHNzGGQfwaqZCbPkByT2nhBq1 JEgQ== MIME-Version: 1.0 X-Received: by 10.60.129.161 with SMTP id nx1mr11573028oeb.77.1427370453115; Thu, 26 Mar 2015 04:47:33 -0700 (PDT) Received: by 10.202.93.69 with HTTP; Thu, 26 Mar 2015 04:47:33 -0700 (PDT) In-Reply-To: References: Date: Thu, 26 Mar 2015 06:47:33 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Justin Uberti Content-Type: multipart/alternative; boundary=047d7b2e0b3fd226f405122f9400 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] draft-ietf-tram-stunbis-02 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, 26 Mar 2015 11:47:35 -0000 --047d7b2e0b3fd226f405122f9400 Content-Type: text/plain; charset=ISO-8859-1 Why is the nonce needed in this case? you cannot challenge the request anyway. Maybe a client nonce is needed here instead? Regards, Rifaat On Wed, Mar 25, 2015 at 10:43 PM, Justin Uberti wrote: > True, but that nonce may have expired by the time the indication is sent. > > On Wed, Mar 25, 2015 at 8:37 PM, Rifaat Shekh-Yusef > wrote: > >> Hi, >> >> I was reading section 9.2 Long-Term Credential Mechanism of the >> draft-ietf-tram-stunbis-02 document, and I came a cross the following >> statement: >> >> >> "Note that the long-term credential mechanism cannot be used to >> protect indications, since indications cannot be challenged. Usages >> utilizing indications must either use a short-term credential or omit >> authentication and message integrity for them." >> >> >> I am not sure that I understand the reason for this statement. >> >> After the client is able to authenticate to the server and get the realm, >> nonce, and maybe the salt from the server, the client should be able to >> create the key that will be used with the HMAC function. >> >> At this stage either side should be able to create an HMAC for any >> request, >> including Indication. In the case that the receiving side failed to >> validate the HMAC for an Indication it should just drop it on the floor. >> >> Regards, >> Rifaat >> >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> >> > --047d7b2e0b3fd226f405122f9400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Why is the nonce needed in this case? you cannot challenge= the request anyway.
Maybe a client nonce is needed here instead?
=

Regards,
=A0Rifaat

=

On Wed, Mar 25, 2= 015 at 10:43 PM, Justin Uberti <juberti@google.com> wrote:<= br>
True, but that nonce may= have expired by the time the indication is sent.

On Wed, Mar 25= , 2015 at 8:37 PM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Hi,

I was reading se= ction 9.2 Long-Term Credential Mechanism of the=A0
draft-ietf-tra= m-stunbis-02 document, and I came a cross the following=A0
statem= ent:


=A0 "Note that the long-t= erm credential mechanism cannot be used to
=A0 =A0protect indicat= ions, since indications cannot be challenged.=A0 Usages
=A0 =A0ut= ilizing indications must either use a short-term credential or omit
=A0 =A0authentication and message integrity for them."

I am not sure that I understand the reason for = this statement.

After the client is able to authen= ticate to the server and get the realm,
nonce, and maybe the salt= from the server, the client should be able to
create the key tha= t will be used with the HMAC function.

At this sta= ge either side should be able to create an HMAC for any request,
= including Indication. In the case that the receiving side failed to=A0
validate the HMAC for an Indication it should just drop it on the flo= or.

Regards,
=A0Rifaat


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



--047d7b2e0b3fd226f405122f9400-- From nobody Thu Mar 26 04:59:11 2015 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 E9D921B2C9A for ; Thu, 26 Mar 2015 04:59:09 -0700 (PDT) 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 TSoQwfXP-uQD for ; Thu, 26 Mar 2015 04:59:06 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C29F21B2CA0 for ; Thu, 26 Mar 2015 04:59:06 -0700 (PDT) Received: by oigz129 with SMTP id z129so1998884oig.1 for ; Thu, 26 Mar 2015 04:59:06 -0700 (PDT) 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=i+a9anFUlqqu6M433akvckGWInxvmcfj30+nJkMFKGg=; b=PCdjB8k6sBGFipzYASEfKGa4OKA+zRsnvdzm8+29AxWOSdggvd8sBoEjCV9Z/fATSJ tf4NCwcqB6QOkxYPuazJO+MYqvsQKnR3HQnzE3sBIuCSXPSEpRsQn825QWicGd5V411n 1vrTOEAsQyOSO3Bq+JO1lBN6WHl4cP/qeDw97ztto9mes+m/MF0CBmP4Xo69gV5f0yxr DdGraUoLvb/HeukngRcPTmJ4jISsE+Ttr1Xts6ZiZH8523BrvpRoOGzPDlJ3YCzzvY1V Mtf7StJwbmSbOWOOxoWUvr8Z9ti4LLuV9UbZ7WMLx8c7P/p1xcSnzIJTKVv+b9zY2dJw XxZw== MIME-Version: 1.0 X-Received: by 10.60.129.161 with SMTP id nx1mr11613048oeb.77.1427371146287; Thu, 26 Mar 2015 04:59:06 -0700 (PDT) Received: by 10.202.93.69 with HTTP; Thu, 26 Mar 2015 04:59:06 -0700 (PDT) In-Reply-To: References: Date: Thu, 26 Mar 2015 06:59:06 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=047d7b2e0b3f231dd905122fbe36 Archived-At: Cc: "tram@ietf.org" , Justin Uberti Subject: Re: [tram] draft-ietf-tram-stunbis-02 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, 26 Mar 2015 11:59:10 -0000 --047d7b2e0b3f231dd905122fbe36 Content-Type: text/plain; charset=ISO-8859-1 Inline... On Wed, Mar 25, 2015 at 11:57 PM, Oleg Moskalenko wrote: > Another reason is that indications can be used for high-volume traffic > (like data traffic) and we may not want to associate extra CPU load > with each indication packet. > > If you want a secure solution you better be ready to pay the cost for that. Did you quantify that "extra CPU load"?. > The indications are usually used either over secure channel (TLS or > DTLS) or contain secured payload (like SRTP). > > I thought that the draft was talking about using STUN over non-secured channels too; right? Securing the payload would not protect you against replay attacks. Regards, Rifaat > > On Wed, Mar 25, 2015 at 8:43 PM, Justin Uberti wrote: > > True, but that nonce may have expired by the time the indication is sent. > > > > On Wed, Mar 25, 2015 at 8:37 PM, Rifaat Shekh-Yusef < > rifaat.ietf@gmail.com> > > wrote: > >> > >> Hi, > >> > >> I was reading section 9.2 Long-Term Credential Mechanism of the > >> draft-ietf-tram-stunbis-02 document, and I came a cross the following > >> statement: > >> > >> > >> "Note that the long-term credential mechanism cannot be used to > >> protect indications, since indications cannot be challenged. Usages > >> utilizing indications must either use a short-term credential or omit > >> authentication and message integrity for them." > >> > >> > >> I am not sure that I understand the reason for this statement. > >> > >> After the client is able to authenticate to the server and get the > realm, > >> nonce, and maybe the salt from the server, the client should be able to > >> create the key that will be used with the HMAC function. > >> > >> At this stage either side should be able to create an HMAC for any > >> request, > >> including Indication. In the case that the receiving side failed to > >> validate the HMAC for an Indication it should just drop it on the floor. > >> > >> Regards, > >> Rifaat > >> > >> > >> _______________________________________________ > >> 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 > > > --047d7b2e0b3f231dd905122fbe36 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Inline...

On Wed, Mar 25, 2015 at 11:57 PM, Oleg Moskalenko <mom040267@gm= ail.com> wrote:
Another rea= son is that indications can be used for high-volume traffic
(like data traffic) and we may not want to associate extra CPU load
with each indication packet.


If you want a secure solution you bett= er be ready to pay the cost for that.
Did you quantify that "= ;extra CPU load"?.

=A0
The indications are usually used either over secure channel (TLS or
DTLS) or contain secured payload (like SRTP).

<= br>
I thought that the draft was talking about using STUN over no= n-secured channels too; right?
Securing the payload would not pro= tect you against replay attacks.

Regards,
=A0Rifaat

=A0

On Wed, Mar 25, 2015 at 8:43 PM, Justin Uberti <juberti@google.com> wrote:
> True, but that nonce may have expired by the time the indication is se= nt.
>
> On Wed, Mar 25, 2015 at 8:37 PM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
> wrote:
>>
>> Hi,
>>
>> I was reading section 9.2 Long-Term Credential Mechanism of the >> draft-ietf-tram-stunbis-02 document, and I came a cross the follow= ing
>> statement:
>>
>>
>>=A0 =A0"Note that the long-term credential mechanism cannot be= used to
>>=A0 =A0 protect indications, since indications cannot be challenged= .=A0 Usages
>>=A0 =A0 utilizing indications must either use a short-term credenti= al or omit
>>=A0 =A0 authentication and message integrity for them."
>>
>>
>> I am not sure that I understand the reason for this statement.
>>
>> After the client is able to authenticate to the server and get the= realm,
>> nonce, and maybe the salt from the server, the client should be ab= le to
>> create the key that will be used with the HMAC function.
>>
>> At this stage either side should be able to create an HMAC for any=
>> request,
>> including Indication. In the case that the receiving side failed t= o
>> validate the HMAC for an Indication it should just drop it on the = floor.
>>
>> Regards,
>>=A0 Rifaat
>>
>>
>> _______________________________________________
>> 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
>

--047d7b2e0b3f231dd905122fbe36-- From nobody Thu Mar 26 05:16:35 2015 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 175891B2CCE for ; Thu, 26 Mar 2015 05:16:34 -0700 (PDT) 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 hwHQ9zpbDWbD for ; Thu, 26 Mar 2015 05:16:27 -0700 (PDT) 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 3DE131B2CD5 for ; Thu, 26 Mar 2015 05:16:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11403; q=dns/txt; s=iport; t=1427372187; x=1428581787; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8BfIYFT6cofqW9X2IRdSVzaB2lPiTK32JV5iSiDU5Qo=; b=dVl37xQCmaFmi+u1Fuxr4txFQ9gVEE2nStI5YX4n1dYYw8kNG8ZYjAhk nwf8k2LlAtx8p2KyGlhPyQkD0+pzP1gHdZ0qP5RILVDsiViPTDgBTsCuj 4iI3I04jE4cRMx6oRh4r0K1VAFB1Bv5F5ADOQU2rkNr0Y5S7Cta2qUW7w 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DECQDk9xNV/4wNJK1cgkNDUloEwm6CMQEJhXUCgVxMAQEBAQEBfYQUAQEBBAEBASpBBgUQAgEIEQQBAQEKHQchBgsUCQgCBAENBQgTiAADEQ3FAQ2FRQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEiyGCR4F+LQQGAQaDEYEWBYYZijeIIo9QhikiggIcgVBvgQQkHH8BAQE X-IronPort-AV: E=Sophos;i="5.11,471,1422921600"; d="scan'208,217";a="135595560" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP; 26 Mar 2015 12:16:26 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t2QCGQeW030452 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Mar 2015 12:16:26 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.80]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Thu, 26 Mar 2015 07:16:26 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Rifaat Shekh-Yusef , Oleg Moskalenko Thread-Topic: [tram] draft-ietf-tram-stunbis-02 Thread-Index: AQHQZ2V/6K0LuPx3OEyhSm4wQoB2qJ0ucxMAgAAUtYCAAHXDAP//raFg Date: Thu, 26 Mar 2015 12:16:25 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A366D0F67@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: [173.39.64.106] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A366D0F67xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" , Justin Uberti Subject: Re: [tram] draft-ietf-tram-stunbis-02 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, 26 Mar 2015 12:16:34 -0000 --_000_913383AAA69FF945B8F946018B75898A366D0F67xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable SRTP can handle replay attacks. Active attacker can consume the indication = message so integrity protection is of no help; Passive attacker sniffing pa= ckets on the wire can replay the indications with or without message integr= ity and remote peer will discard SRTP packets with old sequence number. -Tiru From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Rifaat Shekh-Yusef Sent: Thursday, March 26, 2015 5:29 PM To: Oleg Moskalenko Cc: tram@ietf.org; Justin Uberti Subject: Re: [tram] draft-ietf-tram-stunbis-02 Inline... On Wed, Mar 25, 2015 at 11:57 PM, Oleg Moskalenko > wrote: Another reason is that indications can be used for high-volume traffic (like data traffic) and we may not want to associate extra CPU load with each indication packet. If you want a secure solution you better be ready to pay the cost for that. Did you quantify that "extra CPU load"?. The indications are usually used either over secure channel (TLS or DTLS) or contain secured payload (like SRTP). I thought that the draft was talking about using STUN over non-secured chan= nels too; right? Securing the payload would not protect you against replay attacks. Regards, Rifaat On Wed, Mar 25, 2015 at 8:43 PM, Justin Uberti > wrote: > True, but that nonce may have expired by the time the indication is sent. > > On Wed, Mar 25, 2015 at 8:37 PM, Rifaat Shekh-Yusef > > wrote: >> >> Hi, >> >> I was reading section 9.2 Long-Term Credential Mechanism of the >> draft-ietf-tram-stunbis-02 document, and I came a cross the following >> statement: >> >> >> "Note that the long-term credential mechanism cannot be used to >> protect indications, since indications cannot be challenged. Usages >> utilizing indications must either use a short-term credential or omit >> authentication and message integrity for them." >> >> >> I am not sure that I understand the reason for this statement. >> >> After the client is able to authenticate to the server and get the realm= , >> nonce, and maybe the salt from the server, the client should be able to >> create the key that will be used with the HMAC function. >> >> At this stage either side should be able to create an HMAC for any >> request, >> including Indication. In the case that the receiving side failed to >> validate the HMAC for an Indication it should just drop it on the floor. >> >> Regards, >> Rifaat >> >> >> _______________________________________________ >> 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_913383AAA69FF945B8F946018B75898A366D0F67xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

SRTP can handle replay at= tacks. Active attacker can consume the indication message so integrity prot= ection is of no help; Passive attacker sniffing packets on the wire can replay the indications with or without message integrity a= nd remote peer will discard SRTP packets with old sequence number.

 <= /p>

-Tiru

 <= /p>

From: tram [ma= ilto:tram-bounces@ietf.org] On Behalf Of Rifaat Shekh-Yusef
Sent: Thursday, March 26, 2015 5:29 PM
To: Oleg Moskalenko
Cc: tram@ietf.org; Justin Uberti
Subject: Re: [tram] draft-ietf-tram-stunbis-02

 

Inline...

 

On Wed, Mar 25, 2015 at 11:57 PM, Oleg Moskalenko &l= t;mom040267@gmail.= com> wrote:

Another reason is tha= t indications can be used for high-volume traffic
(like data traffic) and we may not want to associate extra CPU load
with each indication packet.

 

If you want a secure solution you better be ready to= pay the cost for that.

Did you quantify that "extra CPU load"?.

 

 

The indications are usually used either over secure = channel (TLS or
DTLS) or contain secured payload (like SRTP).

 

 

I thought that the draft was talking about using STU= N over non-secured channels too; right?

Securing the payload would not protect you against r= eplay attacks.

 

Regards,

 Rifaat

 

 


On Wed, Mar 25, 2015 at 8:43 PM, Justin Uberti <juberti@google.com> wrote:
> True, but that nonce may have expired by the time the indication is se= nt.
>
> On Wed, Mar 25, 2015 at 8:37 PM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
> wrote:
>>
>> Hi,
>>
>> I was reading section 9.2 Long-Term Credential Mechanism of the >> draft-ietf-tram-stunbis-02 document, and I came a cross the follow= ing
>> statement:
>>
>>
>>   "Note that the long-term credential mechanism can= not be used to
>>    protect indications, since indications cannot be chal= lenged.  Usages
>>    utilizing indications must either use a short-term cr= edential or omit
>>    authentication and message integrity for them."<= br> >>
>>
>> I am not sure that I understand the reason for this statement.
>>
>> After the client is able to authenticate to the server and get the= realm,
>> nonce, and maybe the salt from the server, the client should be ab= le to
>> create the key that will be used with the HMAC function.
>>
>> At this stage either side should be able to create an HMAC for any=
>> request,
>> including Indication. In the case that the receiving side failed t= o
>> validate the HMAC for an Indication it should just drop it on the = floor.
>>
>> Regards,
>>  Rifaat
>>
>>
>> _______________________________________________
>> 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_913383AAA69FF945B8F946018B75898A366D0F67xmbrcdx10ciscoc_-- From nobody Thu Mar 26 06:00:46 2015 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 D58971ACE54 for ; Thu, 26 Mar 2015 06:00:44 -0700 (PDT) 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 DLWYDexaeIdE for ; Thu, 26 Mar 2015 06:00:37 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80B971B2CCE for ; Thu, 26 Mar 2015 06:00:37 -0700 (PDT) Received: by oifl3 with SMTP id l3so48190317oif.0 for ; Thu, 26 Mar 2015 06:00:37 -0700 (PDT) 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=MOCwZYMCoBCp3faugUTDJhiD8hTf3AhKLUd99X6HjvI=; b=0CoON+JvSrfQZrIMHP2Vpe7P+weDAI0Mdo1OYL+pIpLiGiLfwKU8Sf/Bsm6xruZWJx ymAdmnECbji4Vi44WfiGofuMpNeN751rQzPcU5GZ2Gq+tiZM/c+QCbcx4Pq6c+0eoPhx PImRczjqCTxInryw4XLc6AuYkec823VTQy3LFCw7m8c4pJnJ/F+T5rq6BIVsDF2sFs8n eBRUhC8gnLH6TFAD52rDZV31na13/0A7H+0X5kVLQetv9XT10ZpGjVcqCGaxpZXfs8qf mhpRx4aCdGf5hNoTc1MK3Buh+1EvKeqyRLP9sQpPyq15DFBjqH/wwKVXuWd+cuetwKnX 6FVQ== MIME-Version: 1.0 X-Received: by 10.202.44.85 with SMTP id s82mr1573913ois.78.1427374837006; Thu, 26 Mar 2015 06:00:37 -0700 (PDT) Received: by 10.202.93.69 with HTTP; Thu, 26 Mar 2015 06:00:36 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A366D0F67@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A366D0F67@xmb-rcd-x10.cisco.com> Date: Thu, 26 Mar 2015 08:00:36 -0500 Message-ID: From: Rifaat Shekh-Yusef To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=001a1137cfb01f07bb0512309aae Archived-At: Cc: Oleg Moskalenko , "tram@ietf.org" , Justin Uberti Subject: Re: [tram] draft-ietf-tram-stunbis-02 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, 26 Mar 2015 13:00:45 -0000 --001a1137cfb01f07bb0512309aae Content-Type: text/plain; charset=ISO-8859-1 I have not read the whole document, so I do not know how indication is being used. All I am trying to say is that the current statement in the document is not accurate, as there is a way to protect the integrity of the indication. The text should be either removed or clearly state that indication protection is not needed and explain why it is not needed. Regards, Rifaat On Thu, Mar 26, 2015 at 7:16 AM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > SRTP can handle replay attacks. Active attacker can consume the > indication message so integrity protection is of no help; Passive attacker > sniffing packets on the wire can replay the indications with or without > message integrity and remote peer will discard SRTP packets with old > sequence number. > > > > -Tiru > > > > *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Rifaat > Shekh-Yusef > *Sent:* Thursday, March 26, 2015 5:29 PM > *To:* Oleg Moskalenko > *Cc:* tram@ietf.org; Justin Uberti > *Subject:* Re: [tram] draft-ietf-tram-stunbis-02 > > > > Inline... > > > > On Wed, Mar 25, 2015 at 11:57 PM, Oleg Moskalenko > wrote: > > Another reason is that indications can be used for high-volume traffic > (like data traffic) and we may not want to associate extra CPU load > with each indication packet. > > > > If you want a secure solution you better be ready to pay the cost for that. > > Did you quantify that "extra CPU load"?. > > > > > > The indications are usually used either over secure channel (TLS or > DTLS) or contain secured payload (like SRTP). > > > > > > I thought that the draft was talking about using STUN over non-secured > channels too; right? > > Securing the payload would not protect you against replay attacks. > > > > Regards, > > Rifaat > > > > > > > On Wed, Mar 25, 2015 at 8:43 PM, Justin Uberti wrote: > > True, but that nonce may have expired by the time the indication is sent. > > > > On Wed, Mar 25, 2015 at 8:37 PM, Rifaat Shekh-Yusef < > rifaat.ietf@gmail.com> > > wrote: > >> > >> Hi, > >> > >> I was reading section 9.2 Long-Term Credential Mechanism of the > >> draft-ietf-tram-stunbis-02 document, and I came a cross the following > >> statement: > >> > >> > >> "Note that the long-term credential mechanism cannot be used to > >> protect indications, since indications cannot be challenged. Usages > >> utilizing indications must either use a short-term credential or omit > >> authentication and message integrity for them." > >> > >> > >> I am not sure that I understand the reason for this statement. > >> > >> After the client is able to authenticate to the server and get the > realm, > >> nonce, and maybe the salt from the server, the client should be able to > >> create the key that will be used with the HMAC function. > >> > >> At this stage either side should be able to create an HMAC for any > >> request, > >> including Indication. In the case that the receiving side failed to > >> validate the HMAC for an Indication it should just drop it on the floor. > >> > >> Regards, > >> Rifaat > >> > >> > >> _______________________________________________ > >> 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 > > > > > --001a1137cfb01f07bb0512309aae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have not read the whole document, so I do not know = how indication is being used.
All I am trying to say is that the = current statement in the document is not accurate, as there is a way to pro= tect the integrity of the indication. The text should be either removed or = clearly state that indication protection is not needed and explain why it i= s not needed.

Regards,
=A0Rifaat


On Thu, Mar 26, 2015 at 7:16 AM, Tirumaleswar Reddy (tireddy) = <tireddy@cisco.com> wrote:

SRTP can handle replay at= tacks. Active attacker can consume the indication message so integrity prot= ection is of no help; Passive attacker sniffing packets on the wire can replay the indications with or without message integrity a= nd remote peer will discard SRTP packets with old sequence number.

=A0<= /p>

-Tiru

=A0<= /p>

From: tram [ma= ilto:tram-bounce= s@ietf.org] On Behalf Of Rifaat Shekh-Yusef
Sent: Thursday, March 26, 2015 5:29 PM
To: Oleg Moskalenko
Cc: tram@ietf.org= ; Justin Uberti
Subject: Re: [tram] draft-ietf-tram-stunbis-02<= /p>

=A0

Inline...

=A0

On Wed, Mar 25, 2015 at 11:57 PM, Oleg Moskalenko &l= t;mom040267@gmail.= com> wrote:

Another reason is tha= t indications can be used for high-volume traffic
(like data traffic) and we may not want to associate extra CPU load
with each indication packet.

=A0

If you want a secure solution you better be ready to= pay the cost for that.

Did you quantify that "extra CPU load"?.

=A0

=A0

The indications are usually used either over secure = channel (TLS or
DTLS) or contain secured payload (like SRTP).

=A0

=A0

I thought that the draft was talking about using STU= N over non-secured channels too; right?

Securing the payload would not protect you against r= eplay attacks.

=A0

Regards,

=A0Rifaat

=A0

=A0


On Wed, Mar 25, 2015 at 8:43 PM, Justin Uberti <juberti@google.com> wrote:
> True, but that nonce may have expired by the time the indication is se= nt.
>
> On Wed, Mar 25, 2015 at 8:37 PM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com><= br> > wrote:
>>
>> Hi,
>>
>> I was reading section 9.2 Long-Term Credential Mechanism of the >> draft-ietf-tram-stunbis-02 document, and I came a cross the follow= ing
>> statement:
>>
>>
>>=A0 =A0"Note that the long-term credential mechanism cannot be= used to
>>=A0 =A0 protect indications, since indications cannot be challenged= .=A0 Usages
>>=A0 =A0 utilizing indications must either use a short-term credenti= al or omit
>>=A0 =A0 authentication and message integrity for them."
>>
>>
>> I am not sure that I understand the reason for this statement.
>>
>> After the client is able to authenticate to the server and get the= realm,
>> nonce, and maybe the salt from the server, the client should be ab= le to
>> create the key that will be used with the HMAC function.
>>
>> At this stage either side should be able to create an HMAC for any=
>> request,
>> including Indication. In the case that the receiving side failed t= o
>> validate the HMAC for an Indication it should just drop it on the = floor.
>>
>> Regards,
>>=A0 Rifaat
>>
>>
>> _______________________________________________
>> 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
>

=A0


--001a1137cfb01f07bb0512309aae-- From nobody Thu Mar 26 06:25:16 2015 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 7FDDF1A8A58 for ; Thu, 26 Mar 2015 06:25:14 -0700 (PDT) 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 rUkvsXIdRd-a for ; Thu, 26 Mar 2015 06:25:12 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4D31B2D52 for ; Thu, 26 Mar 2015 06:25:10 -0700 (PDT) Received: from [IPv6:2001:67c:370:136:c617:feff:feb6:86ed] (unknown [IPv6:2001:67c:370:136:c617:feff:feb6:86ed]) (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 B0819203C1; Thu, 26 Mar 2015 14:25:08 +0100 (CET) Message-ID: <551408B2.7090500@acm.org> Date: Thu, 26 Mar 2015 08:25:06 -0500 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef , "Tirumaleswar Reddy (tireddy)" References: <913383AAA69FF945B8F946018B75898A366D0F67@xmb-rcd-x10.cisco.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Oleg Moskalenko , "tram@ietf.org" , Justin Uberti Subject: Re: [tram] draft-ietf-tram-stunbis-02 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, 26 Mar 2015 13:25:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/26/2015 08:00 AM, Rifaat Shekh-Yusef wrote: > I have not read the whole document, so I do not know how indication is > being used. > All I am trying to say is that the current statement in the document is not > accurate, as there is a way to protect the integrity of the indication. The > text should be either removed or clearly state that indication protection > is not needed and explain why it is not needed. What we can do is change the text by saying that authentication of indication is possible, but if the NONCE expires then indication MUST be dropped. This way the client or server makes a conscious decision of getting a chance of having the packets dropped without knowing why (the client should in this case periodically send a dummy transaction just for the purpose of giving a chance to the server to renew the NONCE). But note that when moving up the stack to the TURN layer, indications are just a poor man's TURN channel, TURN channels that again are not authenticated, and do not even have a simple way to be authenticated. > > Regards, > Rifaat > > > On Thu, Mar 26, 2015 at 7:16 AM, Tirumaleswar Reddy (tireddy) < > tireddy@cisco.com> wrote: > >> SRTP can handle replay attacks. Active attacker can consume the >> indication message so integrity protection is of no help; Passive attacker >> sniffing packets on the wire can replay the indications with or without >> message integrity and remote peer will discard SRTP packets with old >> sequence number. >> >> >> >> -Tiru >> >> >> >> *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Rifaat >> Shekh-Yusef >> *Sent:* Thursday, March 26, 2015 5:29 PM >> *To:* Oleg Moskalenko >> *Cc:* tram@ietf.org; Justin Uberti >> *Subject:* Re: [tram] draft-ietf-tram-stunbis-02 >> >> >> >> Inline... >> >> >> >> On Wed, Mar 25, 2015 at 11:57 PM, Oleg Moskalenko >> wrote: >> >> Another reason is that indications can be used for high-volume traffic >> (like data traffic) and we may not want to associate extra CPU load >> with each indication packet. >> >> >> >> If you want a secure solution you better be ready to pay the cost for that. >> >> Did you quantify that "extra CPU load"?. >> >> >> >> >> >> The indications are usually used either over secure channel (TLS or >> DTLS) or contain secured payload (like SRTP). >> >> >> >> >> >> I thought that the draft was talking about using STUN over non-secured >> channels too; right? >> >> Securing the payload would not protect you against replay attacks. >> >> >> >> Regards, >> >> Rifaat >> >> >> >> >> >> >> On Wed, Mar 25, 2015 at 8:43 PM, Justin Uberti wrote: >>> True, but that nonce may have expired by the time the indication is sent. >>> >>> On Wed, Mar 25, 2015 at 8:37 PM, Rifaat Shekh-Yusef < >> rifaat.ietf@gmail.com> >>> wrote: >>>> >>>> Hi, >>>> >>>> I was reading section 9.2 Long-Term Credential Mechanism of the >>>> draft-ietf-tram-stunbis-02 document, and I came a cross the following >>>> statement: >>>> >>>> >>>> "Note that the long-term credential mechanism cannot be used to >>>> protect indications, since indications cannot be challenged. Usages >>>> utilizing indications must either use a short-term credential or omit >>>> authentication and message integrity for them." >>>> >>>> >>>> I am not sure that I understand the reason for this statement. >>>> >>>> After the client is able to authenticate to the server and get the >> realm, >>>> nonce, and maybe the salt from the server, the client should be able to >>>> create the key that will be used with the HMAC function. >>>> >>>> At this stage either side should be able to create an HMAC for any >>>> request, >>>> including Indication. In the case that the receiving side failed to >>>> validate the HMAC for an Indication it should just drop it on the floor. >>>> >>>> Regards, >>>> Rifaat >>>> >>>> - -- 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 iQIcBAEBCAAGBQJVFAiyAAoJECnERZXWan7EQOwQAMlkSxcvLjOzyZQRCD4jOrTe y3qTmC0O/JV4wKrzDw0FFEigXKutNg9e1v0AlVI0g71c+MV6y7QN3zkM+Y4HGKSP +tz+E5DwE5lwiE4r57mlM780iRV0Y/cEbYKJPSQvzpcDpq8MnB3iE/6JE4WBZ6Q6 DtoYLvTNnhj5Mf31Ervv43XAJJrv9XfrQvtvRYA0jpv4LMtpOKHFoUy5Ez7Z1yCu E1YF0kEL1sWDk+CqU/PJkiPxt4xx7U/JoqIwvJ7Xk5Jiw4vCVeYVaZTLm2uEeFO6 6fFEnby2zmYb1+5xHSCA/iopRzBr9f6Ze3XrGbnIrnFUi12ZSBGPD49GiitLemr0 +4aPkSnQeyprRUcdtXccqTPrvekMxwuN7slMktHTJsvDuWjPU2FXJ5mDGF1qk8q4 bDp22mcveAjFWvDTFp6djY41t61kJCOX3Otxnk17BavGfuFSMkEZrNbc66ezVWQ1 BQHQ4sRZ8WDsVTCxAfo1uVGtO5dOq0hfe0lcApyitX7BSy+dnXncdRLI3Ts0RvJy xV14we3zZl9tzqSNH+8gNxTPQ3TWF4uJslALRrgrqDT0ZN2lfWur1ncFzDwcw/iy qdbMqemudVrKbFoU6epPrJ7VCY2fPxLcAT9YCZqyA1vP4bPHonGDb1Jf2xGLLf/T aNrDXOb5ChWgkRDWwem4 =C/nZ -----END PGP SIGNATURE----- From nobody Thu Mar 26 08:18:08 2015 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 350A71AC438 for ; Thu, 26 Mar 2015 08:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ooZg5t9kRCRi for ; Thu, 26 Mar 2015 08:18:04 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1721A1B1D for ; Thu, 26 Mar 2015 08:17:45 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BDEFF47795 for ; Thu, 26 Mar 2015 15:17:44 +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 B161447793 for ; Thu, 26 Mar 2015 15:17:44 +0000 (GMT) Received: from [172.28.115.172] (unknown [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id A568980044 for ; Thu, 26 Mar 2015 15:17:44 +0000 (GMT) Message-ID: <55142318.1080406@akamai.com> Date: Thu, 26 Mar 2015 11:17:44 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: tram@ietf.org References: <913383AAA69FF945B8F946018B75898A366D0F67@xmb-rcd-x10.cisco.com> <551408B2.7090500@acm.org> In-Reply-To: <551408B2.7090500@acm.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tram] draft-ietf-tram-stunbis-02 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, 26 Mar 2015 15:18:07 -0000 I don't think the possible but improbable use of MI for indications deserves too much text. I suggest the following. My edits are in brackets. --- Note that the long-term credential mechanism [SHOULD NOT] be used to protect indications, since indications cannot be challenged [to notify the client of authentication errors (e.g. expired NONCE)]. Usages utilizing indications [SHOULD] use a short-term credential or omit authentication and message integrity for them. --- I would be supportive of using MUST here instead of SHOULD, and I would also support removal or modification of this proposed description of why lack of challenge is a problem. --Brandon On 03/26/2015 09:25 AM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 03/26/2015 08:00 AM, Rifaat Shekh-Yusef wrote: >> I have not read the whole document, so I do not know how indication is >> being used. >> All I am trying to say is that the current statement in the document is not >> accurate, as there is a way to protect the integrity of the indication. The >> text should be either removed or clearly state that indication protection >> is not needed and explain why it is not needed. > > What we can do is change the text by saying that authentication of indication is possible, but if the NONCE expires then indication MUST be dropped. This way the client or server makes a conscious decision of getting a chance of having the packets dropped without knowing why (the client should in this case periodically send a dummy transaction just for the purpose of giving a chance to the server to renew the NONCE). > > But note that when moving up the stack to the TURN layer, indications are just a poor man's TURN channel, TURN channels that again are not authenticated, and do not even have a simple way to be authenticated. > >> >> Regards, >> Rifaat >> >> >> On Thu, Mar 26, 2015 at 7:16 AM, Tirumaleswar Reddy (tireddy) < >> tireddy@cisco.com> wrote: >> >>> SRTP can handle replay attacks. Active attacker can consume the >>> indication message so integrity protection is of no help; Passive attacker >>> sniffing packets on the wire can replay the indications with or without >>> message integrity and remote peer will discard SRTP packets with old >>> sequence number. >>> >>> >>> >>> -Tiru >>> >>> >>> >>> *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Rifaat >>> Shekh-Yusef >>> *Sent:* Thursday, March 26, 2015 5:29 PM >>> *To:* Oleg Moskalenko >>> *Cc:* tram@ietf.org; Justin Uberti >>> *Subject:* Re: [tram] draft-ietf-tram-stunbis-02 >>> >>> >>> >>> Inline... >>> >>> >>> >>> On Wed, Mar 25, 2015 at 11:57 PM, Oleg Moskalenko >>> wrote: >>> >>> Another reason is that indications can be used for high-volume traffic >>> (like data traffic) and we may not want to associate extra CPU load >>> with each indication packet. >>> >>> >>> >>> If you want a secure solution you better be ready to pay the cost for that. >>> >>> Did you quantify that "extra CPU load"?. >>> >>> >>> >>> >>> >>> The indications are usually used either over secure channel (TLS or >>> DTLS) or contain secured payload (like SRTP). >>> >>> >>> >>> >>> >>> I thought that the draft was talking about using STUN over non-secured >>> channels too; right? >>> >>> Securing the payload would not protect you against replay attacks. >>> >>> >>> >>> Regards, >>> >>> Rifaat >>> >>> >>> >>> >>> >>> >>> On Wed, Mar 25, 2015 at 8:43 PM, Justin Uberti wrote: >>>> True, but that nonce may have expired by the time the indication is sent. >>>> >>>> On Wed, Mar 25, 2015 at 8:37 PM, Rifaat Shekh-Yusef < >>> rifaat.ietf@gmail.com> >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I was reading section 9.2 Long-Term Credential Mechanism of the >>>>> draft-ietf-tram-stunbis-02 document, and I came a cross the following >>>>> statement: >>>>> >>>>> >>>>> "Note that the long-term credential mechanism cannot be used to >>>>> protect indications, since indications cannot be challenged. Usages >>>>> utilizing indications must either use a short-term credential or omit >>>>> authentication and message integrity for them." >>>>> >>>>> >>>>> I am not sure that I understand the reason for this statement. >>>>> >>>>> After the client is able to authenticate to the server and get the >>> realm, >>>>> nonce, and maybe the salt from the server, the client should be able to >>>>> create the key that will be used with the HMAC function. >>>>> >>>>> At this stage either side should be able to create an HMAC for any >>>>> request, >>>>> including Indication. In the case that the receiving side failed to >>>>> validate the HMAC for an Indication it should just drop it on the floor. >>>>> >>>>> Regards, >>>>> Rifaat >>>>> >>>>> > > > - -- > 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 > > iQIcBAEBCAAGBQJVFAiyAAoJECnERZXWan7EQOwQAMlkSxcvLjOzyZQRCD4jOrTe > y3qTmC0O/JV4wKrzDw0FFEigXKutNg9e1v0AlVI0g71c+MV6y7QN3zkM+Y4HGKSP > +tz+E5DwE5lwiE4r57mlM780iRV0Y/cEbYKJPSQvzpcDpq8MnB3iE/6JE4WBZ6Q6 > DtoYLvTNnhj5Mf31Ervv43XAJJrv9XfrQvtvRYA0jpv4LMtpOKHFoUy5Ez7Z1yCu > E1YF0kEL1sWDk+CqU/PJkiPxt4xx7U/JoqIwvJ7Xk5Jiw4vCVeYVaZTLm2uEeFO6 > 6fFEnby2zmYb1+5xHSCA/iopRzBr9f6Ze3XrGbnIrnFUi12ZSBGPD49GiitLemr0 > +4aPkSnQeyprRUcdtXccqTPrvekMxwuN7slMktHTJsvDuWjPU2FXJ5mDGF1qk8q4 > bDp22mcveAjFWvDTFp6djY41t61kJCOX3Otxnk17BavGfuFSMkEZrNbc66ezVWQ1 > BQHQ4sRZ8WDsVTCxAfo1uVGtO5dOq0hfe0lcApyitX7BSy+dnXncdRLI3Ts0RvJy > xV14we3zZl9tzqSNH+8gNxTPQ3TWF4uJslALRrgrqDT0ZN2lfWur1ncFzDwcw/iy > qdbMqemudVrKbFoU6epPrJ7VCY2fPxLcAT9YCZqyA1vP4bPHonGDb1Jf2xGLLf/T > aNrDXOb5ChWgkRDWwem4 > =C/nZ > -----END PGP SIGNATURE----- > > _______________________________________________ > 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 Mar 26 09:33:53 2015 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 EEE601A8788 for ; Thu, 26 Mar 2015 09:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2nW6OyRE5RWm for ; Thu, 26 Mar 2015 09:33:49 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD27F1A894F for ; Thu, 26 Mar 2015 09:33:35 -0700 (PDT) Received: by ieclw3 with SMTP id lw3so50737969iec.2 for ; Thu, 26 Mar 2015 09:33:35 -0700 (PDT) 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=4UwXpoYP0wr/1MpevFq4fwfA0mqLqGf6uXOqBLGbIBc=; b=dYW3Y+AUgWqemvyktjOEpxmkZU5doVcmfkmk7EYYJPASZ2UjRFF3oiy5bBfbfpCol+ 4x1jY8N4/yhTwOJjsuEdueEgoE1y/BTwDT7F1hSrmhUpQXWDBquvlxmJocWfBFR7kf6+ GlF+IdbBhKP4I3FJkdmeRnxnljsKFS4KZgn4AnJVdufz0AzzGOhRWzXbuocTCXKpzo+T VdW9vGb/Lz0wJ0PgucCsmrCRRqfrGfRar0IbIZE7IA4egKboSwA8jHd8/MM4tk6gHGeM H0wU9mNUP9sTnLzZrnFPS6etrCiHFd5LDP3ElzOAbV3vHaOvOtXgwSN/+1WBg2XEhDnM 5gmw== 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=4UwXpoYP0wr/1MpevFq4fwfA0mqLqGf6uXOqBLGbIBc=; b=FchyRtNIMhkrvIAeTZaozz2tSabdndmhFcFxbQquUCOHrcrtURnPLG1oXyv44M2Rrc ba3+yRc9BCkDfTQJFy21C3TV9DvDB5j2vGKCnff//ohSzeisq8YqCBGTMRVWEyxnIPJj mZO6GyQOglqBiBtXJJtPPIea74zRjM+Cc5h9MSH+f6VsVUcvxuseL5CZo1+arUpD6SpY ZYaZrVJRWLkme6A6kbQYbncFKDr1ceSghJpLy9goCDedljOJtNsZyq//SYurwdCDTvUd WaVIvqzKGrRCjuDeSqYdoys5pOoVPv3Hhp0OlC5vGk/y5VDOk08r37uqinl5qrXz65h3 bYpQ== X-Gm-Message-State: ALoCoQlNm4Pi1wBKRORzVTEuNkv9/Axd5ledR468/Qe/HxIf3rGSbOeQ7st7M5mEgOJsZuBbFME2 X-Received: by 10.42.250.9 with SMTP id mm9mr39255278icb.56.1427387615159; Thu, 26 Mar 2015 09:33:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.64.42 with HTTP; Thu, 26 Mar 2015 09:33:14 -0700 (PDT) In-Reply-To: <55142318.1080406@akamai.com> References: <913383AAA69FF945B8F946018B75898A366D0F67@xmb-rcd-x10.cisco.com> <551408B2.7090500@acm.org> <55142318.1080406@akamai.com> From: Justin Uberti Date: Thu, 26 Mar 2015 11:33:14 -0500 Message-ID: To: Brandon Williams Content-Type: multipart/alternative; boundary=20cf300e4e53c24a2605123393c2 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] draft-ietf-tram-stunbis-02 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, 26 Mar 2015 16:33:52 -0000 --20cf300e4e53c24a2605123393c2 Content-Type: text/plain; charset=UTF-8 It's hard for me to imagine a scenario where MI for indications makes sense. With no challenge, you have to accept that at some point, the remote side could start silently eating the indications, which seems like a particularly bad failure mode. That said, your proposed SHOULDs seem like a good way to handle this. On Thu, Mar 26, 2015 at 10:17 AM, Brandon Williams < brandon.williams@akamai.com> wrote: > I don't think the possible but improbable use of MI for indications > deserves too much text. I suggest the following. My edits are in brackets. > > --- > Note that the long-term credential mechanism [SHOULD NOT] be used to > protect indications, since indications cannot be challenged [to notify the > client of authentication errors (e.g. expired NONCE)]. Usages utilizing > indications [SHOULD] use a short-term credential or omit authentication and > message integrity for them. > --- > > I would be supportive of using MUST here instead of SHOULD, and I would > also support removal or modification of this proposed description of why > lack of challenge is a problem. > > --Brandon > > > On 03/26/2015 09:25 AM, Marc Petit-Huguenin wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> On 03/26/2015 08:00 AM, Rifaat Shekh-Yusef wrote: >> >>> I have not read the whole document, so I do not know how indication is >>> being used. >>> All I am trying to say is that the current statement in the document is >>> not >>> accurate, as there is a way to protect the integrity of the indication. >>> The >>> text should be either removed or clearly state that indication protection >>> is not needed and explain why it is not needed. >>> >> >> What we can do is change the text by saying that authentication of >> indication is possible, but if the NONCE expires then indication MUST be >> dropped. This way the client or server makes a conscious decision of >> getting a chance of having the packets dropped without knowing why (the >> client should in this case periodically send a dummy transaction just for >> the purpose of giving a chance to the server to renew the NONCE). >> >> But note that when moving up the stack to the TURN layer, indications are >> just a poor man's TURN channel, TURN channels that again are not >> authenticated, and do not even have a simple way to be authenticated. >> >> >>> Regards, >>> Rifaat >>> >>> >>> On Thu, Mar 26, 2015 at 7:16 AM, Tirumaleswar Reddy (tireddy) < >>> tireddy@cisco.com> wrote: >>> >>> SRTP can handle replay attacks. Active attacker can consume the >>>> indication message so integrity protection is of no help; Passive >>>> attacker >>>> sniffing packets on the wire can replay the indications with or without >>>> message integrity and remote peer will discard SRTP packets with old >>>> sequence number. >>>> >>>> >>>> >>>> -Tiru >>>> >>>> >>>> >>>> *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Rifaat >>>> Shekh-Yusef >>>> *Sent:* Thursday, March 26, 2015 5:29 PM >>>> *To:* Oleg Moskalenko >>>> *Cc:* tram@ietf.org; Justin Uberti >>>> *Subject:* Re: [tram] draft-ietf-tram-stunbis-02 >>>> >>>> >>>> >>>> Inline... >>>> >>>> >>>> >>>> On Wed, Mar 25, 2015 at 11:57 PM, Oleg Moskalenko >>>> wrote: >>>> >>>> Another reason is that indications can be used for high-volume traffic >>>> (like data traffic) and we may not want to associate extra CPU load >>>> with each indication packet. >>>> >>>> >>>> >>>> If you want a secure solution you better be ready to pay the cost for >>>> that. >>>> >>>> Did you quantify that "extra CPU load"?. >>>> >>>> >>>> >>>> >>>> >>>> The indications are usually used either over secure channel (TLS or >>>> DTLS) or contain secured payload (like SRTP). >>>> >>>> >>>> >>>> >>>> >>>> I thought that the draft was talking about using STUN over non-secured >>>> channels too; right? >>>> >>>> Securing the payload would not protect you against replay attacks. >>>> >>>> >>>> >>>> Regards, >>>> >>>> Rifaat >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Mar 25, 2015 at 8:43 PM, Justin Uberti >>>> wrote: >>>> >>>>> True, but that nonce may have expired by the time the indication is >>>>> sent. >>>>> >>>>> On Wed, Mar 25, 2015 at 8:37 PM, Rifaat Shekh-Yusef < >>>>> >>>> rifaat.ietf@gmail.com> >>>> >>>>> wrote: >>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> I was reading section 9.2 Long-Term Credential Mechanism of the >>>>>> draft-ietf-tram-stunbis-02 document, and I came a cross the following >>>>>> statement: >>>>>> >>>>>> >>>>>> "Note that the long-term credential mechanism cannot be used to >>>>>> protect indications, since indications cannot be challenged. >>>>>> Usages >>>>>> utilizing indications must either use a short-term credential or >>>>>> omit >>>>>> authentication and message integrity for them." >>>>>> >>>>>> >>>>>> I am not sure that I understand the reason for this statement. >>>>>> >>>>>> After the client is able to authenticate to the server and get the >>>>>> >>>>> realm, >>>> >>>>> nonce, and maybe the salt from the server, the client should be able to >>>>>> create the key that will be used with the HMAC function. >>>>>> >>>>>> At this stage either side should be able to create an HMAC for any >>>>>> request, >>>>>> including Indication. In the case that the receiving side failed to >>>>>> validate the HMAC for an Indication it should just drop it on the >>>>>> floor. >>>>>> >>>>>> Regards, >>>>>> Rifaat >>>>>> >>>>>> >>>>>> >> >> - -- >> 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 >> >> iQIcBAEBCAAGBQJVFAiyAAoJECnERZXWan7EQOwQAMlkSxcvLjOzyZQRCD4jOrTe >> y3qTmC0O/JV4wKrzDw0FFEigXKutNg9e1v0AlVI0g71c+MV6y7QN3zkM+Y4HGKSP >> +tz+E5DwE5lwiE4r57mlM780iRV0Y/cEbYKJPSQvzpcDpq8MnB3iE/6JE4WBZ6Q6 >> DtoYLvTNnhj5Mf31Ervv43XAJJrv9XfrQvtvRYA0jpv4LMtpOKHFoUy5Ez7Z1yCu >> E1YF0kEL1sWDk+CqU/PJkiPxt4xx7U/JoqIwvJ7Xk5Jiw4vCVeYVaZTLm2uEeFO6 >> 6fFEnby2zmYb1+5xHSCA/iopRzBr9f6Ze3XrGbnIrnFUi12ZSBGPD49GiitLemr0 >> +4aPkSnQeyprRUcdtXccqTPrvekMxwuN7slMktHTJsvDuWjPU2FXJ5mDGF1qk8q4 >> bDp22mcveAjFWvDTFp6djY41t61kJCOX3Otxnk17BavGfuFSMkEZrNbc66ezVWQ1 >> BQHQ4sRZ8WDsVTCxAfo1uVGtO5dOq0hfe0lcApyitX7BSy+dnXncdRLI3Ts0RvJy >> xV14we3zZl9tzqSNH+8gNxTPQ3TWF4uJslALRrgrqDT0ZN2lfWur1ncFzDwcw/iy >> qdbMqemudVrKbFoU6epPrJ7VCY2fPxLcAT9YCZqyA1vP4bPHonGDb1Jf2xGLLf/T >> aNrDXOb5ChWgkRDWwem4 >> =C/nZ >> -----END PGP SIGNATURE----- >> >> _______________________________________________ >> 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 > --20cf300e4e53c24a2605123393c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It's hard for me to imagine a scenario where MI for in= dications makes sense. With no challenge, you have to accept that at some p= oint, the remote side could start silently eating the indications, which se= ems like a particularly bad failure mode.

That said, you= r proposed SHOULDs seem like a good way to handle this.

On Thu, Mar 26, 2015 at 1= 0:17 AM, Brandon Williams <brandon.williams@akamai.com> wrote:
I don't think the possib= le but improbable use of MI for indications deserves too much text. I sugge= st the following. My edits are in brackets.

---
Note that the long-term credential mechanism [SHOULD NOT] be used to protec= t indications, since indications cannot be challenged [to notify the client= of authentication errors (e.g. expired NONCE)]. Usages utilizing indicatio= ns [SHOULD] use a short-term credential or omit authentication and message = integrity for them.
---

I would be supportive of using MUST here instead of SHOULD, and I would als= o support removal or modification of this proposed description of why lack = of challenge is a problem.

--Brandon


On 03/26/2015 09:25 AM, Marc Petit-Huguenin wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 03/26/2015 08:00 AM, Rifaat Shekh-Yusef wrote:
I have not read the whole document, so I do not know how indication is
being used.
All I am trying to say is that the current statement in the document is not=
accurate, as there is a way to protect the integrity of the indication. The=
text should be either removed or clearly state that indication protection is not needed and explain why it is not needed.

What we can do is change the text by saying that authentication of indicati= on is possible, but if the NONCE expires then indication MUST be dropped.= =C2=A0 This way the client or server makes a conscious decision of getting = a chance of having the packets dropped without knowing why (the client shou= ld in this case periodically send a dummy transaction just for the purpose = of giving a chance to the server to renew the NONCE).

But note that when moving up the stack to the TURN layer, indications are j= ust a poor man's TURN channel, TURN channels that again are not authent= icated, and do not even have a simple way to be authenticated.


Regards,
=C2=A0 Rifaat


On Thu, Mar 26, 2015 at 7:16 AM, Tirumaleswar Reddy (tireddy) <
tireddy@cisco.com> wrote:

=C2=A0 SRTP can handle replay attacks. Active attacker can consume the
indication message so integrity protection is of no help; Passive attacker<= br> sniffing packets on the wire can replay the indications with or without
message integrity and remote peer will discard SRTP packets with old
sequence number.



-Tiru



*From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Rifaat
Shekh-Yusef
*Sent:* Thursday, March 26, 2015 5:29 PM
*To:* Oleg Moskalenko
*Cc:* tram@ietf.org;= Justin Uberti
*Subject:* Re: [tram] draft-ietf-tram-stunbis-02



Inline...



On Wed, Mar 25, 2015 at 11:57 PM, Oleg Moskalenko <mom040267@gmail.com>
wrote:

Another reason is that indications can be used for high-volume traffic
(like data traffic) and we may not want to associate extra CPU load
with each indication packet.



If you want a secure solution you better be ready to pay the cost for that.=

Did you quantify that "extra CPU load"?.





The indications are usually used either over secure channel (TLS or
DTLS) or contain secured payload (like SRTP).





I thought that the draft was talking about using STUN over non-secured
channels too; right?

Securing the payload would not protect you against replay attacks.



Regards,

=C2=A0 Rifaat






On Wed, Mar 25, 2015 at 8:43 PM, Justin Uberti <juberti@google.com> wrote:
True, but that nonce may have expired by the time the indication is sent.
On Wed, Mar 25, 2015 at 8:37 PM, Rifaat Shekh-Yusef <
rifaat.ietf@gmai= l.com>
wrote:

Hi,

I was reading section 9.2 Long-Term Credential Mechanism of the
draft-ietf-tram-stunbis-02 document, and I came a cross the following
statement:


=C2=A0 =C2=A0"Note that the long-term credential mechanism cannot be u= sed to
=C2=A0 =C2=A0 protect indications, since indications cannot be challenged.= =C2=A0 Usages
=C2=A0 =C2=A0 utilizing indications must either use a short-term credential= or omit
=C2=A0 =C2=A0 authentication and message integrity for them."


I am not sure that I understand the reason for this statement.

After the client is able to authenticate to the server and get the
realm,
nonce, and maybe the salt from the server, the client should be able to
create the key that will be used with the HMAC function.

At this stage either side should be able to create an HMAC for any
request,
including Indication. In the case that the receiving side failed to
validate the HMAC for an Indication it should just drop it on the floor.
Regards,
=C2=A0 Rifaat




- --
Marc Petit-Huguenin
Email: marc@pe= tit-huguenin.org
Blog: htt= p://blog.marc.petit-huguenin.org
Profile: = http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJVFAiyAAoJECnERZXWan7EQOwQAMlkSxcvLjOzyZQRCD4jO= rTe
y3qTmC0O/JV4wKrzDw0FFEigXKutNg9e1v0AlVI0g71c+MV6y7QN3zkM+Y4HG= KSP
+tz+E5DwE5lwiE4r57mlM780iRV0Y/cEbYKJPSQvzpcDpq8MnB3iE/6JE4WBZ= 6Q6
DtoYLvTNnhj5Mf31Ervv43XAJJrv9XfrQvtvRYA0jpv4LMtpOKHFoUy5Ez7Z1= yCu
E1YF0kEL1sWDk+CqU/PJkiPxt4xx7U/JoqIwvJ7Xk5Jiw4vCVeYVaZTLm2uEe= FO6
6fFEnby2zmYb1+5xHSCA/iopRzBr9f6Ze3XrGbnIrnFUi12ZSBGPD49GiitLe= mr0
+4aPkSnQeyprRUcdtXccqTPrvekMxwuN7slMktHTJsvDuWjPU2FXJ5mDGF1qk= 8q4
bDp22mcveAjFWvDTFp6djY41t61kJCOX3Otxnk17BavGfuFSMkEZrNbc66ezV= WQ1
BQHQ4sRZ8WDsVTCxAfo1uVGtO5dOq0hfe0lcApyitX7BSy+dnXncdRLI3Ts0R= vJy
xV14we3zZl9tzqSNH+8gNxTPQ3TWF4uJslALRrgrqDT0ZN2lfWur1ncFzDwcw= /iy
qdbMqemudVrKbFoU6epPrJ7VCY2fPxLcAT9YCZqyA1vP4bPHonGDb1Jf2xGLL= f/T
aNrDXOb5ChWgkRDWwem4
=3DC/nZ
-----END PGP SIGNATURE-----

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://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

--20cf300e4e53c24a2605123393c2-- From nobody Thu Mar 26 09:36:22 2015 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 880671AD374 for ; Thu, 26 Mar 2015 09:36:19 -0700 (PDT) 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 il-PHKWC4Umo for ; Thu, 26 Mar 2015 09:36:16 -0700 (PDT) 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 3FE041A8851 for ; Thu, 26 Mar 2015 09:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26652; q=dns/txt; s=iport; t=1427387776; x=1428597376; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UlS8e8i1V4/V9MCQFE1QIE4a/2moToO0T2o+10+Q+FE=; b=Z2ohMPjNnxZUzgMP8fXLpO7NznbsxY6FyoooHQSXaN5ZPcXpzCLeCFrR 2cCOUFp182J/BUjhEGWoVicdnlmIj0sE7j/nUPVk1scvy73vsRSCOuBma kobxNBm6F0LAAf8lx51t5M8QVvaw37cOGzPtDduyukQe16JdUOm74wTq5 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A8BwDTNBRV/4sNJK1cgkNDUloEgw6/YjwqBoFFAQmFdQIcgT84FAEBAQEBAQF8hBQBAQEEAQEBIApBBgUQAgEIDgMEAQELHQMCAgIfBgsUCQgCBAENBQgTiAADEQ2xCpRlDYU/AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sogjgPgU8RAR8WFwQGAQYDgl8vgRYFhhmKN4NvhDOCaDqFUIZfgmKDRyKCAQEcgVBvAYEDBxcGHH8BAQE X-IronPort-AV: E=Sophos;i="5.11,473,1422921600"; d="scan'208,217";a="135646443" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-3.cisco.com with ESMTP; 26 Mar 2015 16:36:15 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t2QGaF1D010211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Mar 2015 16:36:15 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.80]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Thu, 26 Mar 2015 11:36:15 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Justin Uberti , Brandon Williams Thread-Topic: [tram] draft-ietf-tram-stunbis-02 Thread-Index: AQHQZ2V/6K0LuPx3OEyhSm4wQoB2qJ0ucxMAgAAUtYCAAHXDAP//raFggABjjgCAAAbYAIAAH3gAgAAVGQD//6yi0A== Date: Thu, 26 Mar 2015 16:36:14 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A366D134C@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A366D0F67@xmb-rcd-x10.cisco.com> <551408B2.7090500@acm.org> <55142318.1080406@akamai.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.59.128] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A366D134Cxmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] draft-ietf-tram-stunbis-02 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, 26 Mar 2015 16:36:19 -0000 --_000_913383AAA69FF945B8F946018B75898A366D134Cxmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb27igJl0IHRoaW5rIGFueSBhdHRhY2sgaXMgcHJldmVudGVkIGJ5IGluY2x1ZGluZyBNSSBm b3IgaW5kaWNhdGlvbnMuDQoNCi1UaXJ1DQoNCkZyb206IHRyYW0gW21haWx0bzp0cmFtLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKdXN0aW4gVWJlcnRpDQpTZW50OiBUaHVyc2RheSwg TWFyY2ggMjYsIDIwMTUgMTA6MDMgUE0NClRvOiBCcmFuZG9uIFdpbGxpYW1zDQpDYzogdHJhbUBp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFt0cmFtXSBkcmFmdC1pZXRmLXRyYW0tc3R1bmJpcy0wMg0K DQpJdCdzIGhhcmQgZm9yIG1lIHRvIGltYWdpbmUgYSBzY2VuYXJpbyB3aGVyZSBNSSBmb3IgaW5k aWNhdGlvbnMgbWFrZXMgc2Vuc2UuIFdpdGggbm8gY2hhbGxlbmdlLCB5b3UgaGF2ZSB0byBhY2Nl cHQgdGhhdCBhdCBzb21lIHBvaW50LCB0aGUgcmVtb3RlIHNpZGUgY291bGQgc3RhcnQgc2lsZW50 bHkgZWF0aW5nIHRoZSBpbmRpY2F0aW9ucywgd2hpY2ggc2VlbXMgbGlrZSBhIHBhcnRpY3VsYXJs eSBiYWQgZmFpbHVyZSBtb2RlLg0KDQpUaGF0IHNhaWQsIHlvdXIgcHJvcG9zZWQgU0hPVUxEcyBz ZWVtIGxpa2UgYSBnb29kIHdheSB0byBoYW5kbGUgdGhpcy4NCg0KT24gVGh1LCBNYXIgMjYsIDIw MTUgYXQgMTA6MTcgQU0sIEJyYW5kb24gV2lsbGlhbXMgPGJyYW5kb24ud2lsbGlhbXNAYWthbWFp LmNvbTxtYWlsdG86YnJhbmRvbi53aWxsaWFtc0Bha2FtYWkuY29tPj4gd3JvdGU6DQpJIGRvbid0 IHRoaW5rIHRoZSBwb3NzaWJsZSBidXQgaW1wcm9iYWJsZSB1c2Ugb2YgTUkgZm9yIGluZGljYXRp b25zIGRlc2VydmVzIHRvbyBtdWNoIHRleHQuIEkgc3VnZ2VzdCB0aGUgZm9sbG93aW5nLiBNeSBl ZGl0cyBhcmUgaW4gYnJhY2tldHMuDQoNCi0tLQ0KTm90ZSB0aGF0IHRoZSBsb25nLXRlcm0gY3Jl ZGVudGlhbCBtZWNoYW5pc20gW1NIT1VMRCBOT1RdIGJlIHVzZWQgdG8gcHJvdGVjdCBpbmRpY2F0 aW9ucywgc2luY2UgaW5kaWNhdGlvbnMgY2Fubm90IGJlIGNoYWxsZW5nZWQgW3RvIG5vdGlmeSB0 aGUgY2xpZW50IG9mIGF1dGhlbnRpY2F0aW9uIGVycm9ycyAoZS5nLiBleHBpcmVkIE5PTkNFKV0u IFVzYWdlcyB1dGlsaXppbmcgaW5kaWNhdGlvbnMgW1NIT1VMRF0gdXNlIGEgc2hvcnQtdGVybSBj cmVkZW50aWFsIG9yIG9taXQgYXV0aGVudGljYXRpb24gYW5kIG1lc3NhZ2UgaW50ZWdyaXR5IGZv ciB0aGVtLg0KLS0tDQoNCkkgd291bGQgYmUgc3VwcG9ydGl2ZSBvZiB1c2luZyBNVVNUIGhlcmUg aW5zdGVhZCBvZiBTSE9VTEQsIGFuZCBJIHdvdWxkIGFsc28gc3VwcG9ydCByZW1vdmFsIG9yIG1v ZGlmaWNhdGlvbiBvZiB0aGlzIHByb3Bvc2VkIGRlc2NyaXB0aW9uIG9mIHdoeSBsYWNrIG9mIGNo YWxsZW5nZSBpcyBhIHByb2JsZW0uDQoNCi0tQnJhbmRvbg0KDQoNCk9uIDAzLzI2LzIwMTUgMDk6 MjUgQU0sIE1hcmMgUGV0aXQtSHVndWVuaW4gd3JvdGU6DQotLS0tLUJFR0lOIFBHUCBTSUdORUQg TUVTU0FHRS0tLS0tDQpIYXNoOiBTSEEyNTYNCg0KT24gMDMvMjYvMjAxNSAwODowMCBBTSwgUmlm YWF0IFNoZWtoLVl1c2VmIHdyb3RlOg0KSSBoYXZlIG5vdCByZWFkIHRoZSB3aG9sZSBkb2N1bWVu dCwgc28gSSBkbyBub3Qga25vdyBob3cgaW5kaWNhdGlvbiBpcw0KYmVpbmcgdXNlZC4NCkFsbCBJ IGFtIHRyeWluZyB0byBzYXkgaXMgdGhhdCB0aGUgY3VycmVudCBzdGF0ZW1lbnQgaW4gdGhlIGRv Y3VtZW50IGlzIG5vdA0KYWNjdXJhdGUsIGFzIHRoZXJlIGlzIGEgd2F5IHRvIHByb3RlY3QgdGhl IGludGVncml0eSBvZiB0aGUgaW5kaWNhdGlvbi4gVGhlDQp0ZXh0IHNob3VsZCBiZSBlaXRoZXIg cmVtb3ZlZCBvciBjbGVhcmx5IHN0YXRlIHRoYXQgaW5kaWNhdGlvbiBwcm90ZWN0aW9uDQppcyBu b3QgbmVlZGVkIGFuZCBleHBsYWluIHdoeSBpdCBpcyBub3QgbmVlZGVkLg0KDQpXaGF0IHdlIGNh biBkbyBpcyBjaGFuZ2UgdGhlIHRleHQgYnkgc2F5aW5nIHRoYXQgYXV0aGVudGljYXRpb24gb2Yg aW5kaWNhdGlvbiBpcyBwb3NzaWJsZSwgYnV0IGlmIHRoZSBOT05DRSBleHBpcmVzIHRoZW4gaW5k aWNhdGlvbiBNVVNUIGJlIGRyb3BwZWQuICBUaGlzIHdheSB0aGUgY2xpZW50IG9yIHNlcnZlciBt YWtlcyBhIGNvbnNjaW91cyBkZWNpc2lvbiBvZiBnZXR0aW5nIGEgY2hhbmNlIG9mIGhhdmluZyB0 aGUgcGFja2V0cyBkcm9wcGVkIHdpdGhvdXQga25vd2luZyB3aHkgKHRoZSBjbGllbnQgc2hvdWxk IGluIHRoaXMgY2FzZSBwZXJpb2RpY2FsbHkgc2VuZCBhIGR1bW15IHRyYW5zYWN0aW9uIGp1c3Qg Zm9yIHRoZSBwdXJwb3NlIG9mIGdpdmluZyBhIGNoYW5jZSB0byB0aGUgc2VydmVyIHRvIHJlbmV3 IHRoZSBOT05DRSkuDQoNCkJ1dCBub3RlIHRoYXQgd2hlbiBtb3ZpbmcgdXAgdGhlIHN0YWNrIHRv IHRoZSBUVVJOIGxheWVyLCBpbmRpY2F0aW9ucyBhcmUganVzdCBhIHBvb3IgbWFuJ3MgVFVSTiBj aGFubmVsLCBUVVJOIGNoYW5uZWxzIHRoYXQgYWdhaW4gYXJlIG5vdCBhdXRoZW50aWNhdGVkLCBh bmQgZG8gbm90IGV2ZW4gaGF2ZSBhIHNpbXBsZSB3YXkgdG8gYmUgYXV0aGVudGljYXRlZC4NCg0K UmVnYXJkcywNCiAgUmlmYWF0DQoNCg0KT24gVGh1LCBNYXIgMjYsIDIwMTUgYXQgNzoxNiBBTSwg VGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSA8DQp0aXJlZGR5QGNpc2NvLmNvbTxtYWlsdG86 dGlyZWRkeUBjaXNjby5jb20+PiB3cm90ZToNCiAgU1JUUCBjYW4gaGFuZGxlIHJlcGxheSBhdHRh Y2tzLiBBY3RpdmUgYXR0YWNrZXIgY2FuIGNvbnN1bWUgdGhlDQppbmRpY2F0aW9uIG1lc3NhZ2Ug c28gaW50ZWdyaXR5IHByb3RlY3Rpb24gaXMgb2Ygbm8gaGVscDsgUGFzc2l2ZSBhdHRhY2tlcg0K c25pZmZpbmcgcGFja2V0cyBvbiB0aGUgd2lyZSBjYW4gcmVwbGF5IHRoZSBpbmRpY2F0aW9ucyB3 aXRoIG9yIHdpdGhvdXQNCm1lc3NhZ2UgaW50ZWdyaXR5IGFuZCByZW1vdGUgcGVlciB3aWxsIGRp c2NhcmQgU1JUUCBwYWNrZXRzIHdpdGggb2xkDQpzZXF1ZW5jZSBudW1iZXIuDQoNCg0KDQotVGly dQ0KDQoNCg0KKkZyb206KiB0cmFtIFttYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnPG1haWx0 bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmc+XSAqT24gQmVoYWxmIE9mICpSaWZhYXQNClNoZWtoLVl1 c2VmDQoqU2VudDoqIFRodXJzZGF5LCBNYXJjaCAyNiwgMjAxNSA1OjI5IFBNDQoqVG86KiBPbGVn IE1vc2thbGVua28NCipDYzoqIHRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+OyBK dXN0aW4gVWJlcnRpDQoqU3ViamVjdDoqIFJlOiBbdHJhbV0gZHJhZnQtaWV0Zi10cmFtLXN0dW5i aXMtMDINCg0KDQoNCklubGluZS4uLg0KDQoNCg0KT24gV2VkLCBNYXIgMjUsIDIwMTUgYXQgMTE6 NTcgUE0sIE9sZWcgTW9za2FsZW5rbyA8bW9tMDQwMjY3QGdtYWlsLmNvbTxtYWlsdG86bW9tMDQw MjY3QGdtYWlsLmNvbT4+DQp3cm90ZToNCg0KQW5vdGhlciByZWFzb24gaXMgdGhhdCBpbmRpY2F0 aW9ucyBjYW4gYmUgdXNlZCBmb3IgaGlnaC12b2x1bWUgdHJhZmZpYw0KKGxpa2UgZGF0YSB0cmFm ZmljKSBhbmQgd2UgbWF5IG5vdCB3YW50IHRvIGFzc29jaWF0ZSBleHRyYSBDUFUgbG9hZA0Kd2l0 aCBlYWNoIGluZGljYXRpb24gcGFja2V0Lg0KDQoNCg0KSWYgeW91IHdhbnQgYSBzZWN1cmUgc29s dXRpb24geW91IGJldHRlciBiZSByZWFkeSB0byBwYXkgdGhlIGNvc3QgZm9yIHRoYXQuDQoNCkRp ZCB5b3UgcXVhbnRpZnkgdGhhdCAiZXh0cmEgQ1BVIGxvYWQiPy4NCg0KDQoNCg0KDQpUaGUgaW5k aWNhdGlvbnMgYXJlIHVzdWFsbHkgdXNlZCBlaXRoZXIgb3ZlciBzZWN1cmUgY2hhbm5lbCAoVExT IG9yDQpEVExTKSBvciBjb250YWluIHNlY3VyZWQgcGF5bG9hZCAobGlrZSBTUlRQKS4NCg0KDQoN Cg0KDQpJIHRob3VnaHQgdGhhdCB0aGUgZHJhZnQgd2FzIHRhbGtpbmcgYWJvdXQgdXNpbmcgU1RV TiBvdmVyIG5vbi1zZWN1cmVkDQpjaGFubmVscyB0b287IHJpZ2h0Pw0KDQpTZWN1cmluZyB0aGUg cGF5bG9hZCB3b3VsZCBub3QgcHJvdGVjdCB5b3UgYWdhaW5zdCByZXBsYXkgYXR0YWNrcy4NCg0K DQoNClJlZ2FyZHMsDQoNCiAgUmlmYWF0DQoNCg0KDQoNCg0KDQpPbiBXZWQsIE1hciAyNSwgMjAx NSBhdCA4OjQzIFBNLCBKdXN0aW4gVWJlcnRpIDxqdWJlcnRpQGdvb2dsZS5jb208bWFpbHRvOmp1 YmVydGlAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KVHJ1ZSwgYnV0IHRoYXQgbm9uY2UgbWF5IGhhdmUg ZXhwaXJlZCBieSB0aGUgdGltZSB0aGUgaW5kaWNhdGlvbiBpcyBzZW50Lg0KDQpPbiBXZWQsIE1h ciAyNSwgMjAxNSBhdCA4OjM3IFBNLCBSaWZhYXQgU2hla2gtWXVzZWYgPA0KcmlmYWF0LmlldGZA Z21haWwuY29tPG1haWx0bzpyaWZhYXQuaWV0ZkBnbWFpbC5jb20+Pg0Kd3JvdGU6DQoNCkhpLA0K DQpJIHdhcyByZWFkaW5nIHNlY3Rpb24gOS4yIExvbmctVGVybSBDcmVkZW50aWFsIE1lY2hhbmlz bSBvZiB0aGUNCmRyYWZ0LWlldGYtdHJhbS1zdHVuYmlzLTAyIGRvY3VtZW50LCBhbmQgSSBjYW1l IGEgY3Jvc3MgdGhlIGZvbGxvd2luZw0Kc3RhdGVtZW50Og0KDQoNCiAgICJOb3RlIHRoYXQgdGhl IGxvbmctdGVybSBjcmVkZW50aWFsIG1lY2hhbmlzbSBjYW5ub3QgYmUgdXNlZCB0bw0KICAgIHBy b3RlY3QgaW5kaWNhdGlvbnMsIHNpbmNlIGluZGljYXRpb25zIGNhbm5vdCBiZSBjaGFsbGVuZ2Vk LiAgVXNhZ2VzDQogICAgdXRpbGl6aW5nIGluZGljYXRpb25zIG11c3QgZWl0aGVyIHVzZSBhIHNo b3J0LXRlcm0gY3JlZGVudGlhbCBvciBvbWl0DQogICAgYXV0aGVudGljYXRpb24gYW5kIG1lc3Nh Z2UgaW50ZWdyaXR5IGZvciB0aGVtLiINCg0KDQpJIGFtIG5vdCBzdXJlIHRoYXQgSSB1bmRlcnN0 YW5kIHRoZSByZWFzb24gZm9yIHRoaXMgc3RhdGVtZW50Lg0KDQpBZnRlciB0aGUgY2xpZW50IGlz IGFibGUgdG8gYXV0aGVudGljYXRlIHRvIHRoZSBzZXJ2ZXIgYW5kIGdldCB0aGUNCnJlYWxtLA0K bm9uY2UsIGFuZCBtYXliZSB0aGUgc2FsdCBmcm9tIHRoZSBzZXJ2ZXIsIHRoZSBjbGllbnQgc2hv dWxkIGJlIGFibGUgdG8NCmNyZWF0ZSB0aGUga2V5IHRoYXQgd2lsbCBiZSB1c2VkIHdpdGggdGhl IEhNQUMgZnVuY3Rpb24uDQoNCkF0IHRoaXMgc3RhZ2UgZWl0aGVyIHNpZGUgc2hvdWxkIGJlIGFi bGUgdG8gY3JlYXRlIGFuIEhNQUMgZm9yIGFueQ0KcmVxdWVzdCwNCmluY2x1ZGluZyBJbmRpY2F0 aW9uLiBJbiB0aGUgY2FzZSB0aGF0IHRoZSByZWNlaXZpbmcgc2lkZSBmYWlsZWQgdG8NCnZhbGlk YXRlIHRoZSBITUFDIGZvciBhbiBJbmRpY2F0aW9uIGl0IHNob3VsZCBqdXN0IGRyb3AgaXQgb24g dGhlIGZsb29yLg0KDQpSZWdhcmRzLA0KICBSaWZhYXQNCg0KDQoNCi0gLS0NCk1hcmMgUGV0aXQt SHVndWVuaW4NCkVtYWlsOiBtYXJjQHBldGl0LWh1Z3VlbmluLm9yZzxtYWlsdG86bWFyY0BwZXRp dC1odWd1ZW5pbi5vcmc+DQpCbG9nOiBodHRwOi8vYmxvZy5tYXJjLnBldGl0LWh1Z3VlbmluLm9y Zw0KUHJvZmlsZTogaHR0cDovL3d3dy5saW5rZWRpbi5jb20vaW4vcGV0aXRodWcNCi0tLS0tQkVH SU4gUEdQIFNJR05BVFVSRS0tLS0tDQpWZXJzaW9uOiBHbnVQRyB2MQ0KDQppUUljQkFFQkNBQUdC UUpWRkFpeUFBb0pFQ25FUlpYV2FuN0VRT3dRQU1sa1N4Y3ZMak96eVpRUkNENGpPclRlDQp5M3FU bUMwTy9KVjR3S3J6RHcwRkZFaWdYS3V0Tmc5ZTF2MEFsVkkwZzcxYytNVjZ5N1FOM3prTStZNEhH S1NQDQordHorRTVEd0U1bHdpRTRyNTdtbE03ODBpUlYwWS9jRWJZS0pQU1F2enBjRHBxOE1uQjNp RS82SkU0V0JaNlE2DQpEdG9ZTHZUTm5oajVNZjMxRXJ2djQzWEFKSnJ2OVhmclF2dHZSWUEwanB2 NExNdHBPS0hGb1V5NUV6N1oxeUN1DQpFMVlGMGtFTDFzV0RrK0NxVS9QSmtpUHh0NHh4N1UvSm9x SXd2SjdYazVKaXc0dkNWZVlWYVpUTG0ydUVlRk82DQo2ZkZFbmJ5MnptWWIxKzV4SFNDQS9pb3BS ekJyOWY2WmUzWHJHYm5Jcm5GVWkxMlpTQkdQRDQ5R2lpdExlbXIwDQorNGFQa1NuUWV5cHJSVWNk dFhjY3FUUHJ2ZWtNeHd1TjdzbE1rdEhUSnN2RHVXalBVMkZYSjVtREdGMXFrOHE0DQpiRHAyMm1j dmVBakZXdkRURnA2ZGpZNDF0NjFrSkNPWDNPdHhuazE3QmF2R2Z1RlNNa0Vack5iYzY2ZXpWV1Ex DQpCUUhRNHNSWjhXRHNWVEN4QWZvMXVWR3RPNWRPcTBoZmUwbGNBcHlpdFg3QlN5K2RuWG5jZFJM STNUczBSdkp5DQp4VjE0d2UzelpsOXR6cVNOSCs4Z054VFBRM1RXRjR1SnNsQUxScmdycURUMFpO MmxmV3VyMW5jRnpEd2N3L2l5DQpxZGJNcWVtdWRWcktiRm9VNmVwUHJKN1ZDWTJmUHhMY0FUOVlD WnF5QTF2UDRiUEhvbkdEYjFKZjJ4R0xMZi9UDQphTnJEWE9iNUNoV2drUkRXd2VtNA0KPUMvbloN Ci0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCnRyYW0gbWFpbGluZyBsaXN0DQp0cmFtQGlldGYub3JnPG1h aWx0bzp0cmFtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90cmFtDQoNCi0tDQpCcmFuZG9uIFdpbGxpYW1zOyBTZW5pb3IgUHJpbmNpcGFsIFNvZnR3YXJl IEVuZ2luZWVyDQpFbWVyZ2luZyBQcm9kdWN0cyBFbmdpbmVlcmluZzsgQWthbWFpIFRlY2hub2xv Z2llcyBJbmMuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCnRyYW0gbWFpbGluZyBsaXN0DQp0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQoNCg== --_000_913383AAA69FF945B8F946018B75898A366D134Cxmbrcdx10ciscoc_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxl LW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZG9u4oCZdCB0aGluayBhbnkgYXR0YWNrIGlzIHBy ZXZlbnRlZCBieSBpbmNsdWRpbmcgTUkgZm9yIGluZGljYXRpb25zLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LVRpcnU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gdHJhbSBbbWFpbHRv OnRyYW0tYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SnVzdGluIFViZXJ0 aTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTWFyY2ggMjYsIDIwMTUgMTA6MDMgUE08YnI+ DQo8Yj5Ubzo8L2I+IEJyYW5kb24gV2lsbGlhbXM8YnI+DQo8Yj5DYzo8L2I+IHRyYW1AaWV0Zi5v cmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0cmFtXSBkcmFmdC1pZXRmLXRyYW0tc3R1bmJp cy0wMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JdCdzIGhhcmQgZm9yIG1lIHRvIGltYWdpbmUgYSBzY2VuYXJpbyB3aGVyZSBNSSBmb3IgaW5k aWNhdGlvbnMgbWFrZXMgc2Vuc2UuIFdpdGggbm8gY2hhbGxlbmdlLCB5b3UgaGF2ZSB0byBhY2Nl cHQgdGhhdCBhdCBzb21lIHBvaW50LCB0aGUgcmVtb3RlIHNpZGUgY291bGQgc3RhcnQgc2lsZW50 bHkgZWF0aW5nIHRoZSBpbmRpY2F0aW9ucywgd2hpY2ggc2VlbXMgbGlrZSBhIHBhcnRpY3VsYXJs eSBiYWQgZmFpbHVyZQ0KIG1vZGUuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGF0IHNhaWQsIHlvdXIgcHJvcG9zZWQgU0hPVUxEcyBzZWVtIGxpa2UgYSBn b29kIHdheSB0byBoYW5kbGUgdGhpcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBNYXIgMjYsIDIwMTUgYXQgMTA6MTcgQU0sIEJy YW5kb24gV2lsbGlhbXMgJmx0OzxhIGhyZWY9Im1haWx0bzpicmFuZG9uLndpbGxpYW1zQGFrYW1h aS5jb20iIHRhcmdldD0iX2JsYW5rIj5icmFuZG9uLndpbGxpYW1zQGFrYW1haS5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3QgdGhp bmsgdGhlIHBvc3NpYmxlIGJ1dCBpbXByb2JhYmxlIHVzZSBvZiBNSSBmb3IgaW5kaWNhdGlvbnMg ZGVzZXJ2ZXMgdG9vIG11Y2ggdGV4dC4gSSBzdWdnZXN0IHRoZSBmb2xsb3dpbmcuIE15IGVkaXRz IGFyZSBpbiBicmFja2V0cy48YnI+DQo8YnI+DQotLS08YnI+DQpOb3RlIHRoYXQgdGhlIGxvbmct dGVybSBjcmVkZW50aWFsIG1lY2hhbmlzbSBbU0hPVUxEIE5PVF0gYmUgdXNlZCB0byBwcm90ZWN0 IGluZGljYXRpb25zLCBzaW5jZSBpbmRpY2F0aW9ucyBjYW5ub3QgYmUgY2hhbGxlbmdlZCBbdG8g bm90aWZ5IHRoZSBjbGllbnQgb2YgYXV0aGVudGljYXRpb24gZXJyb3JzIChlLmcuIGV4cGlyZWQg Tk9OQ0UpXS4gVXNhZ2VzIHV0aWxpemluZyBpbmRpY2F0aW9ucyBbU0hPVUxEXSB1c2UgYSBzaG9y dC10ZXJtIGNyZWRlbnRpYWwNCiBvciBvbWl0IGF1dGhlbnRpY2F0aW9uIGFuZCBtZXNzYWdlIGlu dGVncml0eSBmb3IgdGhlbS48YnI+DQotLS08YnI+DQo8YnI+DQpJIHdvdWxkIGJlIHN1cHBvcnRp dmUgb2YgdXNpbmcgTVVTVCBoZXJlIGluc3RlYWQgb2YgU0hPVUxELCBhbmQgSSB3b3VsZCBhbHNv IHN1cHBvcnQgcmVtb3ZhbCBvciBtb2RpZmljYXRpb24gb2YgdGhpcyBwcm9wb3NlZCBkZXNjcmlw dGlvbiBvZiB3aHkgbGFjayBvZiBjaGFsbGVuZ2UgaXMgYSBwcm9ibGVtLjxicj4NCjxicj4NCi0t QnJhbmRvbjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnI+DQo8YnI+DQpPbiAwMy8yNi8yMDE1IDA5OjI1IEFNLCBNYXJjIFBldGl0LUh1Z3Vlbmlu IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLS0tQkVHSU4gUEdQIFNJR05FRCBNRVNT QUdFLS0tLS08YnI+DQpIYXNoOiBTSEEyNTY8YnI+DQo8YnI+DQpPbiAwMy8yNi8yMDE1IDA4OjAw IEFNLCBSaWZhYXQgU2hla2gtWXVzZWYgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIGhhdmUgbm90IHJlYWQgdGhlIHdob2xlIGRvY3VtZW50LCBzbyBJIGRvIG5v dCBrbm93IGhvdyBpbmRpY2F0aW9uIGlzPGJyPg0KYmVpbmcgdXNlZC48YnI+DQpBbGwgSSBhbSB0 cnlpbmcgdG8gc2F5IGlzIHRoYXQgdGhlIGN1cnJlbnQgc3RhdGVtZW50IGluIHRoZSBkb2N1bWVu dCBpcyBub3Q8YnI+DQphY2N1cmF0ZSwgYXMgdGhlcmUgaXMgYSB3YXkgdG8gcHJvdGVjdCB0aGUg aW50ZWdyaXR5IG9mIHRoZSBpbmRpY2F0aW9uLiBUaGU8YnI+DQp0ZXh0IHNob3VsZCBiZSBlaXRo ZXIgcmVtb3ZlZCBvciBjbGVhcmx5IHN0YXRlIHRoYXQgaW5kaWNhdGlvbiBwcm90ZWN0aW9uPGJy Pg0KaXMgbm90IG5lZWRlZCBhbmQgZXhwbGFpbiB3aHkgaXQgaXMgbm90IG5lZWRlZC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PGJyPg0KV2hhdCB3ZSBjYW4gZG8gaXMgY2hhbmdlIHRoZSB0ZXh0IGJ5IHNheWluZyB0aGF0 IGF1dGhlbnRpY2F0aW9uIG9mIGluZGljYXRpb24gaXMgcG9zc2libGUsIGJ1dCBpZiB0aGUgTk9O Q0UgZXhwaXJlcyB0aGVuIGluZGljYXRpb24gTVVTVCBiZSBkcm9wcGVkLiZuYnNwOyBUaGlzIHdh eSB0aGUgY2xpZW50IG9yIHNlcnZlciBtYWtlcyBhIGNvbnNjaW91cyBkZWNpc2lvbiBvZiBnZXR0 aW5nIGEgY2hhbmNlIG9mIGhhdmluZyB0aGUgcGFja2V0cyBkcm9wcGVkDQogd2l0aG91dCBrbm93 aW5nIHdoeSAodGhlIGNsaWVudCBzaG91bGQgaW4gdGhpcyBjYXNlIHBlcmlvZGljYWxseSBzZW5k IGEgZHVtbXkgdHJhbnNhY3Rpb24ganVzdCBmb3IgdGhlIHB1cnBvc2Ugb2YgZ2l2aW5nIGEgY2hh bmNlIHRvIHRoZSBzZXJ2ZXIgdG8gcmVuZXcgdGhlIE5PTkNFKS48YnI+DQo8YnI+DQpCdXQgbm90 ZSB0aGF0IHdoZW4gbW92aW5nIHVwIHRoZSBzdGFjayB0byB0aGUgVFVSTiBsYXllciwgaW5kaWNh dGlvbnMgYXJlIGp1c3QgYSBwb29yIG1hbidzIFRVUk4gY2hhbm5lbCwgVFVSTiBjaGFubmVscyB0 aGF0IGFnYWluIGFyZSBub3QgYXV0aGVudGljYXRlZCwgYW5kIGRvIG5vdCBldmVuIGhhdmUgYSBz aW1wbGUgd2F5IHRvIGJlIGF1dGhlbnRpY2F0ZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NClJlZ2FyZHMsPGJy Pg0KJm5ic3A7IFJpZmFhdDxicj4NCjxicj4NCjxicj4NCk9uIFRodSwgTWFyIDI2LCAyMDE1IGF0 IDc6MTYgQU0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgJmx0Ozxicj4NCjxhIGhyZWY9 Im1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRpcmVkZHlAY2lzY28u Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsgU1JUUCBjYW4gaGFuZGxlIHJlcGxheSBhdHRhY2tzLiBBY3RpdmUgYXR0YWNrZXIgY2Fu IGNvbnN1bWUgdGhlPGJyPg0KaW5kaWNhdGlvbiBtZXNzYWdlIHNvIGludGVncml0eSBwcm90ZWN0 aW9uIGlzIG9mIG5vIGhlbHA7IFBhc3NpdmUgYXR0YWNrZXI8YnI+DQpzbmlmZmluZyBwYWNrZXRz IG9uIHRoZSB3aXJlIGNhbiByZXBsYXkgdGhlIGluZGljYXRpb25zIHdpdGggb3Igd2l0aG91dDxi cj4NCm1lc3NhZ2UgaW50ZWdyaXR5IGFuZCByZW1vdGUgcGVlciB3aWxsIGRpc2NhcmQgU1JUUCBw YWNrZXRzIHdpdGggb2xkPGJyPg0Kc2VxdWVuY2UgbnVtYmVyLjxicj4NCjxicj4NCjxicj4NCjxi cj4NCi1UaXJ1PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KKkZyb206KiB0cmFtIFttYWlsdG86PGEg aHJlZj0ibWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRyYW0t Ym91bmNlc0BpZXRmLm9yZzwvYT5dICpPbiBCZWhhbGYgT2YgKlJpZmFhdDxicj4NClNoZWtoLVl1 c2VmPGJyPg0KKlNlbnQ6KiBUaHVyc2RheSwgTWFyY2ggMjYsIDIwMTUgNToyOSBQTTxicj4NCipU bzoqIE9sZWcgTW9za2FsZW5rbzxicj4NCipDYzoqIDxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+dHJhbUBpZXRmLm9yZzwvYT47IEp1c3RpbiBVYmVydGk8YnI+ DQoqU3ViamVjdDoqIFJlOiBbdHJhbV0gZHJhZnQtaWV0Zi10cmFtLXN0dW5iaXMtMDI8YnI+DQo8 YnI+DQo8YnI+DQo8YnI+DQpJbmxpbmUuLi48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpPbiBXZWQs IE1hciAyNSwgMjAxNSBhdCAxMTo1NyBQTSwgT2xlZyBNb3NrYWxlbmtvICZsdDs8YSBocmVmPSJt YWlsdG86bW9tMDQwMjY3QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vbTA0MDI2N0BnbWFp bC5jb208L2E+Jmd0Ozxicj4NCndyb3RlOjxicj4NCjxicj4NCkFub3RoZXIgcmVhc29uIGlzIHRo YXQgaW5kaWNhdGlvbnMgY2FuIGJlIHVzZWQgZm9yIGhpZ2gtdm9sdW1lIHRyYWZmaWM8YnI+DQoo bGlrZSBkYXRhIHRyYWZmaWMpIGFuZCB3ZSBtYXkgbm90IHdhbnQgdG8gYXNzb2NpYXRlIGV4dHJh IENQVSBsb2FkPGJyPg0Kd2l0aCBlYWNoIGluZGljYXRpb24gcGFja2V0Ljxicj4NCjxicj4NCjxi cj4NCjxicj4NCklmIHlvdSB3YW50IGEgc2VjdXJlIHNvbHV0aW9uIHlvdSBiZXR0ZXIgYmUgcmVh ZHkgdG8gcGF5IHRoZSBjb3N0IGZvciB0aGF0Ljxicj4NCjxicj4NCkRpZCB5b3UgcXVhbnRpZnkg dGhhdCAmcXVvdDtleHRyYSBDUFUgbG9hZCZxdW90Oz8uPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KVGhlIGluZGljYXRpb25zIGFyZSB1c3VhbGx5IHVzZWQgZWl0aGVyIG92ZXIg c2VjdXJlIGNoYW5uZWwgKFRMUyBvcjxicj4NCkRUTFMpIG9yIGNvbnRhaW4gc2VjdXJlZCBwYXls b2FkIChsaWtlIFNSVFApLjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCkkgdGhv dWdodCB0aGF0IHRoZSBkcmFmdCB3YXMgdGFsa2luZyBhYm91dCB1c2luZyBTVFVOIG92ZXIgbm9u LXNlY3VyZWQ8YnI+DQpjaGFubmVscyB0b287IHJpZ2h0Pzxicj4NCjxicj4NClNlY3VyaW5nIHRo ZSBwYXlsb2FkIHdvdWxkIG5vdCBwcm90ZWN0IHlvdSBhZ2FpbnN0IHJlcGxheSBhdHRhY2tzLjxi cj4NCjxicj4NCjxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KPGJyPg0KJm5ic3A7IFJpZmFhdDxi cj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCk9uIFdlZCwgTWFyIDI1LCAy MDE1IGF0IDg6NDMgUE0sIEp1c3RpbiBVYmVydGkgJmx0OzxhIGhyZWY9Im1haWx0bzpqdWJlcnRp QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5qdWJlcnRpQGdvb2dsZS5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRydWUsIGJ1dCB0aGF0 IG5vbmNlIG1heSBoYXZlIGV4cGlyZWQgYnkgdGhlIHRpbWUgdGhlIGluZGljYXRpb24gaXMgc2Vu dC48YnI+DQo8YnI+DQpPbiBXZWQsIE1hciAyNSwgMjAxNSBhdCA4OjM3IFBNLCBSaWZhYXQgU2hl a2gtWXVzZWYgJmx0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJl Zj0ibWFpbHRvOnJpZmFhdC5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJpZmFhdC5p ZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij53cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCkhpLDxi cj4NCjxicj4NCkkgd2FzIHJlYWRpbmcgc2VjdGlvbiA5LjIgTG9uZy1UZXJtIENyZWRlbnRpYWwg TWVjaGFuaXNtIG9mIHRoZTxicj4NCmRyYWZ0LWlldGYtdHJhbS1zdHVuYmlzLTAyIGRvY3VtZW50 LCBhbmQgSSBjYW1lIGEgY3Jvc3MgdGhlIGZvbGxvd2luZzxicj4NCnN0YXRlbWVudDo8YnI+DQo8 YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7JnF1b3Q7Tm90ZSB0aGF0IHRoZSBsb25nLXRlcm0gY3Jl ZGVudGlhbCBtZWNoYW5pc20gY2Fubm90IGJlIHVzZWQgdG88YnI+DQombmJzcDsgJm5ic3A7IHBy b3RlY3QgaW5kaWNhdGlvbnMsIHNpbmNlIGluZGljYXRpb25zIGNhbm5vdCBiZSBjaGFsbGVuZ2Vk LiZuYnNwOyBVc2FnZXM8YnI+DQombmJzcDsgJm5ic3A7IHV0aWxpemluZyBpbmRpY2F0aW9ucyBt dXN0IGVpdGhlciB1c2UgYSBzaG9ydC10ZXJtIGNyZWRlbnRpYWwgb3Igb21pdDxicj4NCiZuYnNw OyAmbmJzcDsgYXV0aGVudGljYXRpb24gYW5kIG1lc3NhZ2UgaW50ZWdyaXR5IGZvciB0aGVtLiZx dW90Ozxicj4NCjxicj4NCjxicj4NCkkgYW0gbm90IHN1cmUgdGhhdCBJIHVuZGVyc3RhbmQgdGhl IHJlYXNvbiBmb3IgdGhpcyBzdGF0ZW1lbnQuPGJyPg0KPGJyPg0KQWZ0ZXIgdGhlIGNsaWVudCBp cyBhYmxlIHRvIGF1dGhlbnRpY2F0ZSB0byB0aGUgc2VydmVyIGFuZCBnZXQgdGhlPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5yZWFsbSw8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi Pm5vbmNlLCBhbmQgbWF5YmUgdGhlIHNhbHQgZnJvbSB0aGUgc2VydmVyLCB0aGUgY2xpZW50IHNo b3VsZCBiZSBhYmxlIHRvPGJyPg0KY3JlYXRlIHRoZSBrZXkgdGhhdCB3aWxsIGJlIHVzZWQgd2l0 aCB0aGUgSE1BQyBmdW5jdGlvbi48YnI+DQo8YnI+DQpBdCB0aGlzIHN0YWdlIGVpdGhlciBzaWRl IHNob3VsZCBiZSBhYmxlIHRvIGNyZWF0ZSBhbiBITUFDIGZvciBhbnk8YnI+DQpyZXF1ZXN0LDxi cj4NCmluY2x1ZGluZyBJbmRpY2F0aW9uLiBJbiB0aGUgY2FzZSB0aGF0IHRoZSByZWNlaXZpbmcg c2lkZSBmYWlsZWQgdG88YnI+DQp2YWxpZGF0ZSB0aGUgSE1BQyBmb3IgYW4gSW5kaWNhdGlvbiBp dCBzaG91bGQganVzdCBkcm9wIGl0IG9uIHRoZSBmbG9vci48YnI+DQo8YnI+DQpSZWdhcmRzLDxi cj4NCiZuYnNwOyBSaWZhYXQ8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJy Pg0KPGJyPg0KLSAtLTxicj4NCk1hcmMgUGV0aXQtSHVndWVuaW48YnI+DQpFbWFpbDogPGEgaHJl Zj0ibWFpbHRvOm1hcmNAcGV0aXQtaHVndWVuaW4ub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFyY0Bw ZXRpdC1odWd1ZW5pbi5vcmc8L2E+PGJyPg0KQmxvZzogPGEgaHJlZj0iaHR0cDovL2Jsb2cubWFy Yy5wZXRpdC1odWd1ZW5pbi5vcmciIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vYmxvZy5tYXJjLnBl dGl0LWh1Z3VlbmluLm9yZzwvYT48YnI+DQpQcm9maWxlOiA8YSBocmVmPSJodHRwOi8vd3d3Lmxp bmtlZGluLmNvbS9pbi9wZXRpdGh1ZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cubGlua2Vk aW4uY29tL2luL3BldGl0aHVnPC9hPjxicj4NCi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0t PGJyPg0KVmVyc2lvbjogR251UEcgdjE8YnI+DQo8YnI+DQppUUljQkFFQkNBQUdCUUpWRkFpeUFB b0pFQ25FUlpYV2FuN0VRT3dRQU1sa1N4Y3ZMak96eVpRUkNENGpPclRlPGJyPg0KeTNxVG1DME8v SlY0d0tyekR3MEZGRWlnWEt1dE5nOWUxdjBBbFZJMGc3MWMmIzQzO01WNnk3UU4zemtNJiM0MztZ NEhHS1NQPGJyPg0KJiM0Mzt0eiYjNDM7RTVEd0U1bHdpRTRyNTdtbE03ODBpUlYwWS9jRWJZS0pQ U1F2enBjRHBxOE1uQjNpRS82SkU0V0JaNlE2PGJyPg0KRHRvWUx2VE5uaGo1TWYzMUVydnY0M1hB SkpydjlYZnJRdnR2UllBMGpwdjRMTXRwT0tIRm9VeTVFejdaMXlDdTxicj4NCkUxWUYwa0VMMXNX RGsmIzQzO0NxVS9QSmtpUHh0NHh4N1UvSm9xSXd2SjdYazVKaXc0dkNWZVlWYVpUTG0ydUVlRk82 PGJyPg0KNmZGRW5ieTJ6bVliMSYjNDM7NXhIU0NBL2lvcFJ6QnI5ZjZaZTNYckdibklybkZVaTEy WlNCR1BENDlHaWl0TGVtcjA8YnI+DQomIzQzOzRhUGtTblFleXByUlVjZHRYY2NxVFBydmVrTXh3 dU43c2xNa3RIVEpzdkR1V2pQVTJGWEo1bURHRjFxazhxNDxicj4NCmJEcDIybWN2ZUFqRld2RFRG cDZkalk0MXQ2MWtKQ09YM090eG5rMTdCYXZHZnVGU01rRVpyTmJjNjZlelZXUTE8YnI+DQpCUUhR NHNSWjhXRHNWVEN4QWZvMXVWR3RPNWRPcTBoZmUwbGNBcHlpdFg3QlN5JiM0MztkblhuY2RSTEkz VHMwUnZKeTxicj4NCnhWMTR3ZTN6Wmw5dHpxU05IJiM0Mzs4Z054VFBRM1RXRjR1SnNsQUxScmdy cURUMFpOMmxmV3VyMW5jRnpEd2N3L2l5PGJyPg0KcWRiTXFlbXVkVnJLYkZvVTZlcFBySjdWQ1ky ZlB4TGNBVDlZQ1pxeUExdlA0YlBIb25HRGIxSmYyeEdMTGYvVDxicj4NCmFOckRYT2I1Q2hXZ2tS RFd3ZW00PGJyPg0KPUMvblo8YnI+DQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS08bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KdHJhbSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86dHJh bUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRyYW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPi0tIDwvc3Bhbj48 YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj5CcmFuZG9uIFdpbGxpYW1zOyBTZW5pb3IgUHJpbmNp cGFsIFNvZnR3YXJlIEVuZ2luZWVyPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPkVt ZXJnaW5nIFByb2R1Y3RzIEVuZ2luZWVyaW5nOyBBa2FtYWkgVGVjaG5vbG9naWVzIEluYy48L3Nw YW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCnRyYW0gbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnRyYW1A aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50cmFtQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbSIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbTwvYT48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_913383AAA69FF945B8F946018B75898A366D134Cxmbrcdx10ciscoc_-- From nobody Thu Mar 26 09:53:12 2015 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 D82BD1A8766 for ; Thu, 26 Mar 2015 09:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 J0ORwjhUO6a1 for ; Thu, 26 Mar 2015 09:53:09 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13B221A86FF for ; Thu, 26 Mar 2015 09:53:09 -0700 (PDT) Received: by igbud6 with SMTP id ud6so135491561igb.1 for ; Thu, 26 Mar 2015 09:53:08 -0700 (PDT) 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=OFYM4YA0rE+w/n4EoGCZWvc+DHcavl9a9Sv4Wafpl0A=; b=NWsIdK37MkHPkIxtgewTGHSrnuvRjZTrXF58LQwmL2TyUxalyHFt6pKaG6TpSbIeGe ubrJJbrF1hsOFbuXLrROhuMt2l+LWHDd3jnUxKHVJzjemOXg4w+yUM2GGpZJStaNARyJ M6edhIWYfz+EVDRFg1RuBdfkFUntsGBxN2XnTY44Ao7twys6DwJpekMy+9oNDkdC58Uv 1zaMPsRUgjHBUtI8nNlq2hf1udWs9u1ccJF44XIzvKaWv6545dsHLET4AY3fnU2e5+L1 LnHv9bgY5UTEBrscxyw8f+1bhiIUzReSkRiCtgPwT2B9DOu7Kil3B+Y2QDVltJzVvubE 9QGg== 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=OFYM4YA0rE+w/n4EoGCZWvc+DHcavl9a9Sv4Wafpl0A=; b=OiOwRuVdtJXOYERudP7yP+xPLXvbZG8GIRZFFxlKQwouoHGYoP0L4QIl/FHr+ymViG nfo7lUlWFfO2O9yyoENf3KLLmevmgdQrUGJaWrMnbOL4oYTtxX4n3aqQPTLKMERpFTU8 Soek++QhAqUU3v2YzYJnbs+ulG0lEeNVgLrTgPUEu4AM3RyFRES2e6sQpngpCzWjt3ta 1pJ2/pXISYRE5NHnEHaV4zaZXneABMzcAv9TmZIHX5/VIsopxTGeLopJoTChZYPrsJS+ w+MlHs82O7Xlnf0fOFlosyEoh40mQA+PmdCc9nLcFPyDLDjC21RleDcs47Dv8Xu5LrZR EZKw== X-Gm-Message-State: ALoCoQlSpsbVXhIHTZZIuzerCQJT4Y4Syfxg+vP2x25Ym1q7Xgdh1MfAfwT7FOiO5EgILRZgHEXf X-Received: by 10.50.138.68 with SMTP id qo4mr37856000igb.33.1427388788517; Thu, 26 Mar 2015 09:53:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.64.42 with HTTP; Thu, 26 Mar 2015 09:52:47 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A366D0EDE@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A366D0EDE@xmb-rcd-x10.cisco.com> From: Justin Uberti Date: Thu, 26 Mar 2015 11:52:47 -0500 Message-ID: To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=001a1134bd80b257f4051233d98b Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-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: Thu, 26 Mar 2015 16:53:11 -0000 --001a1134bd80b257f4051233d98b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 26, 2015 at 6:06 AM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > Hi Justin, > > > > Thanks for the comments. Please see inline [TR] > > > > *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Justin Uberti > *Sent:* Thursday, March 26, 2015 11:32 AM > *To:* tram@ietf.org > *Subject:* [tram] Comments on draft-ietf-tram-turnbis-01 > > > > better late than never: > > > > S 6.1: > > I don't think that we need to forbid using RAF with AAF. It should be > possible to do RAF(v4) with AAF(v6), RAF(v6) with AAF(v4), or AAF(v6) by > itself, all with the same meaning. > > > > [TR] RAF is comprehension-required attribute whereas AAF is > comprehension-optional attribute, If client uses both RAF + AAF and the > server does not understand RAF then the request could fail. I don=E2=80= =99t see any > advantage of using both RAF and AAF together. > I agree that typically AAF will be sent by itself, but in the interest of defining a general mechanism I don't think we should prohibit RAF + AAF. > > > S 7.1: > > I think the client should include RAF for the bindings that it wants to > keep, not AAF. AAF is only useful in the ALLOCATE, where the client doesn= 't > know if the server supports AAF. > > > > [TR] If AAF is used for Allocation then there is no reason why RAF should > be used for the binding (server may not support RAF and it will result in > failure to refresh). > There is no server that will support AAF but not RAF. For a dual allocation, the client should be able to refresh the v4, v6, or both. Right now in the doc, we don't have that control. I suggest the following: v4 can be refreshed by sending RAF(v4). v6 can be refreshed by sending RAF(v6). both can be refreshed by sending RAF(v4+v6), and/or, perhaps, no RAF. For a single allocation, I suggest we keep the existing format where sending no RAF refreshes the allocation. > > > S 9.1: > > I don't think we want to support CreatePermissions with multiple > addresses. It doesn't save anything other than 2 packets and just makes > life more complicated. > > > > [TR] Please clarify why it complicates implementation ? > You now need to handle partial successes, so your error handling path is more complicated. But mainly, it's not clear at all why a client would use this. > > > S 11.1: > > How would you do a ChannelBind with multiple addresses? Sent packets go t= o > both destinations? Again, this seems complex with no good reason. > > > > [TR] Agreed, will fix in the next reversion. > > > > S 15.6/15.11: > > It would be good to separate the RAF/AAF payload definition out so that i= t > doesn't need to be repeated in both sections. > > > > [TR] The payload text is not large enough for a separate section. > At 30 lines of text, I disagree. We are already doing this sort of thing for XOR-PEER-ADDRESS. > > > S 15.12: > > The error code field is too small to hold error codes (8 bits). I think > this should use the same structure as ERROR-CODE from 5389, but use some = of > the reserved bits for family. > > > > [TR] Yes, will fix that in the next revision. > > Suggestion: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | Rsvd |Class| Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason Phrase (variable) .. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --001a1134bd80b257f4051233d98b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 26, 2015 at 6:06 AM, Tirumaleswar Reddy (tireddy) <tireddy= @cisco.com> wrote:

Hi Justin,

=C2=A0

Thanks for the comments. Please see inline [= TR]

=C2=A0

From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: Thursday, March 26, 2015 11:32 AM
To: tram@ietf.org=
Subject: [tram] Comments on draft-ietf-tram-turnbis-01=

=C2=A0

better late than never:

=C2=A0

S 6.1:

I don't think that we need to forbid using RAF w= ith AAF. It should be possible to do RAF(v4) with AAF(v6), RAF(v6) with AAF= (v4), or AAF(v6) by itself, all with the same meaning.=C2=A0<= /p>

=C2=A0

[TR] RAF is=C2=A0 comprehension-required att= ribute whereas AAF is comprehension-optional attribute, If client uses both= RAF + AAF and the server does not understand RAF then the request could fail. I don=E2=80=99t see any advantage of usin= g both RAF and AAF together.


I agree that typically AAF will be sent by itsel= f, but in the interest of defining a general mechanism I don't think we= should prohibit RAF + AAF.
=C2=A0

=C2=A0

S 7.1:

I think the client should include RAF for the bindin= gs that it wants to keep, not AAF. AAF is only useful in the ALLOCATE, wher= e the client doesn't know if the server supports AAF.

=C2=A0

[TR] If AAF is used for Allocation th= en there is no reason why RAF should be used for the binding (server may no= t support RAF and it will result in failure to refresh).

There is no server that will support AAF but not RAF.=C2=A0

For a dual allocation, the client should be able to r= efresh the v4, v6, or both. Right now in the doc, we don't have that co= ntrol. I suggest the following:
v4 can be refreshed by sending RA= F(v4).
v6 can be refreshed by sending RAF(v6).
both can= be refreshed by sending RAF(v4+v6), and/or, perhaps, no RAF.
For a single allocation, I suggest we keep the existing format = where sending no RAF refreshes the allocation.
=C2=A0

=C2=A0

S 9.1:

I don't think we want to support CreatePermissio= ns with multiple addresses. It doesn't save anything other than 2 packe= ts and just makes life more complicated.

=C2=A0

[TR] Please clarify why it complicates imple= mentation ?


<= /div>
You now need to handle partial successes, so your error handling = path is more complicated.

But mainly, it's not= clear at all why a client would use this.
=C2=A0

=C2=A0

S 11.1:

How would you do a ChannelBind with multiple address= es? Sent packets go to both destinations? Again, this seems complex with no= good reason.

=C2=A0

[TR] Agreed, will fix in the next rev= ersion.

=C2=A0

S 15.6/15.11:

It would be good to separate the RAF/AAF payload def= inition out so that it doesn't need to be repeated in both sections.=

=C2=A0

[TR] The payload text is not large en= ough for a separate section.


At 30 lines of text, I disagree. We are already = doing this sort of thing for XOR-PEER-ADDRESS.
=C2=A0

=C2=A0

S 15.12:

The error code field is too small to hold error code= s (8 bits). I think this should use the same structure as ERROR-CODE from 5= 389, but use some of the reserved bits for family.

=C2=A0

[TR] Yes, will fix that in the next r= evision.


Suggestion:

<= pre style=3D"white-space:pre-wrap;font-size:1em;margin-top:0px;margin-botto= m:0px;color:rgb(0,0,0)"> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+ | Address Family = | Rsvd |Class| Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason Phrase (variable) .. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--001a1134bd80b257f4051233d98b-- From nobody Thu Mar 26 11:39:29 2015 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 379611B2A73 for ; Thu, 26 Mar 2015 11:39:28 -0700 (PDT) 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 AMfUMfIibOEh for ; Thu, 26 Mar 2015 11:39:25 -0700 (PDT) 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 7BD3D1B2A6E for ; Thu, 26 Mar 2015 11:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34362; q=dns/txt; s=iport; t=1427395165; x=1428604765; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sV+C4OsOM33o2ivlfPnKWf9p4Q0Tn2v1cUa/z1GSHls=; b=R+o1UVGjjRF/VRc9sGXQ3MObe6kGI/2jjZmbTr5h9xpkb/A3GBX/n4hu NgbhfAIc2KZ77iKffAcCEArIWRGsl/2ubADN5SXsYY+4SeM0QJUhpC4tE KQsPA1fz9BjnLkPJ3Le54IcEmkUlFMjiiTCcMNdvuXk+l+sueovzGIhy6 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CABgAtURRV/51dJa1cgkNDUloEgw6/YogwAhyBQEwBAQEBAQF9hBQBAQEEIwoaMhACAQgOAwQBAQsWBwMCAgIwFAkIAQEEDgUIEYgWsV6FFpUWAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sohEcWGwYBgmgvgRYFjkKCDosKgzCMG4NHIoNub4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,474,1422921600"; d="scan'208,217";a="135718667" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP; 26 Mar 2015 18:39:24 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t2QIdN55023528 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Mar 2015 18:39:23 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.80]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Thu, 26 Mar 2015 13:39:23 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Justin Uberti Thread-Topic: [tram] Comments on draft-ietf-tram-turnbis-01 Thread-Index: AdBntPY5ANaPCcypQFyW0ZUNvQto2QAWjv+AAAiXOWA= Date: Thu, 26 Mar 2015 18:39:22 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A366D1482@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A366D0EDE@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.59.128] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A366D1482xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-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: Thu, 26 Mar 2015 18:39:28 -0000 --_000_913383AAA69FF945B8F946018B75898A366D1482xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW5saW5lIFtUUjJdDQoNCkZyb206IEp1c3RpbiBVYmVydGkgW21haWx0bzpqdWJlcnRpQGdvb2ds ZS5jb21dDQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMjYsIDIwMTUgMTA6MjMgUE0NClRvOiBUaXJ1 bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQpDYzogdHJhbUBpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFt0cmFtXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0wMQ0KDQoNCg0KT24g VGh1LCBNYXIgMjYsIDIwMTUgYXQgNjowNiBBTSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5 KSA8dGlyZWRkeUBjaXNjby5jb208bWFpbHRvOnRpcmVkZHlAY2lzY28uY29tPj4gd3JvdGU6DQpI aSBKdXN0aW4sDQoNClRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLiBQbGVhc2Ugc2VlIGlubGluZSBb VFJdDQoNCkZyb206IHRyYW0gW21haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnRy YW0tYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBKdXN0aW4gVWJlcnRpDQpTZW50OiBU aHVyc2RheSwgTWFyY2ggMjYsIDIwMTUgMTE6MzIgQU0NClRvOiB0cmFtQGlldGYub3JnPG1haWx0 bzp0cmFtQGlldGYub3JnPg0KU3ViamVjdDogW3RyYW1dIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYt dHJhbS10dXJuYmlzLTAxDQoNCmJldHRlciBsYXRlIHRoYW4gbmV2ZXI6DQoNClMgNi4xOg0KSSBk b24ndCB0aGluayB0aGF0IHdlIG5lZWQgdG8gZm9yYmlkIHVzaW5nIFJBRiB3aXRoIEFBRi4gSXQg c2hvdWxkIGJlIHBvc3NpYmxlIHRvIGRvIFJBRih2NCkgd2l0aCBBQUYodjYpLCBSQUYodjYpIHdp dGggQUFGKHY0KSwgb3IgQUFGKHY2KSBieSBpdHNlbGYsIGFsbCB3aXRoIHRoZSBzYW1lIG1lYW5p bmcuDQoNCltUUl0gUkFGIGlzICBjb21wcmVoZW5zaW9uLXJlcXVpcmVkIGF0dHJpYnV0ZSB3aGVy ZWFzIEFBRiBpcyBjb21wcmVoZW5zaW9uLW9wdGlvbmFsIGF0dHJpYnV0ZSwgSWYgY2xpZW50IHVz ZXMgYm90aCBSQUYgKyBBQUYgYW5kIHRoZSBzZXJ2ZXIgZG9lcyBub3QgdW5kZXJzdGFuZCBSQUYg dGhlbiB0aGUgcmVxdWVzdCBjb3VsZCBmYWlsLiBJIGRvbuKAmXQgc2VlIGFueSBhZHZhbnRhZ2Ug b2YgdXNpbmcgYm90aCBSQUYgYW5kIEFBRiB0b2dldGhlci4NCg0KSSBhZ3JlZSB0aGF0IHR5cGlj YWxseSBBQUYgd2lsbCBiZSBzZW50IGJ5IGl0c2VsZiwgYnV0IGluIHRoZSBpbnRlcmVzdCBvZiBk ZWZpbmluZyBhIGdlbmVyYWwgbWVjaGFuaXNtIEkgZG9uJ3QgdGhpbmsgd2Ugc2hvdWxkIHByb2hp Yml0IFJBRiArIEFBRi4NCg0KW1RSMl0gUkFGICsgQUFGIGNvbXBsaWNhdGVzIHNlcnZlciBhbmQg Y2xpZW50IGltcGxlbWVudGF0aW9ucyB3aXRob3V0IGFueSBiZW5lZml0cy4NCg0KDQpTIDcuMToN CkkgdGhpbmsgdGhlIGNsaWVudCBzaG91bGQgaW5jbHVkZSBSQUYgZm9yIHRoZSBiaW5kaW5ncyB0 aGF0IGl0IHdhbnRzIHRvIGtlZXAsIG5vdCBBQUYuIEFBRiBpcyBvbmx5IHVzZWZ1bCBpbiB0aGUg QUxMT0NBVEUsIHdoZXJlIHRoZSBjbGllbnQgZG9lc24ndCBrbm93IGlmIHRoZSBzZXJ2ZXIgc3Vw cG9ydHMgQUFGLg0KDQpbVFJdIElmIEFBRiBpcyB1c2VkIGZvciBBbGxvY2F0aW9uIHRoZW4gdGhl cmUgaXMgbm8gcmVhc29uIHdoeSBSQUYgc2hvdWxkIGJlIHVzZWQgZm9yIHRoZSBiaW5kaW5nIChz ZXJ2ZXIgbWF5IG5vdCBzdXBwb3J0IFJBRiBhbmQgaXQgd2lsbCByZXN1bHQgaW4gZmFpbHVyZSB0 byByZWZyZXNoKS4NCg0KVGhlcmUgaXMgbm8gc2VydmVyIHRoYXQgd2lsbCBzdXBwb3J0IEFBRiBi dXQgbm90IFJBRi4NCg0KRm9yIGEgZHVhbCBhbGxvY2F0aW9uLCB0aGUgY2xpZW50IHNob3VsZCBi ZSBhYmxlIHRvIHJlZnJlc2ggdGhlIHY0LCB2Niwgb3IgYm90aC4gUmlnaHQgbm93IGluIHRoZSBk b2MsIHdlIGRvbid0IGhhdmUgdGhhdCBjb250cm9sLg0KDQpbVFIyXSBUaGUgY29udHJvbCBpcyBw b3NzaWJsZSBhbmQgaXMgZGlzY3Vzc2VkIGluIHNlY3Rpb24gNy4xDQoNCjxzbmlwPg0KDQogICBX aGVuIHJlZnJlc2hpbmcgYSBkdWFsIGFsbG9jYXRpb24sIHRoZSBjbGllbnQgaW5jbHVkZXMgQURE SVRJT05BTC0NCiAgIEFERFJFU1MtRkFNSUxZIGF0dHJpYnV0ZSBpbmRpY2F0aW5nIHRoZSBhZGRy ZXNzIGZhbWlseSB0eXBlIHRoYXQNCiAgIHNob3VsZCBiZSByZWZyZXNoZWQuICBJZiBubyBBRERJ VElPTkFMLUFERFJFU1MtRkFNSUxZIGlzIGluY2x1ZGVkDQogICB0aGVuIHRoZSByZXF1ZXN0IHNo b3VsZCBiZSB0cmVhdGVkIGFzIGFwcGx5aW5nIHRvIGFsbCBjdXJyZW50DQogICBhbGxvY2F0aW9u cy4NCjwvc25pcD4NCg0KSSBzdWdnZXN0IHRoZSBmb2xsb3dpbmc6DQp2NCBjYW4gYmUgcmVmcmVz aGVkIGJ5IHNlbmRpbmcgUkFGKHY0KS4NCnY2IGNhbiBiZSByZWZyZXNoZWQgYnkgc2VuZGluZyBS QUYodjYpLg0KYm90aCBjYW4gYmUgcmVmcmVzaGVkIGJ5IHNlbmRpbmcgUkFGKHY0K3Y2KSwgYW5k L29yLCBwZXJoYXBzLCBubyBSQUYuDQoNCkZvciBhIHNpbmdsZSBhbGxvY2F0aW9uLCBJIHN1Z2dl c3Qgd2Uga2VlcCB0aGUgZXhpc3RpbmcgZm9ybWF0IHdoZXJlIHNlbmRpbmcgbm8gUkFGIHJlZnJl c2hlcyB0aGUgYWxsb2NhdGlvbi4NCg0KDQpTIDkuMToNCkkgZG9uJ3QgdGhpbmsgd2Ugd2FudCB0 byBzdXBwb3J0IENyZWF0ZVBlcm1pc3Npb25zIHdpdGggbXVsdGlwbGUgYWRkcmVzc2VzLiBJdCBk b2Vzbid0IHNhdmUgYW55dGhpbmcgb3RoZXIgdGhhbiAyIHBhY2tldHMgYW5kIGp1c3QgbWFrZXMg bGlmZSBtb3JlIGNvbXBsaWNhdGVkLg0KDQpbVFJdIFBsZWFzZSBjbGFyaWZ5IHdoeSBpdCBjb21w bGljYXRlcyBpbXBsZW1lbnRhdGlvbiA/DQoNCllvdSBub3cgbmVlZCB0byBoYW5kbGUgcGFydGlh bCBzdWNjZXNzZXMsIHNvIHlvdXIgZXJyb3IgaGFuZGxpbmcgcGF0aCBpcyBtb3JlIGNvbXBsaWNh dGVkLg0KDQpbVFIyXSBHb29kIHBvaW50LCB3aWxsIHJlbW92ZSBzdXBwb3J0IGZvciBtdWx0aXBs ZSBhZGRyZXNzZXMuDQoNCkJ1dCBtYWlubHksIGl0J3Mgbm90IGNsZWFyIGF0IGFsbCB3aHkgYSBj bGllbnQgd291bGQgdXNlIHRoaXMuDQoNCg0KUyAxMS4xOg0KSG93IHdvdWxkIHlvdSBkbyBhIENo YW5uZWxCaW5kIHdpdGggbXVsdGlwbGUgYWRkcmVzc2VzPyBTZW50IHBhY2tldHMgZ28gdG8gYm90 aCBkZXN0aW5hdGlvbnM/IEFnYWluLCB0aGlzIHNlZW1zIGNvbXBsZXggd2l0aCBubyBnb29kIHJl YXNvbi4NCg0KW1RSXSBBZ3JlZWQsIHdpbGwgZml4IGluIHRoZSBuZXh0IHJldmVyc2lvbi4NCg0K UyAxNS42LzE1LjExOg0KSXQgd291bGQgYmUgZ29vZCB0byBzZXBhcmF0ZSB0aGUgUkFGL0FBRiBw YXlsb2FkIGRlZmluaXRpb24gb3V0IHNvIHRoYXQgaXQgZG9lc24ndCBuZWVkIHRvIGJlIHJlcGVh dGVkIGluIGJvdGggc2VjdGlvbnMuDQoNCltUUl0gVGhlIHBheWxvYWQgdGV4dCBpcyBub3QgbGFy Z2UgZW5vdWdoIGZvciBhIHNlcGFyYXRlIHNlY3Rpb24uDQoNCkF0IDMwIGxpbmVzIG9mIHRleHQs IEkgZGlzYWdyZWUuIFdlIGFyZSBhbHJlYWR5IGRvaW5nIHRoaXMgc29ydCBvZiB0aGluZyBmb3Ig WE9SLVBFRVItQUREUkVTUy4NCg0KW1RSMl0gT2theSwgd2lsbCByZW1vdmUgZHVwbGljYXRlIHRl eHQuDQoNClMgMTUuMTI6DQpUaGUgZXJyb3IgY29kZSBmaWVsZCBpcyB0b28gc21hbGwgdG8gaG9s ZCBlcnJvciBjb2RlcyAoOCBiaXRzKS4gSSB0aGluayB0aGlzIHNob3VsZCB1c2UgdGhlIHNhbWUg c3RydWN0dXJlIGFzIEVSUk9SLUNPREUgZnJvbSA1Mzg5LCBidXQgdXNlIHNvbWUgb2YgdGhlIHJl c2VydmVkIGJpdHMgZm9yIGZhbWlseS4NCg0KW1RSXSBZZXMsIHdpbGwgZml4IHRoYXQgaW4gdGhl IG5leHQgcmV2aXNpb24uDQoNClN1Z2dlc3Rpb246DQoNCg0KICAgICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KICAg ICAgfCAgQWRkcmVzcyBGYW1pbHkgICAgICAgICAgICAgICAgfCAgUnN2ZCAgfENsYXNzfCAgICAg TnVtYmVyICAgIHwNCg0KICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KICAgICAgfCAgICAgIFJlYXNvbiBQaHJh c2UgKHZhcmlhYmxlKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLi4NCg0KICAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCg0KDQoNCltUUjJdIFNob3VsZG7igJl0IGl0IGJlIFJzdmQgZm9sbG93ZWQgYnkg QWRkcmVzcyBmYW1pbHkgPw0KDQoNCg0KLVRpcnUNCg== --_000_913383AAA69FF945B8F946018B75898A366D1482xmbrcdx10ciscoc_ 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 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz O30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWls U3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J bmxpbmUgW1RSMl08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g SnVzdGluIFViZXJ0aSBbbWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6 PC9iPiBUaHVyc2RheSwgTWFyY2ggMjYsIDIwMTUgMTA6MjMgUE08YnI+DQo8Yj5Ubzo8L2I+IFRp cnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk8YnI+DQo8Yj5DYzo8L2I+IHRyYW1AaWV0Zi5vcmc8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0cmFtXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLXRy YW0tdHVybmJpcy0wMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBUaHUsIE1hciAyNiwgMjAxNSBhdCA2OjA2IEFNLCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVk ZHkpICZsdDs8YSBocmVmPSJtYWlsdG86dGlyZWRkeUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5r Ij50aXJlZGR5QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5IaSBKdXN0aW4sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciB0aGUg Y29tbWVudHMuIFBsZWFzZSBzZWUgaW5saW5lIFtUUl08L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHRyYW0gW21haWx0bzo8YSBocmVmPSJtYWlsdG86dHJh bS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dHJhbS1ib3VuY2VzQGlldGYub3Jn PC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SnVzdGluIFViZXJ0aTxicj4NCjxiPlNlbnQ6PC9i PiBUaHVyc2RheSwgTWFyY2ggMjYsIDIwMTUgMTE6MzIgQU08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhy ZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dHJhbUBpZXRmLm9yZzwv YT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3RyYW1dIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtdHJh bS10dXJuYmlzLTAxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5iZXR0ZXIgbGF0ZSB0aGFuIG5ldmVyOjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlMgNi4xOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGRvbid0IHRoaW5rIHRoYXQgd2Ug bmVlZCB0byBmb3JiaWQgdXNpbmcgUkFGIHdpdGggQUFGLiBJdCBzaG91bGQgYmUgcG9zc2libGUg dG8gZG8gUkFGKHY0KSB3aXRoIEFBRih2NiksIFJBRih2Nikgd2l0aCBBQUYodjQpLCBvciBBQUYo djYpIGJ5IGl0c2VsZiwgYWxsIHdpdGggdGhlIHNhbWUgbWVhbmluZy4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltU Ul0gUkFGIGlzJm5ic3A7IGNvbXByZWhlbnNpb24tcmVxdWlyZWQgYXR0cmlidXRlIHdoZXJlYXMg QUFGIGlzIGNvbXByZWhlbnNpb24tb3B0aW9uYWwgYXR0cmlidXRlLCBJZg0KIGNsaWVudCB1c2Vz IGJvdGggUkFGICYjNDM7IEFBRiBhbmQgdGhlIHNlcnZlciBkb2VzIG5vdCB1bmRlcnN0YW5kIFJB RiB0aGVuIHRoZSByZXF1ZXN0IGNvdWxkIGZhaWwuIEkgZG9u4oCZdCBzZWUgYW55IGFkdmFudGFn ZSBvZiB1c2luZyBib3RoIFJBRiBhbmQgQUFGIHRvZ2V0aGVyLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlIHRoYXQgdHlwaWNhbGx5IEFBRiB3aWxsIGJlIHNlbnQg YnkgaXRzZWxmLCBidXQgaW4gdGhlIGludGVyZXN0IG9mIGRlZmluaW5nIGEgZ2VuZXJhbCBtZWNo YW5pc20gSSBkb24ndCB0aGluayB3ZSBzaG91bGQgcHJvaGliaXQgUkFGICYjNDM7IEFBRi48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ W1RSMl0gUkFGICYjNDM7IEFBRiBjb21wbGljYXRlcyBzZXJ2ZXIgYW5kIGNsaWVudCBpbXBsZW1l bnRhdGlvbnMgd2l0aG91dCBhbnkgYmVuZWZpdHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UyA3LjE6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgdGhpbmsgdGhlIGNsaWVu dCBzaG91bGQgaW5jbHVkZSBSQUYgZm9yIHRoZSBiaW5kaW5ncyB0aGF0IGl0IHdhbnRzIHRvIGtl ZXAsIG5vdCBBQUYuIEFBRiBpcyBvbmx5IHVzZWZ1bCBpbiB0aGUgQUxMT0NBVEUsIHdoZXJlIHRo ZSBjbGllbnQgZG9lc24ndCBrbm93IGlmIHRoZSBzZXJ2ZXIgc3VwcG9ydHMgQUFGLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ W1RSXSBJZiBBQUYgaXMgdXNlZCBmb3IgQWxsb2NhdGlvbiB0aGVuIHRoZXJlIGlzIG5vIHJlYXNv biB3aHkgUkFGIHNob3VsZCBiZSB1c2VkIGZvciB0aGUgYmluZGluZw0KIChzZXJ2ZXIgbWF5IG5v dCBzdXBwb3J0IFJBRiBhbmQgaXQgd2lsbCByZXN1bHQgaW4gZmFpbHVyZSB0byByZWZyZXNoKS48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUg aXMgbm8gc2VydmVyIHRoYXQgd2lsbCBzdXBwb3J0IEFBRiBidXQgbm90IFJBRi4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIGEg ZHVhbCBhbGxvY2F0aW9uLCB0aGUgY2xpZW50IHNob3VsZCBiZSBhYmxlIHRvIHJlZnJlc2ggdGhl IHY0LCB2Niwgb3IgYm90aC4gUmlnaHQgbm93IGluIHRoZSBkb2MsIHdlIGRvbid0IGhhdmUgdGhh dCBjb250cm9sLg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1RSMl0g VGhlIGNvbnRyb2wgaXMgcG9zc2libGUgYW5kIGlzIGRpc2N1c3NlZCBpbiBzZWN0aW9uIDcuMTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jmx0O3NuaXAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgV2hlbiByZWZyZXNoaW5nIGEgZHVh bCBhbGxvY2F0aW9uLCB0aGUgY2xpZW50IGluY2x1ZGVzIEFERElUSU9OQUwtPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBB RERSRVNTLUZBTUlMWSBhdHRyaWJ1dGUgaW5kaWNhdGluZyB0aGUgYWRkcmVzcyBmYW1pbHkgdHlw ZSB0aGF0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyBzaG91bGQgYmUgcmVmcmVzaGVkLiZuYnNwOyBJZiBubyBBRERJVElP TkFMLUFERFJFU1MtRkFNSUxZIGlzIGluY2x1ZGVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB0aGVuIHRoZSByZXF1ZXN0 IHNob3VsZCBiZSB0cmVhdGVkIGFzIGFwcGx5aW5nIHRvIGFsbCBjdXJyZW50PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBh bGxvY2F0aW9ucy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbHQ7L3NuaXAmZ3Q7 DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBzdWdnZXN0IHRoZSBmb2xsb3dpbmc6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj52NCBjYW4gYmUg cmVmcmVzaGVkIGJ5IHNlbmRpbmcgUkFGKHY0KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnY2IGNhbiBiZSByZWZyZXNoZWQgYnkgc2VuZGluZyBS QUYodjYpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Ym90aCBjYW4gYmUgcmVmcmVzaGVkIGJ5IHNlbmRpbmcgUkFGKHY0JiM0Mzt2NiksIGFuZC9v ciwgcGVyaGFwcywgbm8gUkFGLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Gb3IgYSBzaW5nbGUgYWxsb2NhdGlvbiwgSSBzdWdnZXN0IHdlIGtl ZXAgdGhlIGV4aXN0aW5nIGZvcm1hdCB3aGVyZSBzZW5kaW5nIG5vIFJBRiByZWZyZXNoZXMgdGhl IGFsbG9jYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5TIDkuMTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SSBkb24ndCB0aGluayB3ZSB3YW50IHRvIHN1cHBvcnQgQ3JlYXRlUGVy bWlzc2lvbnMgd2l0aCBtdWx0aXBsZSBhZGRyZXNzZXMuIEl0IGRvZXNuJ3Qgc2F2ZSBhbnl0aGlu ZyBvdGhlciB0aGFuIDIgcGFja2V0cyBhbmQganVzdCBtYWtlcyBsaWZlIG1vcmUgY29tcGxpY2F0 ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5bVFJdIFBsZWFzZSBjbGFyaWZ5IHdoeSBpdCBjb21wbGljYXRlcyBpbXBsZW1l bnRhdGlvbiA/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPllvdSBub3cgbmVlZCB0byBoYW5kbGUgcGFydGlhbCBzdWNjZXNzZXMsIHNvIHlvdXIgZXJy b3IgaGFuZGxpbmcgcGF0aCBpcyBtb3JlIGNvbXBsaWNhdGVkLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bVFIyXSBHb29kIHBvaW50 LCB3aWxsIHJlbW92ZSBzdXBwb3J0IGZvciBtdWx0aXBsZSBhZGRyZXNzZXMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CdXQgbWFp bmx5LCBpdCdzIG5vdCBjbGVhciBhdCBhbGwgd2h5IGEgY2xpZW50IHdvdWxkIHVzZSB0aGlzLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UyAx MS4xOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5Ib3cgd291bGQgeW91IGRvIGEgQ2hhbm5lbEJpbmQgd2l0aCBtdWx0aXBsZSBhZGRyZXNzZXM/ IFNlbnQgcGFja2V0cyBnbyB0byBib3RoIGRlc3RpbmF0aW9ucz8gQWdhaW4sIHRoaXMgc2VlbXMg Y29tcGxleCB3aXRoIG5vIGdvb2QgcmVhc29uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1RSXSBBZ3JlZWQsIHdpbGwgZml4 IGluIHRoZSBuZXh0IHJldmVyc2lvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TIDE1LjYvMTUuMTE6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkl0IHdvdWxkIGJlIGdv b2QgdG8gc2VwYXJhdGUgdGhlIFJBRi9BQUYgcGF5bG9hZCBkZWZpbml0aW9uIG91dCBzbyB0aGF0 IGl0IGRvZXNuJ3QgbmVlZCB0byBiZSByZXBlYXRlZCBpbiBib3RoIHNlY3Rpb25zLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ W1RSXSBUaGUgcGF5bG9hZCB0ZXh0IGlzIG5vdCBsYXJnZSBlbm91Z2ggZm9yIGEgc2VwYXJhdGUg c2VjdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QXQgMzAgbGluZXMgb2YgdGV4dCwgSSBkaXNhZ3JlZS4gV2UgYXJlIGFscmVhZHkgZG9pbmcg dGhpcyBzb3J0IG9mIHRoaW5nIGZvciBYT1ItUEVFUi1BRERSRVNTLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+W1RSMl0gT2theSwgd2lsbCByZW1vdmUgZHVwbGljYXRlIHRleHQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5TIDE1LjEyOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5UaGUgZXJyb3IgY29kZSBmaWVsZCBpcyB0b28gc21hbGwgdG8gaG9sZCBlcnJvciBj b2RlcyAoOCBiaXRzKS4gSSB0aGluayB0aGlzIHNob3VsZCB1c2UgdGhlIHNhbWUgc3RydWN0dXJl IGFzIEVSUk9SLUNPREUgZnJvbSA1Mzg5LCBidXQgdXNlIHNvbWUgb2YgdGhlIHJlc2VydmVkIGJp dHMgZm9yIGZhbWlseS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltUUl0gWWVzLCB3aWxsIGZpeCB0aGF0IGluIHRoZSBuZXh0 IHJldmlzaW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5TdWdnZXN0aW9uOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIHN0 eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsgQWRkcmVzcyBGYW1pbHkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyBSc3ZkJm5ic3A7IHxDbGFzc3wmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTnVt YmVyJm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7 Jm5ic3A7UmVhc29uIFBocmFzZSAodmFyaWFibGUpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC4uPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0Mzs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bVFIyXSBT aG91bGRu4oCZdCBpdCBiZSBSc3ZkIGZvbGxvd2VkIGJ5IEFkZHJlc3MgZmFtaWx5ID88bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LVRpcnU8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_913383AAA69FF945B8F946018B75898A366D1482xmbrcdx10ciscoc_-- From nobody Thu Mar 26 12:08:54 2015 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 7AE851ABC75 for ; Thu, 26 Mar 2015 12:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 Tfo8HGqM6RCZ for ; Thu, 26 Mar 2015 12:08:48 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id C923B1A9151 for ; Thu, 26 Mar 2015 12:08:48 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C367A285FA for ; Thu, 26 Mar 2015 19:08:47 +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 ACEF1285F8 for ; Thu, 26 Mar 2015 19:08:47 +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 A74682030 for ; Thu, 26 Mar 2015 19:08:47 +0000 (GMT) Message-ID: <5514593F.4050904@akamai.com> Date: Thu, 26 Mar 2015 15:08:47 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: tram@ietf.org References: <913383AAA69FF945B8F946018B75898A366D0EDE@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A366D1482@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A366D1482@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-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: Thu, 26 Mar 2015 19:08:53 -0000 I agree that it may be difficult to handle within an implementation. That said, unless you're certain that no clients have implemented this already (it's not new in turnbis) we'll have to have an explicit backward compatibility mechanism. What do you propose for that? I agree that we shouldn't add multi-address support to ChannelBind requests, though, since it doesn't already exist there. --Brandon On 03/26/2015 02:39 PM, Tirumaleswar Reddy (tireddy) wrote: > S 9.1: > > I don't think we want to support CreatePermissions with multiple > addresses. It doesn't save anything other than 2 packets and just > makes life more complicated. > > [TR] Please clarify why it complicates implementation ? > > You now need to handle partial successes, so your error handling path is > more complicated. > > [TR2] Good point, will remove support for multiple addresses. > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Thu Mar 26 13:06:10 2015 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 D55811B2E45; Thu, 26 Mar 2015 13:06:07 -0700 (PDT) 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 J6iUNA83_THw; Thu, 26 Mar 2015 13:06:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C0D1B2E36; Thu, 26 Mar 2015 13:06:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150326200603.5774.97401.idtracker@ietfa.amsl.com> Date: Thu, 26 Mar 2015 13:06:03 -0700 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-stunbis-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: Thu, 26 Mar 2015 20:06:08 -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 : Session Traversal Utilities for NAT (STUN) Authors : Marc Petit-Huguenin Gonzalo Salgueiro Jonathan Rosenberg Dan Wing Rohan Mahy Philip Matthews Filename : draft-ietf-tram-stunbis-03.txt Pages : 58 Date : 2015-03-26 Abstract: Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This document obsoletes RFC 5389. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tram-stunbis-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stunbis-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 Thu Mar 26 14:55:25 2015 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 DFAD71B2F9F for ; Thu, 26 Mar 2015 14:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 QC7KH_ZKvuc0 for ; Thu, 26 Mar 2015 14:55:21 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B8B81B2F93 for ; Thu, 26 Mar 2015 14:55:21 -0700 (PDT) Received: by igbqf9 with SMTP id qf9so4679059igb.1 for ; Thu, 26 Mar 2015 14:55:21 -0700 (PDT) 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=JchypZcLSX91Jo5EBPgm6twVkhis3fTSJEIcSO19OSU=; b=eq5hKz7q2X1cLBX2DzMUP4/kiCB6roZTzHTmJtFT89aGhh2J8G/Jzbx1yiVSoxmVGb MXdBD0JsfmNT4tg/oSqVFYGysJTPbN6knEF1MD0F6QwTXSzMa99xNf7CZ8jYK2Xejsec pyWx6V81quzt6mAkuUwdCVKqdC/Fk9GxwTGAZfHo5iqNjlVMlCjCWLjFKwtOUE5N8unV 7Afj4yIPa8Bfl1hryVPHSnU/cxnLnPN//QFVuiyMMALjttELISiWUgy5OoIIgHfxE2ex /okL3QGKDIiJ+DmBvWiTs6fG+tTE7tzBmkrUu1+o0ahXvFChA9HnhmTAGPCGDsfxORft 1KKQ== 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=JchypZcLSX91Jo5EBPgm6twVkhis3fTSJEIcSO19OSU=; b=b/2XJb3alEwTwtLOKNxeu/jEvaZVVXeKhIMDi2OIha3Kjq7XjuOWov3mVW3xr/E9b3 U9Cvc6xoK7gEXLMOtCQs2DBZTyFMEqVljZgwEX7uY/ziFzvPQasIZ2GLFxQArqlp5XPe xVaW948kft0b7qbQmALol4sNRw2aTY2Lj7c/GGnf6Cmthyg+wO+R5D33DWG7fBETLS8r 5nZ+39x+3e/aFjNcxlJZpHRYKFlx06GPaDN83ED2bMRAd/YTIVuXUJNczq+dMYJtSIwM vbLlMIUaATwM24QKh3YQysD6Vvl9FRygk6xb4KhJfg4ARouo4Bpc2tAH7Ui0r/2d5bgQ XbyQ== X-Gm-Message-State: ALoCoQnIBqikEqWM83fVLO62v0pSs4Yu+g6xRbASpzMHRkAVKxpbFTXjPSfIwRpQHAtE+L+rfjbB X-Received: by 10.43.110.136 with SMTP id ek8mr42312870icc.87.1427406920877; Thu, 26 Mar 2015 14:55:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.64.42 with HTTP; Thu, 26 Mar 2015 14:55:00 -0700 (PDT) In-Reply-To: <5514593F.4050904@akamai.com> References: <913383AAA69FF945B8F946018B75898A366D0EDE@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A366D1482@xmb-rcd-x10.cisco.com> <5514593F.4050904@akamai.com> From: Justin Uberti Date: Thu, 26 Mar 2015 16:55:00 -0500 Message-ID: To: Brandon Williams Content-Type: multipart/alternative; boundary=bcaec5171ab178342f0512381247 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-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: Thu, 26 Mar 2015 21:55:23 -0000 --bcaec5171ab178342f0512381247 Content-Type: text/plain; charset=UTF-8 OK, this was an oversight on my part. As long as we return 400 if any addresses are busted (as currently indicated in S 9.2), this should work fine - v4 permissions set for the v4 allocation, v6 permissions set for v6 allocation. On Thu, Mar 26, 2015 at 2:08 PM, Brandon Williams < brandon.williams@akamai.com> wrote: > I agree that it may be difficult to handle within an implementation. That > said, unless you're certain that no clients have implemented this already > (it's not new in turnbis) we'll have to have an explicit backward > compatibility mechanism. What do you propose for that? > > I agree that we shouldn't add multi-address support to ChannelBind > requests, though, since it doesn't already exist there. > > --Brandon > > > On 03/26/2015 02:39 PM, Tirumaleswar Reddy (tireddy) wrote: > >> S 9.1: >> >> I don't think we want to support CreatePermissions with multiple >> addresses. It doesn't save anything other than 2 packets and just >> makes life more complicated. >> >> [TR] Please clarify why it complicates implementation ? >> >> You now need to handle partial successes, so your error handling path is >> more complicated. >> >> [TR2] Good point, will remove support for multiple addresses. >> >> > -- > 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 > --bcaec5171ab178342f0512381247 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK, this was an oversight on my part. As long as we return= 400 if any addresses are busted (as currently indicated in S 9.2), this sh= ould work fine - v4 permissions set for the v4 allocation, v6 permissions s= et for v6 allocation.

On Thu, Mar 26, 2015 at 2:08 PM, Brandon Williams <bra= ndon.williams@akamai.com> wrote:
I agree that it may be difficult to handle within an implementation. = That said, unless you're certain that no clients have implemented this = already (it's not new in turnbis) we'll have to have an explicit ba= ckward compatibility mechanism. What do you propose for that?

I agree that we shouldn't add multi-address support to ChannelBind requ= ests, though, since it doesn't already exist there.

--Brandon


On 03/26/2015 02:39 PM, Tirumaleswar Reddy (tireddy) wrote:
=C2=A0 =C2=A0 S 9.1:

=C2=A0 =C2=A0 I don't think we want to support CreatePermissions with m= ultiple
=C2=A0 =C2=A0 addresses. It doesn't save anything other than 2 packets = and just
=C2=A0 =C2=A0 makes life more complicated.

=C2=A0 =C2=A0 [TR] Please clarify why it complicates implementation ?

You now need to handle partial successes, so your error handling path is more complicated.

[TR2] Good point, will remove support for multiple addresses.


--
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

--bcaec5171ab178342f0512381247-- From nobody Thu Mar 26 15:02:30 2015 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 E5E621B2F9B for ; Thu, 26 Mar 2015 15:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 H8OqQTAFDq00 for ; Thu, 26 Mar 2015 15:02:26 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11AE01B2FAA for ; Thu, 26 Mar 2015 15:02:25 -0700 (PDT) Received: by igcxg11 with SMTP id xg11so4888142igc.0 for ; Thu, 26 Mar 2015 15:02:24 -0700 (PDT) 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=q3XVp+wYqWEinPvh67qdLxI4+c0cDlMjDUxOggrNfmI=; b=Q5wdFuwqfcajJ0ZL4c3TQUpji1ncoKpp2eoF7Bllx+TjVq8b9YwveGpSAkXkY+lIEj u1HYmNJs5aKCZUxa24H3tcsIyVabDYpIS1tnIIYiAHgRrFvr4ogPv6djI0v2OgNSX+cY 2qCHUJxj3a1TWDicWxGsBTESXwyFP5j9jZ6tJPqUl3fui98p0C3sg3IVubAFbTLij4Jd LA9rUa5BnqjOz9VX/LwSq7eIorXfvg5dY+d28CP/7bPgIw84XsYwVlU0/lM/l4PtjzHp bCAPrLNhKzLjhOY9hQbJsG9juPycyGxsp+jeiLjVkt65aAPYReu1+xin/uAom7Uj+rR8 ve4A== 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=q3XVp+wYqWEinPvh67qdLxI4+c0cDlMjDUxOggrNfmI=; b=KgbfeYDlytiPeqipcrhz6aCI12RmNG5bZKbEE/YqmCpWcE2drxVxNFJCLnZjDB6Kst 3kPzCRxkpJQ4UFra4l9VTqvU42PfJ7pTtEZKXoJ7X4w5EayqK7qRAPJWPBvNBf1SehjD aF3PGSl2+2M3sa+1273IZtC7PSuGRfrOEKm3s3qgodGWXAGjPiXDJ2C/zCtHv/i8l18C 4vK6hr3ejh9aKLt4XBRppMuIRg2O5zbqjRRHhYZ8xaSxmbsNhBzR4iixnhb/a9pGO7qY y3NrkrRGHOfEAEVMzX6znhgTka4sc5B9oYvoAaTaCrNG1cSCJA/49u9WGzje2eZ22oJ4 Wvqg== X-Gm-Message-State: ALoCoQk2jhSxW6LI/QSLgabv2vD+E4HETeJyInbBusmW9lYJCC6m2JbvXCRRTK99NpUrDUBwWVPg X-Received: by 10.50.118.97 with SMTP id kl1mr33138935igb.23.1427407344453; Thu, 26 Mar 2015 15:02:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.64.42 with HTTP; Thu, 26 Mar 2015 15:02:02 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A366D1482@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A366D0EDE@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A366D1482@xmb-rcd-x10.cisco.com> From: Justin Uberti Date: Thu, 26 Mar 2015 17:02:02 -0500 Message-ID: To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=089e013a1118b7786f0512382b24 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-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: Thu, 26 Mar 2015 22:02:29 -0000 --089e013a1118b7786f0512382b24 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 26, 2015 at 1:39 PM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > Inline [TR2] > > > > *From:* Justin Uberti [mailto:juberti@google.com] > *Sent:* Thursday, March 26, 2015 10:23 PM > *To:* Tirumaleswar Reddy (tireddy) > *Cc:* tram@ietf.org > *Subject:* Re: [tram] Comments on draft-ietf-tram-turnbis-01 > > > > > > > > On Thu, Mar 26, 2015 at 6:06 AM, Tirumaleswar Reddy (tireddy) < > tireddy@cisco.com> wrote: > > Hi Justin, > > > > Thanks for the comments. Please see inline [TR] > > > > *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Justin Uberti > *Sent:* Thursday, March 26, 2015 11:32 AM > *To:* tram@ietf.org > *Subject:* [tram] Comments on draft-ietf-tram-turnbis-01 > > > > better late than never: > > > > S 6.1: > > I don't think that we need to forbid using RAF with AAF. It should be > possible to do RAF(v4) with AAF(v6), RAF(v6) with AAF(v4), or AAF(v6) by > itself, all with the same meaning. > > > > [TR] RAF is comprehension-required attribute whereas AAF is > comprehension-optional attribute, If client uses both RAF + AAF and the > server does not understand RAF then the request could fail. I don=E2=80= =99t see any > advantage of using both RAF and AAF together. > > > > I agree that typically AAF will be sent by itself, but in the interest of > defining a general mechanism I don't think we should prohibit RAF + AAF. > > > > [TR2] RAF + AAF complicates server and client implementations without any > benefits. > I think it makes it easier to reason about what these attributes actually do. Server needs to handle RAF anyway. That said, I don't feel super strongly about this. > > > > > S 7.1: > > I think the client should include RAF for the bindings that it wants to > keep, not AAF. AAF is only useful in the ALLOCATE, where the client doesn= 't > know if the server supports AAF. > > > > [TR] If AAF is used for Allocation then there is no reason why RAF should > be used for the binding (server may not support RAF and it will result in > failure to refresh). > > > > There is no server that will support AAF but not RAF. > > > > For a dual allocation, the client should be able to refresh the v4, v6, o= r > both. Right now in the doc, we don't have that control. > > > > [TR2] The control is possible and is discussed in section 7.1 > > > > > > > > When refreshing a dual allocation, the client includes ADDITIONAL- > > ADDRESS-FAMILY attribute indicating the address family type that > > should be refreshed. If no ADDITIONAL-ADDRESS-FAMILY is included > > then the request should be treated as applying to all current > > allocations. > > > It doesn't say how to only refresh v4, or only refresh v6, in a dual allocation. > > > I suggest the following: > > v4 can be refreshed by sending RAF(v4). > > v6 can be refreshed by sending RAF(v6). > > both can be refreshed by sending RAF(v4+v6), and/or, perhaps, no RAF. > > > > For a single allocation, I suggest we keep the existing format where > sending no RAF refreshes the allocation. > > > > > > S 9.1: > > I don't think we want to support CreatePermissions with multiple > addresses. It doesn't save anything other than 2 packets and just makes > life more complicated. > > > > [TR] Please clarify why it complicates implementation ? > > > > You now need to handle partial successes, so your error handling path is > more complicated. > > > > [TR2] Good point, will remove support for multiple addresses. > > > > But mainly, it's not clear at all why a client would use this. > > > > > > S 11.1: > > How would you do a ChannelBind with multiple addresses? Sent packets go t= o > both destinations? Again, this seems complex with no good reason. > > > > [TR] Agreed, will fix in the next reversion. > > > > S 15.6/15.11: > > It would be good to separate the RAF/AAF payload definition out so that i= t > doesn't need to be repeated in both sections. > > > > [TR] The payload text is not large enough for a separate section. > > > > At 30 lines of text, I disagree. We are already doing this sort of thing > for XOR-PEER-ADDRESS. > > > > [TR2] Okay, will remove duplicate text. > > > > S 15.12: > > The error code field is too small to hold error codes (8 bits). I think > this should use the same structure as ERROR-CODE from 5389, but use some = of > the reserved bits for family. > > > > [TR] Yes, will fix that in the next revision. > > > > Suggestion: > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Address Family | Rsvd |Class| Number | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Reason Phrase (variable) .. > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > [TR2] Shouldn=E2=80=99t it be Rsvd followed by Address family ? > > Then it won't be byte-aligned, which seems bad. --089e013a1118b7786f0512382b24 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 26, 2015 at 1:39 PM, Tirumaleswar Reddy (tireddy) <tireddy= @cisco.com> wrote:

Inline [TR2]

=C2=A0

From: Justin U= berti [mailto:juber= ti@google.com]
Sent: Thursday, March 26, 2015 10:23 PM
To: Tirumaleswar Reddy (tireddy)
Cc: tram@ietf.org=
Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-01=

=C2=A0

=C2=A0

=C2=A0

On Thu, Mar 26, 2015 at 6:06 AM, Tirumaleswar Reddy = (tireddy) <tiredd= y@cisco.com> wrote:

Hi Justin,<= u>

=C2=A0

Thanks for the comments. = Please see inline [TR]

=C2=A0

From: tram [ma= ilto:tram-bounce= s@ietf.org] On Behalf Of Justin Uberti
Sent: Thursday, March 26, 2015 11:32 AM
To: tram@ietf.org=
Subject: [tram] Comments on draft-ietf-tram-turnbis-01=

=C2=A0

better late than never:

=C2=A0

S 6.1:

I don't think that we need to forbid using RAF w= ith AAF. It should be possible to do RAF(v4) with AAF(v6), RAF(v6) with AAF= (v4), or AAF(v6) by itself, all with the same meaning.=C2=A0<= /p>

=C2=A0

[TR] RAF is=C2=A0 compreh= ension-required attribute whereas AAF is comprehension-optional attribute, = If client uses both RAF + AAF and the server does not understand RAF then the= request could fail. I don=E2=80=99t see any advantage of using both RAF an= d AAF together.

=C2=A0

I agree that typically AAF will be sent by itself, b= ut in the interest of defining a general mechanism I don't think we sho= uld prohibit RAF + AAF.

=C2=A0

[TR2] RAF + AAF co= mplicates server and client implementations without any benefits.


I think it makes it easier to reason about what these attributes actually = do. Server needs to handle RAF anyway.

That said, = I don't feel super strongly about this.
=C2=A0

=C2=A0

=C2=A0

S 7.1:

I think the client should include RAF for the bindin= gs that it wants to keep, not AAF. AAF is only useful in the ALLOCATE, wher= e the client doesn't know if the server supports AAF.

=C2=A0

[TR] If AAF is used for A= llocation then there is no reason why RAF should be used for the binding (server may not support RAF and it will result in failure to refresh).

=C2=A0

There is no server that will support AAF but not RAF= .=C2=A0

=C2=A0

For a dual allocation, the client should be able to = refresh the v4, v6, or both. Right now in the doc, we don't have that c= ontrol.

=C2=A0

[TR2] The control = is possible and is discussed in section 7.1

=C2=A0

<snip>

=C2=A0

=C2=A0=C2=A0 When refreshing a dual allocation, the client= includes ADDITIONAL-

=C2=A0=C2=A0 ADDRESS-FAMILY attribute indicating the addre= ss family type that

=C2=A0=C2=A0 should be refreshed.=C2=A0 If no ADDITIONAL-A= DDRESS-FAMILY is included

=C2=A0=C2=A0 then the request should be treated as applyin= g to all current

=C2=A0=C2=A0 allocations.

</snip>

<= /div>

I= t doesn't say how to only refresh v4, or only refresh v6, in a dual all= ocation.
=C2=A0

=C2=A0

I suggest the following:

v4 can be refreshed by sending RAF(v4).

v6 can be refreshed by sending RAF(v6).

both can be refreshed by sending RAF(v4+v6), and/or,= perhaps, no RAF.

=C2=A0

For a single allocation, I suggest we keep the exist= ing format where sending no RAF refreshes the allocation.

=C2=A0

=C2=A0

S 9.1:

I don't think we want to support CreatePermissio= ns with multiple addresses. It doesn't save anything other than 2 packe= ts and just makes life more complicated.

=C2=A0

[TR] Please clarify why i= t complicates implementation ?

=C2=A0

You now need to handle partial successes, so your er= ror handling path is more complicated.

=C2=A0

[TR2] Good point, = will remove support for multiple addresses.

=C2=A0

But mainly, it's not clear at all why a client w= ould use this.

=C2=A0

=C2=A0

S 11.1:

How would you do a ChannelBind with multiple address= es? Sent packets go to both destinations? Again, this seems complex with no= good reason.

=C2=A0

[TR] Agreed, will fix in = the next reversion.

=C2=A0

S 15.6/15.11:

It would be good to separate the RAF/AAF payload def= inition out so that it doesn't need to be repeated in both sections.=

=C2=A0

[TR] The payload text is = not large enough for a separate section.

=C2=A0

At 30 lines of text, I disagree. We are already doin= g this sort of thing for XOR-PEER-ADDRESS.

=C2=A0

[TR2] Okay, will remove d= uplicate text.

=C2=A0

S 15.12:

The error code field is too small to hold error code= s (8 bits). I think this should use the same structure as ERROR-CODE from 5= 389, but use some of the reserved bits for family.

=C2=A0

[TR] Yes, will fix that i= n the next revision.

=C2=A0

Suggestion:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 |=C2=A0 Address Family=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 Rsvd=C2=A0 |Class|=C2=
=A0=C2=A0=C2=A0=C2=A0 Number=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 |=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0Reason Phrase (variable)=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 ..
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

=C2=A0
[TR2] Shouldn=E2=80=99t it be Rsvd f=
ollowed by Address family ?

Then it won't be byte-aligned, = which seems bad.

--089e013a1118b7786f0512382b24-- From nobody Thu Mar 26 15:39:22 2015 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 A430D1A1A02 for ; Thu, 26 Mar 2015 15:39:21 -0700 (PDT) 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 r7BzV35CeC7Y for ; Thu, 26 Mar 2015 15:39:20 -0700 (PDT) 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 247721A09CF for ; Thu, 26 Mar 2015 15:39:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2126; q=dns/txt; s=iport; t=1427409560; x=1428619160; h=from:to:subject:date:message-id:mime-version; bh=E73ohR9gPUIsQ8HMJLGqkmQsUolZNpN4HjtweqhfZRI=; b=EYNvSl2pjR8vtJNGePSZUBG2+9+MN5D9Ayz9i628YldGth53yBvN4cmS dzIvg8ZlrJALbrd8xqZBBhL26UwiPAjVzmPZ5BbG48NgYrtMdkHUJ7ZRo Jsf6Wv4E0/tPPIOo779VNBU2p4lmAcplh0HMqINSKi9V4XGPukbfDMog+ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B3BgBQihRV/40NJK1cgwZSXsJygjuFdYFHTAEBAQEBAX2EG4ELAQwBcycEiEINogqqCAEBAQEGAQEBAQEBAQEWBJAcgyKBFgWQUINvhgCULSKDboIzfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,475,1422921600"; d="scan'208,217";a="403894825" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP; 26 Mar 2015 22:39:19 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t2QMdJu7005228 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 26 Mar 2015 22:39:19 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Thu, 26 Mar 2015 17:39:19 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: tram mailing list Thread-Topic: STUNTrace and PMTUD drafts Thread-Index: AQHQaBWxrJ4SNCovSEOG4EjILFTZnQ== Date: Thu, 26 Mar 2015 22:39:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.217.195] Content-Type: multipart/alternative; boundary="_000_C5F9498AC6AC4EA7B7E6CEE35A04EC42ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [tram] STUNTrace and PMTUD drafts 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, 26 Mar 2015 22:39:21 -0000 --_000_C5F9498AC6AC4EA7B7E6CEE35A04EC42ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable TRAMsters - Based on the discussion (during and after) the final presentation on STUNTr= ace it is clear alignment and overlap between STUNTrace and the PMTUD draft= (draft-petithuguenin-tram-stun-pmtud). The PMTUD draft is solving a broader prob= lem, whereas STUNTrace is practically a specialized use-case of it. I thin= k the best way to proceed with these is to progress these independently, re= move the overlap and cross reference each appropriately. Do folks agree wi= th this approach? Cheers, Gonzalo --_000_C5F9498AC6AC4EA7B7E6CEE35A04EC42ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <5224396CC0D334439B9F9F7126ACDE9B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable TRAMsters - 

Based on the discussion (during and after) the final presen= tation on STUNTrace it is clear alignment and overlap between STUNTrace and= the PMTUD draft (draft-petithuguenin-tram-stun-pmtud).  The PMTUD draft is solving a broader problem, whereas STUNTrace is p= ractically a specialized use-case of it.  I think the best way to proc= eed with these is to progress these independently, remove the overlap and c= ross reference each appropriately.  Do folks agree with this approach?

Cheers,

Gonzalo

--_000_C5F9498AC6AC4EA7B7E6CEE35A04EC42ciscocom_-- From nobody Thu Mar 26 15:41:26 2015 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 52C161A1A11 for ; Thu, 26 Mar 2015 15:41:25 -0700 (PDT) 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 jNFmftMU2X4y for ; Thu, 26 Mar 2015 15:41:23 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id C28871A1A03 for ; Thu, 26 Mar 2015 15:41:23 -0700 (PDT) Received: from [IPv6:2001:67c:370:160:c617:feff:feb6:86ed] (unknown [IPv6:2001:67c:370:160:c617:feff:feb6:86ed]) (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 82C35203C1; Thu, 26 Mar 2015 23:41:22 +0100 (CET) Message-ID: <55148B10.8020806@acm.org> Date: Thu, 26 Mar 2015 17:41:20 -0500 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 To: "Gonzalo Salgueiro (gsalguei)" , tram mailing list References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tram] STUNTrace and PMTUD drafts 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, 26 Mar 2015 22:41:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/26/2015 05:39 PM, Gonzalo Salgueiro (gsalguei) wrote: > TRAMsters - > > Based on the discussion (during and after) the final presentation on > STUNTrace it is clear alignment and overlap between STUNTrace and the > PMTUD draft > (draft-petithuguenin-tram-stun-pmtud). > The PMTUD draft is solving a broader problem, whereas STUNTrace is > practically a specialized use-case of it. I think the best way to > proceed with these is to progress these independently, remove the > overlap and cross reference each appropriately. Do folks agree with > this approach? > I agree with that plan. - -- 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 iQIcBAEBCAAGBQJVFIsQAAoJECnERZXWan7EXvkQAItBGEAtuBPVIgsihWz2zqoa MCZTVRvoqrzozL52748HdPPVNYxnm4fn9eerCqlZC45Ht9u9+TM8Exe8wj7TzKvW 2Cd5TAMO7krD1+lO1wgJG2VZ6AHHo3GbhrYBrPiIQphpZ7D2CMLu+cHjlsMweq06 PfFypMYUQj8aU3IdVQTPVsj3VERLOrz2PokMtP3iedBO7TUgegxk/pQvROX6cqDf QgC0y4P7i2wE1eqgIw/wytNQiBlnVySwOiXkAoRQf2Knw+Wj0myreXNpxQU6DFQY XTVREA5HOH6ljcatA/7zW0KSjm9eQmORL/hUwqxZuw0YY5Ktfvyl38LQ6dvOtHdJ DmgwU5iOJ6Up+5zEQ5e1MHN52UTyWAT4Z01Sf+sEaZF6de20JnSQH80XxP6eVxm9 MPDM1B1631bmW0bmBt8IGhfnLwqC5QEl/A+OfGGVEaZ67T/ntR+DEZsphMc9NYDu +nSnQQkzO0NL7MCKemaFW5Li0Xn01a9/97u+Qc47Ttc0K2sSlt9F9+5r1y/dYaA3 NVjDxKoJA7Tx6XYjVXiNMrAr7wdwqfRhOyesyAXMLwYOR3rfH8K9Js5OZqm5fPLy 181r38bsQCXv5Rt6XWklcBHMbC234ie4c8Uli7pAzYuLurWZhwRRtL1Jo9MEcLAa ybwHEkyS1WI58QGbUIs/ =5jV6 -----END PGP SIGNATURE----- From nobody Thu Mar 26 15:48:09 2015 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 69AC71A1A59 for ; Thu, 26 Mar 2015 15:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 QbPea3kOzANk for ; Thu, 26 Mar 2015 15:48:05 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06BBA1A1A3B for ; Thu, 26 Mar 2015 15:48:05 -0700 (PDT) Received: by igcau2 with SMTP id au2so21960686igc.1 for ; Thu, 26 Mar 2015 15:48:04 -0700 (PDT) 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=j2d8GzaTusfF2TbrlX6vVIvkb2qfUtHYiVXq6hR1abw=; b=LCglpIJpIRZexaZgaaeTEtpFBZz0oChDaCfWT9bOZc5O6t+e7pyqddHVZLmzpBnSBt +Yha8sHnlENVMSzEVzPqIaoYRfwke/j60k2qfsQM9mpEFhxtTqAE/fTNwxrA+pw8ggdS ic157JqeymCAlTD88kVhi4ilnXGVWkinf4tgIw3lQjbDzMlFgFfMSf4RVAQlxfJqlyJg TK2CS5G9Rdudfq34y6KlqIq1SRi+votT+X/lh7zc838zFiZxaHNwgn9mPUGQ215lxlHh 4JY9hjn735oAHJR3Cqlx3Eq6C3gSKTYcj0cIj1l7c9A5dKmrSQx/aHXwjCXbc0HclbZT +t8w== 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=j2d8GzaTusfF2TbrlX6vVIvkb2qfUtHYiVXq6hR1abw=; b=FB6CCFf8jPBmDsEFMomJgmAkLCHHMDX7PiH7+qdDikS5YzJx1yJLmshyA+qlMTfLsD BEQ9Us1gOYod18FaQkp7av8JTtyWf2DqIkwTD/8crFvI4VFUXA4S/AgWPJ7h6RjCAhr1 A3IBZQMHu0DfCePHxYV1bDshUrwDkbwRrFHNg6XQT0L+mjXaWVnKJ5GDoBxS6hX2DnFI nA1qm35J6q4UeOiWvlCiDqPoEjD9+mjZdmMF6LvogDjEP2egfJcsn/pyGBtpzqSrhMcO /m6ZG21cSudxawdMyhk8R7HQb91qS4DIBe8NV72ZY91LaMRC1pIfI2KHg4r7VwQwAdJZ bstQ== X-Gm-Message-State: ALoCoQkx1ys8xLaFWCNfJw7YvVVl1aRmomYfsjhVuyWidD1B6lf3yRCNa66+5ymLYsd6VJDcwjr1 X-Received: by 10.50.20.228 with SMTP id q4mr40010449ige.1.1427410084352; Thu, 26 Mar 2015 15:48:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.64.42 with HTTP; Thu, 26 Mar 2015 15:47:44 -0700 (PDT) In-Reply-To: <55148B10.8020806@acm.org> References: <55148B10.8020806@acm.org> From: Justin Uberti Date: Thu, 26 Mar 2015 17:47:44 -0500 Message-ID: To: Marc Petit-Huguenin Content-Type: multipart/alternative; boundary=047d7bd757c40704ee051238cf99 Archived-At: Cc: "Gonzalo Salgueiro \(gsalguei\)" , tram mailing list Subject: Re: [tram] STUNTrace and PMTUD drafts 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, 26 Mar 2015 22:48:06 -0000 --047d7bd757c40704ee051238cf99 Content-Type: text/plain; charset=UTF-8 +1 On Thu, Mar 26, 2015 at 5:41 PM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 03/26/2015 05:39 PM, Gonzalo Salgueiro (gsalguei) wrote: > > TRAMsters - > > > > Based on the discussion (during and after) the final presentation on > > STUNTrace it is clear alignment and overlap between STUNTrace and the > > PMTUD draft > > (draft-petithuguenin-tram-stun-pmtud< > https://tools.ietf.org/html/draft-petithuguenin-tram-stun-pmtud-00>). > > The PMTUD draft is solving a broader problem, whereas STUNTrace is > > practically a specialized use-case of it. I think the best way to > > proceed with these is to progress these independently, remove the > > overlap and cross reference each appropriately. Do folks agree with > > this approach? > > > > I agree with that plan. > > - -- > 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 > > iQIcBAEBCAAGBQJVFIsQAAoJECnERZXWan7EXvkQAItBGEAtuBPVIgsihWz2zqoa > MCZTVRvoqrzozL52748HdPPVNYxnm4fn9eerCqlZC45Ht9u9+TM8Exe8wj7TzKvW > 2Cd5TAMO7krD1+lO1wgJG2VZ6AHHo3GbhrYBrPiIQphpZ7D2CMLu+cHjlsMweq06 > PfFypMYUQj8aU3IdVQTPVsj3VERLOrz2PokMtP3iedBO7TUgegxk/pQvROX6cqDf > QgC0y4P7i2wE1eqgIw/wytNQiBlnVySwOiXkAoRQf2Knw+Wj0myreXNpxQU6DFQY > XTVREA5HOH6ljcatA/7zW0KSjm9eQmORL/hUwqxZuw0YY5Ktfvyl38LQ6dvOtHdJ > DmgwU5iOJ6Up+5zEQ5e1MHN52UTyWAT4Z01Sf+sEaZF6de20JnSQH80XxP6eVxm9 > MPDM1B1631bmW0bmBt8IGhfnLwqC5QEl/A+OfGGVEaZ67T/ntR+DEZsphMc9NYDu > +nSnQQkzO0NL7MCKemaFW5Li0Xn01a9/97u+Qc47Ttc0K2sSlt9F9+5r1y/dYaA3 > NVjDxKoJA7Tx6XYjVXiNMrAr7wdwqfRhOyesyAXMLwYOR3rfH8K9Js5OZqm5fPLy > 181r38bsQCXv5Rt6XWklcBHMbC234ie4c8Uli7pAzYuLurWZhwRRtL1Jo9MEcLAa > ybwHEkyS1WI58QGbUIs/ > =5jV6 > -----END PGP SIGNATURE----- > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --047d7bd757c40704ee051238cf99 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

On Thu, Mar 26, 2015 at 5:41 PM, Marc Petit-Huguenin <petithug@acm.= org> wrote:
-----BEGIN PGP = SIGNED MESSAGE-----
Hash: SHA256

On 03/26/2015 05:39 PM, Gonzalo Salgueiro (gsalguei) wrote:
> TRAMsters -
>
> Based on the discussion (during and after) the final presentation on > STUNTrace it is clear alignment and overlap between STUNTrace and the<= br> > PMTUD draft
> (draft-petithuguenin-tram-stun-pmtud<h= ttps://tools.ietf.org/html/draft-petithuguenin-tram-stun-pmtud-00>).=
> The PMTUD draft is solving a broader problem, whereas= STUNTrace is
> practically a specialized use-case of it.=C2=A0 I think the best way t= o
> proceed with these is to progress these independently, remove the
> overlap and cross reference each appropriately.=C2=A0 Do folks agree w= ith
> this approach?
>

I agree with that plan.

- --
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: htt= p://blog.marc.petit-huguenin.org
Profile: = http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJVFIsQAAoJECnERZXWan7EXvkQAItBGEAtuBPVIgsihWz2zqoa
MCZTVRvoqrzozL52748HdPPVNYxnm4fn9eerCqlZC45Ht9u9+TM8Exe8wj7TzKvW
2Cd5TAMO7krD1+lO1wgJG2VZ6AHHo3GbhrYBrPiIQphpZ7D2CMLu+cHjlsMweq06
PfFypMYUQj8aU3IdVQTPVsj3VERLOrz2PokMtP3iedBO7TUgegxk/pQvROX6cqDf
QgC0y4P7i2wE1eqgIw/wytNQiBlnVySwOiXkAoRQf2Knw+Wj0myreXNpxQU6DFQY
XTVREA5HOH6ljcatA/7zW0KSjm9eQmORL/hUwqxZuw0YY5Ktfvyl38LQ6dvOtHdJ
DmgwU5iOJ6Up+5zEQ5e1MHN52UTyWAT4Z01Sf+sEaZF6de20JnSQH80XxP6eVxm9
MPDM1B1631bmW0bmBt8IGhfnLwqC5QEl/A+OfGGVEaZ67T/ntR+DEZsphMc9NYDu
+nSnQQkzO0NL7MCKemaFW5Li0Xn01a9/97u+Qc47Ttc0K2sSlt9F9+5r1y/dYaA3
NVjDxKoJA7Tx6XYjVXiNMrAr7wdwqfRhOyesyAXMLwYOR3rfH8K9Js5OZqm5fPLy
181r38bsQCXv5Rt6XWklcBHMbC234ie4c8Uli7pAzYuLurWZhwRRtL1Jo9MEcLAa
ybwHEkyS1WI58QGbUIs/
=3D5jV6
-----END PGP SIGNATURE-----

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

--047d7bd757c40704ee051238cf99-- From nobody Thu Mar 26 17:40:31 2015 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 457441A886A for ; Thu, 26 Mar 2015 17:40:29 -0700 (PDT) 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 hcrYFJb3I6Re for ; Thu, 26 Mar 2015 17:40:27 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 349DF1A1B34 for ; Thu, 26 Mar 2015 17:40:27 -0700 (PDT) Received: by wgdm6 with SMTP id m6so82931476wgd.2 for ; Thu, 26 Mar 2015 17:40:26 -0700 (PDT) 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=GjyubqnnlVMnAu3gZpVxYDldR1bh2oWPPG497fySaX4=; b=c5u1CBk1wEodsrs50QtpKoregxfIL2ylN6I+XSk+LFbWzlAi3Z1LzmijT1xIvyDjXh oF0V/9Op4Rv3j7cckE1Wc861dXMpJLhRCPUAUhdjgfBQ4SnqPBrkyRkWxQwt9mxtxvKR v0IeHbubbmZ3C7MEd/YqBInQu4r2NX0ew/EbSZfbu2klBrW/thWvLJnmIX7r2STM0smP BR49pSjB1cXswtnZWJzlo0zv5JddzUSo7j9UXCrsNsiKsqroXCM6bjcVC0YJaItmFVMO ofsR1lE7ZIoUcmaZDzscwAzch9faVBgvfT8zNqUeOPXcg9kvLkiBXNmzQuMlhKRvyYJ2 /lmg== MIME-Version: 1.0 X-Received: by 10.180.76.148 with SMTP id k20mr52556764wiw.71.1427416825969; Thu, 26 Mar 2015 17:40:25 -0700 (PDT) Received: by 10.27.175.92 with HTTP; Thu, 26 Mar 2015 17:40:25 -0700 (PDT) In-Reply-To: References: <55148B10.8020806@acm.org> Date: Thu, 26 Mar 2015 19:40:25 -0500 Message-ID: From: Suhas Nandakumar To: Justin Uberti Content-Type: multipart/alternative; boundary=f46d04389023dbc10e05123a6080 Archived-At: Cc: Marc Petit-Huguenin , "Gonzalo Salgueiro \(gsalguei\)" , tram mailing list Subject: Re: [tram] STUNTrace and PMTUD drafts 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, 27 Mar 2015 00:40:29 -0000 --f46d04389023dbc10e05123a6080 Content-Type: text/plain; charset=UTF-8 +1 On Thu, Mar 26, 2015 at 5:47 PM, Justin Uberti wrote: > +1 > > On Thu, Mar 26, 2015 at 5:41 PM, Marc Petit-Huguenin > wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> On 03/26/2015 05:39 PM, Gonzalo Salgueiro (gsalguei) wrote: >> > TRAMsters - >> > >> > Based on the discussion (during and after) the final presentation on >> > STUNTrace it is clear alignment and overlap between STUNTrace and the >> > PMTUD draft >> > (draft-petithuguenin-tram-stun-pmtud< >> https://tools.ietf.org/html/draft-petithuguenin-tram-stun-pmtud-00>). >> > The PMTUD draft is solving a broader problem, whereas STUNTrace is >> > practically a specialized use-case of it. I think the best way to >> > proceed with these is to progress these independently, remove the >> > overlap and cross reference each appropriately. Do folks agree with >> > this approach? >> > >> >> I agree with that plan. >> >> - -- >> 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 >> >> iQIcBAEBCAAGBQJVFIsQAAoJECnERZXWan7EXvkQAItBGEAtuBPVIgsihWz2zqoa >> MCZTVRvoqrzozL52748HdPPVNYxnm4fn9eerCqlZC45Ht9u9+TM8Exe8wj7TzKvW >> 2Cd5TAMO7krD1+lO1wgJG2VZ6AHHo3GbhrYBrPiIQphpZ7D2CMLu+cHjlsMweq06 >> PfFypMYUQj8aU3IdVQTPVsj3VERLOrz2PokMtP3iedBO7TUgegxk/pQvROX6cqDf >> QgC0y4P7i2wE1eqgIw/wytNQiBlnVySwOiXkAoRQf2Knw+Wj0myreXNpxQU6DFQY >> XTVREA5HOH6ljcatA/7zW0KSjm9eQmORL/hUwqxZuw0YY5Ktfvyl38LQ6dvOtHdJ >> DmgwU5iOJ6Up+5zEQ5e1MHN52UTyWAT4Z01Sf+sEaZF6de20JnSQH80XxP6eVxm9 >> MPDM1B1631bmW0bmBt8IGhfnLwqC5QEl/A+OfGGVEaZ67T/ntR+DEZsphMc9NYDu >> +nSnQQkzO0NL7MCKemaFW5Li0Xn01a9/97u+Qc47Ttc0K2sSlt9F9+5r1y/dYaA3 >> NVjDxKoJA7Tx6XYjVXiNMrAr7wdwqfRhOyesyAXMLwYOR3rfH8K9Js5OZqm5fPLy >> 181r38bsQCXv5Rt6XWklcBHMbC234ie4c8Uli7pAzYuLurWZhwRRtL1Jo9MEcLAa >> ybwHEkyS1WI58QGbUIs/ >> =5jV6 >> -----END PGP SIGNATURE----- >> >> _______________________________________________ >> 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 > > --f46d04389023dbc10e05123a6080 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

On Thu, Mar 26, 2015 at 5:47 PM, Justin Uberti &l= t;juberti@google.co= m> wrote:
= +1
=
On Thu, Mar 26, 2015 at 5:41 PM, Marc Petit-= Huguenin <petithug@acm.org> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 03/26/2015 05:39 PM, Gonzalo Salgueiro (gsalguei) wrote:
> TRAMsters -
>
> Based on the discussion (during and after) the final presentation on > STUNTrace it is clear alignment and overlap between STUNTrace and the<= br> > PMTUD draft
> (draft-petithuguenin-tram-stun-pmtud<h= ttps://tools.ietf.org/html/draft-petithuguenin-tram-stun-pmtud-00>).=
> The PMTUD draft is solving a broader problem, whereas STUNTrace = is
> practically a specialized use-case of it.=C2=A0 I think the best way t= o
> proceed with these is to progress these independently, remove the
> overlap and cross reference each appropriately.=C2=A0 Do folks agree w= ith
> this approach?
>

I agree with that plan.

- --
Marc Petit-Huguenin
Email: marc@pe= tit-huguenin.org
Blog: htt= p://blog.marc.petit-huguenin.org
Profile: = http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJVFIsQAAoJECnERZXWan7EXvkQAItBGEAtuBPVIgsihWz2zqoa
MCZTVRvoqrzozL52748HdPPVNYxnm4fn9eerCqlZC45Ht9u9+TM8Exe8wj7TzKvW
2Cd5TAMO7krD1+lO1wgJG2VZ6AHHo3GbhrYBrPiIQphpZ7D2CMLu+cHjlsMweq06
PfFypMYUQj8aU3IdVQTPVsj3VERLOrz2PokMtP3iedBO7TUgegxk/pQvROX6cqDf
QgC0y4P7i2wE1eqgIw/wytNQiBlnVySwOiXkAoRQf2Knw+Wj0myreXNpxQU6DFQY
XTVREA5HOH6ljcatA/7zW0KSjm9eQmORL/hUwqxZuw0YY5Ktfvyl38LQ6dvOtHdJ
DmgwU5iOJ6Up+5zEQ5e1MHN52UTyWAT4Z01Sf+sEaZF6de20JnSQH80XxP6eVxm9
MPDM1B1631bmW0bmBt8IGhfnLwqC5QEl/A+OfGGVEaZ67T/ntR+DEZsphMc9NYDu
+nSnQQkzO0NL7MCKemaFW5Li0Xn01a9/97u+Qc47Ttc0K2sSlt9F9+5r1y/dYaA3
NVjDxKoJA7Tx6XYjVXiNMrAr7wdwqfRhOyesyAXMLwYOR3rfH8K9Js5OZqm5fPLy
181r38bsQCXv5Rt6XWklcBHMbC234ie4c8Uli7pAzYuLurWZhwRRtL1Jo9MEcLAa
ybwHEkyS1WI58QGbUIs/
=3D5jV6
-----END PGP SIGNATURE-----

_______________________________________________
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


--f46d04389023dbc10e05123a6080-- From nobody Thu Mar 26 19:17:05 2015 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 2855F1A8880 for ; Thu, 26 Mar 2015 19:17:04 -0700 (PDT) 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 ioeMbZ6CxTkB for ; Thu, 26 Mar 2015 19:16:59 -0700 (PDT) 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 092651A8A7B for ; Thu, 26 Mar 2015 19:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=44168; q=dns/txt; s=iport; t=1427422616; x=1428632216; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QhEBhDnMM/ZY+LJfO1J4fSbXlMFnwkHHFbPFamCVF80=; b=HeeXIR5eVyAbiGbqzb+ygZf57Ug2+oAgOBAZBYBtlrOHLQirMPrCc/Kw jMQYk+diK7g0UH3lP7oYoBRY4dUgsFRSUWoML/rCHO3ccf/cGrUXMG+Ub C9JfH5PAQoZN5csPKmSJwRlgp40mt31Cg48bYdjXUie0rvdTYcMXGVN9u A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DFBgDevBRV/4YNJK1cgkNDUloEgw+/ZmYGh0QCHIEmOBQBAQEBAQEBfIQUAQEBBCMKGjIQAgEIDgMEAQELFgEGAwICAjAUCQgBAQQOBQgRiBaxX4UWlSABAQEBAQEBAQEBAQEBAQEBAQEBAQEXiyiERxYbBgGCaC+BFgWOQoIOiwqDMIwbg0ciggIcgVBvgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,476,1422921600"; d="scan'208,217";a="135802953" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-3.cisco.com with ESMTP; 27 Mar 2015 02:16:55 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t2R2GttQ013468 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Mar 2015 02:16:55 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.80]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Thu, 26 Mar 2015 21:16:54 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Justin Uberti Thread-Topic: [tram] Comments on draft-ietf-tram-turnbis-01 Thread-Index: AdBntPY5ANaPCcypQFyW0ZUNvQto2QAWjv+AAAiXOWAAAjWwAAAB0UEQ Date: Fri, 27 Mar 2015 02:16:54 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A366D17F0@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A366D0EDE@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A366D1482@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.68.94] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A366D17F0xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-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: Fri, 27 Mar 2015 02:17:04 -0000 --_000_913383AAA69FF945B8F946018B75898A366D17F0xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IEp1c3RpbiBVYmVydGkgW21haWx0bzpqdWJlcnRpQGdvb2dsZS5jb21dDQpTZW50 OiBGcmlkYXksIE1hcmNoIDI3LCAyMDE1IDM6MzIgQU0NClRvOiBUaXJ1bWFsZXN3YXIgUmVkZHkg KHRpcmVkZHkpDQpDYzogdHJhbUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt0cmFtXSBDb21tZW50 cyBvbiBkcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0wMQ0KDQoNCg0KT24gVGh1LCBNYXIgMjYsIDIw MTUgYXQgMTozOSBQTSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSA8dGlyZWRkeUBjaXNj by5jb208bWFpbHRvOnRpcmVkZHlAY2lzY28uY29tPj4gd3JvdGU6DQpJbmxpbmUgW1RSMl0NCg0K RnJvbTogSnVzdGluIFViZXJ0aSBbbWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbTxtYWlsdG86anVi ZXJ0aUBnb29nbGUuY29tPl0NClNlbnQ6IFRodXJzZGF5LCBNYXJjaCAyNiwgMjAxNSAxMDoyMyBQ TQ0KVG86IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkNCkNjOiB0cmFtQGlldGYub3JnPG1h aWx0bzp0cmFtQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFt0cmFtXSBDb21tZW50cyBvbiBkcmFm dC1pZXRmLXRyYW0tdHVybmJpcy0wMQ0KDQoNCg0KT24gVGh1LCBNYXIgMjYsIDIwMTUgYXQgNjow NiBBTSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSA8dGlyZWRkeUBjaXNjby5jb208bWFp bHRvOnRpcmVkZHlAY2lzY28uY29tPj4gd3JvdGU6DQpIaSBKdXN0aW4sDQoNClRoYW5rcyBmb3Ig dGhlIGNvbW1lbnRzLiBQbGVhc2Ugc2VlIGlubGluZSBbVFJdDQoNCkZyb206IHRyYW0gW21haWx0 bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZz5dIE9u IEJlaGFsZiBPZiBKdXN0aW4gVWJlcnRpDQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMjYsIDIwMTUg MTE6MzIgQU0NClRvOiB0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPg0KU3ViamVj dDogW3RyYW1dIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTAxDQoNCmJldHRl ciBsYXRlIHRoYW4gbmV2ZXI6DQoNClMgNi4xOg0KSSBkb24ndCB0aGluayB0aGF0IHdlIG5lZWQg dG8gZm9yYmlkIHVzaW5nIFJBRiB3aXRoIEFBRi4gSXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIGRv IFJBRih2NCkgd2l0aCBBQUYodjYpLCBSQUYodjYpIHdpdGggQUFGKHY0KSwgb3IgQUFGKHY2KSBi eSBpdHNlbGYsIGFsbCB3aXRoIHRoZSBzYW1lIG1lYW5pbmcuDQoNCltUUl0gUkFGIGlzICBjb21w cmVoZW5zaW9uLXJlcXVpcmVkIGF0dHJpYnV0ZSB3aGVyZWFzIEFBRiBpcyBjb21wcmVoZW5zaW9u LW9wdGlvbmFsIGF0dHJpYnV0ZSwgSWYgY2xpZW50IHVzZXMgYm90aCBSQUYgKyBBQUYgYW5kIHRo ZSBzZXJ2ZXIgZG9lcyBub3QgdW5kZXJzdGFuZCBSQUYgdGhlbiB0aGUgcmVxdWVzdCBjb3VsZCBm YWlsLiBJIGRvbuKAmXQgc2VlIGFueSBhZHZhbnRhZ2Ugb2YgdXNpbmcgYm90aCBSQUYgYW5kIEFB RiB0b2dldGhlci4NCg0KSSBhZ3JlZSB0aGF0IHR5cGljYWxseSBBQUYgd2lsbCBiZSBzZW50IGJ5 IGl0c2VsZiwgYnV0IGluIHRoZSBpbnRlcmVzdCBvZiBkZWZpbmluZyBhIGdlbmVyYWwgbWVjaGFu aXNtIEkgZG9uJ3QgdGhpbmsgd2Ugc2hvdWxkIHByb2hpYml0IFJBRiArIEFBRi4NCg0KW1RSMl0g UkFGICsgQUFGIGNvbXBsaWNhdGVzIHNlcnZlciBhbmQgY2xpZW50IGltcGxlbWVudGF0aW9ucyB3 aXRob3V0IGFueSBiZW5lZml0cy4NCg0KSSB0aGluayBpdCBtYWtlcyBpdCBlYXNpZXIgdG8gcmVh c29uIGFib3V0IHdoYXQgdGhlc2UgYXR0cmlidXRlcyBhY3R1YWxseSBkby4gU2VydmVyIG5lZWRz IHRvIGhhbmRsZSBSQUYgYW55d2F5Lg0KDQpUaGF0IHNhaWQsIEkgZG9uJ3QgZmVlbCBzdXBlciBz dHJvbmdseSBhYm91dCB0aGlzLg0KDQoNCg0KUyA3LjE6DQpJIHRoaW5rIHRoZSBjbGllbnQgc2hv dWxkIGluY2x1ZGUgUkFGIGZvciB0aGUgYmluZGluZ3MgdGhhdCBpdCB3YW50cyB0byBrZWVwLCBu b3QgQUFGLiBBQUYgaXMgb25seSB1c2VmdWwgaW4gdGhlIEFMTE9DQVRFLCB3aGVyZSB0aGUgY2xp ZW50IGRvZXNuJ3Qga25vdyBpZiB0aGUgc2VydmVyIHN1cHBvcnRzIEFBRi4NCg0KW1RSXSBJZiBB QUYgaXMgdXNlZCBmb3IgQWxsb2NhdGlvbiB0aGVuIHRoZXJlIGlzIG5vIHJlYXNvbiB3aHkgUkFG IHNob3VsZCBiZSB1c2VkIGZvciB0aGUgYmluZGluZyAoc2VydmVyIG1heSBub3Qgc3VwcG9ydCBS QUYgYW5kIGl0IHdpbGwgcmVzdWx0IGluIGZhaWx1cmUgdG8gcmVmcmVzaCkuDQoNClRoZXJlIGlz IG5vIHNlcnZlciB0aGF0IHdpbGwgc3VwcG9ydCBBQUYgYnV0IG5vdCBSQUYuDQoNCkZvciBhIGR1 YWwgYWxsb2NhdGlvbiwgdGhlIGNsaWVudCBzaG91bGQgYmUgYWJsZSB0byByZWZyZXNoIHRoZSB2 NCwgdjYsIG9yIGJvdGguIFJpZ2h0IG5vdyBpbiB0aGUgZG9jLCB3ZSBkb24ndCBoYXZlIHRoYXQg Y29udHJvbC4NCg0KW1RSMl0gVGhlIGNvbnRyb2wgaXMgcG9zc2libGUgYW5kIGlzIGRpc2N1c3Nl ZCBpbiBzZWN0aW9uIDcuMQ0KDQo8c25pcD4NCg0KICAgV2hlbiByZWZyZXNoaW5nIGEgZHVhbCBh bGxvY2F0aW9uLCB0aGUgY2xpZW50IGluY2x1ZGVzIEFERElUSU9OQUwtDQogICBBRERSRVNTLUZB TUlMWSBhdHRyaWJ1dGUgaW5kaWNhdGluZyB0aGUgYWRkcmVzcyBmYW1pbHkgdHlwZSB0aGF0DQog ICBzaG91bGQgYmUgcmVmcmVzaGVkLiAgSWYgbm8gQURESVRJT05BTC1BRERSRVNTLUZBTUlMWSBp cyBpbmNsdWRlZA0KICAgdGhlbiB0aGUgcmVxdWVzdCBzaG91bGQgYmUgdHJlYXRlZCBhcyBhcHBs eWluZyB0byBhbGwgY3VycmVudA0KICAgYWxsb2NhdGlvbnMuDQo8L3NuaXA+DQoNCkl0IGRvZXNu J3Qgc2F5IGhvdyB0byBvbmx5IHJlZnJlc2ggdjQsIG9yIG9ubHkgcmVmcmVzaCB2NiwgaW4gYSBk dWFsIGFsbG9jYXRpb24uDQoNCltUUjNdIEl04oCZcyBleHBsYWluZWQgaW4gdGhlIGZpcnN0IGxp bmU7IGNsaWVudCByZWZyZXNoZXMgdjQgYnkgaW5jbHVkaW5nIEFBRiAodjQpLCBjbGllbnQgcmVm cmVzaGVzIHY2IGJ5IGluY2x1ZGluZyBBQUYgKHY2KS4NCg0KLVRpcnUNCg0KSSBzdWdnZXN0IHRo ZSBmb2xsb3dpbmc6DQp2NCBjYW4gYmUgcmVmcmVzaGVkIGJ5IHNlbmRpbmcgUkFGKHY0KS4NCnY2 IGNhbiBiZSByZWZyZXNoZWQgYnkgc2VuZGluZyBSQUYodjYpLg0KYm90aCBjYW4gYmUgcmVmcmVz aGVkIGJ5IHNlbmRpbmcgUkFGKHY0K3Y2KSwgYW5kL29yLCBwZXJoYXBzLCBubyBSQUYuDQoNCkZv ciBhIHNpbmdsZSBhbGxvY2F0aW9uLCBJIHN1Z2dlc3Qgd2Uga2VlcCB0aGUgZXhpc3RpbmcgZm9y bWF0IHdoZXJlIHNlbmRpbmcgbm8gUkFGIHJlZnJlc2hlcyB0aGUgYWxsb2NhdGlvbi4NCg0KDQpT IDkuMToNCkkgZG9uJ3QgdGhpbmsgd2Ugd2FudCB0byBzdXBwb3J0IENyZWF0ZVBlcm1pc3Npb25z IHdpdGggbXVsdGlwbGUgYWRkcmVzc2VzLiBJdCBkb2Vzbid0IHNhdmUgYW55dGhpbmcgb3RoZXIg dGhhbiAyIHBhY2tldHMgYW5kIGp1c3QgbWFrZXMgbGlmZSBtb3JlIGNvbXBsaWNhdGVkLg0KDQpb VFJdIFBsZWFzZSBjbGFyaWZ5IHdoeSBpdCBjb21wbGljYXRlcyBpbXBsZW1lbnRhdGlvbiA/DQoN CllvdSBub3cgbmVlZCB0byBoYW5kbGUgcGFydGlhbCBzdWNjZXNzZXMsIHNvIHlvdXIgZXJyb3Ig aGFuZGxpbmcgcGF0aCBpcyBtb3JlIGNvbXBsaWNhdGVkLg0KDQpbVFIyXSBHb29kIHBvaW50LCB3 aWxsIHJlbW92ZSBzdXBwb3J0IGZvciBtdWx0aXBsZSBhZGRyZXNzZXMuDQoNCkJ1dCBtYWlubHks IGl0J3Mgbm90IGNsZWFyIGF0IGFsbCB3aHkgYSBjbGllbnQgd291bGQgdXNlIHRoaXMuDQoNCg0K UyAxMS4xOg0KSG93IHdvdWxkIHlvdSBkbyBhIENoYW5uZWxCaW5kIHdpdGggbXVsdGlwbGUgYWRk cmVzc2VzPyBTZW50IHBhY2tldHMgZ28gdG8gYm90aCBkZXN0aW5hdGlvbnM/IEFnYWluLCB0aGlz IHNlZW1zIGNvbXBsZXggd2l0aCBubyBnb29kIHJlYXNvbi4NCg0KW1RSXSBBZ3JlZWQsIHdpbGwg Zml4IGluIHRoZSBuZXh0IHJldmVyc2lvbi4NCg0KUyAxNS42LzE1LjExOg0KSXQgd291bGQgYmUg Z29vZCB0byBzZXBhcmF0ZSB0aGUgUkFGL0FBRiBwYXlsb2FkIGRlZmluaXRpb24gb3V0IHNvIHRo YXQgaXQgZG9lc24ndCBuZWVkIHRvIGJlIHJlcGVhdGVkIGluIGJvdGggc2VjdGlvbnMuDQoNCltU Ul0gVGhlIHBheWxvYWQgdGV4dCBpcyBub3QgbGFyZ2UgZW5vdWdoIGZvciBhIHNlcGFyYXRlIHNl Y3Rpb24uDQoNCkF0IDMwIGxpbmVzIG9mIHRleHQsIEkgZGlzYWdyZWUuIFdlIGFyZSBhbHJlYWR5 IGRvaW5nIHRoaXMgc29ydCBvZiB0aGluZyBmb3IgWE9SLVBFRVItQUREUkVTUy4NCg0KW1RSMl0g T2theSwgd2lsbCByZW1vdmUgZHVwbGljYXRlIHRleHQuDQoNClMgMTUuMTI6DQpUaGUgZXJyb3Ig Y29kZSBmaWVsZCBpcyB0b28gc21hbGwgdG8gaG9sZCBlcnJvciBjb2RlcyAoOCBiaXRzKS4gSSB0 aGluayB0aGlzIHNob3VsZCB1c2UgdGhlIHNhbWUgc3RydWN0dXJlIGFzIEVSUk9SLUNPREUgZnJv bSA1Mzg5LCBidXQgdXNlIHNvbWUgb2YgdGhlIHJlc2VydmVkIGJpdHMgZm9yIGZhbWlseS4NCg0K W1RSXSBZZXMsIHdpbGwgZml4IHRoYXQgaW4gdGhlIG5leHQgcmV2aXNpb24uDQoNClN1Z2dlc3Rp b246DQoNCg0KICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KICAgICAgfCAgQWRkcmVzcyBGYW1pbHkgICAgICAg ICAgICAgICAgfCAgUnN2ZCAgfENsYXNzfCAgICAgTnVtYmVyICAgIHwNCg0KICAgICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsNCg0KICAgICAgfCAgICAgIFJlYXNvbiBQaHJhc2UgKHZhcmlhYmxlKSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgLi4NCg0KICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KDQoNCltUUjJdIFNob3Vs ZG7igJl0IGl0IGJlIFJzdmQgZm9sbG93ZWQgYnkgQWRkcmVzcyBmYW1pbHkgPw0KDQpUaGVuIGl0 IHdvbid0IGJlIGJ5dGUtYWxpZ25lZCwgd2hpY2ggc2VlbXMgYmFkLg0KDQo= --_000_913383AAA69FF945B8F946018B75898A366D17F0xmbrcdx10ciscoc_ 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 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz O30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWls U3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IEp1c3RpbiBVYmVydGkgW21haWx0bzpqdWJlcnRpQGdvb2dsZS5jb21dDQo8 YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXJjaCAyNywgMjAxNSAzOjMyIEFNPGJyPg0KPGI+ VG86PC9iPiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpPGJyPg0KPGI+Q2M6PC9iPiB0cmFt QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHJhbV0gQ29tbWVudHMgb24gZHJh ZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gVGh1LCBNYXIgMjYsIDIwMTUgYXQgMTozOSBQTSwgVGlydW1hbGVzd2FyIFJl ZGR5ICh0aXJlZGR5KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRpcmVkZHlAY2lzY28uY29tIiB0YXJn ZXQ9Il9ibGFuayI+dGlyZWRkeUBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW5saW5lIFtUUjJdPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBKdXN0aW4gVWJlcnRpIFttYWlsdG86PGEg aHJlZj0ibWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmp1YmVydGlA Z29vZ2xlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1hcmNoIDI2LCAy MDE1IDEwOjIzIFBNPGJyPg0KPGI+VG86PC9iPiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkp PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPnRyYW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHJhbV0g Q29tbWVudHMgb24gZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDE8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUaHUsIE1hciAyNiwgMjAxNSBhdCA2 OjA2IEFNLCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpICZsdDs8YSBocmVmPSJtYWlsdG86 dGlyZWRkeUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj50aXJlZGR5QGNpc2NvLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBKdXN0 aW4sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciB0aGUgY29tbWVudHMuIFBsZWFzZSBzZWUgaW5s aW5lIFtUUl08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IHRyYW0gW21haWx0bzo8YSBocmVmPSJtYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+dHJhbS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8 L2I+SnVzdGluIFViZXJ0aTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTWFyY2ggMjYsIDIw MTUgMTE6MzIgQU08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+dHJhbUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4g W3RyYW1dIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTAxPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5iZXR0ZXIgbGF0 ZSB0aGFuIG5ldmVyOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPlMgNi4xOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5JIGRvbid0IHRoaW5rIHRoYXQgd2UgbmVlZCB0byBmb3JiaWQgdXNpbmcgUkFG IHdpdGggQUFGLiBJdCBzaG91bGQgYmUgcG9zc2libGUgdG8gZG8gUkFGKHY0KSB3aXRoIEFBRih2 NiksIFJBRih2Nikgd2l0aCBBQUYodjQpLCBvciBBQUYodjYpIGJ5IGl0c2VsZiwgYWxsIHdpdGgg dGhlIHNhbWUgbWVhbmluZy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltUUl0gUkFGIGlzJm5ic3A7IGNvbXByZWhl bnNpb24tcmVxdWlyZWQgYXR0cmlidXRlIHdoZXJlYXMgQUFGIGlzIGNvbXByZWhlbnNpb24tb3B0 aW9uYWwgYXR0cmlidXRlLCBJZg0KIGNsaWVudCB1c2VzIGJvdGggUkFGICYjNDM7IEFBRiBhbmQg dGhlIHNlcnZlciBkb2VzIG5vdCB1bmRlcnN0YW5kIFJBRiB0aGVuIHRoZSByZXF1ZXN0IGNvdWxk IGZhaWwuIEkgZG9u4oCZdCBzZWUgYW55IGFkdmFudGFnZSBvZiB1c2luZyBib3RoIFJBRiBhbmQg QUFGIHRvZ2V0aGVyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBh Z3JlZSB0aGF0IHR5cGljYWxseSBBQUYgd2lsbCBiZSBzZW50IGJ5IGl0c2VsZiwgYnV0IGluIHRo ZSBpbnRlcmVzdCBvZiBkZWZpbmluZyBhIGdlbmVyYWwgbWVjaGFuaXNtIEkgZG9uJ3QgdGhpbmsg d2Ugc2hvdWxkIHByb2hpYml0IFJBRiAmIzQzOyBBQUYuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bVFIyXSBSQUYgJiM0Mzsg QUFGIGNvbXBsaWNhdGVzIHNlcnZlciBhbmQgY2xpZW50IGltcGxlbWVudGF0aW9ucyB3aXRob3V0 IGFueSBiZW5lZml0cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgdGhpbmsgaXQgbWFrZXMgaXQgZWFzaWVyIHRvIHJlYXNvbiBhYm91dCB3aGF0 IHRoZXNlIGF0dHJpYnV0ZXMgYWN0dWFsbHkgZG8uIFNlcnZlciBuZWVkcyB0byBoYW5kbGUgUkFG IGFueXdheS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhhdCBzYWlkLCBJIGRvbid0IGZlZWwgc3VwZXIgc3Ryb25nbHkgYWJvdXQgdGhpcy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlMg Ny4xOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5JIHRoaW5rIHRoZSBjbGllbnQgc2hvdWxkIGluY2x1ZGUgUkFGIGZvciB0aGUgYmluZGluZ3Mg dGhhdCBpdCB3YW50cyB0byBrZWVwLCBub3QgQUFGLiBBQUYgaXMgb25seSB1c2VmdWwgaW4gdGhl IEFMTE9DQVRFLCB3aGVyZSB0aGUgY2xpZW50IGRvZXNuJ3Qga25vdyBpZiB0aGUgc2VydmVyIHN1 cHBvcnRzIEFBRi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPltUUl0gSWYgQUFGIGlzIHVzZWQgZm9yIEFsbG9jYXRpb24gdGhl biB0aGVyZSBpcyBubyByZWFzb24gd2h5IFJBRiBzaG91bGQgYmUgdXNlZCBmb3IgdGhlIGJpbmRp bmcNCiAoc2VydmVyIG1heSBub3Qgc3VwcG9ydCBSQUYgYW5kIGl0IHdpbGwgcmVzdWx0IGluIGZh aWx1cmUgdG8gcmVmcmVzaCkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5UaGVyZSBpcyBubyBzZXJ2ZXIgdGhhdCB3aWxsIHN1cHBvcnQgQUFG IGJ1dCBub3QgUkFGLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Rm9yIGEgZHVhbCBhbGxvY2F0aW9uLCB0aGUgY2xpZW50IHNo b3VsZCBiZSBhYmxlIHRvIHJlZnJlc2ggdGhlIHY0LCB2Niwgb3IgYm90aC4gUmlnaHQgbm93IGlu IHRoZSBkb2MsIHdlIGRvbid0IGhhdmUgdGhhdCBjb250cm9sLg0KPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bVFIyXSBUaGUg Y29udHJvbCBpcyBwb3NzaWJsZSBhbmQgaXMgZGlzY3Vzc2VkIGluIHNlY3Rpb24gNy4xPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jmx0O3NuaXAmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFdoZW4gcmVmcmVzaGluZyBh IGR1YWwgYWxsb2NhdGlvbiwgdGhlIGNsaWVudCBpbmNsdWRlcyBBRERJVElPTkFMLTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyBBRERSRVNTLUZBTUlMWSBhdHRyaWJ1dGUgaW5kaWNhdGluZyB0aGUgYWRkcmVzcyBmYW1p bHkgdHlwZSB0aGF0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHNob3VsZCBiZSByZWZyZXNoZWQuJm5ic3A7IElmIG5v IEFERElUSU9OQUwtQUREUkVTUy1GQU1JTFkgaXMgaW5jbHVkZWQ8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgdGhlbiB0 aGUgcmVxdWVzdCBzaG91bGQgYmUgdHJlYXRlZCBhcyBhcHBseWluZyB0byBhbGwgY3VycmVudDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyBhbGxvY2F0aW9ucy4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZsdDsvc25pcCZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IGRvZXNuJ3Qgc2F5IGhvdyB0byBvbmx5IHJlZnJl c2ggdjQsIG9yIG9ubHkgcmVmcmVzaCB2NiwgaW4gYSBkdWFsIGFsbG9jYXRpb24uPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltUUjNd IEl04oCZcyBleHBsYWluZWQgaW4gdGhlIGZpcnN0IGxpbmU7IGNsaWVudCByZWZyZXNoZXMgdjQg YnkgaW5jbHVkaW5nIEFBRiAodjQpLCBjbGllbnQgcmVmcmVzaGVzIHY2IGJ5IGluY2x1ZGluZyBB QUYgKHY2KS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+LVRpcnU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHN1Z2dlc3QgdGhlIGZvbGxvd2luZzo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+djQgY2Fu IGJlIHJlZnJlc2hlZCBieSBzZW5kaW5nIFJBRih2NCkuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnY2IGNhbiBiZSByZWZyZXNoZWQgYnkgc2Vu ZGluZyBSQUYodjYpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5ib3RoIGNhbiBiZSByZWZyZXNoZWQgYnkgc2VuZGluZyBSQUYodjQmIzQzO3Y2 KSwgYW5kL29yLCBwZXJoYXBzLCBubyBSQUYuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Gb3IgYSBzaW5nbGUgYWxsb2NhdGlvbiwgSSBz dWdnZXN0IHdlIGtlZXAgdGhlIGV4aXN0aW5nIGZvcm1hdCB3aGVyZSBzZW5kaW5nIG5vIFJBRiBy ZWZyZXNoZXMgdGhlIGFsbG9jYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5TIDkuMTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+SSBkb24ndCB0aGluayB3ZSB3YW50IHRvIHN1cHBvcnQgQ3JlYXRlUGVybWlzc2lv bnMgd2l0aCBtdWx0aXBsZSBhZGRyZXNzZXMuIEl0IGRvZXNuJ3Qgc2F2ZSBhbnl0aGluZyBvdGhl ciB0aGFuIDIgcGFja2V0cyBhbmQganVzdCBtYWtlcyBsaWZlIG1vcmUgY29tcGxpY2F0ZWQuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5bVFJdIFBsZWFzZSBjbGFyaWZ5IHdoeSBpdCBjb21wbGljYXRlcyBpbXBsZW1lbnRhdGlv biA/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5Zb3Ugbm93IG5lZWQgdG8gaGFuZGxlIHBhcnRpYWwgc3VjY2Vzc2VzLCBzbyB5b3VyIGVycm9y IGhhbmRsaW5nIHBhdGggaXMgbW9yZSBjb21wbGljYXRlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltUUjJdIEdvb2QgcG9p bnQsIHdpbGwgcmVtb3ZlIHN1cHBvcnQgZm9yIG11bHRpcGxlIGFkZHJlc3Nlcy48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5C dXQgbWFpbmx5LCBpdCdzIG5vdCBjbGVhciBhdCBhbGwgd2h5IGEgY2xpZW50IHdvdWxkIHVzZSB0 aGlzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow aW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UyAxMS4xOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Ib3cgd291bGQg eW91IGRvIGEgQ2hhbm5lbEJpbmQgd2l0aCBtdWx0aXBsZSBhZGRyZXNzZXM/IFNlbnQgcGFja2V0 cyBnbyB0byBib3RoIGRlc3RpbmF0aW9ucz8gQWdhaW4sIHRoaXMgc2VlbXMgY29tcGxleCB3aXRo IG5vIGdvb2QgcmVhc29uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1RSXSBBZ3JlZWQsIHdpbGwgZml4IGluIHRoZSBuZXh0 IHJldmVyc2lvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5TIDE1LjYvMTUuMTE6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkl0IHdvdWxkIGJlIGdvb2QgdG8gc2VwYXJh dGUgdGhlIFJBRi9BQUYgcGF5bG9hZCBkZWZpbml0aW9uIG91dCBzbyB0aGF0IGl0IGRvZXNuJ3Qg bmVlZCB0byBiZSByZXBlYXRlZCBpbiBib3RoIHNlY3Rpb25zLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1RSXSBUaGUgcGF5 bG9hZCB0ZXh0IGlzIG5vdCBsYXJnZSBlbm91Z2ggZm9yIGEgc2VwYXJhdGUgc2VjdGlvbi48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkF0IDMw IGxpbmVzIG9mIHRleHQsIEkgZGlzYWdyZWUuIFdlIGFyZSBhbHJlYWR5IGRvaW5nIHRoaXMgc29y dCBvZiB0aGluZyBmb3IgWE9SLVBFRVItQUREUkVTUy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5bVFIyXSBPa2F5LCB3aWxsIHJlbW92ZSBkdXBsaWNhdGUgdGV4dC48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TIDE1LjEyOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgZXJyb3IgY29kZSBm aWVsZCBpcyB0b28gc21hbGwgdG8gaG9sZCBlcnJvciBjb2RlcyAoOCBiaXRzKS4gSSB0aGluayB0 aGlzIHNob3VsZCB1c2UgdGhlIHNhbWUgc3RydWN0dXJlIGFzIEVSUk9SLUNPREUgZnJvbSA1Mzg5 LCBidXQgdXNlIHNvbWUgb2YgdGhlIHJlc2VydmVkIGJpdHMgZm9yIGZhbWlseS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltU Ul0gWWVzLCB3aWxsIGZpeCB0aGF0IGluIHRoZSBuZXh0IHJldmlzaW9uLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U3VnZ2VzdGlvbjo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpw cmUtd3JhcCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzwvc3Bh bj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgQWRkcmVz cyBGYW1pbHkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyBSc3ZkJm5i c3A7IHxDbGFzc3wmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTnVtYmVyJm5ic3A7Jm5ic3A7Jm5i c3A7IHw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7UmVhc29uIFBocmFz ZSAodmFyaWFibGUpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bVFIyXSBTaG91bGRu4oCZdCBpdCBiZSBS c3ZkIGZvbGxvd2VkIGJ5IEFkZHJlc3MgZmFtaWx5ID88L3NwYW4+PG86cD48L286cD48L3ByZT4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlbiBpdCB3b24n dCBiZSBieXRlLWFsaWduZWQsIHdoaWNoIHNlZW1zIGJhZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_913383AAA69FF945B8F946018B75898A366D17F0xmbrcdx10ciscoc_-- From nobody Thu Mar 26 19:49:02 2015 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 71C361A9043 for ; Thu, 26 Mar 2015 19:49:00 -0700 (PDT) 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 8DzM1BtRW7fV for ; Thu, 26 Mar 2015 19:48:59 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id D9B201A903F for ; Thu, 26 Mar 2015 19:48:58 -0700 (PDT) Received: from [IPv6:2001:67c:370:136:c617:feff:feb6:86ed] (unknown [IPv6:2001:67c:370:136:c617:feff:feb6:86ed]) (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 972D42044F for ; Fri, 27 Mar 2015 03:48:57 +0100 (CET) Message-ID: <5514C516.2090109@acm.org> Date: Thu, 26 Mar 2015 21:48:54 -0500 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 To: tram@ietf.org References: <20150326200603.5774.97401.idtracker@ietfa.amsl.com> In-Reply-To: <20150326200603.5774.97401.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-03.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, 27 Mar 2015 02:49:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Changelog for -03 (before the WG session in Dallas): o SCTP prefix is now 0b00000101 instead of 0x11. o Add SCTP at various places it was needed. o Update the hash agility plan to take in account HMAC-SHA-256. o Adds the bid down attack on message-integrity in the security section. o Update RFC 4013 to I-D.ietf-precis-saslprepbis. o Update RFc 5245 to rfc5245bis. o Cleaned the IANA consideration section. o Add sodium-free SHA256 password algorithm. o Add rational for the NONCE magic prefix. On 03/26/2015 03:06 PM, internet-drafts@ietf.org wrote: > > 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 : Session Traversal Utilities for NAT (STUN) > Authors : Marc Petit-Huguenin > Gonzalo Salgueiro > Jonathan Rosenberg > Dan Wing > Rohan Mahy > Philip Matthews > Filename : draft-ietf-tram-stunbis-03.txt > Pages : 58 > Date : 2015-03-26 > > Abstract: > Session Traversal Utilities for NAT (STUN) is a protocol that serves > as a tool for other protocols in dealing with Network Address > Translator (NAT) traversal. It can be used by an endpoint to > determine the IP address and port allocated to it by a NAT. It can > also be used to check connectivity between two endpoints, and as a > keep-alive protocol to maintain NAT bindings. STUN works with many > existing NATs, and does not require any special behavior from them. > > STUN is not a NAT traversal solution by itself. Rather, it is a tool > to be used in the context of a NAT traversal solution. > > This document obsoletes RFC 5389. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tram-stunbis-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stunbis-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/ > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > - -- 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 iQIcBAEBCAAGBQJVFMUWAAoJECnERZXWan7E8J0P/1FV617SPGg81mmVDvcobGkg PfPeFN7zIIY8Xs6J/0DqXUQ5+rBqXwjscBWoYNz7/zBercGuKHMEvRV8efPpTq/3 +OCEXhInOPJtqwTtOTcFKNe4qupbMwWZQHOGU72NDqigIKc44jDis1ioFyeK/t9P iNnmvxtB20yojVB2ZrANgvvo6FgSEl2kGyOOySeUVbhGtq0kK21z6eqALL1NdS+4 YJV7B0P6MxG6sg+t5B+I+m7AfQMv6zspEPLxewrIjI9LHIcdVAJW44Mgvp1kIyng NNa9ZhRIYGNAguLaGTSVClLt9UY2kXUSStPrRvH3bpZ42VyuoYdHHBe38tFt65ob VTMD24FgFgsDJBUrQQvkY9eA+cGzZJSOXj35tuy/7JYK2Ryw1lW1uwpS+4lBcWRp tQ6iF9FQ/jq9mIEx2CX8ZiCrhrAMvTs+BmkFxqwI4zEFcAWRASouRekqnMJ0MVFM rvunKw0Vo7wVwlBxmV1wafZ/Z5NnaUQc4s+NtqzFNrYAzTd1PyVdA7QWIlrMx7vc hpw4mi/r1mpDD77qba+wzK2wx6P+fquY56UnKdMIC+Xlf/+ggkdDYlSxw+e6jw7S GtDPrjV4lyV0OsdBleVHeGRAfRwmM7tAw0hQzfduux5Z5Z20i/DpIPLiRK3Wr8yc XL1B1EJN+ztbLBdJupEJ =gQ7G -----END PGP SIGNATURE----- From nobody Thu Mar 26 21:00:26 2015 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 652FE1A1EED for ; Thu, 26 Mar 2015 21:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 CMviELulMh7e for ; Thu, 26 Mar 2015 21:00:22 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D6A81A1F1D for ; Thu, 26 Mar 2015 21:00:22 -0700 (PDT) Received: by igbqf9 with SMTP id qf9so10197855igb.1 for ; Thu, 26 Mar 2015 21:00:21 -0700 (PDT) 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=uI9RkTwVmXESz09kne/sA+U0IHv+3YAZHxkfI9X4kDo=; b=Q4GDxn48uatqM46SkFCgOK9w76XqqX75ZwZtaxdzJYJwdndQNyEdLOvPfAdmGNsZgu diuXckOeJ24TzPDz0a9/uXK5TPkDZRp8D0uzQ7VDYQuQqpNmLrDcT6efxYjjCebNcK9F wrBLevO/9UWgTJrkpxz2tCuqSLo1rPRcBDRsmPQkHu+hGqLWi7CaayF/LtpCc26aVbrI He2gDmbdRHraKWXD5kybCV4GoqoiTPbQAFZZCmtt0eGHnMKCiYTlZA0rhOApXqfVBtI7 I0kA/XM1G9am9Q/RvUXnrXVivNgr6zKxd3yiv9K4D4QPXbyMbg/8CfDQ+BsfioVPE4Yj sB6Q== 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=uI9RkTwVmXESz09kne/sA+U0IHv+3YAZHxkfI9X4kDo=; b=EjUVDn2fNNjg6AfUTMhUOcmHYWhUAfT8NgvBzWSxCyhRksXShS3ij19p2E9XiV71x3 6CY1gUDMNvaN6k4yAO0Zh5bO0eFVDdGnR77e+tTS7xgrCrFrMlK+V2QOmpq7GFUoMsGy 8y5/tZSHwXcrKTZy9fwwbrzSayaRZtq1o7IR/3wUD7exMcWc0CyXYzwIvdFv6sNQhyi1 +xVRNooO1hX/GiDe8V595An0eMyeCCx6OsNyjPgezw3r179ddhESu5pLX0Oe1a8bz6gs MDa0ywhM9/BDSg/u4nESK/5N10yN0xjOQt7WXZezmIlYhmLhYSt9J7biSpqmZ1yMTjVy zF2g== X-Gm-Message-State: ALoCoQmJaOcZrqAjY8FrIvuEUMJu2Sgbqu8LTFMEb7IdTtBhOnQJcjDUFE+lIrT9GGrRYnRbIen7 X-Received: by 10.107.169.146 with SMTP id f18mr26771303ioj.6.1427428821783; Thu, 26 Mar 2015 21:00:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.64.42 with HTTP; Thu, 26 Mar 2015 21:00:01 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A366D17F0@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A366D0EDE@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A366D1482@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A366D17F0@xmb-rcd-x10.cisco.com> From: Justin Uberti Date: Thu, 26 Mar 2015 23:00:01 -0500 Message-ID: To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=001a11426ae4dd840e05123d2bee Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-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: Fri, 27 Mar 2015 04:00:24 -0000 --001a11426ae4dd840e05123d2bee Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 26, 2015 at 9:16 PM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > > > > > *From:* Justin Uberti [mailto:juberti@google.com] > *Sent:* Friday, March 27, 2015 3:32 AM > > *To:* Tirumaleswar Reddy (tireddy) > *Cc:* tram@ietf.org > *Subject:* Re: [tram] Comments on draft-ietf-tram-turnbis-01 > > > > > > > > On Thu, Mar 26, 2015 at 1:39 PM, Tirumaleswar Reddy (tireddy) < > tireddy@cisco.com> wrote: > > Inline [TR2] > > > > *From:* Justin Uberti [mailto:juberti@google.com] > *Sent:* Thursday, March 26, 2015 10:23 PM > *To:* Tirumaleswar Reddy (tireddy) > *Cc:* tram@ietf.org > *Subject:* Re: [tram] Comments on draft-ietf-tram-turnbis-01 > > > > > > > > On Thu, Mar 26, 2015 at 6:06 AM, Tirumaleswar Reddy (tireddy) < > tireddy@cisco.com> wrote: > > Hi Justin, > > > > Thanks for the comments. Please see inline [TR] > > > > *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Justin Uberti > *Sent:* Thursday, March 26, 2015 11:32 AM > *To:* tram@ietf.org > *Subject:* [tram] Comments on draft-ietf-tram-turnbis-01 > > > > better late than never: > > > > S 6.1: > > I don't think that we need to forbid using RAF with AAF. It should be > possible to do RAF(v4) with AAF(v6), RAF(v6) with AAF(v4), or AAF(v6) by > itself, all with the same meaning. > > > > [TR] RAF is comprehension-required attribute whereas AAF is > comprehension-optional attribute, If client uses both RAF + AAF and the > server does not understand RAF then the request could fail. I don=E2=80= =99t see any > advantage of using both RAF and AAF together. > > > > I agree that typically AAF will be sent by itself, but in the interest of > defining a general mechanism I don't think we should prohibit RAF + AAF. > > > > [TR2] RAF + AAF complicates server and client implementations without any > benefits. > > > > I think it makes it easier to reason about what these attributes actually > do. Server needs to handle RAF anyway. > > > > That said, I don't feel super strongly about this. > > > > > > > > S 7.1: > > I think the client should include RAF for the bindings that it wants to > keep, not AAF. AAF is only useful in the ALLOCATE, where the client doesn= 't > know if the server supports AAF. > > > > [TR] If AAF is used for Allocation then there is no reason why RAF should > be used for the binding (server may not support RAF and it will result in > failure to refresh). > > > > There is no server that will support AAF but not RAF. > > > > For a dual allocation, the client should be able to refresh the v4, v6, o= r > both. Right now in the doc, we don't have that control. > > > > [TR2] The control is possible and is discussed in section 7.1 > > > > > > > > When refreshing a dual allocation, the client includes ADDITIONAL- > > ADDRESS-FAMILY attribute indicating the address family type that > > should be refreshed. If no ADDITIONAL-ADDRESS-FAMILY is included > > then the request should be treated as applying to all current > > allocations. > > > > > > It doesn't say how to only refresh v4, or only refresh v6, in a dual > allocation. > > > > [TR3] It=E2=80=99s explained in the first line; client refreshes v4 by in= cluding > AAF (v4), client refreshes v6 by including AAF (v6). > > > OK, I get it now. But I think that is super confusing - the semantics are totally different than for ALLOCATE. In ALLOCATE, no AAF means "v4 only", and v6 AAF means "v4+v6". In REFRESH, no AAF means "v4+v6", and v6 AAF means "v6 only". Part of the problem is that AAF, by its use of the work "additional", implies that the specified address family is in addition to something else. Here, we're not doing that, which is why it is confusing. I think that REFRESH should work as follows: - REFRESH with no attributes refreshes everything, regardless of allocation type - REFRESH with specific RAF refreshes only the specific allocation if it exists, or otherwise fails - REFRESH with any AAF fails because it is not well-defined --001a11426ae4dd840e05123d2bee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Mar 26, 2015 at 9:16 PM, Tirumaleswar Reddy (tireddy) <tireddy@cis= co.com> wrote:

=C2=A0

=C2=A0

From: Justin U= berti [mailto:juber= ti@google.com]
Sent: Friday, March 27, 2015 3:32 AM


To: Tirumaleswar Reddy (tireddy)
Cc: tram@ietf.org=
Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-01=

=C2=A0

=C2=A0

=C2=A0

On Thu, Mar 26, 2015 at 1:39 PM, Tirumaleswar Reddy = (tireddy) <tiredd= y@cisco.com> wrote:

Inline [TR2]

=C2=A0

From: Justin U= berti [mailto:juber= ti@google.com]
Sent: Thursday, March 26, 2015 10:23 PM
To: Tirumaleswar Reddy (tireddy)
Cc: tram@ietf.org=
Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-01=

=C2=A0

=C2=A0

=C2=A0

On Thu, Mar 26, 2015 at 6:06 AM, Tirumaleswar Reddy = (tireddy) <tiredd= y@cisco.com> wrote:

Hi Justin,<= u>

=C2=A0

Thanks for the comments. = Please see inline [TR]

=C2=A0

From: tram [ma= ilto:tram-bounce= s@ietf.org] On Behalf Of Justin Uberti
Sent: Thursday, March 26, 2015 11:32 AM
To: tram@ietf.org=
Subject: [tram] Comments on draft-ietf-tram-turnbis-01=

=C2=A0

better late than never:

=C2=A0

S 6.1:

I don't think that we need to forbid using RAF w= ith AAF. It should be possible to do RAF(v4) with AAF(v6), RAF(v6) with AAF= (v4), or AAF(v6) by itself, all with the same meaning.=C2=A0<= /p>

=C2=A0

[TR] RAF is=C2=A0 compreh= ension-required attribute whereas AAF is comprehension-optional attribute, = If client uses both RAF + AAF and the server does not understand RAF then the= request could fail. I don=E2=80=99t see any advantage of using both RAF an= d AAF together.

=C2=A0

I agree that typically AAF will be sent by itself, b= ut in the interest of defining a general mechanism I don't think we sho= uld prohibit RAF + AAF.

=C2=A0

[TR2] RAF + AAF complicat= es server and client implementations without any benefits.=

=C2=A0

I think it makes it easier to reason about what thes= e attributes actually do. Server needs to handle RAF anyway.<= /p>

=C2=A0

That said, I don't feel super strongly about thi= s.

=C2=A0

=C2=A0

=C2=A0

S 7.1:

I think the client should include RAF for the bindin= gs that it wants to keep, not AAF. AAF is only useful in the ALLOCATE, wher= e the client doesn't know if the server supports AAF.

=C2=A0

[TR] If AAF is used for A= llocation then there is no reason why RAF should be used for the binding (server may not support RAF and it will result in failure to refresh).

=C2=A0

There is no server that will support AAF but not RAF= .=C2=A0

=C2=A0

For a dual allocation, the client should be able to = refresh the v4, v6, or both. Right now in the doc, we don't have that c= ontrol.

=C2=A0

[TR2] The control is poss= ible and is discussed in section 7.1

=C2=A0

<snip>

=C2=A0

=C2=A0=C2=A0 When refreshing a dual allocation, the client= includes ADDITIONAL-

=C2=A0=C2=A0 ADDRESS-FAMILY attribute indicating the addre= ss family type that

=C2=A0=C2=A0 should be refreshed.=C2=A0 If no ADDITIONAL-A= DDRESS-FAMILY is included

=C2=A0=C2=A0 then the request should be treated as applyin= g to all current

=C2=A0=C2=A0 allocations.

</snip>

=C2=A0

It doesn't say how to only refresh v4, or only r= efresh v6, in a dual allocation.

=C2=A0

[TR3] It=E2= =80=99s explained in the first line; client refreshes v4 by including AAF (= v4), client refreshes v6 by including AAF (v6).

=C2=A0

<= /div>

O= K, I get it now. But I think that is super confusing - the semantics are to= tally different than for ALLOCATE.

In ALLOCATE, no= AAF means "v4 only", and v6 AAF means "v4+v6".
In REFRESH, no AAF means "v4+v6", and v6 AAF means "v6 on= ly".

Part of the problem is that AAF, by its = use of the work "additional", implies that the specified address = family is in addition to something else. Here, we're not doing that, wh= ich is why it is confusing.

I think that REFRESH s= hould work as follows:
- REFRESH with no attributes refreshes eve= rything, regardless of allocation type
- REFRESH with specific RA= F refreshes only the specific allocation if it exists, or otherwise fails
- REFRESH with any AAF fails because it is not well-defined
<= /div>
--001a11426ae4dd840e05123d2bee-- From nobody Thu Mar 26 21:42:35 2015 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 B7A6E1A9105 for ; Thu, 26 Mar 2015 21:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, 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 YRIET8QLNt5Y for ; Thu, 26 Mar 2015 21:42:34 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9D981A9103 for ; Thu, 26 Mar 2015 21:42:33 -0700 (PDT) Received: by wgs2 with SMTP id 2so86927870wgs.1 for ; Thu, 26 Mar 2015 21:42:32 -0700 (PDT) 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=YpmDW/JscQY1JX6h195eNEk3Ns3/3dCNrq0zqJ0omsc=; b=veeucSEJTKzXYYKPoPrcVOyDFxzztytq5M1xXVoNu9f1KNCy83yD4jG/quP8tIWPlY RBR+yfyratIr9wbxqYsbtad/CEzA57sNx84l605c9bS3LslGchG6KmYXlDKeSFxWrt24 raMy4zIuVnrv9WeSY7FSrxyzj3Tyh6qDxs96zGzMOhklttccLeAuv4FsjZSgJxKBb/zd ykHmiSbfvnKOvI1OrdgrSgLHiErDsxdAh3M/9wn8UhhjzE/ta2muwuCXupiltOS4rMvR /1uvaeHh8tIV/QQRtKOVVSxVFjlpmKr2E4QucsJaHBBtgpIZj1XkT4QJxCw+EKoX6hYr w75w== MIME-Version: 1.0 X-Received: by 10.180.103.170 with SMTP id fx10mr48216623wib.57.1427431352344; Thu, 26 Mar 2015 21:42:32 -0700 (PDT) Received: by 10.194.190.18 with HTTP; Thu, 26 Mar 2015 21:42:32 -0700 (PDT) In-Reply-To: References: <913383AAA69FF945B8F946018B75898A366D0EDE@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A366D1482@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A366D17F0@xmb-rcd-x10.cisco.com> Date: Thu, 26 Mar 2015 21:42:32 -0700 Message-ID: From: Oleg Moskalenko To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-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: Fri, 27 Mar 2015 04:42:34 -0000 On Thu, Mar 26, 2015 at 9:00 PM, Justin Uberti wrote: > > > I think that REFRESH should work as follows: > - REFRESH with no attributes refreshes everything, regardless of allocation > type > - REFRESH with specific RAF refreshes only the specific allocation if it > exists, or otherwise fails > - REFRESH with any AAF fails because it is not well-defined this behaviour is not compatible with older (RFC5766-compliant) servers that do not understand AAF. They will treat option 1 and option 3 as the same case. From nobody Thu Mar 26 22:08:15 2015 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 9AA7F1A8ABB for ; Thu, 26 Mar 2015 22:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 MM8pD_DM39DT for ; Thu, 26 Mar 2015 22:08:12 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F5E41A7001 for ; Thu, 26 Mar 2015 22:08:12 -0700 (PDT) Received: by ieclw3 with SMTP id lw3so62967313iec.2 for ; Thu, 26 Mar 2015 22:08:12 -0700 (PDT) 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=MPnqWSCSE37rJWHXsrrHf6TM+B6g5wvbtXp6/LPDLiE=; b=dPG5EpKekztw9QQbDL0WrEDEUoY6dM/EM5Dclhv13W8L+gTxpJ9ghofjCM6cv7WTgE tTm+Lh1WBdvsuzaqY0wMDLWk7UMx9XOI82lPeGlfoAxMFvihaucKPyoSyleEnrf1ilMn /8/HLjGCjVCgBDFQUgyPHsI4nOSPHU6dKUWfq1lpsWmssusKn9BVga+6Wlgr6IFFxw4Q Pa/LMwNYUU+YoSHAkstL8WdUukw1twm1OnSHOBWBwMCgAiqO1YJIBbAitFk5r3kv4233 Ru4UjSu+nAm1CCGY8SgyJvI3CDLjD2nbneZBFEpyQb/gMXTwVzZSGEaw6CO47OSDwmlg WKAA== 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=MPnqWSCSE37rJWHXsrrHf6TM+B6g5wvbtXp6/LPDLiE=; b=CM1hAm8HKVH5208t8Q502er/nd1Xqss/pyW+LeuqJQyJAqoDc3fPHk90KdQ1n60Hpa SlK7fcFWzNj6upblKEqNcV402qwqrdMvRN6OnWsPaeWKotlb9p8xN3+blDtphoY+8DYd XbJEQT1Xzs2jMc0ZNDet1rRydKniRbd4IiNt2nUZdd31rm/Mb3zardYtt75/dk/HdtZP zCjM6XqY6zKdpv18+O5u2gYOUax5SLsrKYlXql5Uev0foS3Q9I4+Q6Bulpko1vNOiiMz 5MLdny6tRf0IVQ368OPR9hpNTbvBYYu+oW1sV9JajJnFz/K0PrkdJo9aNV00jUqKDwST gXyg== X-Gm-Message-State: ALoCoQlOoxeuaP9svUuwrcrowmM3m7i5AXr+Kt8Cc4LJbKVkClGOmeFqkLDcFAecHYTmvYNl+iCH X-Received: by 10.43.66.131 with SMTP id xq3mr43954874icb.9.1427432891919; Thu, 26 Mar 2015 22:08:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.64.42 with HTTP; Thu, 26 Mar 2015 22:07:51 -0700 (PDT) In-Reply-To: References: <913383AAA69FF945B8F946018B75898A366D0EDE@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A366D1482@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A366D17F0@xmb-rcd-x10.cisco.com> From: Justin Uberti Date: Fri, 27 Mar 2015 00:07:51 -0500 Message-ID: To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=001a11c2159876fc4d05123e1e03 Archived-At: Cc: "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-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: Fri, 27 Mar 2015 05:08:13 -0000 --001a11c2159876fc4d05123e1e03 Content-Type: text/plain; charset=UTF-8 Sure, I am just saying that we shouldn't recommend that clients send AAF in Refresh requests. Send nothing if you want to refresh everything (or are not using a dual allocation); send RAF if you want to refresh (or kill) just one part of a dual allocation. On Thu, Mar 26, 2015 at 11:42 PM, Oleg Moskalenko wrote: > On Thu, Mar 26, 2015 at 9:00 PM, Justin Uberti wrote: > > > > > > I think that REFRESH should work as follows: > > - REFRESH with no attributes refreshes everything, regardless of > allocation > > type > > - REFRESH with specific RAF refreshes only the specific allocation if it > > exists, or otherwise fails > > - REFRESH with any AAF fails because it is not well-defined > > this behaviour is not compatible with older (RFC5766-compliant) > servers that do not understand AAF. They will treat option 1 and > option 3 as the same case. > --001a11c2159876fc4d05123e1e03 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sure, I am just saying that we shouldn't recommend tha= t clients send AAF in Refresh requests.=C2=A0

Send nothi= ng if you want to refresh everything (or are not using a dual allocation); = send RAF if you want to refresh (or kill) just one part of a dual allocatio= n.

On = Thu, Mar 26, 2015 at 11:42 PM, Oleg Moskalenko <mom040267@gmail.com&= gt; wrote:
On Thu= , Mar 26, 2015 at 9:00 PM, Justin Uberti <juberti@google.com> wrote:
>
>
> I think that REFRESH should work as follows:
> - REFRESH with no attributes refreshes everything, regardless of alloc= ation
> type
> - REFRESH with specific RAF refreshes only the specific allocation if = it
> exists, or otherwise fails
> - REFRESH with any AAF fails because it is not well-defined

this behaviour is not compatible with older (RFC5766-compliant)
servers that do not understand AAF. They will treat option 1 and
option 3 as the same case.

--001a11c2159876fc4d05123e1e03-- From nobody Thu Mar 26 22:29:41 2015 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 3DAFF1A89B1 for ; Thu, 26 Mar 2015 22:29:39 -0700 (PDT) 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 Gj-9BXMkkbdu for ; Thu, 26 Mar 2015 22:29:33 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 390591A89C6 for ; Thu, 26 Mar 2015 22:29:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35122; q=dns/txt; s=iport; t=1427434173; x=1428643773; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=mzQVFpRFnmtIkfBUbbUysHU47u8hr3kMVDM4ejNQdcI=; b=f9F7YbBDD8AJaTw6uPFc6ABm6umMyO2PUCzf6E99xvdc8OIQjgnq42zT TSlMJ8WV2AprXjXm4eBacPuP/xghlow5PKgA1PziY5HohIrwR3A2AHFi3 dDzX9woPbol3XFlI+cfzV1RNmg8qjjBEhQt0d0w1SuJZHEMGFAvPx00Xi g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A7CACC6RRV/4ENJK1cgkNDUloEgw+/aDyBf4V1AhyBIEwBAQEBAQF9hBQBAQEEIwoaMhACAQgOAwQBAQsWAQYDAgICMBQJCAIEDgUIiCcNsW+FFpUcAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sohEcWGwYBgmgvgRYFjkKCDoNvhxs6gnaPYiKCAhyBUG8BgUN/AQEB X-IronPort-AV: E=Sophos;i="5.11,477,1422921600"; d="scan'208,217";a="407144407" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-4.cisco.com with ESMTP; 27 Mar 2015 05:29:32 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t2R5TWhW004682 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Mar 2015 05:29:32 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.80]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Fri, 27 Mar 2015 00:29:31 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Justin Uberti Thread-Topic: [tram] Comments on draft-ietf-tram-turnbis-01 Thread-Index: AdBntPY5ANaPCcypQFyW0ZUNvQto2QAWjv+AAAiXOWAAAjWwAAAB0UEQAAqvXoAAB7xnUA== Date: Fri, 27 Mar 2015 05:29:31 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A366D1A9B@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A366D0EDE@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A366D1482@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A366D17F0@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.60.194] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A366D1A9Bxmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-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: Fri, 27 Mar 2015 05:29:39 -0000 --_000_913383AAA69FF945B8F946018B75898A366D1A9Bxmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW5saW5lIFtUUjRdDQoNCkZyb206IEp1c3RpbiBVYmVydGkgW21haWx0bzpqdWJlcnRpQGdvb2ds ZS5jb21dDQpTZW50OiBGcmlkYXksIE1hcmNoIDI3LCAyMDE1IDk6MzAgQU0NClRvOiBUaXJ1bWFs ZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQpDYzogdHJhbUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt0 cmFtXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0wMQ0KDQoNCk9uIFRodSwg TWFyIDI2LCAyMDE1IGF0IDk6MTYgUE0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgPHRp cmVkZHlAY2lzY28uY29tPG1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbT4+IHdyb3RlOg0KDQoNCkZy b206IEp1c3RpbiBVYmVydGkgW21haWx0bzpqdWJlcnRpQGdvb2dsZS5jb208bWFpbHRvOmp1YmVy dGlAZ29vZ2xlLmNvbT5dDQpTZW50OiBGcmlkYXksIE1hcmNoIDI3LCAyMDE1IDM6MzIgQU0NCg0K VG86IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkNCkNjOiB0cmFtQGlldGYub3JnPG1haWx0 bzp0cmFtQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFt0cmFtXSBDb21tZW50cyBvbiBkcmFmdC1p ZXRmLXRyYW0tdHVybmJpcy0wMQ0KDQoNCg0KT24gVGh1LCBNYXIgMjYsIDIwMTUgYXQgMTozOSBQ TSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSA8dGlyZWRkeUBjaXNjby5jb208bWFpbHRv OnRpcmVkZHlAY2lzY28uY29tPj4gd3JvdGU6DQpJbmxpbmUgW1RSMl0NCg0KRnJvbTogSnVzdGlu IFViZXJ0aSBbbWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbTxtYWlsdG86anViZXJ0aUBnb29nbGUu Y29tPl0NClNlbnQ6IFRodXJzZGF5LCBNYXJjaCAyNiwgMjAxNSAxMDoyMyBQTQ0KVG86IFRpcnVt YWxlc3dhciBSZWRkeSAodGlyZWRkeSkNCkNjOiB0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFt0cmFtXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLXRyYW0t dHVybmJpcy0wMQ0KDQoNCg0KT24gVGh1LCBNYXIgMjYsIDIwMTUgYXQgNjowNiBBTSwgVGlydW1h bGVzd2FyIFJlZGR5ICh0aXJlZGR5KSA8dGlyZWRkeUBjaXNjby5jb208bWFpbHRvOnRpcmVkZHlA Y2lzY28uY29tPj4gd3JvdGU6DQpIaSBKdXN0aW4sDQoNClRoYW5rcyBmb3IgdGhlIGNvbW1lbnRz LiBQbGVhc2Ugc2VlIGlubGluZSBbVFJdDQoNCkZyb206IHRyYW0gW21haWx0bzp0cmFtLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBK dXN0aW4gVWJlcnRpDQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMjYsIDIwMTUgMTE6MzIgQU0NClRv OiB0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPg0KU3ViamVjdDogW3RyYW1dIENv bW1lbnRzIG9uIGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTAxDQoNCmJldHRlciBsYXRlIHRoYW4g bmV2ZXI6DQoNClMgNi4xOg0KSSBkb24ndCB0aGluayB0aGF0IHdlIG5lZWQgdG8gZm9yYmlkIHVz aW5nIFJBRiB3aXRoIEFBRi4gSXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIGRvIFJBRih2NCkgd2l0 aCBBQUYodjYpLCBSQUYodjYpIHdpdGggQUFGKHY0KSwgb3IgQUFGKHY2KSBieSBpdHNlbGYsIGFs bCB3aXRoIHRoZSBzYW1lIG1lYW5pbmcuDQoNCltUUl0gUkFGIGlzICBjb21wcmVoZW5zaW9uLXJl cXVpcmVkIGF0dHJpYnV0ZSB3aGVyZWFzIEFBRiBpcyBjb21wcmVoZW5zaW9uLW9wdGlvbmFsIGF0 dHJpYnV0ZSwgSWYgY2xpZW50IHVzZXMgYm90aCBSQUYgKyBBQUYgYW5kIHRoZSBzZXJ2ZXIgZG9l cyBub3QgdW5kZXJzdGFuZCBSQUYgdGhlbiB0aGUgcmVxdWVzdCBjb3VsZCBmYWlsLiBJIGRvbuKA mXQgc2VlIGFueSBhZHZhbnRhZ2Ugb2YgdXNpbmcgYm90aCBSQUYgYW5kIEFBRiB0b2dldGhlci4N Cg0KSSBhZ3JlZSB0aGF0IHR5cGljYWxseSBBQUYgd2lsbCBiZSBzZW50IGJ5IGl0c2VsZiwgYnV0 IGluIHRoZSBpbnRlcmVzdCBvZiBkZWZpbmluZyBhIGdlbmVyYWwgbWVjaGFuaXNtIEkgZG9uJ3Qg dGhpbmsgd2Ugc2hvdWxkIHByb2hpYml0IFJBRiArIEFBRi4NCg0KW1RSMl0gUkFGICsgQUFGIGNv bXBsaWNhdGVzIHNlcnZlciBhbmQgY2xpZW50IGltcGxlbWVudGF0aW9ucyB3aXRob3V0IGFueSBi ZW5lZml0cy4NCg0KSSB0aGluayBpdCBtYWtlcyBpdCBlYXNpZXIgdG8gcmVhc29uIGFib3V0IHdo YXQgdGhlc2UgYXR0cmlidXRlcyBhY3R1YWxseSBkby4gU2VydmVyIG5lZWRzIHRvIGhhbmRsZSBS QUYgYW55d2F5Lg0KDQpUaGF0IHNhaWQsIEkgZG9uJ3QgZmVlbCBzdXBlciBzdHJvbmdseSBhYm91 dCB0aGlzLg0KDQoNCg0KUyA3LjE6DQpJIHRoaW5rIHRoZSBjbGllbnQgc2hvdWxkIGluY2x1ZGUg UkFGIGZvciB0aGUgYmluZGluZ3MgdGhhdCBpdCB3YW50cyB0byBrZWVwLCBub3QgQUFGLiBBQUYg aXMgb25seSB1c2VmdWwgaW4gdGhlIEFMTE9DQVRFLCB3aGVyZSB0aGUgY2xpZW50IGRvZXNuJ3Qg a25vdyBpZiB0aGUgc2VydmVyIHN1cHBvcnRzIEFBRi4NCg0KW1RSXSBJZiBBQUYgaXMgdXNlZCBm b3IgQWxsb2NhdGlvbiB0aGVuIHRoZXJlIGlzIG5vIHJlYXNvbiB3aHkgUkFGIHNob3VsZCBiZSB1 c2VkIGZvciB0aGUgYmluZGluZyAoc2VydmVyIG1heSBub3Qgc3VwcG9ydCBSQUYgYW5kIGl0IHdp bGwgcmVzdWx0IGluIGZhaWx1cmUgdG8gcmVmcmVzaCkuDQoNClRoZXJlIGlzIG5vIHNlcnZlciB0 aGF0IHdpbGwgc3VwcG9ydCBBQUYgYnV0IG5vdCBSQUYuDQoNCkZvciBhIGR1YWwgYWxsb2NhdGlv biwgdGhlIGNsaWVudCBzaG91bGQgYmUgYWJsZSB0byByZWZyZXNoIHRoZSB2NCwgdjYsIG9yIGJv dGguIFJpZ2h0IG5vdyBpbiB0aGUgZG9jLCB3ZSBkb24ndCBoYXZlIHRoYXQgY29udHJvbC4NCg0K W1RSMl0gVGhlIGNvbnRyb2wgaXMgcG9zc2libGUgYW5kIGlzIGRpc2N1c3NlZCBpbiBzZWN0aW9u IDcuMQ0KDQo8c25pcD4NCg0KICAgV2hlbiByZWZyZXNoaW5nIGEgZHVhbCBhbGxvY2F0aW9uLCB0 aGUgY2xpZW50IGluY2x1ZGVzIEFERElUSU9OQUwtDQogICBBRERSRVNTLUZBTUlMWSBhdHRyaWJ1 dGUgaW5kaWNhdGluZyB0aGUgYWRkcmVzcyBmYW1pbHkgdHlwZSB0aGF0DQogICBzaG91bGQgYmUg cmVmcmVzaGVkLiAgSWYgbm8gQURESVRJT05BTC1BRERSRVNTLUZBTUlMWSBpcyBpbmNsdWRlZA0K ICAgdGhlbiB0aGUgcmVxdWVzdCBzaG91bGQgYmUgdHJlYXRlZCBhcyBhcHBseWluZyB0byBhbGwg Y3VycmVudA0KICAgYWxsb2NhdGlvbnMuDQo8L3NuaXA+DQoNCkl0IGRvZXNuJ3Qgc2F5IGhvdyB0 byBvbmx5IHJlZnJlc2ggdjQsIG9yIG9ubHkgcmVmcmVzaCB2NiwgaW4gYSBkdWFsIGFsbG9jYXRp b24uDQoNCltUUjNdIEl04oCZcyBleHBsYWluZWQgaW4gdGhlIGZpcnN0IGxpbmU7IGNsaWVudCBy ZWZyZXNoZXMgdjQgYnkgaW5jbHVkaW5nIEFBRiAodjQpLCBjbGllbnQgcmVmcmVzaGVzIHY2IGJ5 IGluY2x1ZGluZyBBQUYgKHY2KS4NCg0KDQpPSywgSSBnZXQgaXQgbm93LiBCdXQgSSB0aGluayB0 aGF0IGlzIHN1cGVyIGNvbmZ1c2luZyAtIHRoZSBzZW1hbnRpY3MgYXJlIHRvdGFsbHkgZGlmZmVy ZW50IHRoYW4gZm9yIEFMTE9DQVRFLg0KDQpJbiBBTExPQ0FURSwgbm8gQUFGIG1lYW5zICJ2NCBv bmx5IiwgYW5kIHY2IEFBRiBtZWFucyAidjQrdjYiLg0KSW4gUkVGUkVTSCwgbm8gQUFGIG1lYW5z ICJ2NCt2NiIsIGFuZCB2NiBBQUYgbWVhbnMgInY2IG9ubHkiLg0KDQpbVFJdIFllcy4NCg0KUGFy dCBvZiB0aGUgcHJvYmxlbSBpcyB0aGF0IEFBRiwgYnkgaXRzIHVzZSBvZiB0aGUgd29yayAiYWRk aXRpb25hbCIsIGltcGxpZXMgdGhhdCB0aGUgc3BlY2lmaWVkIGFkZHJlc3MgZmFtaWx5IGlzIGlu IGFkZGl0aW9uIHRvIHNvbWV0aGluZyBlbHNlLiBIZXJlLCB3ZSdyZSBub3QgZG9pbmcgdGhhdCwg d2hpY2ggaXMgd2h5IGl0IGlzIGNvbmZ1c2luZy4NCg0KSSB0aGluayB0aGF0IFJFRlJFU0ggc2hv dWxkIHdvcmsgYXMgZm9sbG93czoNCi0gUkVGUkVTSCB3aXRoIG5vIGF0dHJpYnV0ZXMgcmVmcmVz aGVzIGV2ZXJ5dGhpbmcsIHJlZ2FyZGxlc3Mgb2YgYWxsb2NhdGlvbiB0eXBlDQotIFJFRlJFU0gg d2l0aCBzcGVjaWZpYyBSQUYgcmVmcmVzaGVzIG9ubHkgdGhlIHNwZWNpZmljIGFsbG9jYXRpb24g aWYgaXQgZXhpc3RzLCBvciBvdGhlcndpc2UgZmFpbHMNCi0gUkVGUkVTSCB3aXRoIGFueSBBQUYg ZmFpbHMgYmVjYXVzZSBpdCBpcyBub3Qgd2VsbC1kZWZpbmVkDQoNCltUUjRdIFRoZXJlIGFyZSB0 d28gcmVhc29ucyBmb3IgdXNpbmcgQUFGIGluIFJlZnJlc2ggcmVxdWVzdC4gT25lIGlzIHRoYXQg aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjE1NiNzZWN0aW9uLTUuMSBleHBsYWlucyBS QUYgY2Fubm90IGJlIHVzZWQgaW4gUmVmcmVzaCByZXF1ZXN0IGFuZCB0aGUgb3RoZXIgaXMgdG8g dXNlIHRoZSBzYW1lIGF0dHJpYnV0ZSBpbiBib3RoIEFsbG9jYXRlIGFuZCBSZWZyZXNoLg0KDQot VGlydQ0K --_000_913383AAA69FF945B8F946018B75898A366D1A9Bxmbrcdx10ciscoc_ 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 LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0 OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SW5saW5lIFtUUjRdPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBw dCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEp1c3RpbiBVYmVydGkgW21haWx0bzpqdWJlcnRpQGdvb2ds ZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXJjaCAyNywgMjAxNSA5OjMwIEFN PGJyPg0KPGI+VG86PC9iPiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpPGJyPg0KPGI+Q2M6 PC9iPiB0cmFtQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHJhbV0gQ29tbWVu dHMgb24gZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgTWFyIDI2LCAyMDE1IGF0IDk6 MTYgUE0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgJmx0OzxhIGhyZWY9Im1haWx0bzp0 aXJlZGR5QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRpcmVkZHlAY2lzY28uY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSnVzdGluIFVi ZXJ0aSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpqdWJlcnRpQGdvb2dsZS5jb20iIHRhcmdldD0i X2JsYW5rIj5qdWJlcnRpQGdvb2dsZS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRh eSwgTWFyY2ggMjcsIDIwMTUgMzozMiBBTTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGI+VG86PC9iPiBUaXJ1bWFsZXN3YXIg UmVkZHkgKHRpcmVkZHkpPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRyYW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbdHJhbV0gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDE8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPk9uIFRodSwgTWFyIDI2LCAyMDE1IGF0IDE6MzkgUE0sIFRpcnVtYWxlc3dh ciBSZWRkeSAodGlyZWRkeSkgJmx0OzxhIGhyZWY9Im1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnRpcmVkZHlAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklubGluZSBbVFIyXTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4g MGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSnVzdGluIFViZXJ0aSBbbWFpbHRv OjxhIGhyZWY9Im1haWx0bzpqdWJlcnRpQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5qdWJl cnRpQGdvb2dsZS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBNYXJjaCAy NiwgMjAxNSAxMDoyMyBQTTxicj4NCjxiPlRvOjwvYj4gVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJl ZGR5KTxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj50cmFtQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Ry YW1dIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTAxPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVGh1LCBNYXIgMjYsIDIwMTUg YXQgNjowNiBBTSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSAmbHQ7PGEgaHJlZj0ibWFp bHRvOnRpcmVkZHlAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+dGlyZWRkeUBjaXNjby5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkg SnVzdGluLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLiBQbGVhc2Ugc2Vl IGlubGluZSBbVFJdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiB0cmFtIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnRyYW0tYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPkp1c3RpbiBVYmVydGk8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1hcmNoIDI2 LCAyMDE1IDExOjMyIEFNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRyYW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFt0cmFtXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0wMTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+YmV0dGVy IGxhdGUgdGhhbiBuZXZlcjo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5TIDYuMTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SSBkb24ndCB0aGluayB0aGF0IHdlIG5lZWQgdG8gZm9yYmlkIHVzaW5n IFJBRiB3aXRoIEFBRi4gSXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIGRvIFJBRih2NCkgd2l0aCBB QUYodjYpLCBSQUYodjYpIHdpdGggQUFGKHY0KSwgb3IgQUFGKHY2KSBieSBpdHNlbGYsIGFsbCB3 aXRoIHRoZSBzYW1lIG1lYW5pbmcuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bVFJdIFJBRiBpcyZuYnNwOyBjb21w cmVoZW5zaW9uLXJlcXVpcmVkIGF0dHJpYnV0ZSB3aGVyZWFzIEFBRiBpcyBjb21wcmVoZW5zaW9u LW9wdGlvbmFsIGF0dHJpYnV0ZSwgSWYNCiBjbGllbnQgdXNlcyBib3RoIFJBRiAmIzQzOyBBQUYg YW5kIHRoZSBzZXJ2ZXIgZG9lcyBub3QgdW5kZXJzdGFuZCBSQUYgdGhlbiB0aGUgcmVxdWVzdCBj b3VsZCBmYWlsLiBJIGRvbuKAmXQgc2VlIGFueSBhZHZhbnRhZ2Ugb2YgdXNpbmcgYm90aCBSQUYg YW5kIEFBRiB0b2dldGhlci48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkkgYWdyZWUgdGhhdCB0eXBpY2FsbHkgQUFGIHdpbGwgYmUgc2VudCBieSBpdHNlbGYsIGJ1dCBp biB0aGUgaW50ZXJlc3Qgb2YgZGVmaW5pbmcgYSBnZW5lcmFsIG1lY2hhbmlzbSBJIGRvbid0IHRo aW5rIHdlIHNob3VsZCBwcm9oaWJpdCBSQUYgJiM0MzsgQUFGLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1RSMl0gUkFGICYj NDM7IEFBRiBjb21wbGljYXRlcyBzZXJ2ZXIgYW5kIGNsaWVudCBpbXBsZW1lbnRhdGlvbnMgd2l0 aG91dCBhbnkgYmVuZWZpdHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+SSB0aGluayBpdCBtYWtlcyBpdCBlYXNpZXIgdG8gcmVhc29uIGFi b3V0IHdoYXQgdGhlc2UgYXR0cmlidXRlcyBhY3R1YWxseSBkby4gU2VydmVyIG5lZWRzIHRvIGhh bmRsZSBSQUYgYW55d2F5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+VGhhdCBzYWlkLCBJIGRvbid0IGZlZWwgc3VwZXIgc3Ryb25nbHkg YWJvdXQgdGhpcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t cmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t cmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlMgNy4xOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHRo aW5rIHRoZSBjbGllbnQgc2hvdWxkIGluY2x1ZGUgUkFGIGZvciB0aGUgYmluZGluZ3MgdGhhdCBp dCB3YW50cyB0byBrZWVwLCBub3QgQUFGLiBBQUYgaXMgb25seSB1c2VmdWwgaW4gdGhlIEFMTE9D QVRFLCB3aGVyZSB0aGUgY2xpZW50IGRvZXNuJ3Qga25vdyBpZiB0aGUgc2VydmVyIHN1cHBvcnRz IEFBRi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPltUUl0gSWYgQUFGIGlzIHVzZWQgZm9yIEFsbG9jYXRpb24gdGhlbiB0aGVy ZSBpcyBubyByZWFzb24gd2h5IFJBRiBzaG91bGQgYmUgdXNlZCBmb3IgdGhlIGJpbmRpbmcNCiAo c2VydmVyIG1heSBub3Qgc3VwcG9ydCBSQUYgYW5kIGl0IHdpbGwgcmVzdWx0IGluIGZhaWx1cmUg dG8gcmVmcmVzaCkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5UaGVyZSBpcyBubyBzZXJ2ZXIgdGhhdCB3aWxsIHN1cHBvcnQgQUFGIGJ1dCBu b3QgUkFGLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Rm9yIGEgZHVhbCBhbGxvY2F0aW9uLCB0aGUgY2xpZW50IHNob3VsZCBi ZSBhYmxlIHRvIHJlZnJlc2ggdGhlIHY0LCB2Niwgb3IgYm90aC4gUmlnaHQgbm93IGluIHRoZSBk b2MsIHdlIGRvbid0IGhhdmUgdGhhdCBjb250cm9sLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bVFIyXSBUaGUgY29udHJv bCBpcyBwb3NzaWJsZSBhbmQgaXMgZGlzY3Vzc2VkIGluIHNlY3Rpb24gNy4xPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jmx0O3NuaXAmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFdoZW4gcmVmcmVzaGluZyBhIGR1YWwg YWxsb2NhdGlvbiwgdGhlIGNsaWVudCBpbmNsdWRlcyBBRERJVElPTkFMLTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBB RERSRVNTLUZBTUlMWSBhdHRyaWJ1dGUgaW5kaWNhdGluZyB0aGUgYWRkcmVzcyBmYW1pbHkgdHlw ZSB0aGF0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7IHNob3VsZCBiZSByZWZyZXNoZWQuJm5ic3A7IElmIG5vIEFERElU SU9OQUwtQUREUkVTUy1GQU1JTFkgaXMgaW5jbHVkZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgdGhlbiB0aGUgcmVx dWVzdCBzaG91bGQgYmUgdHJlYXRlZCBhcyBhcHBseWluZyB0byBhbGwgY3VycmVudDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyBhbGxvY2F0aW9ucy4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZsdDsv c25pcCZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCBk b2Vzbid0IHNheSBob3cgdG8gb25seSByZWZyZXNoIHY0LCBvciBvbmx5IHJlZnJlc2ggdjYsIGlu IGEgZHVhbCBhbGxvY2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltUUjNdIEl04oCZcyBl eHBsYWluZWQgaW4gdGhlIGZpcnN0IGxpbmU7IGNsaWVudCByZWZyZXNoZXMgdjQgYnkgaW5jbHVk aW5nIEFBRiAodjQpLCBjbGllbnQgcmVmcmVzaGVzDQogdjYgYnkgaW5jbHVkaW5nIEFBRiAodjYp LiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9LLCBJIGdldCBpdCBub3cuIEJ1 dCBJIHRoaW5rIHRoYXQgaXMgc3VwZXIgY29uZnVzaW5nIC0gdGhlIHNlbWFudGljcyBhcmUgdG90 YWxseSBkaWZmZXJlbnQgdGhhbiBmb3IgQUxMT0NBVEUuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIEFMTE9DQVRFLCBubyBBQUYgbWVhbnMg JnF1b3Q7djQgb25seSZxdW90OywgYW5kIHY2IEFBRiBtZWFucyAmcXVvdDt2NCYjNDM7djYmcXVv dDsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J biBSRUZSRVNILCBubyBBQUYgbWVhbnMgJnF1b3Q7djQmIzQzO3Y2JnF1b3Q7LCBhbmQgdjYgQUFG IG1lYW5zICZxdW90O3Y2IG9ubHkmcXVvdDsuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltUUl0gWWVzLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGFydCBvZiB0aGUg cHJvYmxlbSBpcyB0aGF0IEFBRiwgYnkgaXRzIHVzZSBvZiB0aGUgd29yayAmcXVvdDthZGRpdGlv bmFsJnF1b3Q7LCBpbXBsaWVzIHRoYXQgdGhlIHNwZWNpZmllZCBhZGRyZXNzIGZhbWlseSBpcyBp biBhZGRpdGlvbiB0byBzb21ldGhpbmcgZWxzZS4gSGVyZSwgd2UncmUgbm90IGRvaW5nIHRoYXQs IHdoaWNoIGlzIHdoeSBpdCBpcyBjb25mdXNpbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhhdCBSRUZSRVNIIHNob3VsZCB3 b3JrIGFzIGZvbGxvd3M6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4tIFJFRlJFU0ggd2l0aCBubyBhdHRyaWJ1dGVzIHJlZnJlc2hlcyBldmVyeXRo aW5nLCByZWdhcmRsZXNzIG9mIGFsbG9jYXRpb24gdHlwZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBSRUZSRVNIIHdpdGggc3BlY2lmaWMgUkFG IHJlZnJlc2hlcyBvbmx5IHRoZSBzcGVjaWZpYyBhbGxvY2F0aW9uIGlmIGl0IGV4aXN0cywgb3Ig b3RoZXJ3aXNlIGZhaWxzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4tIFJFRlJFU0ggd2l0aCBhbnkgQUFGIGZhaWxzIGJlY2F1c2UgaXQgaXMgbm90 IHdlbGwtZGVmaW5lZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5bVFI0XSBUaGVyZSBhcmUgdHdvIHJlYXNvbnMgZm9yIHVzaW5nIEFB RiBpbiBSZWZyZXNoIHJlcXVlc3QuIE9uZSBpcyB0aGF0DQo8YSBocmVmPSJodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM2MTU2I3NlY3Rpb24tNS4xIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmM2MTU2I3NlY3Rpb24tNS4xPC9hPiBleHBsYWlucyBSQUYgY2Fubm90IGJlIHVzZWQg aW4gUmVmcmVzaCByZXF1ZXN0IGFuZCB0aGUgb3RoZXIgaXMgdG8gdXNlIHRoZSBzYW1lIGF0dHJp YnV0ZSBpbiBib3RoIEFsbG9jYXRlIGFuZCBSZWZyZXNoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LVRpcnUNCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_913383AAA69FF945B8F946018B75898A366D1A9Bxmbrcdx10ciscoc_-- From nobody Thu Mar 26 22:38:32 2015 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 500871A89B9 for ; Thu, 26 Mar 2015 22:38:30 -0700 (PDT) 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 jd1efXzoZnsW for ; Thu, 26 Mar 2015 22:38:29 -0700 (PDT) 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 2BFA01A8905 for ; Thu, 26 Mar 2015 22:38:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1364; q=dns/txt; s=iport; t=1427434709; x=1428644309; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=k4P+g49CKoN/Ahn+lXy5ws52Gcytb+k+DznMoZn73sE=; b=bukYsKnOeJi3VpCExj5ljRYYm4j1YLauGn3c4n3ekVdbr/lGUSumS5Iz vo4JYjloNBxPj2LYZr4DcODwcGHAK+YwH1JWcTA6kZlf6tZA34XBAj6/9 x7lQAmPu0wHLEQyoao9cX7fmVl309hwDKs/egmoh4M06MGJtcNMM7xJMN o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CaBwDb6xRV/40NJK1cgwaBLASDD79oiDACHIEgTAEBAQEBAX2EFAEBAQQjEUUMBAIBCA4DBAEBAQICBh0DAgICHxEUAQgIAgQBDQUIiBMDEbIAlGMNhUMBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGKB4JHggAWGwcGgmIvgRYBBJBQiCKPUYYpIoNub4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,477,1422921600"; d="scan'208";a="407067972" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-5.cisco.com with ESMTP; 27 Mar 2015 05:38:28 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t2R5cS1A003206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Mar 2015 05:38:28 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.80]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Fri, 27 Mar 2015 00:38:28 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko , Justin Uberti Thread-Topic: [tram] Comments on draft-ietf-tram-turnbis-01 Thread-Index: AdBntPY5ANaPCcypQFyW0ZUNvQto2QAWjv+AAAiXOWAAAjWwAAAB0UEQAAqvXoAAAXwhAAAImOLw Date: Fri, 27 Mar 2015 05:38:27 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A366D1AB5@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A366D0EDE@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A366D1482@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A366D17F0@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.60.194] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-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: Fri, 27 Mar 2015 05:38:30 -0000 VGhlIGNsaWVudCBpbmNsdWRlcyBBQUYgaW4gUmVmcmVzaCBvbmx5IGlmIGR1YWwgYWxsb2NhdGlv biBpcyBzdWNjZXNzZnVsIHdoaWNoIG1lYW5zIGNsaWVudCB3aGVuIGl0IHNlbmRzIFJlZnJlc2gg a25vd3MgaWYgc2VydmVyIHN1cHBvcnRzIEFBRiBvciBub3QuDQoNCi1UaXJ1DQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogT2xlZyBNb3NrYWxlbmtvIFttYWlsdG86bW9t MDQwMjY3QGdtYWlsLmNvbV0NCj4gU2VudDogRnJpZGF5LCBNYXJjaCAyNywgMjAxNSAxMDoxMyBB TQ0KPiBUbzogSnVzdGluIFViZXJ0aQ0KPiBDYzogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5 KTsgdHJhbUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3RyYW1dIENvbW1lbnRzIG9uIGRyYWZ0 LWlldGYtdHJhbS10dXJuYmlzLTAxDQo+IA0KPiBPbiBUaHUsIE1hciAyNiwgMjAxNSBhdCA5OjAw IFBNLCBKdXN0aW4gVWJlcnRpIDxqdWJlcnRpQGdvb2dsZS5jb20+IHdyb3RlOg0KPiA+DQo+ID4N Cj4gPiBJIHRoaW5rIHRoYXQgUkVGUkVTSCBzaG91bGQgd29yayBhcyBmb2xsb3dzOg0KPiA+IC0g UkVGUkVTSCB3aXRoIG5vIGF0dHJpYnV0ZXMgcmVmcmVzaGVzIGV2ZXJ5dGhpbmcsIHJlZ2FyZGxl c3Mgb2YNCj4gPiBhbGxvY2F0aW9uIHR5cGUNCj4gPiAtIFJFRlJFU0ggd2l0aCBzcGVjaWZpYyBS QUYgcmVmcmVzaGVzIG9ubHkgdGhlIHNwZWNpZmljIGFsbG9jYXRpb24gaWYNCj4gPiBpdCBleGlz dHMsIG9yIG90aGVyd2lzZSBmYWlscw0KPiA+IC0gUkVGUkVTSCB3aXRoIGFueSBBQUYgZmFpbHMg YmVjYXVzZSBpdCBpcyBub3Qgd2VsbC1kZWZpbmVkDQo+IA0KPiB0aGlzIGJlaGF2aW91ciBpcyBu b3QgY29tcGF0aWJsZSB3aXRoIG9sZGVyIChSRkM1NzY2LWNvbXBsaWFudCkgc2VydmVycyB0aGF0 IGRvDQo+IG5vdCB1bmRlcnN0YW5kIEFBRi4gVGhleSB3aWxsIHRyZWF0IG9wdGlvbiAxIGFuZCBv cHRpb24gMyBhcyB0aGUgc2FtZSBjYXNlLg0K From nobody Fri Mar 27 00:55:42 2015 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 D0E7B1A90DB; Fri, 27 Mar 2015 00:55:40 -0700 (PDT) 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 nzhwLYnFC_6h; Fri, 27 Mar 2015 00:55:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B0B1A1B27; Fri, 27 Mar 2015 00:55:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150327075539.26326.49374.idtracker@ietfa.amsl.com> Date: Fri, 27 Mar 2015 00:55:39 -0700 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-stunbis-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: Fri, 27 Mar 2015 07:55:41 -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 : Session Traversal Utilities for NAT (STUN) Authors : Marc Petit-Huguenin Gonzalo Salgueiro Jonathan Rosenberg Dan Wing Rohan Mahy Philip Matthews Filename : draft-ietf-tram-stunbis-04.txt Pages : 55 Date : 2015-03-27 Abstract: Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This document obsoletes RFC 5389. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tram-stunbis-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stunbis-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 Fri Mar 27 06:35:47 2015 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 F30551ACE10 for ; Fri, 27 Mar 2015 06:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 CEupOjB-OLIy for ; Fri, 27 Mar 2015 06:35:39 -0700 (PDT) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15E861ACE0D for ; Fri, 27 Mar 2015 06:35:39 -0700 (PDT) Received: by wibbg6 with SMTP id bg6so26867404wib.0 for ; Fri, 27 Mar 2015 06:35:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=tC1jGkeEla61GNKPosRJfmpIrCVfTv/LosNSPzLACz0=; b=AYa1djQj5kW1ubFLmW2RpSCOBawgPg2L+cxwSCGteUZlEbAuP+KffkoV/Msg+9vEfm Qhl03B6RB6cZdMPkD8+9ejfu2qk5wltfzF283nQHCkoXkohTSm7jth5scrVDjPhpgvhA 1UJrbWaFezdKWn+mwbJ5MmzN4nUzH7UtFHLhDAfm/ydlJk6lLafkHr/pH+kNXBOKH9GO 7+VlSxRNWBA1Hr+UCZVU90xAUUjuJHsqfsBGVfwCYWaT3pOaJYDGAS2gvjd+AKzwlyrN Cbb2k1Uu5+eAi+Zw4Q6yQsIM8R9MeGuirM+WSN/uKi4VqmMuT45zcp/z46em1Bs2+Gg/ Frvg== X-Gm-Message-State: ALoCoQn6NUiSjmXfdv0lkvEndxkXh1OS9Oh0xVWcsjCcWb1qQnfjN77FtEoHRJUWKI/hnpXIOg72 X-Received: by 10.180.73.146 with SMTP id l18mr41967314wiv.89.1427463337811; Fri, 27 Mar 2015 06:35:37 -0700 (PDT) Received: from dhcp-b271.meeting.ietf.org (dhcp-b271.meeting.ietf.org. [31.133.178.113]) by mx.google.com with ESMTPSA id ha10sm2877454wjc.37.2015.03.27.06.35.36 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Mar 2015 06:35:37 -0700 (PDT) Message-ID: <55155CA7.3050403@jive.com> Date: Fri, 27 Mar 2015 08:35:35 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "tram@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [tram] Adoption of draft-reddy-tram-stun-path-data-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: Fri, 27 Mar 2015 13:35:44 -0000 TRAMsters, This is to confirm the adoption of draft-reddy-tram-stun-path-data-01 as a working group draft. If anyone is opposed, now is a good time to explain why. Simon & Gonzalo From nobody Fri Mar 27 07:51:03 2015 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 82C531ACEA5 for ; Fri, 27 Mar 2015 07:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 bZOq5MlppmCL for ; Fri, 27 Mar 2015 07:51:01 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F55E1ACEB4 for ; Fri, 27 Mar 2015 07:51:01 -0700 (PDT) Received: by igbud6 with SMTP id ud6so22287787igb.1 for ; Fri, 27 Mar 2015 07:51:00 -0700 (PDT) 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=4wxNx2fWn9zt/UiAO6Zw1kBtGo1tVaBitDB2CINb0vI=; b=GbKh9UbPsdb56IADuv2SWKCG9VSCSwCpr19nJr7fbY4fDZlcKcJFCLHnQk7nNaPyCK 86Sr9X+RNXfoZZeeXmAoQppnizco4k4c+I8oZ+uz7c/pPxglJb06YnP/IR8na6X0GJZU 6g/b584AH/FyfN4NWzpPdUJRVfvqxwH+koruEn0nWJLOoZLrojzOnuKMimNc2j1zTbAj juqgWJX5T5zv9AdptJJTjxx+RTVeaFVL0OaloQRLzai4h3Hoaq2iBeZBPo/eYMklUpoW HXC53emmZRJA8ItqK5iRftXSMqZFIWhHtpo/sgj2/7P3JxxWzx4iMq0+T0/KV1UklFfm vPxw== 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=4wxNx2fWn9zt/UiAO6Zw1kBtGo1tVaBitDB2CINb0vI=; b=GE4F25v5Hqfkkik6gqL9eSml8GeQsA9AjAJwxUirx/5CML2cfhAkAZ9Yd0SLLe8LeG RyyoIqyOSSOFG5uT8S7/4z4tH5OwAsk4ryEd/FY2sUMbDQKI9w+NHfXT6Ohlid/K8sEP a4bU1wOj0Km8sLD/oNhEFB66QWetOY8J0UI9ZVRsseNlM4KqYN3zOs62X2rXwnoDzpuV ppxDPN0E9kW0Jig6NC047XJxuow1BLA9q82n1A6a+2rGx4K7mo8zmNqzaiXZ1mFM6hVN mKzdimwmJLQeEDWAzUm4uMuhyJ3+sWPSoTRdBC75kt8hD7Q7eRl2ewLluIz/SI4WoUlh SCEA== X-Gm-Message-State: ALoCoQlHsMNxcvN3ncfaAFK0gWY3e1c313w1uoJz2SlxVaA+q9i1YSLctRJbhbgZFIKE+vQ6x/GP X-Received: by 10.50.114.4 with SMTP id jc4mr7782988igb.14.1427467860633; Fri, 27 Mar 2015 07:51:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.64.42 with HTTP; Fri, 27 Mar 2015 07:50:40 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A366D1AB5@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A366D0EDE@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A366D1482@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A366D17F0@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A366D1AB5@xmb-rcd-x10.cisco.com> From: Justin Uberti Date: Fri, 27 Mar 2015 09:50:40 -0500 Message-ID: To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=047d7b2e0983c319e905124642bd Archived-At: Cc: Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-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: Fri, 27 Mar 2015 14:51:02 -0000 --047d7b2e0983c319e905124642bd Content-Type: text/plain; charset=UTF-8 Agreed, but I think using AAF in Refresh has confusing semantics, since they are different from Allocate. Restating from my previous message: In ALLOCATE, v4 AAF is forbidden, and v6 AAF means "v4+v6". In REFRESH, v4 AAF means "v4 only", and v6 AAF means "v6 only". Compare this to how RAF could be handled: In ALLOCATE, v4 RAF means "v4 only", and v6 RAF means "v6 only". In REFRESH, v4 RAF means "v4 only", and v6 RAF means "v6 only". On Fri, Mar 27, 2015 at 12:38 AM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > The client includes AAF in Refresh only if dual allocation is successful > which means client when it sends Refresh knows if server supports AAF or > not. > > -Tiru > > > -----Original Message----- > > From: Oleg Moskalenko [mailto:mom040267@gmail.com] > > Sent: Friday, March 27, 2015 10:13 AM > > To: Justin Uberti > > Cc: Tirumaleswar Reddy (tireddy); tram@ietf.org > > Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-01 > > > > On Thu, Mar 26, 2015 at 9:00 PM, Justin Uberti > wrote: > > > > > > > > > I think that REFRESH should work as follows: > > > - REFRESH with no attributes refreshes everything, regardless of > > > allocation type > > > - REFRESH with specific RAF refreshes only the specific allocation if > > > it exists, or otherwise fails > > > - REFRESH with any AAF fails because it is not well-defined > > > > this behaviour is not compatible with older (RFC5766-compliant) servers > that do > > not understand AAF. They will treat option 1 and option 3 as the same > case. > --047d7b2e0983c319e905124642bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agreed, but I think using AAF in Refresh has confusing sem= antics, since they are different from Allocate. Restating from my previous = message:

In ALLOCATE, v4 AAF is forbidden, and v6 AAF means = "v4+v6".
In REFR= ESH, v4 AAF means "v4 only", and v6 AAF means "v6 only"= .

Compare this to how RAF could be handled:

In ALLOCATE, v4 RAF means "v4 only", and= v6 RAF means "v6 only".
In REFRESH,=C2=A0v4 R= AF means "v4 only", and v6 RAF means "v6 only".<= /div>

On Fri, Mar 27, 2015 at 12:38 AM, Tirumaleswar Reddy (tireddy) <= span dir=3D"ltr"><tireddy@cisco.com> wrote:
The client inc= ludes AAF in Refresh only if dual allocation is successful which means clie= nt when it sends Refresh knows if server supports AAF or not.

-Tiru

> -----Original Message-----
> From: Oleg Moskalenko [mailto:m= om040267@gmail.com]
> Sent: Friday, March 27, 2015 10:13 AM
> To: Justin Uberti
> Cc: Tirumaleswar Reddy (tireddy); tra= m@ietf.org
> Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-01
>
> On Thu, Mar 26, 2015 at 9:00 = PM, Justin Uberti <juberti@google.= com> wrote:
> >
> >
> > I think that REFRESH should work as follows:
> > - REFRESH with no attributes refreshes everything, regardless of<= br> > > allocation type
> > - REFRESH with specific RAF refreshes only the specific allocatio= n if
> > it exists, or otherwise fails
> > - REFRESH with any AAF fails because it is not well-defined
>
> this behaviour is not compatible with older (RFC5766-compliant) server= s that do
> not understand AAF. They will treat option 1 and option 3 as the same = case.

--047d7b2e0983c319e905124642bd-- From nobody Fri Mar 27 10:54:05 2015 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 D7E131A8839 for ; Fri, 27 Mar 2015 10:54:04 -0700 (PDT) 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 DlJa3wvZcOhp for ; Fri, 27 Mar 2015 10:53:59 -0700 (PDT) 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 75EDA1A0368 for ; Fri, 27 Mar 2015 10:53:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12334; q=dns/txt; s=iport; t=1427478839; x=1428688439; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bUAWLTzTijzSNhPCb9BkEhOubr6pydCwoPEN1E//47U=; b=mXfyuSxpII+d0DzxFqwNsUOIq4I8j+FCPBpuM7jU4jMSBh93ss2GpEdJ W0Yu+IGwu5P7jqBiLHd27D0rEFZ/KXymOgz8ysie9Mj42yV6r/TO2p5DF 2TWKSIJF3SuUKecY8kAM/UTxgxAFYTQTDyAcjp80/bYFYT3RY/+Oho4YA Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DOBQBdmBVV/51dJa1cgwZSWgSDD79iT4F1AQmFdQIcgRtMAQEBAQEBfYQVAQEEAQEBIEsLEAIBCBgnAwICAh8GCxQRAgQOBYgbAxENsiGUVw2FQQEBAQEBAQEBAQEBAQEBAQEBAQEBAReLKII4D4FPEQE1FwQHCYJfL4EWBY5Jgg6Db4Q0gU2BVYwxhisiggEdgVBvAYEKOX8BAQE X-IronPort-AV: E=Sophos;i="5.11,480,1422921600"; d="scan'208,217";a="136041891" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP; 27 Mar 2015 17:53:58 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t2RHrwUC020981 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Mar 2015 17:53:58 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.40]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Fri, 27 Mar 2015 12:53:57 -0500 From: "Pal Martinsen (palmarti)" To: tram mailing list Thread-Topic: [tram] STUNTrace and PMTUD drafts Thread-Index: AQHQaBWxrJ4SNCovSEOG4EjILFTZnZ0vr5sAgAABygCAAB97gIABIMMA Date: Fri, 27 Mar 2015 17:53:55 +0000 Message-ID: <4DE9CF4B-ACB4-4913-BDA6-9CB6C903F721@cisco.com> References: <55148B10.8020806@acm.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.213.238] Content-Type: multipart/alternative; boundary="_000_4DE9CF4BACB44913BDA69CB6C903F721ciscocom_" MIME-Version: 1.0 Archived-At: Cc: Marc Petit-Huguenin , "Gonzalo Salgueiro \(gsalguei\)" Subject: Re: [tram] STUNTrace and PMTUD drafts 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, 27 Mar 2015 17:54:05 -0000 --_000_4DE9CF4BACB44913BDA69CB6C903F721ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Ky8tMA0KDQpJIHRoaW5rIGl0IHdpbGwgbWFrZSBpdCBlYXNpZXIgZm9yIHRoZSByZWFkZXIgaWYg dGhlIHR3byB3YXMgbWVyZ2VkLiBJIF90aGlua18gdGhlcmUgaXMgYSBsb3Qgb2Ygb3ZlcmxhcHBp bmcgdGhlIGdlbmVyaWMgbWVjaGFuaXNtOyBzZXQgc29tZXRoaW5nIGluIHRoZSBvdXRnb2luZyBw YWNrZXQgcHJlcGFyZSB0byByZWNlaXZlIElDTVApLiBPbmNlIHRoYXQgaXMgZGVzY3JpYmVkIHRo ZSBtdHUgYW5kIHRyYWVjcm91dGUgZnVuY3Rpb25hbGl0eSBjYW4gYmUgZGVzY3JpYmVkIGluIGZh aXJseSBzbWFsbCBzZWN0aW9ucy4NCg0KSSB3aWxsIG1ha2UgYW4gYXR0ZW1wdCB0byBtZXJnZSB0 aGVtIGFuZCBzZWUgaG93IHRoYXQgbG9va3MuDQoNCi4tLg0KUMOlbC1FcmlrDQoNCg0KT24gMjYg TWFyIDIwMTUsIGF0IDE5OjQwLCBTdWhhcyBOYW5kYWt1bWFyIDxzdWhhc2lldGZAZ21haWwuY29t PG1haWx0bzpzdWhhc2lldGZAZ21haWwuY29tPj4gd3JvdGU6DQoNCisxDQoNCk9uIFRodSwgTWFy IDI2LCAyMDE1IGF0IDU6NDcgUE0sIEp1c3RpbiBVYmVydGkgPGp1YmVydGlAZ29vZ2xlLmNvbTxt YWlsdG86anViZXJ0aUBnb29nbGUuY29tPj4gd3JvdGU6DQorMQ0KDQpPbiBUaHUsIE1hciAyNiwg MjAxNSBhdCA1OjQxIFBNLCBNYXJjIFBldGl0LUh1Z3VlbmluIDxwZXRpdGh1Z0BhY20ub3JnPG1h aWx0bzpwZXRpdGh1Z0BhY20ub3JnPj4gd3JvdGU6DQotLS0tLUJFR0lOIFBHUCBTSUdORUQgTUVT U0FHRS0tLS0tDQpIYXNoOiBTSEEyNTYNCg0KT24gMDMvMjYvMjAxNSAwNTozOSBQTSwgR29uemFs byBTYWxndWVpcm8gKGdzYWxndWVpKSB3cm90ZToNCj4gVFJBTXN0ZXJzIC0NCj4NCj4gQmFzZWQg b24gdGhlIGRpc2N1c3Npb24gKGR1cmluZyBhbmQgYWZ0ZXIpIHRoZSBmaW5hbCBwcmVzZW50YXRp b24gb24NCj4gU1RVTlRyYWNlIGl0IGlzIGNsZWFyIGFsaWdubWVudCBhbmQgb3ZlcmxhcCBiZXR3 ZWVuIFNUVU5UcmFjZSBhbmQgdGhlDQo+IFBNVFVEIGRyYWZ0DQo+IChkcmFmdC1wZXRpdGh1Z3Vl bmluLXRyYW0tc3R1bi1wbXR1ZDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGV0 aXRodWd1ZW5pbi10cmFtLXN0dW4tcG10dWQtMDA+KS4NCj4gVGhlIFBNVFVEIGRyYWZ0IGlzIHNv bHZpbmcgYSBicm9hZGVyIHByb2JsZW0sIHdoZXJlYXMgU1RVTlRyYWNlIGlzDQo+IHByYWN0aWNh bGx5IGEgc3BlY2lhbGl6ZWQgdXNlLWNhc2Ugb2YgaXQuICBJIHRoaW5rIHRoZSBiZXN0IHdheSB0 bw0KPiBwcm9jZWVkIHdpdGggdGhlc2UgaXMgdG8gcHJvZ3Jlc3MgdGhlc2UgaW5kZXBlbmRlbnRs eSwgcmVtb3ZlIHRoZQ0KPiBvdmVybGFwIGFuZCBjcm9zcyByZWZlcmVuY2UgZWFjaCBhcHByb3By aWF0ZWx5LiAgRG8gZm9sa3MgYWdyZWUgd2l0aA0KPiB0aGlzIGFwcHJvYWNoPw0KPg0KDQpJIGFn cmVlIHdpdGggdGhhdCBwbGFuLg0KDQotIC0tDQpNYXJjIFBldGl0LUh1Z3VlbmluDQpFbWFpbDog bWFyY0BwZXRpdC1odWd1ZW5pbi5vcmc8bWFpbHRvOm1hcmNAcGV0aXQtaHVndWVuaW4ub3JnPg0K QmxvZzogaHR0cDovL2Jsb2cubWFyYy5wZXRpdC1odWd1ZW5pbi5vcmc8aHR0cDovL2Jsb2cubWFy Yy5wZXRpdC1odWd1ZW5pbi5vcmcvPg0KUHJvZmlsZTogaHR0cDovL3d3dy5saW5rZWRpbi5jb20v aW4vcGV0aXRodWcNCi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tDQpWZXJzaW9uOiBHbnVQ RyB2MQ0KDQppUUljQkFFQkNBQUdCUUpWRklzUUFBb0pFQ25FUlpYV2FuN0VYdmtRQUl0QkdFQXR1 QlBWSWdzaWhXejJ6cW9hDQpNQ1pUVlJ2b3Fyem96TDUyNzQ4SGRQUFZOWXhubTRmbjllZXJDcWxa QzQ1SHQ5dTkrVE04RXhlOHdqN1R6S3ZXDQoyQ2Q1VEFNTzdrckQxK2xPMXdnSkcyVlo2QUhIbzNH YmhyWUJyUGlJUXBocFo3RDJDTUx1K2NIamxzTXdlcTA2DQpQZkZ5cE1ZVVFqOGFVM0lkVlFUUFZz ajNWRVJMT3J6MlBva010UDNpZWRCTzdUVWdlZ3hrL3BRdlJPWDZjcURmDQpRZ0MweTRQN2kyd0Ux ZXFnSXcvd3l0TlFpQmxuVnlTd09pWGtBb1JRZjJLbncrV2owbXlyZVhOcHhRVTZERlFZDQpYVFZS RUE1SE9INmxqY2F0QS83elcwS1NqbTllUW1PUkwvaFV3cXhadXcwWVk1S3RmdnlsMzhMUTZkdk90 SGRKDQpEbWd3VTVpT0o2VXArNXpFUTVlMU1ITjUyVVR5V0FUNFowMVNmK3NFYVpGNmRlMjBKblNR SDgwWHhQNmVWeG05DQpNUERNMUIxNjMxYm1XMGJtQnQ4SUdoZm5Md3FDNVFFbC9BK09mR0dWRWFa NjdUL250UitERVpzcGhNYzlOWUR1DQorblNuUVFrek8wTkw3TUNLZW1hRlc1TGkwWG4wMWE5Lzk3 dStRYzQ3VHRjMEsyc1NsdDlGOSs1cjF5L2RZYUEzDQpOVmpEeEtvSkE3VHg2WFlqVlhpTk1yQXI3 d2R3cWZSaE95ZXN5QVhNTHdZT1IzcmZIOEs5SnM1T1pxbTVmUEx5DQoxODFyMzhic1FDWHY1UnQ2 WFdrbGNCSE1iQzIzNGllNGM4VWxpN3BBell1THVyV1pod1JSdEwxSm85TUVjTEFhDQp5YndIRWt5 UzFXSTU4UUdiVUlzLw0KPTVqVjYNCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdHJhbSBtYWlsaW5n IGxpc3QNCnRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KdHJhbSBtYWlsaW5nIGxpc3QNCnRyYW1AaWV0Zi5v cmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3RyYW0NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KdHJhbSBtYWlsaW5nIGxpc3QNCnRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg0K --_000_4DE9CF4BACB44913BDA69CB6C903F721ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KJiM0MzsvLTANCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgdGhpbmsgaXQgd2lsbCBt YWtlIGl0IGVhc2llciBmb3IgdGhlIHJlYWRlciBpZiB0aGUgdHdvIHdhcyBtZXJnZWQuIEkgX3Ro aW5rXyB0aGVyZSBpcyBhIGxvdCBvZiBvdmVybGFwcGluZyB0aGUgZ2VuZXJpYyBtZWNoYW5pc207 IHNldCBzb21ldGhpbmcgaW4gdGhlIG91dGdvaW5nIHBhY2tldCBwcmVwYXJlIHRvIHJlY2VpdmUg SUNNUCkuIE9uY2UgdGhhdCBpcyBkZXNjcmliZWQgdGhlIG10dSBhbmQgdHJhZWNyb3V0ZSBmdW5j dGlvbmFsaXR5DQogY2FuIGJlIGRlc2NyaWJlZCBpbiBmYWlybHkgc21hbGwgc2VjdGlvbnMuPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5J IHdpbGwgbWFrZSBhbiBhdHRlbXB0IHRvIG1lcmdlIHRoZW0gYW5kIHNlZSBob3cgdGhhdCBsb29r cy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPi4tLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Qw6VsLUVyaWs8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOzwvZGl2Pg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIDI2IE1hciAyMDE1LCBhdCAxOTo0MCwgU3Vo YXMgTmFuZGFrdW1hciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN1aGFzaWV0ZkBnbWFpbC5jb20iIGNs YXNzPSIiPnN1aGFzaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFz cz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9 Imx0ciIgY2xhc3M9IiI+JiM0MzsxPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJy IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFRodSwgTWFyIDI2LCAyMDE1 IGF0IDU6NDcgUE0sIEp1c3RpbiBVYmVydGkgPHNwYW4gZGlyPSJsdHIiIGNsYXNzPSIiPg0KJmx0 OzxhIGhyZWY9Im1haWx0bzpqdWJlcnRpQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFz cz0iIj5qdWJlcnRpQGdvb2dsZS5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44 ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGRp cj0ibHRyIiBjbGFzcz0iIj4mIzQzOzE8L2Rpdj4NCjxkaXYgY2xhc3M9IkhPRW5aYiI+DQo8ZGl2 IGNsYXNzPSJoNSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFRodSwgTWFyIDI2LCAyMDE1IGF0IDU6NDEgUE0sIE1h cmMgUGV0aXQtSHVndWVuaW4gPHNwYW4gZGlyPSJsdHIiIGNsYXNzPSIiPg0KJmx0OzxhIGhyZWY9 Im1haWx0bzpwZXRpdGh1Z0BhY20ub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+cGV0aXRo dWdAYWNtLm9yZzwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90 ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVm dDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCi0tLS0tQkVHSU4gUEdQIFNJR05F RCBNRVNTQUdFLS0tLS08YnIgY2xhc3M9IiI+DQpIYXNoOiBTSEEyNTY8YnIgY2xhc3M9IiI+DQo8 c3BhbiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQpPbiAwMy8yNi8yMDE1IDA1OjM5IFBNLCBHb256 YWxvIFNhbGd1ZWlybyAoZ3NhbGd1ZWkpIHdyb3RlOjxiciBjbGFzcz0iIj4NCiZndDsgVFJBTXN0 ZXJzIC08YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyBCYXNlZCBvbiB0aGUg ZGlzY3Vzc2lvbiAoZHVyaW5nIGFuZCBhZnRlcikgdGhlIGZpbmFsIHByZXNlbnRhdGlvbiBvbjxi ciBjbGFzcz0iIj4NCiZndDsgU1RVTlRyYWNlIGl0IGlzIGNsZWFyIGFsaWdubWVudCBhbmQgb3Zl cmxhcCBiZXR3ZWVuIFNUVU5UcmFjZSBhbmQgdGhlPGJyIGNsYXNzPSIiPg0KJmd0OyBQTVRVRCBk cmFmdDxiciBjbGFzcz0iIj4NCjwvc3Bhbj4mZ3Q7IChkcmFmdC1wZXRpdGh1Z3VlbmluLXRyYW0t c3R1bi1wbXR1ZCZsdDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt cGV0aXRodWd1ZW5pbi10cmFtLXN0dW4tcG10dWQtMDAiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0i Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGV0aXRodWd1ZW5pbi10cmFtLXN0 dW4tcG10dWQtMDA8L2E+Jmd0OykuPGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+Jmd0OyBU aGUgUE1UVUQgZHJhZnQgaXMgc29sdmluZyBhIGJyb2FkZXIgcHJvYmxlbSwgd2hlcmVhcyBTVFVO VHJhY2UgaXM8YnIgY2xhc3M9IiI+DQomZ3Q7IHByYWN0aWNhbGx5IGEgc3BlY2lhbGl6ZWQgdXNl LWNhc2Ugb2YgaXQuJm5ic3A7IEkgdGhpbmsgdGhlIGJlc3Qgd2F5IHRvPGJyIGNsYXNzPSIiPg0K Jmd0OyBwcm9jZWVkIHdpdGggdGhlc2UgaXMgdG8gcHJvZ3Jlc3MgdGhlc2UgaW5kZXBlbmRlbnRs eSwgcmVtb3ZlIHRoZTxiciBjbGFzcz0iIj4NCiZndDsgb3ZlcmxhcCBhbmQgY3Jvc3MgcmVmZXJl bmNlIGVhY2ggYXBwcm9wcmlhdGVseS4mbmJzcDsgRG8gZm9sa3MgYWdyZWUgd2l0aDxiciBjbGFz cz0iIj4NCiZndDsgdGhpcyBhcHByb2FjaD88YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KPC9zcGFuPkkgYWdyZWUgd2l0aCB0aGF0IHBsYW4uPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KLSAtLTxiciBjbGFzcz0iIj4NCk1hcmMgUGV0aXQtSHVndWVu aW48YnIgY2xhc3M9IiI+DQpFbWFpbDogPGEgaHJlZj0ibWFpbHRvOm1hcmNAcGV0aXQtaHVndWVu aW4ub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+bWFyY0BwZXRpdC1odWd1ZW5pbi5vcmc8 L2E+PGJyIGNsYXNzPSIiPg0KQmxvZzogPGEgaHJlZj0iaHR0cDovL2Jsb2cubWFyYy5wZXRpdC1o dWd1ZW5pbi5vcmcvIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cDovL2Jsb2cubWFyYy5w ZXRpdC1odWd1ZW5pbi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KUHJvZmlsZTogPGEgaHJlZj0iaHR0 cDovL3d3dy5saW5rZWRpbi5jb20vaW4vcGV0aXRodWciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0i Ij5odHRwOi8vd3d3LmxpbmtlZGluLmNvbS9pbi9wZXRpdGh1ZzwvYT48YnIgY2xhc3M9IiI+DQot LS0tLUJFR0lOIFBHUCBTSUdOQVRVUkUtLS0tLTxiciBjbGFzcz0iIj4NClZlcnNpb246IEdudVBH IHYxPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KaVFJY0JBRUJDQUFHQlFKVkZJc1FBQW9K RUNuRVJaWFdhbjdFWHZrUUFJdEJHRUF0dUJQVklnc2loV3oyenFvYTxiciBjbGFzcz0iIj4NCk1D WlRWUnZvcXJ6b3pMNTI3NDhIZFBQVk5ZeG5tNGZuOWVlckNxbFpDNDVIdDl1OSYjNDM7VE04RXhl OHdqN1R6S3ZXPGJyIGNsYXNzPSIiPg0KMkNkNVRBTU83a3JEMSYjNDM7bE8xd2dKRzJWWjZBSEhv M0diaHJZQnJQaUlRcGhwWjdEMkNNTHUmIzQzO2NIamxzTXdlcTA2PGJyIGNsYXNzPSIiPg0KUGZG eXBNWVVRajhhVTNJZFZRVFBWc2ozVkVSTE9yejJQb2tNdFAzaWVkQk83VFVnZWd4ay9wUXZST1g2 Y3FEZjxiciBjbGFzcz0iIj4NClFnQzB5NFA3aTJ3RTFlcWdJdy93eXROUWlCbG5WeVN3T2lYa0Fv UlFmMktudyYjNDM7V2owbXlyZVhOcHhRVTZERlFZPGJyIGNsYXNzPSIiPg0KWFRWUkVBNUhPSDZs amNhdEEvN3pXMEtTam05ZVFtT1JML2hVd3F4WnV3MFlZNUt0ZnZ5bDM4TFE2ZHZPdEhkSjxiciBj bGFzcz0iIj4NCkRtZ3dVNWlPSjZVcCYjNDM7NXpFUTVlMU1ITjUyVVR5V0FUNFowMVNmJiM0Mztz RWFaRjZkZTIwSm5TUUg4MFh4UDZlVnhtOTxiciBjbGFzcz0iIj4NCk1QRE0xQjE2MzFibVcwYm1C dDhJR2hmbkx3cUM1UUVsL0EmIzQzO09mR0dWRWFaNjdUL250UiYjNDM7REVac3BoTWM5TllEdTxi ciBjbGFzcz0iIj4NCiYjNDM7blNuUVFrek8wTkw3TUNLZW1hRlc1TGkwWG4wMWE5Lzk3dSYjNDM7 UWM0N1R0YzBLMnNTbHQ5RjkmIzQzOzVyMXkvZFlhQTM8YnIgY2xhc3M9IiI+DQpOVmpEeEtvSkE3 VHg2WFlqVlhpTk1yQXI3d2R3cWZSaE95ZXN5QVhNTHdZT1IzcmZIOEs5SnM1T1pxbTVmUEx5PGJy IGNsYXNzPSIiPg0KMTgxcjM4YnNRQ1h2NVJ0NlhXa2xjQkhNYkMyMzRpZTRjOFVsaTdwQXpZdUx1 cldaaHdSUnRMMUpvOU1FY0xBYTxiciBjbGFzcz0iIj4NCnlid0hFa3lTMVdJNThRR2JVSXMvPGJy IGNsYXNzPSIiPg0KPTVqVjY8YnIgY2xhc3M9IiI+DQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0t LS08YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCnRyYW0gbWFpbGluZyBsaXN0PGJy IGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r IiBjbGFzcz0iIj50cmFtQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbSIgdGFyZ2V0PSJfYmxhbmsiIGNs YXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbTwvYT48YnIg Y2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KdHJhbSBtYWlsaW5nIGxpc3Q8YnIg Y2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgY2xhc3M9IiI+dHJhbUBp ZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3RyYW0iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW08L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIi Pg0KdHJhbSBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86dHJhbUBp ZXRmLm9yZyIgY2xhc3M9IiI+dHJhbUBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW08YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_4DE9CF4BACB44913BDA69CB6C903F721ciscocom_-- From nobody Fri Mar 27 19:08:15 2015 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 613D01A0127 for ; Fri, 27 Mar 2015 19:08:13 -0700 (PDT) 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 leAz-IUS-uWh for ; Fri, 27 Mar 2015 19:08:11 -0700 (PDT) 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 823EB1A0032 for ; Fri, 27 Mar 2015 19:08:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12132; q=dns/txt; s=iport; t=1427508492; x=1428718092; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gCdP98/JU4k5LVlmkpvXBp1+Mtke6uH5070W5R9DfZI=; b=BNy0J8SlWZ9xjBYzynuogbeEFJCQejm0ve4e2AhxBRYFZCQuFocQ7Vdc Z9aJWMLsn2c7d+H8wfw/guBTY057XWc4IFMpYPdZqFHqWcWwNc1UGWuvv J0O+Yul3zKHkEvfG/Blk59JDVCWYTDtAYQAVUHHB02+MnQ2y2IvQ6nIld 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BJBwChDBZV/4UNJK1cgkNDUlwEgw/ABoguAhyBFkwBAQEBAQF9hBQBAQEDASMKTAUHBAIBCA4DBAEBAQodAwICAh8RFAkIAgQOBQiIEwMJCLJqlBINhUoBAQEBAQEBAQEBAQEBAQEBAQEBAQEXiyiCR4IAFhsGAQaCYi+BFgWQV4gjj1OGKyKDbm+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.11,482,1422921600"; d="scan'208,217";a="136153010" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-6.cisco.com with ESMTP; 28 Mar 2015 02:08:11 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t2S28Atx023604 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 28 Mar 2015 02:08:10 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.80]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Fri, 27 Mar 2015 21:08:10 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Justin Uberti Thread-Topic: [tram] Comments on draft-ietf-tram-turnbis-01 Thread-Index: AdBntPY5ANaPCcypQFyW0ZUNvQto2QAWjv+AAAiXOWAAAjWwAAAB0UEQAAqvXoAAAXwhAAAImOLwAAykQQAADRUNgA== Date: Sat, 28 Mar 2015 02:08:09 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A366D2DBC@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A366D0EDE@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A366D1482@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A366D17F0@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A366D1AB5@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.162] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A366D2DBCxmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-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: Sat, 28 Mar 2015 02:08:13 -0000 --_000_913383AAA69FF945B8F946018B75898A366D2DBCxmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSnVzdGluLA0KDQpUaGUgcHJvYmxlbSBpcyBSRkMgNjE1NiBzYXlzIHRoYXQgUkFGIG11c3Qg bm90IGJlIHVzZWQgaW4gUmVmcmVzaCByZXF1ZXN0LCB0aGF0IGlzIG9uZSBvZiB0aGUgcmVhc29u cyBmb3IgdXNpbmcgQUFGIGluIFJlZnJlc2guDQoNCi1UaXJ1DQoNCkZyb206IEp1c3RpbiBVYmVy dGkgW21haWx0bzpqdWJlcnRpQGdvb2dsZS5jb21dDQpTZW50OiBGcmlkYXksIE1hcmNoIDI3LCAy MDE1IDg6MjEgUE0NClRvOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQpDYzogT2xlZyBN b3NrYWxlbmtvOyB0cmFtQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3RyYW1dIENvbW1lbnRzIG9u IGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTAxDQoNCkFncmVlZCwgYnV0IEkgdGhpbmsgdXNpbmcg QUFGIGluIFJlZnJlc2ggaGFzIGNvbmZ1c2luZyBzZW1hbnRpY3MsIHNpbmNlIHRoZXkgYXJlIGRp ZmZlcmVudCBmcm9tIEFsbG9jYXRlLiBSZXN0YXRpbmcgZnJvbSBteSBwcmV2aW91cyBtZXNzYWdl Og0KDQpJbiBBTExPQ0FURSwgdjQgQUFGIGlzIGZvcmJpZGRlbiwgYW5kIHY2IEFBRiBtZWFucyAi djQrdjYiLg0KSW4gUkVGUkVTSCwgdjQgQUFGIG1lYW5zICJ2NCBvbmx5IiwgYW5kIHY2IEFBRiBt ZWFucyAidjYgb25seSIuDQoNCkNvbXBhcmUgdGhpcyB0byBob3cgUkFGIGNvdWxkIGJlIGhhbmRs ZWQ6DQoNCkluIEFMTE9DQVRFLCB2NCBSQUYgbWVhbnMgInY0IG9ubHkiLCBhbmQgdjYgUkFGIG1l YW5zICJ2NiBvbmx5Ii4NCkluIFJFRlJFU0gsIHY0IFJBRiBtZWFucyAidjQgb25seSIsIGFuZCB2 NiBSQUYgbWVhbnMgInY2IG9ubHkiLg0KDQpPbiBGcmksIE1hciAyNywgMjAxNSBhdCAxMjozOCBB TSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSA8dGlyZWRkeUBjaXNjby5jb208bWFpbHRv OnRpcmVkZHlAY2lzY28uY29tPj4gd3JvdGU6DQpUaGUgY2xpZW50IGluY2x1ZGVzIEFBRiBpbiBS ZWZyZXNoIG9ubHkgaWYgZHVhbCBhbGxvY2F0aW9uIGlzIHN1Y2Nlc3NmdWwgd2hpY2ggbWVhbnMg Y2xpZW50IHdoZW4gaXQgc2VuZHMgUmVmcmVzaCBrbm93cyBpZiBzZXJ2ZXIgc3VwcG9ydHMgQUFG IG9yIG5vdC4NCg0KLVRpcnUNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBPbGVnIE1vc2thbGVua28gW21haWx0bzptb20wNDAyNjdAZ21haWwuY29tPG1haWx0bzptb20w NDAyNjdAZ21haWwuY29tPl0NCj4gU2VudDogRnJpZGF5LCBNYXJjaCAyNywgMjAxNSAxMDoxMyBB TQ0KPiBUbzogSnVzdGluIFViZXJ0aQ0KPiBDYzogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5 KTsgdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFt0 cmFtXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0wMQ0KPg0KPiBPbiBUaHUs IE1hciAyNiwgMjAxNSBhdCA5OjAwIFBNLCBKdXN0aW4gVWJlcnRpIDxqdWJlcnRpQGdvb2dsZS5j b208bWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KPiA+DQo+ID4NCj4gPiBJIHRo aW5rIHRoYXQgUkVGUkVTSCBzaG91bGQgd29yayBhcyBmb2xsb3dzOg0KPiA+IC0gUkVGUkVTSCB3 aXRoIG5vIGF0dHJpYnV0ZXMgcmVmcmVzaGVzIGV2ZXJ5dGhpbmcsIHJlZ2FyZGxlc3Mgb2YNCj4g PiBhbGxvY2F0aW9uIHR5cGUNCj4gPiAtIFJFRlJFU0ggd2l0aCBzcGVjaWZpYyBSQUYgcmVmcmVz aGVzIG9ubHkgdGhlIHNwZWNpZmljIGFsbG9jYXRpb24gaWYNCj4gPiBpdCBleGlzdHMsIG9yIG90 aGVyd2lzZSBmYWlscw0KPiA+IC0gUkVGUkVTSCB3aXRoIGFueSBBQUYgZmFpbHMgYmVjYXVzZSBp dCBpcyBub3Qgd2VsbC1kZWZpbmVkDQo+DQo+IHRoaXMgYmVoYXZpb3VyIGlzIG5vdCBjb21wYXRp YmxlIHdpdGggb2xkZXIgKFJGQzU3NjYtY29tcGxpYW50KSBzZXJ2ZXJzIHRoYXQgZG8NCj4gbm90 IHVuZGVyc3RhbmQgQUFGLiBUaGV5IHdpbGwgdHJlYXQgb3B0aW9uIDEgYW5kIG9wdGlvbiAzIGFz IHRoZSBzYW1lIGNhc2UuDQoNCg== --_000_913383AAA69FF945B8F946018B75898A366D2DBCxmbrcdx10ciscoc_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5pbQ0KCXttc28tc3R5bGUtbmFt ZTppbTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5IaSBKdXN0aW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgcHJvYmxlbSBpcyBSRkMg NjE1NiBzYXlzIHRoYXQgUkFGIG11c3Qgbm90IGJlIHVzZWQgaW4gUmVmcmVzaCByZXF1ZXN0LCB0 aGF0IGlzIG9uZSBvZiB0aGUgcmVhc29ucyBmb3IgdXNpbmcgQUFGIGluIFJlZnJlc2guPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4tVGlydTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBK dXN0aW4gVWJlcnRpIFttYWlsdG86anViZXJ0aUBnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8 L2I+IEZyaWRheSwgTWFyY2ggMjcsIDIwMTUgODoyMSBQTTxicj4NCjxiPlRvOjwvYj4gVGlydW1h bGVzd2FyIFJlZGR5ICh0aXJlZGR5KTxicj4NCjxiPkNjOjwvYj4gT2xlZyBNb3NrYWxlbmtvOyB0 cmFtQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHJhbV0gQ29tbWVudHMgb24g ZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWdyZWVkLCBidXQgSSB0aGluayB1c2luZyBBQUYgaW4g UmVmcmVzaCBoYXMgY29uZnVzaW5nIHNlbWFudGljcywgc2luY2UgdGhleSBhcmUgZGlmZmVyZW50 IGZyb20gQWxsb2NhdGUuIFJlc3RhdGluZyBmcm9tIG15IHByZXZpb3VzIG1lc3NhZ2U6PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPkluIEFMTE9DQVRFLCB2NCBBQUYgaXMgZm9yYmlk ZGVuLCBhbmQgdjYgQUFGIG1lYW5zICZxdW90O3Y0JiM0Mzt2NiZxdW90Oy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuNXB0Ij5JbiBSRUZSRVNILCB2NCBBQUYgbWVhbnMgJnF1b3Q7djQgb25s eSZxdW90OywgYW5kIHY2IEFBRiBtZWFucyAmcXVvdDt2NiBvbmx5JnF1b3Q7LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS41cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41 cHQiPkNvbXBhcmUgdGhpcyB0byBob3cgUkFGIGNvdWxkIGJlIGhhbmRsZWQ6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjVwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVw dCI+SW4gQUxMT0NBVEUsIHY0IFJBRiBtZWFucyAmcXVvdDt2NCBvbmx5JnF1b3Q7LCBhbmQgdjYg UkFGIG1lYW5zICZxdW90O3Y2IG9ubHkmcXVvdDsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjVwdCI+SW4gUkVGUkVTSCwmbmJzcDt2NCBSQUYgbWVhbnMgJnF1b3Q7djQgb25seSZxdW90Oywg YW5kIHY2IFJBRiBtZWFucyAmcXVvdDt2NiBvbmx5JnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS41cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgTWFyIDI3LCAyMDE1IGF0IDEyOjM4IEFNLCBU aXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpICZsdDs8YSBocmVmPSJtYWlsdG86dGlyZWRkeUBj aXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj50aXJlZGR5QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGNsaWVudCBpbmNsdWRl cyBBQUYgaW4gUmVmcmVzaCBvbmx5IGlmIGR1YWwgYWxsb2NhdGlvbiBpcyBzdWNjZXNzZnVsIHdo aWNoIG1lYW5zIGNsaWVudCB3aGVuIGl0IHNlbmRzIFJlZnJlc2gga25vd3MgaWYgc2VydmVyIHN1 cHBvcnRzIEFBRiBvciBub3QuPGJyPg0KPGJyPg0KLVRpcnU8YnI+DQo8YnI+DQo8c3BhbiBjbGFz cz0iaW0iPiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L3NwYW4+PGJyPg0KPHNwYW4g Y2xhc3M9ImltIj4mZ3Q7IEZyb206IE9sZWcgTW9za2FsZW5rbyBbbWFpbHRvOjxhIGhyZWY9Im1h aWx0bzptb20wNDAyNjdAZ21haWwuY29tIj5tb20wNDAyNjdAZ21haWwuY29tPC9hPl08L3NwYW4+ PGJyPg0KPHNwYW4gY2xhc3M9ImltIj4mZ3Q7IFNlbnQ6IEZyaWRheSwgTWFyY2ggMjcsIDIwMTUg MTA6MTMgQU08L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImltIj4mZ3Q7IFRvOiBKdXN0aW4gVWJl cnRpPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJpbSI+Jmd0OyBDYzogVGlydW1hbGVzd2FyIFJl ZGR5ICh0aXJlZGR5KTsgPGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciPg0KdHJhbUBpZXRm Lm9yZzwvYT48L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImltIj4mZ3Q7IFN1YmplY3Q6IFJlOiBb dHJhbV0gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDE8L3NwYW4+PGJyPg0K PHNwYW4gY2xhc3M9ImltIj4mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IE9uIFRodSwgTWFyIDI2LCAyMDE1IGF0IDk6MDAg UE0sIEp1c3RpbiBVYmVydGkgJmx0OzxhIGhyZWY9Im1haWx0bzpqdWJlcnRpQGdvb2dsZS5jb20i Pmp1YmVydGlAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyBJIHRoaW5rIHRoYXQgUkVGUkVTSCBzaG91bGQgd29yayBh cyBmb2xsb3dzOjxicj4NCiZndDsgJmd0OyAtIFJFRlJFU0ggd2l0aCBubyBhdHRyaWJ1dGVzIHJl ZnJlc2hlcyBldmVyeXRoaW5nLCByZWdhcmRsZXNzIG9mPGJyPg0KJmd0OyAmZ3Q7IGFsbG9jYXRp b24gdHlwZTxicj4NCiZndDsgJmd0OyAtIFJFRlJFU0ggd2l0aCBzcGVjaWZpYyBSQUYgcmVmcmVz aGVzIG9ubHkgdGhlIHNwZWNpZmljIGFsbG9jYXRpb24gaWY8YnI+DQomZ3Q7ICZndDsgaXQgZXhp c3RzLCBvciBvdGhlcndpc2UgZmFpbHM8YnI+DQomZ3Q7ICZndDsgLSBSRUZSRVNIIHdpdGggYW55 IEFBRiBmYWlscyBiZWNhdXNlIGl0IGlzIG5vdCB3ZWxsLWRlZmluZWQ8YnI+DQomZ3Q7PGJyPg0K Jmd0OyB0aGlzIGJlaGF2aW91ciBpcyBub3QgY29tcGF0aWJsZSB3aXRoIG9sZGVyIChSRkM1NzY2 LWNvbXBsaWFudCkgc2VydmVycyB0aGF0IGRvPGJyPg0KJmd0OyBub3QgdW5kZXJzdGFuZCBBQUYu IFRoZXkgd2lsbCB0cmVhdCBvcHRpb24gMSBhbmQgb3B0aW9uIDMgYXMgdGhlIHNhbWUgY2FzZS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_913383AAA69FF945B8F946018B75898A366D2DBCxmbrcdx10ciscoc_-- From nobody Sat Mar 28 17:47:24 2015 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 70CAA1A037C for ; Sat, 28 Mar 2015 17:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.511 X-Spam-Level: X-Spam-Status: No, score=0.511 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 hiRs_iH0CdRL for ; Sat, 28 Mar 2015 17:47:22 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16DAD1A01F0 for ; Sat, 28 Mar 2015 17:47:22 -0700 (PDT) Received: by ignm3 with SMTP id m3so52306308ign.0 for ; Sat, 28 Mar 2015 17:47:21 -0700 (PDT) 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=62j46FiwNwGFq/g6tMcQrxZwQ9SuPihszOtVnT89cgU=; b=i/hpdvjbyYs+OUsifIG5oPUGTjOZFaCUGgAqyUd0jMF//D52ElzIM0i2sL673ezqFa 4s7gGCLSfo0sVnTCPkbrxf217HXVc47ObuIzGY6yeyM5sSVSQ2PgyjG8K5ZHPTi2pr+2 wmtpzJ5zidzvxDkzRcMKeAHKe26UvEBjvv4FrtXmW0l0G/RpDYeiHdOMyJJ0elvX8XZn PLtZru3rOqTPSKHQOOD9CZSDX4SN1lVuCuufk2tUnOTIkwN+4ceX52xDJqmGCOAEsdFU W2PbDaI6mqkQGdK0TszkHiHrztLiO5sYegdT8YuA+mhPJndSqBuHK1wND/ehwCtQ8/mZ T4hg== 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=62j46FiwNwGFq/g6tMcQrxZwQ9SuPihszOtVnT89cgU=; b=I+4oHCxBoqf7GfS+yWGir0rM3wevYY2WhqGV8GGP93CswIbHjI7C5nJ39aBDJzojuf alkjLmujJ2p02J2EYT/M/ze59rv+G7ktRknaUJ81HoFMsj+4A5C8eAkVKqkUVzo8SBlf ZhRrPxPzEYn+NxjqO2kQuE1PnROLLFlsDlR5zibfYFcqmeDxy/vWzGsObgi5VZInzf4Z fVF+b1pjoW9n3ekGfoQOJLa/VIyeOMBWi3OwBcvNYvhI9ZwnXN20Wd4o9+DmKg+9/a67 H7bzk2+kkoq28ERg8gvuQ6XTDPRBY2uNIZUaxtXtM536c9B01sIkDxn8BTCQ14E4ggPu suuQ== X-Gm-Message-State: ALoCoQkfbRC7lN96KqSoIga76sfo7aizWpS1SFHHq/5wLTgj2LVEb33RkOOSf1e6frWMyw+imgR8 X-Received: by 10.50.79.163 with SMTP id k3mr8269224igx.30.1427590041409; Sat, 28 Mar 2015 17:47:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.64.42 with HTTP; Sat, 28 Mar 2015 17:47:01 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A366D2DBC@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A366D0EDE@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A366D1482@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A366D17F0@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A366D1AB5@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A366D2DBC@xmb-rcd-x10.cisco.com> From: Justin Uberti Date: Sat, 28 Mar 2015 17:47:01 -0700 Message-ID: To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=089e011840384dc7b8051262b5ab Archived-At: Cc: Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-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: Sun, 29 Mar 2015 00:47:23 -0000 --089e011840384dc7b8051262b5ab Content-Type: text/plain; charset=UTF-8 We are obsoleting 6156, so we can say whatever we want - especially in the case of dual allocations. On Fri, Mar 27, 2015 at 7:08 PM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > Hi Justin, > > > > The problem is RFC 6156 says that RAF must not be used in Refresh request, > that is one of the reasons for using AAF in Refresh. > > > > -Tiru > > > > *From:* Justin Uberti [mailto:juberti@google.com] > *Sent:* Friday, March 27, 2015 8:21 PM > *To:* Tirumaleswar Reddy (tireddy) > *Cc:* Oleg Moskalenko; tram@ietf.org > > *Subject:* Re: [tram] Comments on draft-ietf-tram-turnbis-01 > > > > Agreed, but I think using AAF in Refresh has confusing semantics, since > they are different from Allocate. Restating from my previous message: > > > > In ALLOCATE, v4 AAF is forbidden, and v6 AAF means "v4+v6". > > In REFRESH, v4 AAF means "v4 only", and v6 AAF means "v6 only". > > > > Compare this to how RAF could be handled: > > > > In ALLOCATE, v4 RAF means "v4 only", and v6 RAF means "v6 only". > > In REFRESH, v4 RAF means "v4 only", and v6 RAF means "v6 only". > > > > On Fri, Mar 27, 2015 at 12:38 AM, Tirumaleswar Reddy (tireddy) < > tireddy@cisco.com> wrote: > > The client includes AAF in Refresh only if dual allocation is successful > which means client when it sends Refresh knows if server supports AAF or > not. > > -Tiru > > > -----Original Message----- > > From: Oleg Moskalenko [mailto:mom040267@gmail.com] > > Sent: Friday, March 27, 2015 10:13 AM > > To: Justin Uberti > > Cc: Tirumaleswar Reddy (tireddy); tram@ietf.org > > Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-01 > > > > > On Thu, Mar 26, 2015 at 9:00 PM, Justin Uberti > wrote: > > > > > > > > > I think that REFRESH should work as follows: > > > - REFRESH with no attributes refreshes everything, regardless of > > > allocation type > > > - REFRESH with specific RAF refreshes only the specific allocation if > > > it exists, or otherwise fails > > > - REFRESH with any AAF fails because it is not well-defined > > > > this behaviour is not compatible with older (RFC5766-compliant) servers > that do > > not understand AAF. They will treat option 1 and option 3 as the same > case. > > > --089e011840384dc7b8051262b5ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We are obsoleting 6156, so we can say whatever we want - e= specially in the case of dual allocations.
On Fri, Mar 27, 2015 at 7:08 PM, Tirumaleswar = Reddy (tireddy) <tireddy@cisco.com> wrote:

Hi Justin,<= /span>

=C2=A0

The problem is RFC 6156 s= ays that RAF must not be used in Refresh request, that is one of the reason= s for using AAF in Refresh.

=C2=A0

-Tiru

=C2=A0

From: Justin U= berti [mailto:juber= ti@google.com]
Sent: Friday, March 27, 2015 8:21 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Oleg Moskalenko; tram@ietf.org


Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-01=

=C2=A0

Agreed, but I think using AAF in Refresh has confusi= ng semantics, since they are different from Allocate. Restating from my pre= vious message:

=C2=A0

In ALLOCATE, v4 AAF = is forbidden, and v6 AAF means "v4+v6".

In REFRESH, v4 AAF m= eans "v4 only", and v6 AAF means "v6 only".

=C2=A0=

Compare this to how = RAF could be handled:

=C2=A0=

In ALLOCATE, v4 RAF = means "v4 only", and v6 RAF means "v6 only".<= /u>

In REFRESH,=C2=A0v4 = RAF means "v4 only", and v6 RAF means "v6 only".=

=C2=A0=

On Fri, Mar 27, 2015 at 12:38 AM, Tirumaleswar Reddy= (tireddy) <tired= dy@cisco.com> wrote:

The client includes AAF in Refresh only if dual allo= cation is successful which means client when it sends Refresh knows if serv= er supports AAF or not.

-Tiru

> -----Original Message-----
> From: Oleg Moskalenko [mailto:mom040267@gmail.com]
> Sent: Friday, March 27, 2015 10:13 AM
> To: Justin Uberti
> Cc: Tirumaleswar Reddy (tireddy); tram@ietf.org
> Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-01
>

> On Thu, Mar 26, 2015 at 9:00 PM, Justin Uberti = <juberti@google.= com> wrote:
> >
> >
> > I think that REFRESH should work as follows:
> > - REFRESH with no attributes refreshes everything, regardless of<= br> > > allocation type
> > - REFRESH with specific RAF refreshes only the specific allocatio= n if
> > it exists, or otherwise fails
> > - REFRESH with any AAF fails because it is not well-defined
>
> this behaviour is not compatible with older (RFC5766-compliant) server= s that do
> not understand AAF. They will treat option 1 and option 3 as the same = case.

=C2=A0


--089e011840384dc7b8051262b5ab-- From nobody Sat Mar 28 17:52:02 2015 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 1B2261A90BF for ; Sat, 28 Mar 2015 17:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YXDPJctiNkXw for ; Sat, 28 Mar 2015 17:52:00 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F84D1A90BE for ; Sat, 28 Mar 2015 17:51:59 -0700 (PDT) Received: by igcau2 with SMTP id au2so52196969igc.1 for ; Sat, 28 Mar 2015 17:51:59 -0700 (PDT) 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=OzxhPJDc/q2sXIw0/IeLMY0P00GxCi3osL7CNTKSYqk=; b=EklrPV/7Sg7Jbdes065+RN2uruHi/9BgcdsC9LF+ZU0TVywMcNrz7K/RPHCsCMMngd gUYsRWQ/HpwwrUpOFnwycJn6tob/4xwoACZZXXI/KgDK6Hdi6oQjSgkX+Mx2WhMj3mrX cOBN7EJLxbOrZW17XYJSsjxtqwZI0ZppAhk796S9iLV7sYe5hVWR5bjROJGfE12xBq0V FL9IZ2EMOkXUPB7SQcLS/V2U6PftAzIdfAB2CQ8RIHbsyvhAW3FgwY4QIZjtv462LvGt Jd0NVsqQy0EWpDQLm7MbREsxjWfjF2TZorCVg9Ai29ruNrzMrX+j7vnliqgA5kwxBEm4 UKQA== 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=OzxhPJDc/q2sXIw0/IeLMY0P00GxCi3osL7CNTKSYqk=; b=CQxO3mgMuCGs1GEugoxiylF4R0I6kLpVzaO/rZG9S/zBqhs9hQHQNF8RTEOnFHVUDa v9ROIot3vsUs2AWy/Rb2JpoF2TjpwrOIfjHXWMl01do5ukoLByAGkXS5VREZAIknrCuf o5hIIHgQ4Bu8sGCuaKGk/HzynsPMpGinB9ok/sI8yoFEhyMcpardcslWEhG/4f4Z0xB/ UPnxX/XNjt4jtgyvpaPbC0FeSHWyBGEXX9FeZXGDFYCuZUefd9Dz4Y1uCc6t4AIjk6Gi fbm/nFN8ZZozJXfDx8R2J1Mc7Z26Vjs6lx/FiVpf4BfbwIrwQOO1j3pJaNvDTrV4q0GE NAmw== X-Gm-Message-State: ALoCoQkwvtjJzq1NW51/ApGq1lVSk8EDKm01h/a3gt8uUN9tnS68Qe2FoLfsURz2LaT3MUxbD4ZK X-Received: by 10.42.119.202 with SMTP id c10mr53264704icr.4.1427590319333; Sat, 28 Mar 2015 17:51:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.64.42 with HTTP; Sat, 28 Mar 2015 17:51:39 -0700 (PDT) In-Reply-To: <55155CA7.3050403@jive.com> References: <55155CA7.3050403@jive.com> From: Justin Uberti Date: Sat, 28 Mar 2015 17:51:39 -0700 Message-ID: To: Simon Perreault Content-Type: multipart/alternative; boundary=90e6ba61465ade8a57051262c5c7 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Adoption of draft-reddy-tram-stun-path-data-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: Sun, 29 Mar 2015 00:52:01 -0000 --90e6ba61465ade8a57051262c5c7 Content-Type: text/plain; charset=UTF-8 I support the adoption of this draft. On Fri, Mar 27, 2015 at 6:35 AM, Simon Perreault wrote: > TRAMsters, > > This is to confirm the adoption of draft-reddy-tram-stun-path-data-01 as > a working group draft. If anyone is opposed, now is a good time to > explain why. > > Simon & Gonzalo > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --90e6ba61465ade8a57051262c5c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support the adoption of this draft.

On Fri, Mar 27, 2015 at 6:35 AM,= Simon Perreault <sperreault@jive.com> wrote:
TRAMsters,

This is to confirm the adoption of draft-reddy-tram-stun-path-data-01 as a working group draft. If anyone is opposed, now is a good time to
explain why.

Simon & Gonzalo

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

--90e6ba61465ade8a57051262c5c7-- From nobody Sun Mar 29 21:35:45 2015 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 A140F1A8FD3 for ; Sun, 29 Mar 2015 21:35:43 -0700 (PDT) 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 lLQUW6XUwMnE for ; Sun, 29 Mar 2015 21:35:42 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A7191A8FD2 for ; Sun, 29 Mar 2015 21:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=587; q=dns/txt; s=iport; t=1427690142; x=1428899742; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=g3KLqi+Y1U+Pz4XHwYvoIVf4v6IoKEFMV1qQ109xfus=; b=TyQr7FAilz4IDQJApvZEid9HvLGRDT3/OEgqnn3OXihdsZvLEj096jzK 6E6wZLtAsvWmWAu5dW90Qc1OVcZBpbGz/ZKiixqY42iHjguAGdi2ldQ4o RStaPSIueu6X9oQydRi8a573aiiNA/8i95fo110HQjbQsFB5ha4zp71lp 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AOBQCb0RhV/4gNJK1cgwZSXATFIwqFcwKBKUwBAQEBAQF9hBQBAQEEAQEBNzQXBAIBCA4DAwECHxAnCx0IAgQBEogvDck8AQEBAQEBAQEBAQEBAQEBAQEBARUEiymEfwaEJwWQXIl0lDUig25vgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,491,1422921600"; d="scan'208";a="407595292" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-7.cisco.com with ESMTP; 30 Mar 2015 04:35:41 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t2U4Zfxs007346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Mar 2015 04:35:41 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.172]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Sun, 29 Mar 2015 23:35:41 -0500 From: "Ram Mohan R (rmohanr)" To: Simon Perreault , "tram@ietf.org" Thread-Topic: [tram] Adoption of draft-reddy-tram-stun-path-data-01 Thread-Index: AQHQaqL54Y4vs+i4kU+MtSC501VEbA== Date: Mon, 30 Mar 2015 04:35:40 +0000 Message-ID: References: <55155CA7.3050403@jive.com> In-Reply-To: <55155CA7.3050403@jive.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [173.39.64.101] Content-Type: text/plain; charset="us-ascii" Content-ID: <0C65E3B9910A4446B019D4CF0F001872@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tram] Adoption of draft-reddy-tram-stun-path-data-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: Mon, 30 Mar 2015 04:35:43 -0000 I support adoption of this draft. Ram -----Original Message----- From: Simon Perreault Date: Friday, 27 March 2015 7:05 pm To: "tram@ietf.org" Subject: [tram] Adoption of draft-reddy-tram-stun-path-data-01 >TRAMsters, > >This is to confirm the adoption of draft-reddy-tram-stun-path-data-01 as >a working group draft. If anyone is opposed, now is a good time to >explain why. > >Simon & Gonzalo > >_______________________________________________ >tram mailing list >tram@ietf.org >https://www.ietf.org/mailman/listinfo/tram From nobody Sun Mar 29 23:44:31 2015 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 43EC61A90D7 for ; Sun, 29 Mar 2015 23:44:30 -0700 (PDT) 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 H4Jf9ngXZkDJ for ; Sun, 29 Mar 2015 23:44:28 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 080ED1A90D2 for ; Sun, 29 Mar 2015 23:44:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25334; q=dns/txt; s=iport; t=1427697868; x=1428907468; h=from:to:cc:subject:date:message-id:mime-version; bh=wPaJ0lVc3Gno3xZ6QCaqmWQ6Xu36dAJap8VvZii9V0o=; b=H4kMkPj2kHA28Zik4p0M0NSF1BNDb1axOEzRw5g1aL8lhDOW0/ZGFZJL z9x42/Otz56yXw2RshH5KJ25pgMjZk6RxBzvKhKmYPfhuCFsf/V6K9fF5 hsME5ByQ3GtYVa3pX6m95axG+z7nmUeS4mCmZ1DWLjEc9dea4R/2aAOuI w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AtCABM8BhV/5hdJa1cgkNDUlwEgw+/Y4guAhyBD0wBAQEBAQF9hBQBAQEDASMKTAUHBgEIDgMEAQEBCh0DAgQfERQJCQEEDgUIiBMDCQiwd5J5DYVKAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4spgkeCABYbBgeCYi+BFgWQXIgnj1eGKyKDbm+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.11,492,1422921600"; d="scan'208,217";a="136527441" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-5.cisco.com with ESMTP; 30 Mar 2015 06:44:27 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t2U6iRrr008222 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Mar 2015 06:44:27 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.175]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Mon, 30 Mar 2015 01:44:27 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Justin Uberti Thread-Topic: [tram] Comments on draft-ietf-tram-turnbis-01 Thread-Index: AdBqtO8LEmxHurQaR+CZrwc163VgbA== Date: Mon, 30 Mar 2015 06:44:26 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A411F810E@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.47.2] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A411F810Exmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-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: Mon, 30 Mar 2015 06:44:30 -0000 --_000_913383AAA69FF945B8F946018B75898A411F810Exmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V29ya3MgZm9yIG1lLiBTdW1tYXJpemluZyBsaXN0IG9mIGNoYW5nZXMgZGlzY3Vzc2VkOg0KDQox KSBUaGVyZSBpcyBubyB1c2Ugb2YgYWRkcmVzcyBmYW1pbHkgYXR0cmlidXRlIGluIEFBRiBhbmQg SSBndWVzcyBpdCBjYW4gYmUgcmVtb3ZlZDsgSW5zdGVhZCBvZiBBQUYgd2UgY2FuIHByb2JhYmx5 IGNhbGwgaWYgRFVBTC1TVEFDSy1BRERSRVNTLUZBTUlMWS4NCg0KMikNCmEpIFJFRlJFU0ggd2l0 aCBubyBhdHRyaWJ1dGVzIHJlZnJlc2hlcyBldmVyeXRoaW5nLCByZWdhcmRsZXNzIG9mIGFsbG9j YXRpb24gdHlwZS4NCmIpIFJFRlJFU0ggd2l0aCBzcGVjaWZpYyBSQUYgcmVmcmVzaGVzIG9ubHkg dGhlIHNwZWNpZmljIGFsbG9jYXRpb24gaWYgaXQgZXhpc3RzLCBvciBvdGhlcndpc2UgZmFpbHMN CmMpIFJFRlJFU0ggd2l0aCBSQUYgY2FuIGJlIHVzZWQgd2l0aCBvdXIgd2l0aG91dCBkdWFsIHN0 YWNrIGFsbG9jYXRpb24gYW5kIGRlcHJlY2F0ZXMgdGhlIGJlaGF2aW9yIGluIFJGQyA2MTU2Lg0K DQozKUNoYW5nZSB0aGUgZm9ybWF0IG9mIEFERFJFU1MtRVJST1ItQ09ERSB0bw0KDQoNCiAgICAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rDQoNCiAgICAgIHwgIEFkZHJlc3MgRmFtaWx5ICAgICAgICAgICAgICAgIHwgIFJz dmQgIHxDbGFzc3wgICAgIE51bWJlciAgICB8DQoNCiAgICAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCiAgICAgIHwg ICAgICBSZWFzb24gUGhyYXNlICh2YXJpYWJsZSkgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIC4uDQoNCiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCjQpUmVtb3ZlIG11bHRpLWFkZHJlc3Mgc3VwcG9y dCB0byBDaGFubmVsQmluZCByZXF1ZXN0Lg0KDQotVGlydQ0KDQpGcm9tOiBKdXN0aW4gVWJlcnRp IFttYWlsdG86anViZXJ0aUBnb29nbGUuY29tXQ0KU2VudDogU3VuZGF5LCBNYXJjaCAyOSwgMjAx NSA2OjE3IEFNDQpUbzogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KQ0KQ2M6IE9sZWcgTW9z a2FsZW5rbzsgdHJhbUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt0cmFtXSBDb21tZW50cyBvbiBk cmFmdC1pZXRmLXRyYW0tdHVybmJpcy0wMQ0KDQpXZSBhcmUgb2Jzb2xldGluZyA2MTU2LCBzbyB3 ZSBjYW4gc2F5IHdoYXRldmVyIHdlIHdhbnQgLSBlc3BlY2lhbGx5IGluIHRoZSBjYXNlIG9mIGR1 YWwgYWxsb2NhdGlvbnMuDQoNCk9uIEZyaSwgTWFyIDI3LCAyMDE1IGF0IDc6MDggUE0sIFRpcnVt YWxlc3dhciBSZWRkeSAodGlyZWRkeSkgPHRpcmVkZHlAY2lzY28uY29tPG1haWx0bzp0aXJlZGR5 QGNpc2NvLmNvbT4+IHdyb3RlOg0KSGkgSnVzdGluLA0KDQpUaGUgcHJvYmxlbSBpcyBSRkMgNjE1 NiBzYXlzIHRoYXQgUkFGIG11c3Qgbm90IGJlIHVzZWQgaW4gUmVmcmVzaCByZXF1ZXN0LCB0aGF0 IGlzIG9uZSBvZiB0aGUgcmVhc29ucyBmb3IgdXNpbmcgQUFGIGluIFJlZnJlc2guDQoNCi1UaXJ1 DQoNCkZyb206IEp1c3RpbiBVYmVydGkgW21haWx0bzpqdWJlcnRpQGdvb2dsZS5jb208bWFpbHRv Omp1YmVydGlAZ29vZ2xlLmNvbT5dDQpTZW50OiBGcmlkYXksIE1hcmNoIDI3LCAyMDE1IDg6MjEg UE0NClRvOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQpDYzogT2xlZyBNb3NrYWxlbmtv OyB0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW3Ry YW1dIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTAxDQoNCkFncmVlZCwgYnV0 IEkgdGhpbmsgdXNpbmcgQUFGIGluIFJlZnJlc2ggaGFzIGNvbmZ1c2luZyBzZW1hbnRpY3MsIHNp bmNlIHRoZXkgYXJlIGRpZmZlcmVudCBmcm9tIEFsbG9jYXRlLiBSZXN0YXRpbmcgZnJvbSBteSBw cmV2aW91cyBtZXNzYWdlOg0KDQpJbiBBTExPQ0FURSwgdjQgQUFGIGlzIGZvcmJpZGRlbiwgYW5k IHY2IEFBRiBtZWFucyAidjQrdjYiLg0KSW4gUkVGUkVTSCwgdjQgQUFGIG1lYW5zICJ2NCBvbmx5 IiwgYW5kIHY2IEFBRiBtZWFucyAidjYgb25seSIuDQoNCkNvbXBhcmUgdGhpcyB0byBob3cgUkFG IGNvdWxkIGJlIGhhbmRsZWQ6DQoNCkluIEFMTE9DQVRFLCB2NCBSQUYgbWVhbnMgInY0IG9ubHki LCBhbmQgdjYgUkFGIG1lYW5zICJ2NiBvbmx5Ii4NCkluIFJFRlJFU0gsIHY0IFJBRiBtZWFucyAi djQgb25seSIsIGFuZCB2NiBSQUYgbWVhbnMgInY2IG9ubHkiLg0KDQpPbiBGcmksIE1hciAyNywg MjAxNSBhdCAxMjozOCBBTSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSA8dGlyZWRkeUBj aXNjby5jb208bWFpbHRvOnRpcmVkZHlAY2lzY28uY29tPj4gd3JvdGU6DQpUaGUgY2xpZW50IGlu Y2x1ZGVzIEFBRiBpbiBSZWZyZXNoIG9ubHkgaWYgZHVhbCBhbGxvY2F0aW9uIGlzIHN1Y2Nlc3Nm dWwgd2hpY2ggbWVhbnMgY2xpZW50IHdoZW4gaXQgc2VuZHMgUmVmcmVzaCBrbm93cyBpZiBzZXJ2 ZXIgc3VwcG9ydHMgQUFGIG9yIG5vdC4NCg0KLVRpcnUNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBPbGVnIE1vc2thbGVua28gW21haWx0bzptb20wNDAyNjdAZ21haWwu Y29tPG1haWx0bzptb20wNDAyNjdAZ21haWwuY29tPl0NCj4gU2VudDogRnJpZGF5LCBNYXJjaCAy NywgMjAxNSAxMDoxMyBBTQ0KPiBUbzogSnVzdGluIFViZXJ0aQ0KPiBDYzogVGlydW1hbGVzd2Fy IFJlZGR5ICh0aXJlZGR5KTsgdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz4NCj4g U3ViamVjdDogUmU6IFt0cmFtXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0w MQ0KPg0KPiBPbiBUaHUsIE1hciAyNiwgMjAxNSBhdCA5OjAwIFBNLCBKdXN0aW4gVWJlcnRpIDxq dWJlcnRpQGdvb2dsZS5jb208bWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KPiA+ DQo+ID4NCj4gPiBJIHRoaW5rIHRoYXQgUkVGUkVTSCBzaG91bGQgd29yayBhcyBmb2xsb3dzOg0K PiA+IC0gUkVGUkVTSCB3aXRoIG5vIGF0dHJpYnV0ZXMgcmVmcmVzaGVzIGV2ZXJ5dGhpbmcsIHJl Z2FyZGxlc3Mgb2YNCj4gPiBhbGxvY2F0aW9uIHR5cGUNCj4gPiAtIFJFRlJFU0ggd2l0aCBzcGVj aWZpYyBSQUYgcmVmcmVzaGVzIG9ubHkgdGhlIHNwZWNpZmljIGFsbG9jYXRpb24gaWYNCj4gPiBp dCBleGlzdHMsIG9yIG90aGVyd2lzZSBmYWlscw0KPiA+IC0gUkVGUkVTSCB3aXRoIGFueSBBQUYg ZmFpbHMgYmVjYXVzZSBpdCBpcyBub3Qgd2VsbC1kZWZpbmVkDQo+DQo+IHRoaXMgYmVoYXZpb3Vy IGlzIG5vdCBjb21wYXRpYmxlIHdpdGggb2xkZXIgKFJGQzU3NjYtY29tcGxpYW50KSBzZXJ2ZXJz IHRoYXQgZG8NCj4gbm90IHVuZGVyc3RhbmQgQUFGLiBUaGV5IHdpbGwgdHJlYXQgb3B0aW9uIDEg YW5kIG9wdGlvbiAzIGFzIHRoZSBzYW1lIGNhc2UuDQoNCg0K --_000_913383AAA69FF945B8F946018B75898A411F810Exmbrcdx10ciscoc_ 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 LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJhZ3Jh cGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHls ZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1h cmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V29ya3MgZm9yIG1lLiBTdW1tYXJpemlu ZyBsaXN0IG9mIGNoYW5nZXMgZGlzY3Vzc2VkOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+MSkgVGhlcmUgaXMgbm8gdXNl IG9mIGFkZHJlc3MgZmFtaWx5IGF0dHJpYnV0ZSBpbiBBQUYgYW5kIEkgZ3Vlc3MgaXQgY2FuIGJl IHJlbW92ZWQ7IEluc3RlYWQgb2YgQUFGIHdlIGNhbiBwcm9iYWJseSBjYWxsIGlmIERVQUwtU1RB Q0stQUREUkVTUy1GQU1JTFkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4yKQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPmEpIFJFRlJFU0ggd2l0aCBubyBhdHRyaWJ1dGVzIHJlZnJlc2hlcyBldmVyeXRoaW5n LCByZWdhcmRsZXNzIG9mIGFsbG9jYXRpb24gdHlwZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+YikgUkVGUkVTSCB3aXRoIHNwZWNpZmljIFJBRiByZWZyZXNoZXMgb25seSB0aGUgc3Bl Y2lmaWMgYWxsb2NhdGlvbiBpZiBpdCBleGlzdHMsIG9yIG90aGVyd2lzZSBmYWlsczwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5jKSBSRUZSRVNIIHdpdGggUkFGIGNhbiBiZSB1c2VkIHdp dGggb3VyIHdpdGhvdXQgZHVhbCBzdGFjayBhbGxvY2F0aW9uIGFuZCBkZXByZWNhdGVzIHRoZSBi ZWhhdmlvciBpbiBSRkMgNjE1Ni48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjMpQ2hhbmdlIHRoZSBmb3JtYXQgb2YgQURE UkVTUy1FUlJPUi1DT0RFIHRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsgQWRkcmVzcyBGYW1pbHkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyBSc3ZkJm5ic3A7IHxDbGFzc3wmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTnVt YmVyJm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7 Jm5ic3A7UmVhc29uIFBocmFzZSAodmFyaWFibGUpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC4uPC9zcGFuPjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0Mzs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+NClSZW1vdmUgbXVsdGktYWRkcmVzcyBzdXBwb3J0IHRvIENo YW5uZWxCaW5kIHJlcXVlc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tVGlydTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBKdXN0aW4gVWJlcnRpIFttYWlsdG86anViZXJ0aUBnb29n bGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgTWFyY2ggMjksIDIwMTUgNjoxNyBB TTxicj4NCjxiPlRvOjwvYj4gVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTxicj4NCjxiPkNj OjwvYj4gT2xlZyBNb3NrYWxlbmtvOyB0cmFtQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbdHJhbV0gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDE8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgYXJlIG9i c29sZXRpbmcgNjE1Niwgc28gd2UgY2FuIHNheSB3aGF0ZXZlciB3ZSB3YW50IC0gZXNwZWNpYWxs eSBpbiB0aGUgY2FzZSBvZiBkdWFsIGFsbG9jYXRpb25zLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgTWFyIDI3LCAyMDE1IGF0IDc6MDggUE0sIFRpcnVtYWxl c3dhciBSZWRkeSAodGlyZWRkeSkgJmx0OzxhIGhyZWY9Im1haWx0bzp0aXJlZGR5QGNpc2NvLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnRpcmVkZHlAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEp1c3Rpbiw8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5UaGUgcHJvYmxlbSBpcyBSRkMgNjE1NiBzYXlzIHRoYXQgUkFGIG11c3Qgbm90IGJlIHVzZWQg aW4gUmVmcmVzaCByZXF1ZXN0LCB0aGF0IGlzIG9uZSBvZiB0aGUgcmVhc29ucw0KIGZvciB1c2lu ZyBBQUYgaW4gUmVmcmVzaC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tVGlydTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBp biA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSnVzdGluIFViZXJ0aSBbbWFpbHRvOjwvc3Bh bj48YSBocmVmPSJtYWlsdG86anViZXJ0aUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmp1YmVydGlAZ29vZ2xlLmNvbTwvc3Bhbj48L2E+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE1h cmNoIDI3LCAyMDE1IDg6MjEgUE08YnI+DQo8Yj5Ubzo8L2I+IFRpcnVtYWxlc3dhciBSZWRkeSAo dGlyZWRkeSk8YnI+DQo8Yj5DYzo8L2I+IE9sZWcgTW9za2FsZW5rbzsgPC9zcGFuPjxhIGhyZWY9 Im1haWx0bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPnRyYW1AaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0 cmFtXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0wMTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5BZ3JlZWQsIGJ1dCBJIHRoaW5rIHVzaW5nIEFBRiBpbiBSZWZyZXNoIGhhcyBj b25mdXNpbmcgc2VtYW50aWNzLCBzaW5jZSB0aGV5IGFyZSBkaWZmZXJlbnQgZnJvbSBBbGxvY2F0 ZS4gUmVzdGF0aW5nIGZyb20gbXkgcHJldmlvdXMgbWVzc2FnZTo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS41cHQiPkluIEFMTE9DQVRFLCB2NCBBQUYgaXMgZm9yYmlkZGVuLCBhbmQg djYgQUFGIG1lYW5zICZxdW90O3Y0JiM0Mzt2NiZxdW90Oy48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS41cHQiPkluIFJFRlJFU0gsIHY0IEFBRiBtZWFucyAmcXVvdDt2NCBvbmx5JnF1b3Q7 LCBhbmQgdjYgQUFGIG1lYW5zICZxdW90O3Y2IG9ubHkmcXVvdDsuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuNXB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQi PkNvbXBhcmUgdGhpcyB0byBob3cgUkFGIGNvdWxkIGJlIGhhbmRsZWQ6PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuNXB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41 cHQiPkluIEFMTE9DQVRFLCB2NCBSQUYgbWVhbnMgJnF1b3Q7djQgb25seSZxdW90OywgYW5kIHY2 IFJBRiBtZWFucyAmcXVvdDt2NiBvbmx5JnF1b3Q7Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjVwdCI+SW4gUkVGUkVTSCwmbmJzcDt2NCBSQUYgbWVhbnMgJnF1b3Q7djQgb25seSZxdW90 OywgYW5kIHY2IFJBRiBtZWFucyAmcXVvdDt2NiBvbmx5JnF1b3Q7Ljwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjVwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBGcmksIE1hciAyNywgMjAxNSBhdCAxMjoz OCBBTSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRp cmVkZHlAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+dGlyZWRkeUBjaXNjby5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIGNsaWVu dCBpbmNsdWRlcyBBQUYgaW4gUmVmcmVzaCBvbmx5IGlmIGR1YWwgYWxsb2NhdGlvbiBpcyBzdWNj ZXNzZnVsIHdoaWNoIG1lYW5zIGNsaWVudCB3aGVuIGl0IHNlbmRzIFJlZnJlc2gga25vd3MgaWYg c2VydmVyIHN1cHBvcnRzIEFBRiBvciBub3QuPGJyPg0KPGJyPg0KLVRpcnU8YnI+DQo8YnI+DQom Z3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9tOiBPbGVnIE1vc2th bGVua28gW21haWx0bzo8YSBocmVmPSJtYWlsdG86bW9tMDQwMjY3QGdtYWlsLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPm1vbTA0MDI2N0BnbWFpbC5jb208L2E+XTxicj4NCiZndDsgU2VudDogRnJpZGF5 LCBNYXJjaCAyNywgMjAxNSAxMDoxMyBBTTxicj4NCiZndDsgVG86IEp1c3RpbiBVYmVydGk8YnI+ DQomZ3Q7IENjOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpOyA8YSBocmVmPSJtYWlsdG86 dHJhbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdHJhbUBpZXRmLm9yZzwvYT48YnI+DQom Z3Q7IFN1YmplY3Q6IFJlOiBbdHJhbV0gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi10cmFtLXR1cm5i aXMtMDE8YnI+DQomZ3Q7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jmd0OyBPbiBUaHUsIE1hciAyNiwgMjAxNSBhdCA5OjAwIFBNLCBKdXN0aW4g VWJlcnRpICZsdDs8YSBocmVmPSJtYWlsdG86anViZXJ0aUBnb29nbGUuY29tIiB0YXJnZXQ9Il9i bGFuayI+anViZXJ0aUBnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEkgdGhpbmsgdGhhdCBSRUZSRVNIIHNob3VsZCB3 b3JrIGFzIGZvbGxvd3M6PGJyPg0KJmd0OyAmZ3Q7IC0gUkVGUkVTSCB3aXRoIG5vIGF0dHJpYnV0 ZXMgcmVmcmVzaGVzIGV2ZXJ5dGhpbmcsIHJlZ2FyZGxlc3Mgb2Y8YnI+DQomZ3Q7ICZndDsgYWxs b2NhdGlvbiB0eXBlPGJyPg0KJmd0OyAmZ3Q7IC0gUkVGUkVTSCB3aXRoIHNwZWNpZmljIFJBRiBy ZWZyZXNoZXMgb25seSB0aGUgc3BlY2lmaWMgYWxsb2NhdGlvbiBpZjxicj4NCiZndDsgJmd0OyBp dCBleGlzdHMsIG9yIG90aGVyd2lzZSBmYWlsczxicj4NCiZndDsgJmd0OyAtIFJFRlJFU0ggd2l0 aCBhbnkgQUFGIGZhaWxzIGJlY2F1c2UgaXQgaXMgbm90IHdlbGwtZGVmaW5lZDxicj4NCiZndDs8 YnI+DQomZ3Q7IHRoaXMgYmVoYXZpb3VyIGlzIG5vdCBjb21wYXRpYmxlIHdpdGggb2xkZXIgKFJG QzU3NjYtY29tcGxpYW50KSBzZXJ2ZXJzIHRoYXQgZG88YnI+DQomZ3Q7IG5vdCB1bmRlcnN0YW5k IEFBRi4gVGhleSB3aWxsIHRyZWF0IG9wdGlvbiAxIGFuZCBvcHRpb24gMyBhcyB0aGUgc2FtZSBj YXNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_913383AAA69FF945B8F946018B75898A411F810Exmbrcdx10ciscoc_-- From nobody Sun Mar 29 23:48:12 2015 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 F30891A90D8 for ; Sun, 29 Mar 2015 23:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, 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 44jigjkGeJRb for ; Sun, 29 Mar 2015 23:48:09 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77DDA1A90D7 for ; Sun, 29 Mar 2015 23:48:09 -0700 (PDT) Received: by wibg7 with SMTP id g7so90052740wib.1 for ; Sun, 29 Mar 2015 23:48:08 -0700 (PDT) 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=svOjpcd1gfsY/HF+aigNK+Sld/NHcoMV0c0S2rNMtlE=; b=oUIghUhBafpKt9wpnHerXbbujQBRQmzQW5vDkyANMMrQxv++WSrwf+yrF9q2EqX8Bh s9cMk8QvqGNcdr92Y6bokJ4bAIQQwZx3FDbYRyy6G3sZf8lJ05/Dc3fnZozevzTzVreP Mgo20YnSOem9x/KCrn9xwGdNXC4+hDtK37wmJ4sH8/vklvE7ZLtli7/bQGs6JSt6eR9c 4Ozx4cvcT93DkNz7vdk2F3kni/B6EBEEU7HC6rE7Dv5SST8JhrIkQrvgVvxGwybgDKGe nQAMxGF6PzG/jAAfASXi0XqzF2YHOhu98NJkQL84ZIMEY6gQ1Xx9frvC95WH6++iWdWa +GzA== MIME-Version: 1.0 X-Received: by 10.194.159.105 with SMTP id xb9mr60588980wjb.156.1427698087922; Sun, 29 Mar 2015 23:48:07 -0700 (PDT) Received: by 10.194.190.18 with HTTP; Sun, 29 Mar 2015 23:48:07 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A411F810E@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A411F810E@xmb-rcd-x10.cisco.com> Date: Sun, 29 Mar 2015 23:48:07 -0700 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tram@ietf.org" , Justin Uberti Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-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: Mon, 30 Mar 2015 06:48:11 -0000 Tiru, please clarify the point 2c, I did not get it. Thanks Oleg On Sun, Mar 29, 2015 at 11:44 PM, Tirumaleswar Reddy (tireddy) wrote: > Works for me. Summarizing list of changes discussed: > > > > 1) There is no use of address family attribute in AAF and I guess it can be > removed; Instead of AAF we can probably call if DUAL-STACK-ADDRESS-FAMILY. > > > > 2) > > a) REFRESH with no attributes refreshes everything, regardless of allocation > type. > > b) REFRESH with specific RAF refreshes only the specific allocation if it > exists, or otherwise fails > > c) REFRESH with RAF can be used with our without dual stack allocation and > deprecates the behavior in RFC 6156. > > > > 3)Change the format of ADDRESS-ERROR-CODE to > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Address Family | Rsvd |Class| Number | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Reason Phrase (variable) .. > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > 4)Remove multi-address support to ChannelBind request. > > > > -Tiru > > > > From: Justin Uberti [mailto:juberti@google.com] > Sent: Sunday, March 29, 2015 6:17 AM > > > To: Tirumaleswar Reddy (tireddy) > Cc: Oleg Moskalenko; tram@ietf.org > Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-01 > > > > We are obsoleting 6156, so we can say whatever we want - especially in the > case of dual allocations. > > > > On Fri, Mar 27, 2015 at 7:08 PM, Tirumaleswar Reddy (tireddy) > wrote: > > Hi Justin, > > > > The problem is RFC 6156 says that RAF must not be used in Refresh request, > that is one of the reasons for using AAF in Refresh. > > > > -Tiru > > > > From: Justin Uberti [mailto:juberti@google.com] > Sent: Friday, March 27, 2015 8:21 PM > To: Tirumaleswar Reddy (tireddy) > Cc: Oleg Moskalenko; tram@ietf.org > > > Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-01 > > > > Agreed, but I think using AAF in Refresh has confusing semantics, since they > are different from Allocate. Restating from my previous message: > > > > In ALLOCATE, v4 AAF is forbidden, and v6 AAF means "v4+v6". > > In REFRESH, v4 AAF means "v4 only", and v6 AAF means "v6 only". > > > > Compare this to how RAF could be handled: > > > > In ALLOCATE, v4 RAF means "v4 only", and v6 RAF means "v6 only". > > In REFRESH, v4 RAF means "v4 only", and v6 RAF means "v6 only". > > > > On Fri, Mar 27, 2015 at 12:38 AM, Tirumaleswar Reddy (tireddy) > wrote: > > The client includes AAF in Refresh only if dual allocation is successful > which means client when it sends Refresh knows if server supports AAF or > not. > > -Tiru > >> -----Original Message----- >> From: Oleg Moskalenko [mailto:mom040267@gmail.com] >> Sent: Friday, March 27, 2015 10:13 AM >> To: Justin Uberti >> Cc: Tirumaleswar Reddy (tireddy); tram@ietf.org >> Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-01 >> > >> On Thu, Mar 26, 2015 at 9:00 PM, Justin Uberti wrote: >> > >> > >> > I think that REFRESH should work as follows: >> > - REFRESH with no attributes refreshes everything, regardless of >> > allocation type >> > - REFRESH with specific RAF refreshes only the specific allocation if >> > it exists, or otherwise fails >> > - REFRESH with any AAF fails because it is not well-defined >> >> this behaviour is not compatible with older (RFC5766-compliant) servers >> that do >> not understand AAF. They will treat option 1 and option 3 as the same >> case. > > > > From nobody Sun Mar 29 23:55:57 2015 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 930151A90E1 for ; Sun, 29 Mar 2015 23:55:56 -0700 (PDT) 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 2oeqa2xg_CnN for ; Sun, 29 Mar 2015 23:55:55 -0700 (PDT) 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 9ADFF1A90E6 for ; Sun, 29 Mar 2015 23:55:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6470; q=dns/txt; s=iport; t=1427698553; x=1428908153; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=oFPNpdVHNJlowsnKYak3MaRcPSGBg4ROp65GtvhBQyI=; b=l1gqyV/47oDwtJjymRdKu/m2JYozU3fPnyVqbrltjLB40+U2i7wrFizt PzQASYpeSAg4WgCSr5EseAoYwQgHE776tpcPsJ/A7LR9MYKgs8zBBjzo3 iJQxsVuV19fjTmgeUV+uSQisZjN4+ULYHE3nHRcwTXwtdJqoIemk3v/bI s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AqCADo8RhV/5pdJa1cgwaBLgSDD79jiC4CHIEPTAEBAQEBAX2EFAEBAQMBIxFFDAQCAQgOAwQBAQECAgYdAwICAh8RFAEICAEBBA4FCIgTAwkIsHiSeg2FSgEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYoIgkeCABYbBwaCYi+BFgWQXIgngmmDMok8hisiggIcgVBvgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,492,1422921600"; d="scan'208";a="136523527" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-2.cisco.com with ESMTP; 30 Mar 2015 06:55:52 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t2U6tqMa009560 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Mar 2015 06:55:52 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.175]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Mon, 30 Mar 2015 01:55:52 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko Thread-Topic: [tram] Comments on draft-ietf-tram-turnbis-01 Thread-Index: AdBqtO8LEmxHurQaR+CZrwc163VgbAAKnRCAAApdbAA= Date: Mon, 30 Mar 2015 06:55:52 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A411F8156@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A411F810E@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.47.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" , Justin Uberti Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-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: Mon, 30 Mar 2015 06:55:56 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBPbGVnIE1vc2thbGVua28gW21h aWx0bzptb20wNDAyNjdAZ21haWwuY29tXQ0KPiBTZW50OiBNb25kYXksIE1hcmNoIDMwLCAyMDE1 IDEyOjE4IFBNDQo+IFRvOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQo+IENjOiBKdXN0 aW4gVWJlcnRpOyB0cmFtQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdHJhbV0gQ29tbWVudHMg b24gZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDENCj4gDQo+IFRpcnUsDQo+IA0KPiBwbGVhc2Ug Y2xhcmlmeSB0aGUgcG9pbnQgMmMsIEkgZGlkIG5vdCBnZXQgaXQuDQoNCkkgbWVhbnQgaWYgY2xp ZW50IGhhZCBzZW50ICBBQUYgaW4gQWxsb2NhdGUgcmVxdWVzdCBhbmQgc2VydmVyIHJlc3BvbmRz IHdpdGggcGFydGlhbCBzdWNjZXNzIChhbGxvY2F0aW9uIHN1Y2Nlc3NmdWwgZm9yIG9ubHkgb25l IGFkZHJlc3MgZmFtaWx5KTsgY2xpZW50IGNhbiB1c2UgUmVmcmVzaCArIFJBRiB0byByZWZyZXNo IHRoZSBzcGVjaWZpYyBhZGRyZXNzIGZhbWlseSBmb3Igd2hpY2ggdGhlIGFsbG9jYXRpb24gaXMg c3VjY2Vzc2Z1bC4gDQooSXQgY2hhbmdlcyB0aGUgYmVoYXZpb3IgZGlzY3Vzc2VkIGluIFJGQyA2 MTU2IHRoYXQgY2xpZW50IG11c3Qgbm90IHNlbmQgUkFGIGluIHJlZnJlc2gpLiANCg0KLVRpcnUN Cg0KPiANCj4gVGhhbmtzDQo+IE9sZWcNCj4gDQo+IE9uIFN1biwgTWFyIDI5LCAyMDE1IGF0IDEx OjQ0IFBNLCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQo+IDx0aXJlZGR5QGNpc2NvLmNv bT4gd3JvdGU6DQo+ID4gV29ya3MgZm9yIG1lLiBTdW1tYXJpemluZyBsaXN0IG9mIGNoYW5nZXMg ZGlzY3Vzc2VkOg0KPiA+DQo+ID4NCj4gPg0KPiA+IDEpIFRoZXJlIGlzIG5vIHVzZSBvZiBhZGRy ZXNzIGZhbWlseSBhdHRyaWJ1dGUgaW4gQUFGIGFuZCBJIGd1ZXNzIGl0DQo+ID4gY2FuIGJlIHJl bW92ZWQ7IEluc3RlYWQgb2YgQUFGIHdlIGNhbiBwcm9iYWJseSBjYWxsIGlmIERVQUwtU1RBQ0st QUREUkVTUy0NCj4gRkFNSUxZLg0KPiA+DQo+ID4NCj4gPg0KPiA+IDIpDQo+ID4NCj4gPiBhKSBS RUZSRVNIIHdpdGggbm8gYXR0cmlidXRlcyByZWZyZXNoZXMgZXZlcnl0aGluZywgcmVnYXJkbGVz cyBvZg0KPiA+IGFsbG9jYXRpb24gdHlwZS4NCj4gPg0KPiA+IGIpIFJFRlJFU0ggd2l0aCBzcGVj aWZpYyBSQUYgcmVmcmVzaGVzIG9ubHkgdGhlIHNwZWNpZmljIGFsbG9jYXRpb24gaWYNCj4gPiBp dCBleGlzdHMsIG9yIG90aGVyd2lzZSBmYWlscw0KPiA+DQo+ID4gYykgUkVGUkVTSCB3aXRoIFJB RiBjYW4gYmUgdXNlZCB3aXRoIG91ciB3aXRob3V0IGR1YWwgc3RhY2sgYWxsb2NhdGlvbg0KPiA+ IGFuZCBkZXByZWNhdGVzIHRoZSBiZWhhdmlvciBpbiBSRkMgNjE1Ni4NCj4gPg0KPiA+DQo+ID4N Cj4gPiAzKUNoYW5nZSB0aGUgZm9ybWF0IG9mIEFERFJFU1MtRVJST1ItQ09ERSB0bw0KPiA+DQo+ ID4NCj4gPg0KPiA+DQo+ID4gKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gPg0KPiA+ICAgICAgIHwgIEFkZHJlc3MgRmFt aWx5ICAgICAgICAgICAgICAgIHwgIFJzdmQgIHxDbGFzc3wgICAgIE51bWJlciAgICB8DQo+ID4N Cj4gPg0KPiA+ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rDQo+ID4NCj4gPiAgICAgICB8ICAgICAgUmVhc29uIFBocmFzZSAo dmFyaWFibGUpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuLg0KPiA+DQo+ID4NCj4g PiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0KPiA+DQo+ID4NCj4gPg0KPiA+IDQpUmVtb3ZlIG11bHRpLWFkZHJlc3Mgc3Vw cG9ydCB0byBDaGFubmVsQmluZCByZXF1ZXN0Lg0KPiA+DQo+ID4NCj4gPg0KPiA+IC1UaXJ1DQo+ ID4NCj4gPg0KPiA+DQo+ID4gRnJvbTogSnVzdGluIFViZXJ0aSBbbWFpbHRvOmp1YmVydGlAZ29v Z2xlLmNvbV0NCj4gPiBTZW50OiBTdW5kYXksIE1hcmNoIDI5LCAyMDE1IDY6MTcgQU0NCj4gPg0K PiA+DQo+ID4gVG86IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkNCj4gPiBDYzogT2xlZyBN b3NrYWxlbmtvOyB0cmFtQGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFt0cmFtXSBDb21tZW50 cyBvbiBkcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0wMQ0KPiA+DQo+ID4NCj4gPg0KPiA+IFdlIGFy ZSBvYnNvbGV0aW5nIDYxNTYsIHNvIHdlIGNhbiBzYXkgd2hhdGV2ZXIgd2Ugd2FudCAtIGVzcGVj aWFsbHkgaW4NCj4gPiB0aGUgY2FzZSBvZiBkdWFsIGFsbG9jYXRpb25zLg0KPiA+DQo+ID4NCj4g Pg0KPiA+IE9uIEZyaSwgTWFyIDI3LCAyMDE1IGF0IDc6MDggUE0sIFRpcnVtYWxlc3dhciBSZWRk eSAodGlyZWRkeSkNCj4gPiA8dGlyZWRkeUBjaXNjby5jb20+IHdyb3RlOg0KPiA+DQo+ID4gSGkg SnVzdGluLA0KPiA+DQo+ID4NCj4gPg0KPiA+IFRoZSBwcm9ibGVtIGlzIFJGQyA2MTU2IHNheXMg dGhhdCBSQUYgbXVzdCBub3QgYmUgdXNlZCBpbiBSZWZyZXNoDQo+ID4gcmVxdWVzdCwgdGhhdCBp cyBvbmUgb2YgdGhlIHJlYXNvbnMgZm9yIHVzaW5nIEFBRiBpbiBSZWZyZXNoLg0KPiA+DQo+ID4N Cj4gPg0KPiA+IC1UaXJ1DQo+ID4NCj4gPg0KPiA+DQo+ID4gRnJvbTogSnVzdGluIFViZXJ0aSBb bWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbV0NCj4gPiBTZW50OiBGcmlkYXksIE1hcmNoIDI3LCAy MDE1IDg6MjEgUE0NCj4gPiBUbzogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KQ0KPiA+IENj OiBPbGVnIE1vc2thbGVua287IHRyYW1AaWV0Zi5vcmcNCj4gPg0KPiA+DQo+ID4gU3ViamVjdDog UmU6IFt0cmFtXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0wMQ0KPiA+DQo+ ID4NCj4gPg0KPiA+IEFncmVlZCwgYnV0IEkgdGhpbmsgdXNpbmcgQUFGIGluIFJlZnJlc2ggaGFz IGNvbmZ1c2luZyBzZW1hbnRpY3MsDQo+ID4gc2luY2UgdGhleSBhcmUgZGlmZmVyZW50IGZyb20g QWxsb2NhdGUuIFJlc3RhdGluZyBmcm9tIG15IHByZXZpb3VzIG1lc3NhZ2U6DQo+ID4NCj4gPg0K PiA+DQo+ID4gSW4gQUxMT0NBVEUsIHY0IEFBRiBpcyBmb3JiaWRkZW4sIGFuZCB2NiBBQUYgbWVh bnMgInY0K3Y2Ii4NCj4gPg0KPiA+IEluIFJFRlJFU0gsIHY0IEFBRiBtZWFucyAidjQgb25seSIs IGFuZCB2NiBBQUYgbWVhbnMgInY2IG9ubHkiLg0KPiA+DQo+ID4NCj4gPg0KPiA+IENvbXBhcmUg dGhpcyB0byBob3cgUkFGIGNvdWxkIGJlIGhhbmRsZWQ6DQo+ID4NCj4gPg0KPiA+DQo+ID4gSW4g QUxMT0NBVEUsIHY0IFJBRiBtZWFucyAidjQgb25seSIsIGFuZCB2NiBSQUYgbWVhbnMgInY2IG9u bHkiLg0KPiA+DQo+ID4gSW4gUkVGUkVTSCwgdjQgUkFGIG1lYW5zICJ2NCBvbmx5IiwgYW5kIHY2 IFJBRiBtZWFucyAidjYgb25seSIuDQo+ID4NCj4gPg0KPiA+DQo+ID4gT24gRnJpLCBNYXIgMjcs IDIwMTUgYXQgMTI6MzggQU0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkNCj4gPiA8dGly ZWRkeUBjaXNjby5jb20+IHdyb3RlOg0KPiA+DQo+ID4gVGhlIGNsaWVudCBpbmNsdWRlcyBBQUYg aW4gUmVmcmVzaCBvbmx5IGlmIGR1YWwgYWxsb2NhdGlvbiBpcw0KPiA+IHN1Y2Nlc3NmdWwgd2hp Y2ggbWVhbnMgY2xpZW50IHdoZW4gaXQgc2VuZHMgUmVmcmVzaCBrbm93cyBpZiBzZXJ2ZXINCj4g PiBzdXBwb3J0cyBBQUYgb3Igbm90Lg0KPiA+DQo+ID4gLVRpcnUNCj4gPg0KPiA+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBPbGVnIE1vc2thbGVua28gW21haWx0bzpt b20wNDAyNjdAZ21haWwuY29tXQ0KPiA+PiBTZW50OiBGcmlkYXksIE1hcmNoIDI3LCAyMDE1IDEw OjEzIEFNDQo+ID4+IFRvOiBKdXN0aW4gVWJlcnRpDQo+ID4+IENjOiBUaXJ1bWFsZXN3YXIgUmVk ZHkgKHRpcmVkZHkpOyB0cmFtQGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBbdHJhbV0gQ29t bWVudHMgb24gZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDENCj4gPj4NCj4gPg0KPiA+PiBPbiBU aHUsIE1hciAyNiwgMjAxNSBhdCA5OjAwIFBNLCBKdXN0aW4gVWJlcnRpIDxqdWJlcnRpQGdvb2ds ZS5jb20+IHdyb3RlOg0KPiA+PiA+DQo+ID4+ID4NCj4gPj4gPiBJIHRoaW5rIHRoYXQgUkVGUkVT SCBzaG91bGQgd29yayBhcyBmb2xsb3dzOg0KPiA+PiA+IC0gUkVGUkVTSCB3aXRoIG5vIGF0dHJp YnV0ZXMgcmVmcmVzaGVzIGV2ZXJ5dGhpbmcsIHJlZ2FyZGxlc3Mgb2YNCj4gPj4gPiBhbGxvY2F0 aW9uIHR5cGUNCj4gPj4gPiAtIFJFRlJFU0ggd2l0aCBzcGVjaWZpYyBSQUYgcmVmcmVzaGVzIG9u bHkgdGhlIHNwZWNpZmljIGFsbG9jYXRpb24NCj4gPj4gPiBpZiBpdCBleGlzdHMsIG9yIG90aGVy d2lzZSBmYWlscw0KPiA+PiA+IC0gUkVGUkVTSCB3aXRoIGFueSBBQUYgZmFpbHMgYmVjYXVzZSBp dCBpcyBub3Qgd2VsbC1kZWZpbmVkDQo+ID4+DQo+ID4+IHRoaXMgYmVoYXZpb3VyIGlzIG5vdCBj b21wYXRpYmxlIHdpdGggb2xkZXIgKFJGQzU3NjYtY29tcGxpYW50KQ0KPiA+PiBzZXJ2ZXJzIHRo YXQgZG8gbm90IHVuZGVyc3RhbmQgQUFGLiBUaGV5IHdpbGwgdHJlYXQgb3B0aW9uIDEgYW5kDQo+ ID4+IG9wdGlvbiAzIGFzIHRoZSBzYW1lIGNhc2UuDQo+ID4NCj4gPg0KPiA+DQo+ID4NCg== From nobody Mon Mar 30 00:01:49 2015 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 88C1D1A90E9 for ; Mon, 30 Mar 2015 00:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, 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 IVHVGXHT9heY for ; Mon, 30 Mar 2015 00:01:46 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D61E51A90E7 for ; Mon, 30 Mar 2015 00:01:45 -0700 (PDT) Received: by wgra20 with SMTP id a20so161446869wgr.3 for ; Mon, 30 Mar 2015 00:01:44 -0700 (PDT) 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=wSvHHmI6p5UfS0JcUE4FlHXCu1DUxqfpSEk6DEa5f1Y=; b=TMK9YZbwv2nluh96BgjyP+ChFRKYQmWpea2qb35eZKLiGDakBDqOQxvra+wOO51OoN SLhqqouaFQy6gkPGeds3FVJmmApA0Wil2qMNYVQKM98A0tE4quzZamN1nqjTJYjcT8ah cwX2sBDaRbCx6B5oa8zMj6ujWgUALpn3CS9jMdM1gHOhVxp/lFhIySpC1fhm8Z+1cXKq D1rTSkT1WoQghUFcx8WE9JA50O46+/tcj/3oYjQ6TkpcWnK3xEhHPn3zHEm1DVlcbDgd aT0AKAUfSrOkqnewlwvp5F9QYYBKv29w+9wyVXZX4My+iU4GeSixEY/KYB0cDd12G3P6 TEMQ== MIME-Version: 1.0 X-Received: by 10.194.159.105 with SMTP id xb9mr60707276wjb.156.1427698904582; Mon, 30 Mar 2015 00:01:44 -0700 (PDT) Received: by 10.194.190.18 with HTTP; Mon, 30 Mar 2015 00:01:44 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A411F8156@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A411F810E@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A411F8156@xmb-rcd-x10.cisco.com> Date: Mon, 30 Mar 2015 00:01:44 -0700 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tram@ietf.org" , Justin Uberti Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-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: Mon, 30 Mar 2015 07:01:47 -0000 OK, thanks. Oleg On Sun, Mar 29, 2015 at 11:55 PM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: Oleg Moskalenko [mailto:mom040267@gmail.com] >> Sent: Monday, March 30, 2015 12:18 PM >> To: Tirumaleswar Reddy (tireddy) >> Cc: Justin Uberti; tram@ietf.org >> Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-01 >> >> Tiru, >> >> please clarify the point 2c, I did not get it. > > I meant if client had sent AAF in Allocate request and server responds with partial success (allocation successful for only one address family); client can use Refresh + RAF to refresh the specific address family for which the allocation is successful. > (It changes the behavior discussed in RFC 6156 that client must not send RAF in refresh). > > -Tiru > >> >> Thanks >> Oleg >> >> On Sun, Mar 29, 2015 at 11:44 PM, Tirumaleswar Reddy (tireddy) >> wrote: >> > Works for me. Summarizing list of changes discussed: >> > >> > >> > >> > 1) There is no use of address family attribute in AAF and I guess it >> > can be removed; Instead of AAF we can probably call if DUAL-STACK-ADDRESS- >> FAMILY. >> > >> > >> > >> > 2) >> > >> > a) REFRESH with no attributes refreshes everything, regardless of >> > allocation type. >> > >> > b) REFRESH with specific RAF refreshes only the specific allocation if >> > it exists, or otherwise fails >> > >> > c) REFRESH with RAF can be used with our without dual stack allocation >> > and deprecates the behavior in RFC 6156. >> > >> > >> > >> > 3)Change the format of ADDRESS-ERROR-CODE to >> > >> > >> > >> > >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > >> > | Address Family | Rsvd |Class| Number | >> > >> > >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > >> > | Reason Phrase (variable) .. >> > >> > >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > >> > >> > >> > 4)Remove multi-address support to ChannelBind request. >> > >> > >> > >> > -Tiru >> > >> > >> > >> > From: Justin Uberti [mailto:juberti@google.com] >> > Sent: Sunday, March 29, 2015 6:17 AM >> > >> > >> > To: Tirumaleswar Reddy (tireddy) >> > Cc: Oleg Moskalenko; tram@ietf.org >> > Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-01 >> > >> > >> > >> > We are obsoleting 6156, so we can say whatever we want - especially in >> > the case of dual allocations. >> > >> > >> > >> > On Fri, Mar 27, 2015 at 7:08 PM, Tirumaleswar Reddy (tireddy) >> > wrote: >> > >> > Hi Justin, >> > >> > >> > >> > The problem is RFC 6156 says that RAF must not be used in Refresh >> > request, that is one of the reasons for using AAF in Refresh. >> > >> > >> > >> > -Tiru >> > >> > >> > >> > From: Justin Uberti [mailto:juberti@google.com] >> > Sent: Friday, March 27, 2015 8:21 PM >> > To: Tirumaleswar Reddy (tireddy) >> > Cc: Oleg Moskalenko; tram@ietf.org >> > >> > >> > Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-01 >> > >> > >> > >> > Agreed, but I think using AAF in Refresh has confusing semantics, >> > since they are different from Allocate. Restating from my previous message: >> > >> > >> > >> > In ALLOCATE, v4 AAF is forbidden, and v6 AAF means "v4+v6". >> > >> > In REFRESH, v4 AAF means "v4 only", and v6 AAF means "v6 only". >> > >> > >> > >> > Compare this to how RAF could be handled: >> > >> > >> > >> > In ALLOCATE, v4 RAF means "v4 only", and v6 RAF means "v6 only". >> > >> > In REFRESH, v4 RAF means "v4 only", and v6 RAF means "v6 only". >> > >> > >> > >> > On Fri, Mar 27, 2015 at 12:38 AM, Tirumaleswar Reddy (tireddy) >> > wrote: >> > >> > The client includes AAF in Refresh only if dual allocation is >> > successful which means client when it sends Refresh knows if server >> > supports AAF or not. >> > >> > -Tiru >> > >> >> -----Original Message----- >> >> From: Oleg Moskalenko [mailto:mom040267@gmail.com] >> >> Sent: Friday, March 27, 2015 10:13 AM >> >> To: Justin Uberti >> >> Cc: Tirumaleswar Reddy (tireddy); tram@ietf.org >> >> Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-01 >> >> >> > >> >> On Thu, Mar 26, 2015 at 9:00 PM, Justin Uberti wrote: >> >> > >> >> > >> >> > I think that REFRESH should work as follows: >> >> > - REFRESH with no attributes refreshes everything, regardless of >> >> > allocation type >> >> > - REFRESH with specific RAF refreshes only the specific allocation >> >> > if it exists, or otherwise fails >> >> > - REFRESH with any AAF fails because it is not well-defined >> >> >> >> this behaviour is not compatible with older (RFC5766-compliant) >> >> servers that do not understand AAF. They will treat option 1 and >> >> option 3 as the same case. >> > >> > >> > >> > From nobody Mon Mar 30 08:49:11 2015 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 4B9961A0242 for ; Mon, 30 Mar 2015 08:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 aJ0RFEWwLy9F for ; Mon, 30 Mar 2015 08:49:08 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DD341A024E for ; Mon, 30 Mar 2015 08:48:56 -0700 (PDT) Received: by igcxg11 with SMTP id xg11so76787375igc.0 for ; Mon, 30 Mar 2015 08:48:55 -0700 (PDT) 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=Gc0KtvzALCqvcihYdKK6jjbR8o8XMvSgm6sOl9RKhMA=; b=XRyKB8KqkBd6pR7Ziln8DEt18TKdv9IOoIH7/jC0RfilzbcElZ3KcnNydX3724YzRL KhGgSBI0pSFbT8ESNZUMqEkZtzY/hCP1cgcJFquPA7fXw/YHrkStde9HnzsDIIB+def7 btrLfiMoF85NPVeqY+16qdDfJ5H+HlQeS5/TIaL45gjWVE0u6eQrc3NgMDKXSlq18X+5 Q5MNQQzGBHdpCaw8CRLcOobzxTG/T4EvGkYLe7+W27YIegaFpkvGQWkagiLTdBM0iTwJ ebyr6IbcujYWlCFrEB0jz3itFbbQCyoPC3GZZqTiGWeeVaLfmrREdzX9BmU91IVPk8oJ 4Ypw== 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=Gc0KtvzALCqvcihYdKK6jjbR8o8XMvSgm6sOl9RKhMA=; b=NsnLduRIQherexQAq21slHLD39sTT523XDhKAl7WvZiYMlTUQlrVSKHwK3gOrdTh5k uchGaY9ZwvrQYl4EDagYppd/eQf2ZUOG5MGkxyPLi8IOFPrBDstHZ/wAZjo7QiFImjt4 De8NuUyOhAAhlUTWi8gcvRd+B+MRMIr+XHUyUH/2PuIQYMOCEs9q+L3mfbfySzAmwE2Z lKAZgg8V0xAJAz8FKzfdDEN+zoywYJNAReq+LNQ+3dSKPg+F372wby5ck4cGY9w1XoU3 6U7jI+W8Rr0IH6+iEKfC7ZTwt0xPNFMbSBzlMzKbEmHq2C+4xZnjQfdg45B/+5nC1E95 Gfjg== X-Gm-Message-State: ALoCoQmLkvRybiIgEO88tyLDCYb9BqwDX8dbWWg4D5stPXEhap64Zs+KBaZGJCyQahRs2tIM3y5o X-Received: by 10.50.43.197 with SMTP id y5mr7908080igl.14.1427730535551; Mon, 30 Mar 2015 08:48:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.64.42 with HTTP; Mon, 30 Mar 2015 08:48:34 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A411F810E@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A411F810E@xmb-rcd-x10.cisco.com> From: Justin Uberti Date: Mon, 30 Mar 2015 08:48:34 -0700 Message-ID: To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=089e01182608684b9a0512836bb8 Archived-At: Cc: Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-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: Mon, 30 Mar 2015 15:49:10 -0000 --089e01182608684b9a0512836bb8 Content-Type: text/plain; charset=UTF-8 On Sun, Mar 29, 2015 at 11:44 PM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > Works for me. Summarizing list of changes discussed: > > > > 1) There is no use of address family attribute in AAF and I guess it can > be removed; Instead of AAF we can probably call if > DUAL-STACK-ADDRESS-FAMILY. > I would keep AAF as currently defined - there may be other places to use it in the future. However, we can currently return an error if it doesn't match the expected value (i.e. v6). > > > 2) > > a) REFRESH with no attributes refreshes everything, regardless of > allocation type. > > b) REFRESH with specific RAF refreshes only the specific allocation if it > exists, or otherwise fails > > c) REFRESH with RAF can be used with our without dual stack allocation and > deprecates the behavior in RFC 6156. > Agreed. Clients will probably want to do a) unless they know they are talking to a turn-bis server. > > > 3)Change the format of ADDRESS-ERROR-CODE to > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Address Family | Rsvd |Class| Number | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Reason Phrase (variable) .. > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > 4)Remove multi-address support to ChannelBind request. > LGTM > > > -Tiru > > > > *From:* Justin Uberti [mailto:juberti@google.com] > *Sent:* Sunday, March 29, 2015 6:17 AM > > *To:* Tirumaleswar Reddy (tireddy) > *Cc:* Oleg Moskalenko; tram@ietf.org > *Subject:* Re: [tram] Comments on draft-ietf-tram-turnbis-01 > > > > We are obsoleting 6156, so we can say whatever we want - especially in the > case of dual allocations. > > > > On Fri, Mar 27, 2015 at 7:08 PM, Tirumaleswar Reddy (tireddy) < > tireddy@cisco.com> wrote: > > Hi Justin, > > > > The problem is RFC 6156 says that RAF must not be used in Refresh request, > that is one of the reasons for using AAF in Refresh. > > > > -Tiru > > > > *From:* Justin Uberti [mailto:juberti@google.com] > *Sent:* Friday, March 27, 2015 8:21 PM > *To:* Tirumaleswar Reddy (tireddy) > *Cc:* Oleg Moskalenko; tram@ietf.org > > > *Subject:* Re: [tram] Comments on draft-ietf-tram-turnbis-01 > > > > Agreed, but I think using AAF in Refresh has confusing semantics, since > they are different from Allocate. Restating from my previous message: > > > > In ALLOCATE, v4 AAF is forbidden, and v6 AAF means "v4+v6". > > In REFRESH, v4 AAF means "v4 only", and v6 AAF means "v6 only". > > > > Compare this to how RAF could be handled: > > > > In ALLOCATE, v4 RAF means "v4 only", and v6 RAF means "v6 only". > > In REFRESH, v4 RAF means "v4 only", and v6 RAF means "v6 only". > > > > On Fri, Mar 27, 2015 at 12:38 AM, Tirumaleswar Reddy (tireddy) < > tireddy@cisco.com> wrote: > > The client includes AAF in Refresh only if dual allocation is successful > which means client when it sends Refresh knows if server supports AAF or > not. > > -Tiru > > > -----Original Message----- > > From: Oleg Moskalenko [mailto:mom040267@gmail.com] > > Sent: Friday, March 27, 2015 10:13 AM > > To: Justin Uberti > > Cc: Tirumaleswar Reddy (tireddy); tram@ietf.org > > Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-01 > > > > > On Thu, Mar 26, 2015 at 9:00 PM, Justin Uberti > wrote: > > > > > > > > > I think that REFRESH should work as follows: > > > - REFRESH with no attributes refreshes everything, regardless of > > > allocation type > > > - REFRESH with specific RAF refreshes only the specific allocation if > > > it exists, or otherwise fails > > > - REFRESH with any AAF fails because it is not well-defined > > > > this behaviour is not compatible with older (RFC5766-compliant) servers > that do > > not understand AAF. They will treat option 1 and option 3 as the same > case. > > > > > --089e01182608684b9a0512836bb8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Mar 29, 2015 at 11:44 PM, Tirumaleswar Reddy (tireddy) <tiredd= y@cisco.com> wrote:

Works for me. Summarizing= list of changes discussed:

=C2=A0

1) There is no use of add= ress family attribute in AAF and I guess it can be removed; Instead of AAF = we can probably call if DUAL-STACK-ADDRESS-FAMILY.


I would keep AAF as currently defined - ther= e may be other places to use it in the future. However, we can currently re= turn an error if it doesn't match the expected value (i.e. v6).

<= /span>

=C2=A0

2)

a) REFRESH with no attrib= utes refreshes everything, regardless of allocation type.

b) REFRESH with specific = RAF refreshes only the specific allocation if it exists, or otherwise fails=

c) REFRESH with RAF can b= e used with our without dual stack allocation and deprecates the behavior i= n RFC 6156.


Agreed. = Clients will probably want to do a) unless they know they are talking to a = turn-bis server.=C2=A0

=C2=A0

3)Change the format of AD= DRESS-ERROR-CODE to

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 |=C2=A0 Address Family=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 Rsvd=C2=A0 |Class|=C2=
=A0=C2=A0=C2=A0=C2=A0 Number=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 |=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0Reason Phrase (variable)=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 ..
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=C2=A0

4)Remove multi-add= ress support to ChannelBind request.


LGTM=C2=A0

=C2=A0

-Tiru

=C2=A0

From: Justin U= berti [mailto:juber= ti@google.com]
Sent: Sunday, March 29, 2015 6:17 AM


To: Tirumaleswar Reddy (tireddy)
Cc: Oleg Moskalenko; tram@ietf.org
Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-01=

=C2=A0

We are obsoleting 6156, so we can say whatever we wa= nt - especially in the case of dual allocations.

=C2=A0

On Fri, Mar 27, 2015 at 7:08 PM, Tirumaleswar Reddy = (tireddy) <tiredd= y@cisco.com> wrote:

Hi Justin,<= u>

=C2=A0

The problem is RFC 6156 s= ays that RAF must not be used in Refresh request, that is one of the reason= s for using AAF in Refresh.

=C2=A0

-Tiru

=C2=A0

From: Justin U= berti [mailto:juberti@google.com]
Sent: Friday, March 27, 2015 8:21 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Oleg Moskalenko; tram@ietf.org


Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-01=

=C2=A0

Agreed, but I think using AAF in Refresh has confusi= ng semantics, since they are different from Allocate. Restating from my pre= vious message:

=C2=A0

In ALLOCATE, v4 AAF = is forbidden, and v6 AAF means "v4+v6".

In REFRESH, v4 AAF m= eans "v4 only", and v6 AAF means "v6 only".

=C2=A0=

Compare this to how = RAF could be handled:

=C2=A0=

In ALLOCATE, v4 RAF = means "v4 only", and v6 RAF means "v6 only".<= /u>

In REFRESH,=C2=A0v4 = RAF means "v4 only", and v6 RAF means "v6 only".=

=C2=A0=

On Fri, Mar 27, 2015 at 12:38 AM, Tirumaleswar Reddy= (tireddy) <tired= dy@cisco.com> wrote:

The client includes AAF in Refresh only if dual allo= cation is successful which means client when it sends Refresh knows if serv= er supports AAF or not.

-Tiru

> -----Original Message-----
> From: Oleg Moskalenko [mailto:mom040267@gmail.com]
> Sent: Friday, March 27, 2015 10:13 AM
> To: Justin Uberti
> Cc: Tirumaleswar Reddy (tireddy); tram@ietf.org
> Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-01
>

> On Thu, Mar 26, 2015 at 9:00 PM, Justin Uberti = <juberti@google.= com> wrote:
> >
> >
> > I think that REFRESH should work as follows:
> > - REFRESH with no attributes refreshes everything, regardless of<= br> > > allocation type
> > - REFRESH with specific RAF refreshes only the specific allocatio= n if
> > it exists, or otherwise fails
> > - REFRESH with any AAF fails because it is not well-defined
>
> this behaviour is not compatible with older (RFC5766-compliant) server= s that do
> not understand AAF. They will treat option 1 and option 3 as the same = case.

=C2=A0

=C2=A0


--089e01182608684b9a0512836bb8-- From nobody Mon Mar 30 12:55:50 2015 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 6578D1AD333 for ; Mon, 30 Mar 2015 12:55:49 -0700 (PDT) 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 77m9Xm1TMajN for ; Mon, 30 Mar 2015 12:55:47 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B90531A8945 for ; Mon, 30 Mar 2015 12:55:47 -0700 (PDT) Received: by obbgh1 with SMTP id gh1so73188622obb.1 for ; Mon, 30 Mar 2015 12:55:47 -0700 (PDT) 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=MYvrpROfXmRp0Enr2SBF23MLGpIGqHLU45jQ2ia+nTc=; b=D2x7H/oMtm4dnk4+6QSB4S8g2tQnQgisOuQifhbQgi3g5CFzvQluuCfoY1uEOgNc5l FgK34HjQkjQ2qGdI5lxTRvAw3yGhX5f81b89ay8o4gxZLmSdScB6hkVGuoygsAf8MAOE YGFH8xMrRC541cjYgELJW7I6BMDjLMBKqtWhp2YcjxFJoiNRHFORMoHi+YtjLEFZ4sTl ARbm2mLSv3LwHs0Q0WEdYD42cQXHoT7QwdJzcI5xDMXGdCbqhHjI5NeYvwVT9Nr8bL3R 92HH9eSFUKrtgBbku4S7L+6lLOuRB8ymsiH8eXe6lVa81JLI4cJtRqsTg58bOULxucS6 6hsA== MIME-Version: 1.0 X-Received: by 10.182.20.237 with SMTP id q13mr28467248obe.82.1427745347268; Mon, 30 Mar 2015 12:55:47 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Mon, 30 Mar 2015 12:55:47 -0700 (PDT) In-Reply-To: <55155CA7.3050403@jive.com> References: <55155CA7.3050403@jive.com> Date: Mon, 30 Mar 2015 14:55:47 -0500 Message-ID: From: Martin Thomson To: Simon Perreault Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Adoption of draft-reddy-tram-stun-path-data-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: Mon, 30 Mar 2015 19:55:49 -0000 On 27 March 2015 at 08:35, Simon Perreault wrote: > This is to confirm the adoption of draft-reddy-tram-stun-path-data-01 as > a working group draft. If anyone is opposed, now is a good time to > explain why. This looks fine in general, with one issue: Issue: ReTransCnt, ReqTransCnt and RespTransCnt are so similar that this is very confusing. When I finally parsed this, I realize that the server isn't going to have three piece of information; it only needs to a) echo the client's counter, and b) (if stateful) indicate how many times it has responded over time. As specified, I can't see any way that having the number of received messages being different to the number of responses is of any value. Finally, I think that you should specify a more regular form for the parameter. One byte of Client Retransmission Counter, and one byte of Server Retransmission Counter should be easy to understand. Zero being an indication that the sender didn't want to say for any reason, as currently specified. Nit: These metrics can then be used by the controlling agent to influence the ICE candidate pair priorities. Changing priorities is not possible, changing what might be selected is. From nobody Mon Mar 30 19:04:01 2015 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 A79FD1A8775 for ; Mon, 30 Mar 2015 19:04:00 -0700 (PDT) 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 zfGdwojU8Z2N for ; Mon, 30 Mar 2015 19:03:58 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 219CC1A8946 for ; Mon, 30 Mar 2015 19:03:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32610; q=dns/txt; s=iport; t=1427767438; x=1428977038; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=mD6iFUXnliqm8KpGywzQlr/KAYQM7jSnPoMlpM9IFUM=; b=G2DRZEmA5/SwyZDi+vYN84owwHC2myM+wmw0TZcmNhGmcZ39ZYIpBDCt umz0N9JCYRiiOS4TYEBC99UaVQ/hTO2EiHo8DA9v2m7j/CR98BtLkSFx8 3z02ML1gz1hlMVr9DNl9+bqexa/lD/jEP8e6wsb6lHrPh97YW6SIAvhQN Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C+CQCx/xlV/49dJa1cgkNDUlwEgw/ABoguAhyBJUwBAQEBAQF9hBQBAQEDASMKTAUHBAIBCA4DBAEBAQoWBwMCAgIfERQJCAEBBA4FCIgTAwkIsx6TTw2FOgEBAQEBAQEBAQEBAQEBAQEBAQEBAReLKYJHggAWGwYBBoJiL4EWBZBciCePV4YrIoNub4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,498,1422921600"; d="scan'208,217";a="136825893" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-7.cisco.com with ESMTP; 31 Mar 2015 02:03:52 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t2V23q8G027171 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 31 Mar 2015 02:03:52 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.175]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Mon, 30 Mar 2015 21:03:51 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Justin Uberti Thread-Topic: [tram] Comments on draft-ietf-tram-turnbis-01 Thread-Index: AdBqtO8LEmxHurQaR+CZrwc163VgbAAdfRAAAAr7hKA= Date: Tue, 31 Mar 2015 02:03:51 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A411F8BC8@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A411F810E@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.71.228] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A411F8BC8xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-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: Tue, 31 Mar 2015 02:04:00 -0000 --_000_913383AAA69FF945B8F946018B75898A411F8BC8xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogSnVzdGluIFViZXJ0aSBbbWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbV0NClNlbnQ6IE1v bmRheSwgTWFyY2ggMzAsIDIwMTUgOToxOSBQTQ0KVG86IFRpcnVtYWxlc3dhciBSZWRkeSAodGly ZWRkeSkNCkNjOiBPbGVnIE1vc2thbGVua287IHRyYW1AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb dHJhbV0gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDENCg0KDQoNCk9uIFN1 biwgTWFyIDI5LCAyMDE1IGF0IDExOjQ0IFBNLCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkp IDx0aXJlZGR5QGNpc2NvLmNvbTxtYWlsdG86dGlyZWRkeUBjaXNjby5jb20+PiB3cm90ZToNCldv cmtzIGZvciBtZS4gU3VtbWFyaXppbmcgbGlzdCBvZiBjaGFuZ2VzIGRpc2N1c3NlZDoNCg0KMSkg VGhlcmUgaXMgbm8gdXNlIG9mIGFkZHJlc3MgZmFtaWx5IGF0dHJpYnV0ZSBpbiBBQUYgYW5kIEkg Z3Vlc3MgaXQgY2FuIGJlIHJlbW92ZWQ7IEluc3RlYWQgb2YgQUFGIHdlIGNhbiBwcm9iYWJseSBj YWxsIGlmIERVQUwtU1RBQ0stQUREUkVTUy1GQU1JTFkuDQoNCkkgd291bGQga2VlcCBBQUYgYXMg Y3VycmVudGx5IGRlZmluZWQgLSB0aGVyZSBtYXkgYmUgb3RoZXIgcGxhY2VzIHRvIHVzZSBpdCBp biB0aGUgZnV0dXJlLiBIb3dldmVyLCB3ZSBjYW4gY3VycmVudGx5IHJldHVybiBhbiBlcnJvciBp ZiBpdCBkb2Vzbid0IG1hdGNoIHRoZSBleHBlY3RlZCB2YWx1ZSAoaS5lLiB2NikuDQoNCltUUl0g T2theS4NCg0KLVRpcnUNCg0KMikNCmEpIFJFRlJFU0ggd2l0aCBubyBhdHRyaWJ1dGVzIHJlZnJl c2hlcyBldmVyeXRoaW5nLCByZWdhcmRsZXNzIG9mIGFsbG9jYXRpb24gdHlwZS4NCmIpIFJFRlJF U0ggd2l0aCBzcGVjaWZpYyBSQUYgcmVmcmVzaGVzIG9ubHkgdGhlIHNwZWNpZmljIGFsbG9jYXRp b24gaWYgaXQgZXhpc3RzLCBvciBvdGhlcndpc2UgZmFpbHMNCmMpIFJFRlJFU0ggd2l0aCBSQUYg Y2FuIGJlIHVzZWQgd2l0aCBvdXIgd2l0aG91dCBkdWFsIHN0YWNrIGFsbG9jYXRpb24gYW5kIGRl cHJlY2F0ZXMgdGhlIGJlaGF2aW9yIGluIFJGQyA2MTU2Lg0KDQpBZ3JlZWQuIENsaWVudHMgd2ls bCBwcm9iYWJseSB3YW50IHRvIGRvIGEpIHVubGVzcyB0aGV5IGtub3cgdGhleSBhcmUgdGFsa2lu ZyB0byBhIHR1cm4tYmlzIHNlcnZlci4NCg0KMylDaGFuZ2UgdGhlIGZvcm1hdCBvZiBBRERSRVNT LUVSUk9SLUNPREUgdG8NCg0KDQogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQogICAgICB8ICBBZGRyZXNzIEZh bWlseSAgICAgICAgICAgICAgICB8ICBSc3ZkICB8Q2xhc3N8ICAgICBOdW1iZXIgICAgfA0KDQog ICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KDQogICAgICB8ICAgICAgUmVhc29uIFBocmFzZSAodmFyaWFibGUpICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuLg0KDQogICAgICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQo0KVJl bW92ZSBtdWx0aS1hZGRyZXNzIHN1cHBvcnQgdG8gQ2hhbm5lbEJpbmQgcmVxdWVzdC4NCg0KTEdU TQ0KDQotVGlydQ0KDQpGcm9tOiBKdXN0aW4gVWJlcnRpIFttYWlsdG86anViZXJ0aUBnb29nbGUu Y29tPG1haWx0bzpqdWJlcnRpQGdvb2dsZS5jb20+XQ0KU2VudDogU3VuZGF5LCBNYXJjaCAyOSwg MjAxNSA2OjE3IEFNDQoNClRvOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQpDYzogT2xl ZyBNb3NrYWxlbmtvOyB0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFt0cmFtXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0wMQ0KDQpX ZSBhcmUgb2Jzb2xldGluZyA2MTU2LCBzbyB3ZSBjYW4gc2F5IHdoYXRldmVyIHdlIHdhbnQgLSBl c3BlY2lhbGx5IGluIHRoZSBjYXNlIG9mIGR1YWwgYWxsb2NhdGlvbnMuDQoNCk9uIEZyaSwgTWFy IDI3LCAyMDE1IGF0IDc6MDggUE0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgPHRpcmVk ZHlAY2lzY28uY29tPG1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbT4+IHdyb3RlOg0KSGkgSnVzdGlu LA0KDQpUaGUgcHJvYmxlbSBpcyBSRkMgNjE1NiBzYXlzIHRoYXQgUkFGIG11c3Qgbm90IGJlIHVz ZWQgaW4gUmVmcmVzaCByZXF1ZXN0LCB0aGF0IGlzIG9uZSBvZiB0aGUgcmVhc29ucyBmb3IgdXNp bmcgQUFGIGluIFJlZnJlc2guDQoNCi1UaXJ1DQoNCkZyb206IEp1c3RpbiBVYmVydGkgW21haWx0 bzpqdWJlcnRpQGdvb2dsZS5jb208bWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbT5dDQpTZW50OiBG cmlkYXksIE1hcmNoIDI3LCAyMDE1IDg6MjEgUE0NClRvOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRp cmVkZHkpDQpDYzogT2xlZyBNb3NrYWxlbmtvOyB0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGll dGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW3RyYW1dIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtdHJh bS10dXJuYmlzLTAxDQoNCkFncmVlZCwgYnV0IEkgdGhpbmsgdXNpbmcgQUFGIGluIFJlZnJlc2gg aGFzIGNvbmZ1c2luZyBzZW1hbnRpY3MsIHNpbmNlIHRoZXkgYXJlIGRpZmZlcmVudCBmcm9tIEFs bG9jYXRlLiBSZXN0YXRpbmcgZnJvbSBteSBwcmV2aW91cyBtZXNzYWdlOg0KDQpJbiBBTExPQ0FU RSwgdjQgQUFGIGlzIGZvcmJpZGRlbiwgYW5kIHY2IEFBRiBtZWFucyAidjQrdjYiLg0KSW4gUkVG UkVTSCwgdjQgQUFGIG1lYW5zICJ2NCBvbmx5IiwgYW5kIHY2IEFBRiBtZWFucyAidjYgb25seSIu DQoNCkNvbXBhcmUgdGhpcyB0byBob3cgUkFGIGNvdWxkIGJlIGhhbmRsZWQ6DQoNCkluIEFMTE9D QVRFLCB2NCBSQUYgbWVhbnMgInY0IG9ubHkiLCBhbmQgdjYgUkFGIG1lYW5zICJ2NiBvbmx5Ii4N CkluIFJFRlJFU0gsIHY0IFJBRiBtZWFucyAidjQgb25seSIsIGFuZCB2NiBSQUYgbWVhbnMgInY2 IG9ubHkiLg0KDQpPbiBGcmksIE1hciAyNywgMjAxNSBhdCAxMjozOCBBTSwgVGlydW1hbGVzd2Fy IFJlZGR5ICh0aXJlZGR5KSA8dGlyZWRkeUBjaXNjby5jb208bWFpbHRvOnRpcmVkZHlAY2lzY28u Y29tPj4gd3JvdGU6DQpUaGUgY2xpZW50IGluY2x1ZGVzIEFBRiBpbiBSZWZyZXNoIG9ubHkgaWYg ZHVhbCBhbGxvY2F0aW9uIGlzIHN1Y2Nlc3NmdWwgd2hpY2ggbWVhbnMgY2xpZW50IHdoZW4gaXQg c2VuZHMgUmVmcmVzaCBrbm93cyBpZiBzZXJ2ZXIgc3VwcG9ydHMgQUFGIG9yIG5vdC4NCg0KLVRp cnUNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBPbGVnIE1vc2thbGVu a28gW21haWx0bzptb20wNDAyNjdAZ21haWwuY29tPG1haWx0bzptb20wNDAyNjdAZ21haWwuY29t Pl0NCj4gU2VudDogRnJpZGF5LCBNYXJjaCAyNywgMjAxNSAxMDoxMyBBTQ0KPiBUbzogSnVzdGlu IFViZXJ0aQ0KPiBDYzogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsgdHJhbUBpZXRmLm9y ZzxtYWlsdG86dHJhbUBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFt0cmFtXSBDb21tZW50cyBv biBkcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0wMQ0KPg0KPiBPbiBUaHUsIE1hciAyNiwgMjAxNSBh dCA5OjAwIFBNLCBKdXN0aW4gVWJlcnRpIDxqdWJlcnRpQGdvb2dsZS5jb208bWFpbHRvOmp1YmVy dGlAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KPiA+DQo+ID4NCj4gPiBJIHRoaW5rIHRoYXQgUkVGUkVT SCBzaG91bGQgd29yayBhcyBmb2xsb3dzOg0KPiA+IC0gUkVGUkVTSCB3aXRoIG5vIGF0dHJpYnV0 ZXMgcmVmcmVzaGVzIGV2ZXJ5dGhpbmcsIHJlZ2FyZGxlc3Mgb2YNCj4gPiBhbGxvY2F0aW9uIHR5 cGUNCj4gPiAtIFJFRlJFU0ggd2l0aCBzcGVjaWZpYyBSQUYgcmVmcmVzaGVzIG9ubHkgdGhlIHNw ZWNpZmljIGFsbG9jYXRpb24gaWYNCj4gPiBpdCBleGlzdHMsIG9yIG90aGVyd2lzZSBmYWlscw0K PiA+IC0gUkVGUkVTSCB3aXRoIGFueSBBQUYgZmFpbHMgYmVjYXVzZSBpdCBpcyBub3Qgd2VsbC1k ZWZpbmVkDQo+DQo+IHRoaXMgYmVoYXZpb3VyIGlzIG5vdCBjb21wYXRpYmxlIHdpdGggb2xkZXIg KFJGQzU3NjYtY29tcGxpYW50KSBzZXJ2ZXJzIHRoYXQgZG8NCj4gbm90IHVuZGVyc3RhbmQgQUFG LiBUaGV5IHdpbGwgdHJlYXQgb3B0aW9uIDEgYW5kIG9wdGlvbiAzIGFzIHRoZSBzYW1lIGNhc2Uu DQoNCg0KDQo= --_000_913383AAA69FF945B8F946018B75898A411F8BC8xmbrcdx10ciscoc_ 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 Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAu TXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFt ZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBKdXN0aW4g VWJlcnRpIFttYWlsdG86anViZXJ0aUBnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1v bmRheSwgTWFyY2ggMzAsIDIwMTUgOToxOSBQTTxicj4NCjxiPlRvOjwvYj4gVGlydW1hbGVzd2Fy IFJlZGR5ICh0aXJlZGR5KTxicj4NCjxiPkNjOjwvYj4gT2xlZyBNb3NrYWxlbmtvOyB0cmFtQGll dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHJhbV0gQ29tbWVudHMgb24gZHJhZnQt aWV0Zi10cmFtLXR1cm5iaXMtMDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gU3VuLCBNYXIgMjksIDIwMTUgYXQgMTE6NDQgUE0sIFRpcnVtYWxlc3dhciBSZWRk eSAodGlyZWRkeSkgJmx0OzxhIGhyZWY9Im1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPnRpcmVkZHlAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldvcmtzIGZvciBtZS4gU3VtbWFyaXppbmcgbGlzdCBv ZiBjaGFuZ2VzIGRpc2N1c3NlZDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4xKSBUaGVyZSBpcyBubyB1c2Ugb2Yg YWRkcmVzcyBmYW1pbHkgYXR0cmlidXRlIGluIEFBRiBhbmQgSSBndWVzcyBpdCBjYW4gYmUgcmVt b3ZlZDsgSW5zdGVhZCBvZiBBQUYNCiB3ZSBjYW4gcHJvYmFibHkgY2FsbCBpZiBEVUFMLVNUQUNL LUFERFJFU1MtRkFNSUxZLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdvdWxkIGtlZXAgQUFGIGFzIGN1cnJlbnRs eSBkZWZpbmVkIC0gdGhlcmUgbWF5IGJlIG90aGVyIHBsYWNlcyB0byB1c2UgaXQgaW4gdGhlIGZ1 dHVyZS4gSG93ZXZlciwgd2UgY2FuIGN1cnJlbnRseSByZXR1cm4gYW4gZXJyb3IgaWYgaXQgZG9l c24ndCBtYXRjaCB0aGUgZXhwZWN0ZWQgdmFsdWUgKGkuZS4gdjYpLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bVFJdIE9rYXkuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4tVGlydTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+MikNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmEpIFJFRlJFU0ggd2l0 aCBubyBhdHRyaWJ1dGVzIHJlZnJlc2hlcyBldmVyeXRoaW5nLCByZWdhcmRsZXNzIG9mIGFsbG9j YXRpb24gdHlwZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5iKSBSRUZSRVNIIHdp dGggc3BlY2lmaWMgUkFGIHJlZnJlc2hlcyBvbmx5IHRoZSBzcGVjaWZpYyBhbGxvY2F0aW9uIGlm IGl0IGV4aXN0cywgb3Igb3RoZXJ3aXNlIGZhaWxzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+YykgUkVGUkVTSCB3aXRoIFJBRiBjYW4gYmUgdXNlZCB3aXRoIG91ciB3aXRob3V0IGR1 YWwgc3RhY2sgYWxsb2NhdGlvbiBhbmQgZGVwcmVjYXRlcyB0aGUgYmVoYXZpb3INCiBpbiBSRkMg NjE1Ni48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWdyZWVkLiBDbGllbnRzIHdpbGwgcHJv YmFibHkgd2FudCB0byBkbyBhKSB1bmxlc3MgdGhleSBrbm93IHRoZXkgYXJlIHRhbGtpbmcgdG8g YSB0dXJuLWJpcyBzZXJ2ZXIuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjMpQ2hhbmdlIHRoZSBmb3JtYXQgb2YgQUREUkVTUy1FUlJPUi1DT0RFIHRvPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyBBZGRyZXNz IEZhbWlseSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IFJzdmQmbmJz cDsgfENsYXNzfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBOdW1iZXImbmJzcDsmbmJzcDsmbmJz cDsgfDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDtSZWFzb24gUGhyYXNl ICh2YXJpYWJsZSkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLi48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+NClSZW1vdmUgbXVsdGktYWRkcmVzcyBzdXBwb3J0IHRvIENoYW5uZWxCaW5kIHJlcXVl c3QuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxHVE0mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LVRpcnU8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEp1c3RpbiBVYmVydGkgW21haWx0bzo8YSBocmVmPSJt YWlsdG86anViZXJ0aUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+anViZXJ0aUBnb29nbGUu Y29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIE1hcmNoIDI5LCAyMDE1IDY6MTcg QU08L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCjxiPlRvOjwvYj4gVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTxicj4NCjxi PkNjOjwvYj4gT2xlZyBNb3NrYWxlbmtvOyA8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnRyYW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbdHJhbV0gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDE8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+V2UgYXJlIG9ic29sZXRpbmcgNjE1Niwgc28gd2UgY2FuIHNheSB3aGF0 ZXZlciB3ZSB3YW50IC0gZXNwZWNpYWxseSBpbiB0aGUgY2FzZSBvZiBkdWFsIGFsbG9jYXRpb25z LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBGcmksIE1hciAy NywgMjAxNSBhdCA3OjA4IFBNLCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpICZsdDs8YSBo cmVmPSJtYWlsdG86dGlyZWRkeUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj50aXJlZGR5QGNp c2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5IaSBKdXN0aW4sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIHByb2JsZW0gaXMgUkZDIDYxNTYgc2F5 cyB0aGF0IFJBRiBtdXN0IG5vdCBiZSB1c2VkIGluIFJlZnJlc2ggcmVxdWVzdCwgdGhhdCBpcyBv bmUgb2YgdGhlIHJlYXNvbnMNCiBmb3IgdXNpbmcgQUFGIGluIFJlZnJlc2guPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+LVRpcnU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IEp1c3RpbiBVYmVydGkgW21haWx0bzo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmp1YmVydGlAZ29v Z2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5qdWJl cnRpQGdvb2dsZS5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5dDQo8 YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXJjaCAyNywgMjAxNSA4OjIxIFBNPGJyPg0KPGI+ VG86PC9iPiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpPGJyPg0KPGI+Q2M6PC9iPiBPbGVn IE1vc2thbGVua287IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50cmFtQGlldGYub3JnPC9zcGFu PjwvYT48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0cmFtXSBDb21tZW50cyBvbiBkcmFmdC1pZXRm LXRyYW0tdHVybmJpcy0wMTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BZ3JlZWQsIGJ1dCBJIHRo aW5rIHVzaW5nIEFBRiBpbiBSZWZyZXNoIGhhcyBjb25mdXNpbmcgc2VtYW50aWNzLCBzaW5jZSB0 aGV5IGFyZSBkaWZmZXJlbnQgZnJvbSBBbGxvY2F0ZS4gUmVzdGF0aW5nIGZyb20gbXkgcHJldmlv dXMgbWVzc2FnZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPkluIEFMTE9D QVRFLCB2NCBBQUYgaXMgZm9yYmlkZGVuLCBhbmQgdjYgQUFGIG1lYW5zICZxdW90O3Y0JiM0Mzt2 NiZxdW90Oy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPkluIFJFRlJFU0gsIHY0 IEFBRiBtZWFucyAmcXVvdDt2NCBvbmx5JnF1b3Q7LCBhbmQgdjYgQUFGIG1lYW5zICZxdW90O3Y2 IG9ubHkmcXVvdDsuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPkNvbXBhcmUgdGhpcyB0byBob3cgUkFGIGNv dWxkIGJlIGhhbmRsZWQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPkluIEFMTE9DQVRFLCB2NCBSQUYgbWVh bnMgJnF1b3Q7djQgb25seSZxdW90OywgYW5kIHY2IFJBRiBtZWFucyAmcXVvdDt2NiBvbmx5JnF1 b3Q7Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+SW4gUkVGUkVTSCwmbmJzcDt2 NCBSQUYgbWVhbnMgJnF1b3Q7djQgb25seSZxdW90OywgYW5kIHY2IFJBRiBtZWFucyAmcXVvdDt2 NiBvbmx5JnF1b3Q7Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5PbiBGcmksIE1hciAyNywgMjAxNSBhdCAxMjozOCBBTSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0 aXJlZGR5KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRpcmVkZHlAY2lzY28uY29tIiB0YXJnZXQ9Il9i bGFuayI+dGlyZWRkeUBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIGNsaWVudCBpbmNsdWRlcyBBQUYgaW4gUmVmcmVzaCBv bmx5IGlmIGR1YWwgYWxsb2NhdGlvbiBpcyBzdWNjZXNzZnVsIHdoaWNoIG1lYW5zIGNsaWVudCB3 aGVuIGl0IHNlbmRzIFJlZnJlc2gga25vd3MgaWYgc2VydmVyIHN1cHBvcnRzIEFBRiBvciBub3Qu PGJyPg0KPGJyPg0KLVRpcnU8YnI+DQo8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tPGJyPg0KJmd0OyBGcm9tOiBPbGVnIE1vc2thbGVua28gW21haWx0bzo8YSBocmVmPSJtYWls dG86bW9tMDQwMjY3QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vbTA0MDI2N0BnbWFpbC5j b208L2E+XTxicj4NCiZndDsgU2VudDogRnJpZGF5LCBNYXJjaCAyNywgMjAxNSAxMDoxMyBBTTxi cj4NCiZndDsgVG86IEp1c3RpbiBVYmVydGk8YnI+DQomZ3Q7IENjOiBUaXJ1bWFsZXN3YXIgUmVk ZHkgKHRpcmVkZHkpOyA8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPg0KdHJhbUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBbdHJhbV0gQ29t bWVudHMgb24gZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMDE8YnI+DQomZ3Q7PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jmd0OyBPbiBUaHUsIE1h ciAyNiwgMjAxNSBhdCA5OjAwIFBNLCBKdXN0aW4gVWJlcnRpICZsdDs8YSBocmVmPSJtYWlsdG86 anViZXJ0aUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+anViZXJ0aUBnb29nbGUuY29tPC9h PiZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 IEkgdGhpbmsgdGhhdCBSRUZSRVNIIHNob3VsZCB3b3JrIGFzIGZvbGxvd3M6PGJyPg0KJmd0OyAm Z3Q7IC0gUkVGUkVTSCB3aXRoIG5vIGF0dHJpYnV0ZXMgcmVmcmVzaGVzIGV2ZXJ5dGhpbmcsIHJl Z2FyZGxlc3Mgb2Y8YnI+DQomZ3Q7ICZndDsgYWxsb2NhdGlvbiB0eXBlPGJyPg0KJmd0OyAmZ3Q7 IC0gUkVGUkVTSCB3aXRoIHNwZWNpZmljIFJBRiByZWZyZXNoZXMgb25seSB0aGUgc3BlY2lmaWMg YWxsb2NhdGlvbiBpZjxicj4NCiZndDsgJmd0OyBpdCBleGlzdHMsIG9yIG90aGVyd2lzZSBmYWls czxicj4NCiZndDsgJmd0OyAtIFJFRlJFU0ggd2l0aCBhbnkgQUFGIGZhaWxzIGJlY2F1c2UgaXQg aXMgbm90IHdlbGwtZGVmaW5lZDxicj4NCiZndDs8YnI+DQomZ3Q7IHRoaXMgYmVoYXZpb3VyIGlz IG5vdCBjb21wYXRpYmxlIHdpdGggb2xkZXIgKFJGQzU3NjYtY29tcGxpYW50KSBzZXJ2ZXJzIHRo YXQgZG88YnI+DQomZ3Q7IG5vdCB1bmRlcnN0YW5kIEFBRi4gVGhleSB3aWxsIHRyZWF0IG9wdGlv biAxIGFuZCBvcHRpb24gMyBhcyB0aGUgc2FtZSBjYXNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_913383AAA69FF945B8F946018B75898A411F8BC8xmbrcdx10ciscoc_-- From nobody Mon Mar 30 23:55:27 2015 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 14A871A8AC5 for ; Mon, 30 Mar 2015 23:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, 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 7qfBPdG9IbKk for ; Mon, 30 Mar 2015 23:55:24 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A93DF1B2AED for ; Mon, 30 Mar 2015 23:55:23 -0700 (PDT) Received: by wixm2 with SMTP id m2so7415670wix.0 for ; Mon, 30 Mar 2015 23:55:22 -0700 (PDT) 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=MhhMiFi/4Our4Nx4/ohLUH4Mvs4d0LbffeOEnWaoXIw=; b=tERPP4K5HjOGyelrsAd9kENtPFYcmvRktwHYo8Jk9qI+1ArCAsOaY6cCDwr1k7qa2I xz6AAy7aUUOXM+c13O3ieQNh3YmUVdhFTq5EOvckwDuoCzb0pw9Qd5RvTY9+fZYNvdFf a+Pn91LqLFgbbeWj5fqCmXV8IjpvFKgRPbNQrFnNy1dt4u0cASvKaX+cC10eTG0cfUoN gEQrcS7TtLa5EdpFsr/weWez1rq2EmL+UAuKP6lvmKqQdow0HrM6cLJteT0wddgHk8XW nfs8Qk19cHYy1jxUNL4MCKuX9QDzho8rebVKWGkWqB0YmjaaFjfPA5YEXqGU3eCXRWp3 xyPA== MIME-Version: 1.0 X-Received: by 10.180.206.98 with SMTP id ln2mr2672481wic.94.1427784922457; Mon, 30 Mar 2015 23:55:22 -0700 (PDT) Received: by 10.194.190.18 with HTTP; Mon, 30 Mar 2015 23:55:22 -0700 (PDT) In-Reply-To: References: <55155CA7.3050403@jive.com> Date: Mon, 30 Mar 2015 23:55:22 -0700 Message-ID: From: Oleg Moskalenko To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] Adoption of draft-reddy-tram-stun-path-data-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: Tue, 31 Mar 2015 06:55:26 -0000 I agree with Martin that the PATH-CHARACTERISTIC attribute is confusing: 1) In the request it has 4 bytes (1+3), in the response in has 8 bytes (2+2+2+2) - that is bizarre. It would be a good style to keep the attribute of the same size and structure, regardless of the attribute placement. 2) The server is never doing any retransmissions for the responses; all retransmissions in STUN are responsibility of the client. So, the ReqTransCnt and RespTransCnt are always equal. The number of received requests is always equal to the number of responses. So, why do we need two separate fields for the same value ? 3) Why ReTransCnt in the request occupies 1 bytes, but in the response the same value takes 2 bytes ? That is very strange. I agree with the usefulness of the approach and I think that the draft has to be adopted - but those things to be clarified before the adoption. Thanks Oleg On Mon, Mar 30, 2015 at 12:55 PM, Martin Thomson wrote: > On 27 March 2015 at 08:35, Simon Perreault wrote: >> This is to confirm the adoption of draft-reddy-tram-stun-path-data-01 as >> a working group draft. If anyone is opposed, now is a good time to >> explain why. > > This looks fine in general, with one issue: > > Issue: > ReTransCnt, ReqTransCnt and RespTransCnt are so similar that this is > very confusing. When I finally parsed this, I realize that the server > isn't going to have three piece of information; it only needs to a) > echo the client's counter, and b) (if stateful) indicate how many > times it has responded over time. As specified, I can't see any way > that having the number of received messages being different to the > number of responses is of any value. > > Finally, I think that you should specify a more regular form for the > parameter. One byte of Client Retransmission Counter, and one byte of > Server Retransmission Counter should be easy to understand. Zero > being an indication that the sender didn't want to say for any reason, > as currently specified. > > Nit: > These metrics can then be used > by the controlling agent to influence the ICE candidate pair > priorities. > Changing priorities is not possible, changing what might be selected is. > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Mon Mar 30 23:58:50 2015 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 78BD21B2AEE for ; Mon, 30 Mar 2015 23:58:48 -0700 (PDT) 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 UyXLbqwXHY3k for ; Mon, 30 Mar 2015 23:58:47 -0700 (PDT) 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 EFFCE1B2AEC for ; Mon, 30 Mar 2015 23:58:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1860; q=dns/txt; s=iport; t=1427785128; x=1428994728; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zrYvqXCEPWf2J3P2KwLRFAba88Y2yJ9BGNmV1C/J5Vc=; b=Y87CFKmMg2IJGjy3sgZl48jSiMhTeGZYIM0olXdcD7FPpkwhc4nhqI+k nZJforwcVZBXeW8gB4gvo/H9vKcR/XGCShW3mlVu9za/IeP+dd8l8qILe nF3ox4xYbsvESbk9eTZaWoOwdF7rMQvCDmjaO1nzqh6MK21dPFuYf7IET A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C8CQBFRRpV/5pdJa1cgwZSXATDJYIxCoVzAoE5TAEBAQEBAX2EFAEBAQMBAQEBNzQLBQcEAgEIEQQBAQEKFAkHJwsUCQgCBAENBQiIHwgNzCIBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIsphEcxBwaDEYEWAQSQXIsQjCGGeCKDbm+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.11,499,1422921600"; d="scan'208";a="407965506" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 31 Mar 2015 06:58:47 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t2V6wkLW010373 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 31 Mar 2015 06:58:46 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.175]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Tue, 31 Mar 2015 01:58:46 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Martin Thomson , Simon Perreault Thread-Topic: [tram] Adoption of draft-reddy-tram-stun-path-data-01 Thread-Index: AQHQaJL5e3ce9izYgkqQ28GPP77IHp01ybKAgAArGkA= Date: Tue, 31 Mar 2015 06:58:45 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A411F8D66@xmb-rcd-x10.cisco.com> References: <55155CA7.3050403@jive.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.44.213] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Adoption of draft-reddy-tram-stun-path-data-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: Tue, 31 Mar 2015 06:58:48 -0000 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Martin Thomson > Sent: Tuesday, March 31, 2015 1:26 AM > To: Simon Perreault > Cc: tram@ietf.org > Subject: Re: [tram] Adoption of draft-reddy-tram-stun-path-data-01 >=20 > On 27 March 2015 at 08:35, Simon Perreault wrote: > > This is to confirm the adoption of draft-reddy-tram-stun-path-data-01 > > as a working group draft. If anyone is opposed, now is a good time to > > explain why. >=20 > This looks fine in general, with one issue: >=20 > Issue: > ReTransCnt, ReqTransCnt and RespTransCnt are so similar that this is very > confusing. When I finally parsed this, I realize that the server isn't g= oing to > have three piece of information; it only needs to a) echo the client's co= unter, > and b) (if stateful) indicate how many times it has responded over time. = As > specified, I can't see any way that having the number of received message= s > being different to the number of responses is of any value. Agreed, ReqTransCnt can be removed. >=20 > Finally, I think that you should specify a more regular form for the > parameter. One byte of Client Retransmission Counter, and one byte of > Server Retransmission Counter should be easy to understand. =20 Yes, will update draft. > Zero being an > indication that the sender didn't want to say for any reason, as currentl= y > specified. >=20 > Nit: > These metrics can then be used > by the controlling agent to influence the ICE candidate pair > priorities. > Changing priorities is not possible, changing what might be selected is. Yup, will correct in the next version. -Tiru >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Tue Mar 31 05:23:06 2015 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 DEA1A1A9154 for ; Tue, 31 Mar 2015 05:23:04 -0700 (PDT) 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 OCxk-ZXDSI0C for ; Tue, 31 Mar 2015 05:23:03 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 088221A9144 for ; Tue, 31 Mar 2015 05:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3635; q=dns/txt; s=iport; t=1427804584; x=1429014184; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=UW5pYEBl/RLO8qCB6YSOCO+6DO57APLCm28RFxpho2g=; b=O3dGVZSk5UQvwVWOAw6dTObSAcXJivzZzWcX6S9atDPBgi/rJyxF+ga8 L0Q6G8vrxUFAC13oUVySbHBLq09zVcbSC1I1dsSuio5tsxxi/iZa6t0hU sMlDHZMHCiYYf3H2NzCCFMFJLx4YBlo40FIy1wcni3dGSJWupH0uJhUoy A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DeCACJkBpV/5JdJa1cgwZSXAXDOYIyCoVzAoE/TAEBAQEBAX2EFAEBAQMBAQEBNzQLDAYBCA4DBAEBAQoUCSgGCxQJCQEEAQ0FCIgTAwkIDcc1DYU6AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLKYJHggAxDYMRgRYFkGKIKIJqjCZNhisigX8fgVBvgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,500,1422921600"; d="scan'208";a="136951976" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-5.cisco.com with ESMTP; 31 Mar 2015 12:23:03 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t2VCN2E2016385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 31 Mar 2015 12:23:02 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.175]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Tue, 31 Mar 2015 07:23:01 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko , Martin Thomson Thread-Topic: [tram] Adoption of draft-reddy-tram-stun-path-data-01 Thread-Index: AdBrrWMo2fF/cN6yQ1G27fATqB8zzw== Date: Tue, 31 Mar 2015 12:23:00 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A411F90DF@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.64.88] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] Adoption of draft-reddy-tram-stun-path-data-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: Tue, 31 Mar 2015 12:23:05 -0000 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko > Sent: Tuesday, March 31, 2015 12:25 PM > To: Martin Thomson > Cc: Simon Perreault; tram@ietf.org > Subject: Re: [tram] Adoption of draft-reddy-tram-stun-path-data-01 >=20 > I agree with Martin that the PATH-CHARACTERISTIC attribute is confusing: >=20 > 1) In the request it has 4 bytes (1+3), in the response in has 8 bytes > (2+2+2+2) - that is bizarre. It would be a good style to keep the attribu= te of > the same size and structure, regardless of the attribute placement. > 2) The server is never doing any retransmissions for the responses; all > retransmissions in STUN are responsibility of the client. So, the ReqTran= sCnt > and RespTransCnt are always equal. The number of received requests is > always equal to the number of responses. So, why do we need two separate > fields for the same value ? > 3) Why ReTransCnt in the request occupies 1 bytes, but in the response th= e > same value takes 2 bytes ? That is very strange. Agreed on all the above points; will update the format of PATH-CHARACTERIST= IC attribute as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved, should be 0 | ReTransCnt | RespTransCnt | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RespTransCnt must be set to zero in request and ignored by the server. RespTransCnt could be zero in response (e.g. server is stateless). >=20 > I agree with the usefulness of the approach and I think that the draft ha= s to > be adopted=20 Thanks, -Tiru > - but those things to be clarified before the adoption. >=20 > Thanks > Oleg >=20 >=20 > On Mon, Mar 30, 2015 at 12:55 PM, Martin Thomson > wrote: > > On 27 March 2015 at 08:35, Simon Perreault wrote: > >> This is to confirm the adoption of draft-reddy-tram-stun-path-data-01 > >> as a working group draft. If anyone is opposed, now is a good time to > >> explain why. > > > > This looks fine in general, with one issue: > > > > Issue: > > ReTransCnt, ReqTransCnt and RespTransCnt are so similar that this is > > very confusing. When I finally parsed this, I realize that the server > > isn't going to have three piece of information; it only needs to a) > > echo the client's counter, and b) (if stateful) indicate how many > > times it has responded over time. As specified, I can't see any way > > that having the number of received messages being different to the > > number of responses is of any value. > > > > Finally, I think that you should specify a more regular form for the > > parameter. One byte of Client Retransmission Counter, and one byte of > > Server Retransmission Counter should be easy to understand. Zero > > being an indication that the sender didn't want to say for any reason, > > as currently specified. > > > > Nit: > > These metrics can then be used > > by the controlling agent to influence the ICE candidate pair > > priorities. > > Changing priorities is not possible, changing what might be selected is= . > > > > _______________________________________________ > > 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 From nobody Tue Mar 31 05:25:07 2015 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 0EFF11A916E for ; Tue, 31 Mar 2015 05:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 iVrtarY4dC-0 for ; Tue, 31 Mar 2015 05:25:04 -0700 (PDT) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D20C01A9144 for ; Tue, 31 Mar 2015 05:25:02 -0700 (PDT) Received: by qgep97 with SMTP id p97so12252224qge.1 for ; Tue, 31 Mar 2015 05:25:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hcEfUMaNsykiPRBFMJPSdsnX8wAAjqNm/BsZfGusUcQ=; b=X/uLE1e5rfnuRY8j3v2fvO+RL4lAv7zFMdFC7t1EA/Hy+gF7zKeb8pXZk1tyGZJFjg oWOlMOfMWYyfHfmNO1xnW0WdDsgpcSjFoL06mtLMApZwAVoEAJTADHVZCyFd3IOEeg9F 3NNu/qgGm/5VRBVSMpL4oxKjIaXG8MN0ijUBDKbqZJG6P9lCnl51BXKZ183MctRQeZOR 6BiHulFQwtYR9Q7l7hpww5DsIT0lLyaSu14h48uwP0q/3Vy/rVcapAo4qLoD5axbqLWU 7c+t7Ta8zzlEKApOhx++DrjsvdSw7gTtgnT7S4aNpPyfUFVkMmRaiNn/cJ2tCuNErDyu s9kQ== X-Gm-Message-State: ALoCoQkuSrTzCdYblHzZ7c8vSG6fAJN2i7pcFP6nireBqeh58FxT6mlTwEc4BvFpIaLKGWDmUM5t X-Received: by 10.140.148.147 with SMTP id 141mr24859995qhu.45.1427804702070; Tue, 31 Mar 2015 05:25:02 -0700 (PDT) Received: from [192.168.1.43] (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id w130sm9739548qha.25.2015.03.31.05.25.00 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Mar 2015 05:25:01 -0700 (PDT) Message-ID: <551A921B.9040208@jive.com> Date: Tue, 31 Mar 2015 08:24:59 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Oleg Moskalenko , Martin Thomson References: <55155CA7.3050403@jive.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Adoption of draft-reddy-tram-stun-path-data-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: Tue, 31 Mar 2015 12:25:06 -0000 Le 2015-03-31 02:55, Oleg Moskalenko a écrit : > I agree with Martin that the PATH-CHARACTERISTIC attribute is confusing: > > 1) In the request it has 4 bytes (1+3), in the response in has 8 bytes > (2+2+2+2) - that is bizarre. It would be a good style to keep the > attribute of the same size and structure, regardless of the attribute > placement. > 2) The server is never doing any retransmissions for the responses; > all retransmissions in STUN are responsibility of the client. So, the > ReqTransCnt and RespTransCnt are always equal. The number of received > requests is always equal to the number of responses. So, why do we > need two separate fields for the same value ? > 3) Why ReTransCnt in the request occupies 1 bytes, but in the response > the same value takes 2 bytes ? That is very strange. > > I agree with the usefulness of the approach and I think that the draft > has to be adopted - but those things to be clarified before the > adoption. I don't see why these relatively minor things couldn't be worked on after adoption. Simon From nobody Tue Mar 31 05:42:15 2015 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 1321F1A9234 for ; Tue, 31 Mar 2015 05:42:15 -0700 (PDT) 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 H6jQEHELpGer for ; Tue, 31 Mar 2015 05:42:13 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCAC1A6FEA for ; Tue, 31 Mar 2015 05:42:13 -0700 (PDT) Received: from [IPv6:2602:43:2da:6400:5158:cfc2:833:fbc2] (unknown [IPv6:2602:43:2da:6400:5158:cfc2:833:fbc2]) (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 D054C202AB for ; Tue, 31 Mar 2015 14:42:11 +0200 (CEST) Message-ID: <551A9620.5010405@acm.org> Date: Tue, 31 Mar 2015 06:42:08 -0600 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 To: tram@ietf.org References: <20150327075539.26326.49374.idtracker@ietfa.amsl.com> In-Reply-To: <20150327075539.26326.49374.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-04.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, 31 Mar 2015 12:42:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Changelog: o Remove SCTP. o Remove DANE. o s/MESSAGE-INTEGRITY2/MESSAGE-INTEGRITY-SHA256/ o Remove Salted SHA256 password hash. o The RTO delay between transactions is removed. o Make clear that reusing NONCE will trigger a wasted round trip. Remaining TODO list: 1. Add reference to RFC 5769 (stun vectors). 2. Add flow diagram for long-term authentication. 3. Add vectors for SHA256 password hash. On 03/27/2015 01:55 AM, internet-drafts@ietf.org wrote: > > 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 : Session Traversal Utilities for NAT (STUN) > Authors : Marc Petit-Huguenin > Gonzalo Salgueiro > Jonathan Rosenberg > Dan Wing > Rohan Mahy > Philip Matthews > Filename : draft-ietf-tram-stunbis-04.txt > Pages : 55 > Date : 2015-03-27 > > Abstract: > Session Traversal Utilities for NAT (STUN) is a protocol that serves > as a tool for other protocols in dealing with Network Address > Translator (NAT) traversal. It can be used by an endpoint to > determine the IP address and port allocated to it by a NAT. It can > also be used to check connectivity between two endpoints, and as a > keep-alive protocol to maintain NAT bindings. STUN works with many > existing NATs, and does not require any special behavior from them. > > STUN is not a NAT traversal solution by itself. Rather, it is a tool > to be used in the context of a NAT traversal solution. > > This document obsoletes RFC 5389. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tram-stunbis-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stunbis-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/ > - -- 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 iQIcBAEBCAAGBQJVGpYgAAoJECnERZXWan7EQxUQAJb3cerMgz+k34+9ms3eXwVd vaLxOY4jla7j9Gf4O9Xmyd0wKo3VgG9xnfeil95Y/hBMkoIgiwC1iRMEJT0hH9jO fe4ekjjuO81wuPyiGOJA7CvsM+dKqc9Y3v+KE43SbYkgoFS12U2m/+0u+emdT4lJ olbAnJhl3s6+XCH1HqaSd1S7LGl3f2y1eHPLxkvpLQXZFyHZYJo1JNt0yKR/UZWu JJauXVMMqlVMjauAiY7eWOlNOpM15a7+YZ7ShED/eTForBwWyOMfcqZ+kk1at8Fi b4XfN+bHOvotoxgJ9myZZvlkMZwmne/XGLkr9HIQgJGMYlbattLpAEoaDApBnxKx HYQhl9VECis4TGxUWPSvHgoIP6tHxpomSJ1eD0XDzqqad1ZWqK8OsTy8NZdLgK1n H0xaz5QVPaB8k2uVvcmGwzKdsIfUbkFQudTjV8FuuSobsh7QeLL50o8oFdABW/1g 201Z7aPmYsseti4JGKpCO5j9VNxjNTxbB3XaAketkRA8afHAUuR8JMFUFLi4Rinv MJLaOaKciFfWrBo1FqqoGCqoy7dC8+UN3LFx6Nn9ygpNZt/n8cVNVniRk4hYkbi0 XOmIzvWtLURupJSr/Wo29K0gsmKJq2MWOK5TFxEyer9i0fArH5W7H8ueirtvWwgc vH8+lFtAOQSjokR/eUhT =/KmB -----END PGP SIGNATURE----- From nobody Tue Mar 31 08:11:34 2015 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 733E41ACDF2 for ; Tue, 31 Mar 2015 08:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, 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 drB1zfJOi6RZ for ; Tue, 31 Mar 2015 08:11:32 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1082B1ACDF1 for ; Tue, 31 Mar 2015 08:11:32 -0700 (PDT) Received: by pdrw1 with SMTP id w1so15342222pdr.0 for ; Tue, 31 Mar 2015 08:11:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8sq/dO97hjF8yz/EQPxqA04TMNO5H20vQY85vVuG/xA=; b=h7G0XPVBWi4kNUjqqQ3XfBJbwpJEbqWyKh6gAIKCeqyqS+jDnvHLy5TjnUBkV44lMk bDmOLVLqM9cpqoQjwA3orzWYUqgtqnTacmaUXjsatjSeVJ7AHcgI+heYmY27GOV6cIzk yv/cyEntJ18V2YFy5b87h3tkxgXVXT0SrNl6GznRZvVdNOvBH1ck+ChoNwIEgg/aQy6s LEYKBq6LsQpYP49CORs8Nq1faEbjUSht1wNzkuKyie1PFBlE6OIqj6CPQ0bk/JBKGc1V aC7ibS2sSh72AoMUtcbwjOQFH0rbjEbpeTBc5Fbuh14oGsDHaekOMiVhgqAu5p+EbRnR HGNQ== X-Received: by 10.70.53.226 with SMTP id e2mr11385335pdp.25.1427814691724; Tue, 31 Mar 2015 08:11:31 -0700 (PDT) Received: from [21.62.179.108] ([172.56.38.76]) by mx.google.com with ESMTPSA id v5sm14259491pdc.41.2015.03.31.08.11.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 31 Mar 2015 08:11:30 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Oleg Moskalenko X-Mailer: iPhone Mail (12F39) In-Reply-To: <551A921B.9040208@jive.com> Date: Tue, 31 Mar 2015 08:11:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55155CA7.3050403@jive.com> <551A921B.9040208@jive.com> To: Simon Perreault Archived-At: Cc: Martin Thomson , "tram@ietf.org" Subject: Re: [tram] Adoption of draft-reddy-tram-stun-path-data-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: Tue, 31 Mar 2015 15:11:33 -0000 OK, I agree. Oleg Sent from my iPhone > On Mar 31, 2015, at 5:24 AM, Simon Perreault wrote: >=20 > Le 2015-03-31 02:55, Oleg Moskalenko a =C3=A9crit : >> I agree with Martin that the PATH-CHARACTERISTIC attribute is confusing: >>=20 >> 1) In the request it has 4 bytes (1+3), in the response in has 8 bytes >> (2+2+2+2) - that is bizarre. It would be a good style to keep the >> attribute of the same size and structure, regardless of the attribute >> placement. >> 2) The server is never doing any retransmissions for the responses; >> all retransmissions in STUN are responsibility of the client. So, the >> ReqTransCnt and RespTransCnt are always equal. The number of received >> requests is always equal to the number of responses. So, why do we >> need two separate fields for the same value ? >> 3) Why ReTransCnt in the request occupies 1 bytes, but in the response >> the same value takes 2 bytes ? That is very strange. >>=20 >> I agree with the usefulness of the approach and I think that the draft >> has to be adopted - but those things to be clarified before the >> adoption. >=20 > I don't see why these relatively minor things couldn't be worked on > after adoption. >=20 > Simon From nobody Tue Mar 31 08:59:31 2015 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 A2E0F1AC439 for ; Tue, 31 Mar 2015 08:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, 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 Vv-jrqooP1zv for ; Tue, 31 Mar 2015 08:59:28 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA9A41AC411 for ; Tue, 31 Mar 2015 08:59:27 -0700 (PDT) Received: by wgbdm7 with SMTP id dm7so24483607wgb.1 for ; Tue, 31 Mar 2015 08:59:26 -0700 (PDT) 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=ZEX9mNQQHeqibEZJS6IPkklXHv36CQoav1ja7N2q+dU=; b=JWiaV1EYaRtIiNmpADpEr50xiTCSKSbcldPrIhBxuDZZoEeWogUFMSA6BJSKxKnE3J DZU2i9ze+Eo77QnfUPrYyzt2XXTT/w+AIcAx2wRgLpBePBvNtwVX27KTONuUXRivJfFR X6TVnJVc7RtRzDHnaoNhuOWboEQtY++dz/ZhBxb4tVnM3KM+F9gAm/S3kdSYHyzdvezk EociNau7c/6Bi2ZtYNVeU5nJ/97NEnaGXin8Ge5rNUybGX0PuuOUezEtuPgIJTdeiKHb WZ2w8zzIiOUXOmz2qIq8fdoYHzsxc8dkvpXstXaKTTbvcTn7sJrYb4YEFwRxk1fYPA5a /lww== MIME-Version: 1.0 X-Received: by 10.180.206.98 with SMTP id ln2mr6602842wic.94.1427817566540; Tue, 31 Mar 2015 08:59:26 -0700 (PDT) Received: by 10.194.190.18 with HTTP; Tue, 31 Mar 2015 08:59:26 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A411F90DF@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A411F90DF@xmb-rcd-x10.cisco.com> Date: Tue, 31 Mar 2015 08:59:26 -0700 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Simon Perreault , Martin Thomson , "tram@ietf.org" Subject: Re: [tram] Adoption of draft-reddy-tram-stun-path-data-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: Tue, 31 Mar 2015 15:59:29 -0000 On Tue, Mar 31, 2015 at 5:23 AM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko >> Sent: Tuesday, March 31, 2015 12:25 PM >> To: Martin Thomson >> Cc: Simon Perreault; tram@ietf.org >> Subject: Re: [tram] Adoption of draft-reddy-tram-stun-path-data-01 >> >> I agree with Martin that the PATH-CHARACTERISTIC attribute is confusing: >> >> 1) In the request it has 4 bytes (1+3), in the response in has 8 bytes >> (2+2+2+2) - that is bizarre. It would be a good style to keep the attribute of >> the same size and structure, regardless of the attribute placement. >> 2) The server is never doing any retransmissions for the responses; all >> retransmissions in STUN are responsibility of the client. So, the ReqTransCnt >> and RespTransCnt are always equal. The number of received requests is >> always equal to the number of responses. So, why do we need two separate >> fields for the same value ? >> 3) Why ReTransCnt in the request occupies 1 bytes, but in the response the >> same value takes 2 bytes ? That is very strange. > > Agreed on all the above points; will update the format of PATH-CHARACTERISTIC attribute as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved, should be 0 | ReTransCnt | RespTransCnt | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > RespTransCnt must be set to zero in request and ignored by the server. > RespTransCnt could be zero in response (e.g. server is stateless). That's cool. I support the adoption. Thanks Oleg > >> >> I agree with the usefulness of the approach and I think that the draft has to >> be adopted > > Thanks, > -Tiru > >> - but those things to be clarified before the adoption. >> >> Thanks >> Oleg >> >> >> On Mon, Mar 30, 2015 at 12:55 PM, Martin Thomson >> wrote: >> > On 27 March 2015 at 08:35, Simon Perreault wrote: >> >> This is to confirm the adoption of draft-reddy-tram-stun-path-data-01 >> >> as a working group draft. If anyone is opposed, now is a good time to >> >> explain why. >> > >> > This looks fine in general, with one issue: >> > >> > Issue: >> > ReTransCnt, ReqTransCnt and RespTransCnt are so similar that this is >> > very confusing. When I finally parsed this, I realize that the server >> > isn't going to have three piece of information; it only needs to a) >> > echo the client's counter, and b) (if stateful) indicate how many >> > times it has responded over time. As specified, I can't see any way >> > that having the number of received messages being different to the >> > number of responses is of any value. >> > >> > Finally, I think that you should specify a more regular form for the >> > parameter. One byte of Client Retransmission Counter, and one byte of >> > Server Retransmission Counter should be easy to understand. Zero >> > being an indication that the sender didn't want to say for any reason, >> > as currently specified. >> > >> > Nit: >> > These metrics can then be used >> > by the controlling agent to influence the ICE candidate pair >> > priorities. >> > Changing priorities is not possible, changing what might be selected is. >> > >> > _______________________________________________ >> > 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 Tue Mar 31 12:43:55 2015 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 8B1831AC415 for ; Tue, 31 Mar 2015 12:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 CxQ5DxgIdWai for ; Tue, 31 Mar 2015 12:43:51 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62DB61AC3BE for ; Tue, 31 Mar 2015 12:43:51 -0700 (PDT) Received: by igcau2 with SMTP id au2so28430709igc.0 for ; Tue, 31 Mar 2015 12:43:50 -0700 (PDT) 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=F3r4V5VH0cvLafiLdrErkm09qbpcQl51oBUGk2hulDo=; b=RHI9Kzj2PQmweAMvPkupmC7P+vSRkZf2vbSCIq9YQGxoZRLmYuKak5aDhrHH2nZQ81 552rwgVsj8At/s6mhMFddLavEQEBi5ZKTxUJpYJeKrHC/DYa4RDbdzUW0cSHid5L4oJt sGzxSQxdqdluWyEclL8dYmpoxm56hfLDG73SpeupeNFhqTrHT6141AdPH2WM43B035Lg Qr2/JmnSGpjMTqZdmfBxs6KpMe0AbGLuyRpuYTaofwfwBFuoUorGC52WFO3f9GaAjp8P ids/lwXdJfduM1QisYdW3BXnAogJ1lXgXXe7d/sog1MZjx8cezJG5YKxU1ZRsOwmgqpJ tTTw== 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=F3r4V5VH0cvLafiLdrErkm09qbpcQl51oBUGk2hulDo=; b=Qi2hchr9XuIiBONVlZiF+8v7VK9SF50ABNvl9ghGsdCFBUy8L9iMA7PTGjydktOU2b bAuF3CkHxsBBfk0nQ/7liNfibBDsLM+nxKULwN5La12Mpjn/PtGK4RaqV0cWauRwelwv zNWvt5wfzj+vN3lHAX9TYMlAVVC10+hsZhVHEvs8E3ClAVjiLm0YezYebxFn1I0jZaoq ewFDFvpD6HMcSOoDsQL4RkEgNCEANR9GkW7CjT1nehM/1htTrbSRNCSryohQIXn3NLbF GXL6IbHkLcMkymvFWpV75idWI0VDdyrjCvwZgUyKXsM3Y77dWIfzv8hzYhPzdcZWIzI9 UEXg== X-Gm-Message-State: ALoCoQmWHIECFmI+Mpwo9V7bENmDLKAqorPrKgVqAp+5rqNK2Rl9ObDPl6TNeXeplO7RF6FDgZFX X-Received: by 10.107.19.201 with SMTP id 70mr14862130iot.71.1427831030766; Tue, 31 Mar 2015 12:43:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.64.42 with HTTP; Tue, 31 Mar 2015 12:43:30 -0700 (PDT) In-Reply-To: <551A9620.5010405@acm.org> References: <20150327075539.26326.49374.idtracker@ietfa.amsl.com> <551A9620.5010405@acm.org> From: Justin Uberti Date: Tue, 31 Mar 2015 12:43:30 -0700 Message-ID: To: Marc Petit-Huguenin Content-Type: multipart/alternative; boundary=001a113f7fd863a74405129ad106 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-04.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, 31 Mar 2015 19:43:53 -0000 --001a113f7fd863a74405129ad106 Content-Type: text/plain; charset=UTF-8 Especially for short-term auth, do we need to send the entire 256-bit MAC? I am concerned that some implementations will be slow to switch to stun-bis because of the increased size (and thereby bandwidth) needed for connectivity checks. Would it make sense to allow use of a truncated SHA-256 MAC (e.g. 80 bits or less), similar to how this is done in SRTP? On Tue, Mar 31, 2015 at 5:42 AM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Changelog: > > o Remove SCTP. > o Remove DANE. > o s/MESSAGE-INTEGRITY2/MESSAGE-INTEGRITY-SHA256/ > o Remove Salted SHA256 password hash. > o The RTO delay between transactions is removed. > o Make clear that reusing NONCE will trigger a wasted round trip. > > Remaining TODO list: > > 1. Add reference to RFC 5769 (stun vectors). > 2. Add flow diagram for long-term authentication. > 3. Add vectors for SHA256 password hash. > > On 03/27/2015 01:55 AM, internet-drafts@ietf.org wrote: > > > > 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 : Session Traversal Utilities for NAT (STUN) > > Authors : Marc Petit-Huguenin > > Gonzalo Salgueiro > > Jonathan Rosenberg > > Dan Wing > > Rohan Mahy > > Philip Matthews > > Filename : draft-ietf-tram-stunbis-04.txt > > Pages : 55 > > Date : 2015-03-27 > > > > Abstract: > > Session Traversal Utilities for NAT (STUN) is a protocol that serves > > as a tool for other protocols in dealing with Network Address > > Translator (NAT) traversal. It can be used by an endpoint to > > determine the IP address and port allocated to it by a NAT. It can > > also be used to check connectivity between two endpoints, and as a > > keep-alive protocol to maintain NAT bindings. STUN works with many > > existing NATs, and does not require any special behavior from them. > > > > STUN is not a NAT traversal solution by itself. Rather, it is a tool > > to be used in the context of a NAT traversal solution. > > > > This document obsoletes RFC 5389. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-tram-stunbis-04 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stunbis-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/ > > > > - -- > 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 > > iQIcBAEBCAAGBQJVGpYgAAoJECnERZXWan7EQxUQAJb3cerMgz+k34+9ms3eXwVd > vaLxOY4jla7j9Gf4O9Xmyd0wKo3VgG9xnfeil95Y/hBMkoIgiwC1iRMEJT0hH9jO > fe4ekjjuO81wuPyiGOJA7CvsM+dKqc9Y3v+KE43SbYkgoFS12U2m/+0u+emdT4lJ > olbAnJhl3s6+XCH1HqaSd1S7LGl3f2y1eHPLxkvpLQXZFyHZYJo1JNt0yKR/UZWu > JJauXVMMqlVMjauAiY7eWOlNOpM15a7+YZ7ShED/eTForBwWyOMfcqZ+kk1at8Fi > b4XfN+bHOvotoxgJ9myZZvlkMZwmne/XGLkr9HIQgJGMYlbattLpAEoaDApBnxKx > HYQhl9VECis4TGxUWPSvHgoIP6tHxpomSJ1eD0XDzqqad1ZWqK8OsTy8NZdLgK1n > H0xaz5QVPaB8k2uVvcmGwzKdsIfUbkFQudTjV8FuuSobsh7QeLL50o8oFdABW/1g > 201Z7aPmYsseti4JGKpCO5j9VNxjNTxbB3XaAketkRA8afHAUuR8JMFUFLi4Rinv > MJLaOaKciFfWrBo1FqqoGCqoy7dC8+UN3LFx6Nn9ygpNZt/n8cVNVniRk4hYkbi0 > XOmIzvWtLURupJSr/Wo29K0gsmKJq2MWOK5TFxEyer9i0fArH5W7H8ueirtvWwgc > vH8+lFtAOQSjokR/eUhT > =/KmB > -----END PGP SIGNATURE----- > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --001a113f7fd863a74405129ad106 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Especially for short-term auth, do we need to send the ent= ire 256-bit MAC? I am concerned that some implementations will be slow to s= witch to stun-bis because of the increased size (and thereby bandwidth) nee= ded for connectivity checks.

Would it make sense to allo= w use of a truncated SHA-256 MAC (e.g. 80 bits or less), similar to how thi= s is done in SRTP?

On Tue, Mar 31, 2015 at 5:42 AM, Marc Petit-Huguenin <petithug= @acm.org> wrote:
-----BEG= IN PGP SIGNED MESSAGE-----
Hash: SHA256

Changelog:

o=C2=A0 Remove SCTP.
o=C2=A0 Remove DANE.
o=C2=A0 s/MESSAGE-INTEGRITY2/MESSAGE-INTEGRITY-SHA256/
o=C2=A0 Remove Salted SHA256 password hash.
o=C2=A0 The RTO delay between transactions is removed.
o=C2=A0 Make clear that reusing NONCE will trigger a wasted round trip.

Remaining TODO list:

1.=C2=A0 Add reference to RFC 5769 (stun vectors).
2.=C2=A0 Add flow diagram for long-term authentication.
3.=C2=A0 Add vectors for SHA256 password hash.

On 03/27/2015 01:55 AM, interne= t-drafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
>=C2=A0 This draft is a work item of the TURN Revised and Modernized Wor= king Group of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Session Traversal Utilities for NAT (STUN)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Marc Petit-Huguenin
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Gonzalo Salgueiro
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Jonathan Rosenberg
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Dan Wing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Rohan Mahy
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Philip Matthews
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-tram-stunbis-04.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 55
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2015-03-27
>
> Abstract:
>=C2=A0 =C2=A0 Session Traversal Utilities for NAT (STUN) is a protocol = that serves
>=C2=A0 =C2=A0 as a tool for other protocols in dealing with Network Add= ress
>=C2=A0 =C2=A0 Translator (NAT) traversal.=C2=A0 It can be used by an en= dpoint to
>=C2=A0 =C2=A0 determine the IP address and port allocated to it by a NA= T.=C2=A0 It can
>=C2=A0 =C2=A0 also be used to check connectivity between two endpoints,= and as a
>=C2=A0 =C2=A0 keep-alive protocol to maintain NAT bindings.=C2=A0 STUN = works with many
>=C2=A0 =C2=A0 existing NATs, and does not require any special behavior = from them.
>
>=C2=A0 =C2=A0 STUN is not a NAT traversal solution by itself.=C2=A0 Rat= her, it is a tool
>=C2=A0 =C2=A0 to be used in the context of a NAT traversal solution. >
>=C2=A0 =C2=A0 This document obsoletes RFC 5389.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/=
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-tram-stunbis-04
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-st= unbis-04
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> 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/
>

- --
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: htt= p://blog.marc.petit-huguenin.org
Profile: = http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJVGpYgAAoJECnERZXWan7EQxUQAJb3cerMgz+k34+9ms3eXwVd
vaLxOY4jla7j9Gf4O9Xmyd0wKo3VgG9xnfeil95Y/hBMkoIgiwC1iRMEJT0hH9jO
fe4ekjjuO81wuPyiGOJA7CvsM+dKqc9Y3v+KE43SbYkgoFS12U2m/+0u+emdT4lJ
olbAnJhl3s6+XCH1HqaSd1S7LGl3f2y1eHPLxkvpLQXZFyHZYJo1JNt0yKR/UZWu
JJauXVMMqlVMjauAiY7eWOlNOpM15a7+YZ7ShED/eTForBwWyOMfcqZ+kk1at8Fi
b4XfN+bHOvotoxgJ9myZZvlkMZwmne/XGLkr9HIQgJGMYlbattLpAEoaDApBnxKx
HYQhl9VECis4TGxUWPSvHgoIP6tHxpomSJ1eD0XDzqqad1ZWqK8OsTy8NZdLgK1n
H0xaz5QVPaB8k2uVvcmGwzKdsIfUbkFQudTjV8FuuSobsh7QeLL50o8oFdABW/1g
201Z7aPmYsseti4JGKpCO5j9VNxjNTxbB3XaAketkRA8afHAUuR8JMFUFLi4Rinv
MJLaOaKciFfWrBo1FqqoGCqoy7dC8+UN3LFx6Nn9ygpNZt/n8cVNVniRk4hYkbi0
XOmIzvWtLURupJSr/Wo29K0gsmKJq2MWOK5TFxEyer9i0fArH5W7H8ueirtvWwgc
vH8+lFtAOQSjokR/eUhT
=3D/KmB
-----END PGP SIGNATURE-----

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

--001a113f7fd863a74405129ad106--