From nobody Mon Nov 19 06:35:43 2018 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5152130DD5 for ; Mon, 19 Nov 2018 06:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.771 X-Spam-Level: X-Spam-Status: No, score=-4.771 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Pi2h0TIG; dkim=pass (1024-bit key) header.d=ericsson.com header.b=CEQnCftS Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIfpabnd88n6 for ; Mon, 19 Nov 2018 06:35:36 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 3C8E112426A for ; Mon, 19 Nov 2018 06:35:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1542638126; x=1545230126; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=SKORms3Tbuem02S6hZKdpz6L1jkPSqKxYSaSUf41OIM=; b=Pi2h0TIG3NGjXuFHH8AJ+8v4QxTfltjXmM3Y9GAhjMInLu18UW9AeVrvk/E9p9G5 3bmiJKqJZbvbOzZpnJZ1hH0aBfpVFDt/R97RLheAU/NwEqjHvBZShrWl8M/yaDnz rmyjhBV2AQ2X4DIOfwR48JkRryxZtXLp/gYbYQ1Bxi8=; X-AuditID: c1b4fb30-f15ff700000043c4-3f-5bf2ca2b5c90 Received: from ESESBMB504.ericsson.se (Unknown_Domain [153.88.183.117]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 84.22.17348.B2AC2FB5; Mon, 19 Nov 2018 15:35:23 +0100 (CET) Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 19 Nov 2018 15:35:23 +0100 Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 19 Nov 2018 15:35:23 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SKORms3Tbuem02S6hZKdpz6L1jkPSqKxYSaSUf41OIM=; b=CEQnCftSQkrsWQPXWbzh4JN5ysMgkxmV6Dx1y8vLF65pAFsfZXfKPyZAcPafnbYYdGSDhPB2ZQtNpTceiS7p+kuTj9T5c8B6R1x9iKWFe/G0YvEBIR08KX0BRG9+G88MSn1iedtpcT/D3GEI+64+G/s6okGGR1c/ruvYvdb3qKQ= Received: from DB7PR07MB4934.eurprd07.prod.outlook.com (20.177.192.211) by DB7PR07MB4523.eurprd07.prod.outlook.com (52.135.140.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.9; Mon, 19 Nov 2018 14:35:18 +0000 Received: from DB7PR07MB4934.eurprd07.prod.outlook.com ([fe80::b1b5:857b:a4fb:d45d]) by DB7PR07MB4934.eurprd07.prod.outlook.com ([fe80::b1b5:857b:a4fb:d45d%3]) with mapi id 15.20.1361.013; Mon, 19 Nov 2018 14:35:18 +0000 From: Gonzalo Camarillo To: Spencer Dawkins at IETF , "Marc Petit-Huguenin" CC: Eric Rescorla , "tram-chairs@ietf.org" , "tram@ietf.org" , "Asveren, Tolga" , IESG , "draft-ietf-tram-stunbis@ietf.org" Thread-Topic: [tram] Eric Rescorla's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT) Thread-Index: AQHUgBUYh3SWjavZEkyxlhSdCV9H9w== Date: Mon, 19 Nov 2018 14:35:18 +0000 Message-ID: References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> <02569943-db8f-654e-7322-49bc1f1a1163@acm.org> <235b838f-2800-2cd0-8b01-947e70837619@ericsson.com> <472563ee-5fc3-655d-8e31-138cc774e608@acm.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [89.166.49.243] user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 x-clientproxiedby: AM6PR0202CA0068.eurprd02.prod.outlook.com (2603:10a6:20b:3a::45) To DB7PR07MB4934.eurprd07.prod.outlook.com (2603:10a6:10:5b::19) authentication-results: spf=none (sender IP is ) smtp.mailfrom=gonzalo.camarillo@ericsson.com; x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB7PR07MB4523; 6:vm1mgRzYa8ELWtBeUCz3mwJdA/XtHLowFlmxK6etfBVQkJwj+BuLQUdt6djx7oFsqyHQfQFcJ9fe6yQiqr4/isEv2x0kw9BS6hN2at6nXuffQja3J4+Wt7lx7PSw+uLLUeyfLLvdlPJY+5w8XThg9mW0q4+XCb0yPEGEeydC7OylqMxAcHSfuaTC1eOrdq1ZFP/rkh13NUkpE91BmMyErb8fWeEzJEL/zSShQoLrFCg0oFPK378jLeJgCtgA2Nwhq1VJjSRvkU+FE6ubQE1Ou09PvWpIsCedytk0IgTO56kMvrmdwOzTu7h+6IGdlXXZrEW4LpqRj1xFR3YGUogUKnneVsF2CAX6DQ0mUzfF64hwPLkQdoxPgS1QwJ2BVGPRyNJUBdufQmaW8jHtOis3BOCgVaw3+6Hqg6GU+J/9D9kQ+2wfJGvBBVbtIvI0ehlih408Zfsu26yEtPoyrkjrEg==; 5:U5vHW/Ikg50xIZJkiGYtjxK2VHa4OCUti1qxWSBHG500RQw/XvDVXsWWEYNin74xHVgDfMbVfl/2MTFTNrdsykVf71ldNBzCAKzWO6XSB+nBpKSrr3236djYD4wovwAhyDsIq6Cv9IAFyPHJFw59ey7Kbd9I6SBTDYene7PkV/c=; 7:zZ3lVipXwPy5EBApvocoLw/e3WK/fk/Q16bLqRZGDX1kf4Hhw6zmgMR60OUqcaP2OEryIRUNf3EjCn3xxRVOqspnZfZ7STHCRbq7RJ503sYe8Rjp8r/c7aWWT/UX7U8frDjDgB0LXAr8Q9JSkVSnaQ== x-ms-office365-filtering-correlation-id: 27860c1a-8d4d-4f4e-cce9-08d64e2c3a25 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:DB7PR07MB4523; x-ms-traffictypediagnostic: DB7PR07MB4523: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231415)(944501410)(52105112)(148016)(149066)(150057)(6041310)(20161123564045)(20161123562045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:DB7PR07MB4523; BCL:0; PCL:0; RULEID:; SRVR:DB7PR07MB4523; x-forefront-prvs: 08617F610C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(346002)(396003)(376002)(136003)(54094003)(252514010)(51444003)(199004)(189003)(71200400001)(97736004)(64126003)(8676002)(316002)(3260700006)(25786009)(478600001)(81166006)(81156014)(4326008)(6306002)(2906002)(14454004)(446003)(551934003)(106356001)(52116002)(68736007)(5660300001)(36756003)(8936002)(6512007)(71190400001)(256004)(966005)(93886005)(99286004)(53946003)(14444005)(53936002)(4744004)(2616005)(476003)(31696002)(551544002)(486006)(45080400002)(11346002)(86362001)(65806001)(65956001)(66066001)(65826007)(53546011)(386003)(6506007)(31686004)(2900100001)(76176011)(105586002)(6486002)(110136005)(6246003)(58126008)(6436002)(229853002)(305945005)(7736002)(3846002)(54906003)(102836004)(6116002)(39060400002)(186003)(26005)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB4523; H:DB7PR07MB4934.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: LN8xAcPdv9avg9zHv1BHOHyFarExQrfjb/W4z9aFHoJnDw5YcbrTV+cm41zWNcQ+XLx5wJi+Lmql3sIAt0Apagx4UNDG0BmyXFDxoZK1Fc/lLyBBkKKg2MD8zq1Yagf16rpnyNRJioDD2x9Dv4pIKIh3VP/nA+cpghrabOPbymPLGMU6vv77EnIgIVGDYiR1CItKvn3SUsV9m4Tpj4y/MWyGNmP0+25MXOD89NW9KtFns2vtn8Fh6a9WMi2CyD31RbhE3AhBB0IK4v1L6sIK91a3q6yhxVrK/09ys9oZrgWlTinkqOS9QOEmDquaWUwciUqAlQDX3ydQ4tBfDh0bp+meGSAxpikF/Lb77CQ28Is= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <9EDD6BAA0A04F142BACADE8F457CB31D@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 27860c1a-8d4d-4f4e-cce9-08d64e2c3a25 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2018 14:35:18.7942 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4523 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA01Sa0hTYRjmO2dnOxsNvrzkm5Xgoh9K3qUOJFoIMQzF6k9ooitPKuq0MxU1 CDOUvKRmVrosw4bmLWHeRfOSpg7vhpopaU5KLRUDy9Ro2zHo3/O8z/O8l4+PJs3aKGs6QhnH ckpFlEwoERRdaYp3cNRtBjo/d2cy6ieEzKvVYRFTuPuAZEar5wimrKCNZGrLt0RM+XaFkNmo GRWepeUT7y/IW9RzIrlGs03I24rzkfzhYjrpTwVIPELZqIgElnPyDJGEj/3aEMQOZxOJVV8L UAqaTSMyEU0DdgddzolMJKHNcA+Cpd+fCJ5sIehobKUykdhANATsjXBGQYDzSKgo3SB4oYCA 3EZvPvEZQfF2BmlsK8QM3Ks6ZfRY4DBoL2pBRg+JtxFsdRmJmDY3CB9Xpiij3wKHw8SOD+93 hOW1WVMbAT4BhVkmtxR7wf38RhE/6qUQtHrjKDEtxhehbrjEhBE+BD911abdSGwFM/oSEwaM QdM2QvLYEpYX/1A8toWhtQWTxxIHwVLqgul6wIUIqnebRXxTBcyn1eyHT8LQlB7x+BiMl2Qh PjAphD7tjpAXfKFmvk/AC6MI5qZb9sfZQ+6jZ/srRcJSyTiVh9zU/22rNlxNYjuobXXiy3IY G0iheGwLBVkLIrXpNQ7CQJFe8AJRlchSxaquRYe5ujqyXMR1lSpG6ahk47TI8Ke66necm9Hy l3PdCNNIdkCqC9oMNKMUCaqk6G4ENCmzkPqXGUrSUEVSMsvFBHPxUayqGx2hBTIrKeNXF2CG wxRxbCTLxrLcP5WgxdYpyN3+h0fe+GD/jQrzzje3Qxrulk5LsaWLlfit3bsZu/St1p6M79k+ WYkjs0+S3VqCbWq50n6xdN17Nei4xOa0sji4Q3RVd9j3Q87gzM2B9tdnxjrLn96RnN+zGdb2 Wom83NbdVvT6yN2jk5fjv1WXN+XeUl/y9/NMHWmozH3cq3TQygSqcIWLPcmpFH8BI565RE8D AAA= Archived-At: Subject: Re: [tram] Eric Rescorla's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 19 Nov 2018 14:35:41 -0000 SGkgU3BlbmNlciwNCg0Kd2hhdCBpcyB0aGUgc3RhdHVzIG9mIHRoaXM/IEFyZSB0aGUgYXV0aG9y cyBhbmQgdGhlIGRvY3VtZW50IHNoZXBoZXJkDQp3b3JraW5nIHdpdGggdGhlIHJlbGV2YW50IEFE cyBvbiB0aGUgZGlzY3Vzc2VzPw0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLXRyYW0tc3R1bi1wbXR1ZC9iYWxsb3QvDQoNCkNoZWVycywNCg0KR29uemFsbw0K DQpPbiAyNC1PY3QtMTggMTY6NDAsIFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGIHdyb3RlOg0KPiBI aSwgTWFyYyzCoA0KPiANCj4gT24gV2VkLCBPY3QgMjQsIDIwMTggYXQgMzo0NCBBTSBNYXJjIFBl dGl0LUh1Z3VlbmluIDxwZXRpdGh1Z0BhY20ub3JnDQo+IDxtYWlsdG86cGV0aXRodWdAYWNtLm9y Zz4+IHdyb3RlOg0KPiANCj4gICAgIEhpIFNwZW5jZXIsDQo+IA0KPiAgICAgSSBzZW50IG15IGFu c3dlcnMgdG8gRXJpYyBSZXNjb3JsYSBxdWVzdGlvbnMgb24gMjAxOC0xMC0wNyBmb2xsb3dpbmcN Cj4gICAgIGFuIGluLXBlcnNvbiBtZWV0aW5nIHdpdGggbXkgY28tYXV0aG9yLCBidXQgbmV2ZXIg Z290IGEgcmVzcG9uc2UNCj4gICAgIGJhY2suwqAgQmVjYXVzZSB0aGVyZSB3YXMgbm8gY2hhbmdl IHByb3Bvc2VkIGJ5IEVyaWMgSSB3ZW50IGFoZWFkIGFuZA0KPiAgICAgcHVibGlzaGVkIC0xOSBh IGNvdXBsZSBvZiB3ZWVrcyBhZnRlciB0aGF0LCB3aXRoIHRoZSB0ZXh0IGFncmVlZCBpbg0KPiAg ICAgcmVzcG9uc2UgdG8gQWRhbSdzIGFuZCBCZW5qYW1pbidzIGNvbW1lbnRzLg0KPiANCj4gICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvdHJhbS9jdXJyZW50L21zZzAy NjM1Lmh0bWwNCj4gDQo+IA0KPiBBaCAtIEkgd29uZGVyIGlmIHRoYXQgd2FzIHdoYXQgaGFkIGhh cHBlbmVkLsKgDQo+IA0KPiBJdCBzb3VuZHMgbGlrZSB5b3UgZGlkIHRoZSByaWdodCB0aGluZywg YW5kIHRoYXQgRXJpYyBoYXMgbm93IHJlc3BvbmRlZCwNCj4gd2hpY2ggaXMgYWxzbyB0aGUgcmln aHQgdGhpbmcgdG8gZG8uwqANCj4gDQo+IFRoYW5rcyBmb3IgaGVscGluZyBtZSB1bmRlcnN0YW5k Lg0KPiANCj4gU3BlbmNlcg0KPiDCoA0KPiANCj4gICAgIE9uIDEwLzIzLzE4IDc6MjggUE0sIFNw ZW5jZXIgRGF3a2lucyBhdCBJRVRGIHdyb3RlOg0KPiAgICAgPiBIaSwgTWFyYywNCj4gICAgID4N Cj4gICAgID4gSSBzZWUgdGhhdCBhIC0xOSBoYXMgYmVlbiBzdWJtaXR0ZWQsIGJ1dCBkaWRuJ3Qg c2VlIGEgcmVwbHkgZnJvbQ0KPiAgICAgRXJpYyBpbg0KPiAgICAgPiB0aGlzIHRocmVhZC4gRG8g eW91IHRoaW5rIHRoYXQgeW91J3ZlIGNvbnZlcmdlZD8NCj4gICAgID4NCj4gICAgID4gKEkgc2F3 IGFuIG9mZmVyIG9mIGEgY29uZmVyZW5jZSBjYWxsLCBzbyB0aG91Z2h0IGFuIG91dC1vZi1iYW5k DQo+ICAgICA+IGNvbnZlcnNhdGlvbiBtaWdodCBoYXZlIGhhcHBlbmVkKQ0KPiAgICAgPg0KPiAg ICAgPiBUaGFua3MsDQo+ICAgICA+DQo+ICAgICA+IFNwZW5jZXINCj4gICAgID4NCj4gICAgID4g T24gU3VuLCBPY3QgNywgMjAxOCBhdCA5OjM1IEFNIE1hcmMgUGV0aXQtSHVndWVuaW4NCj4gICAg IDxwZXRpdGh1Z0BhY20ub3JnIDxtYWlsdG86cGV0aXRodWdAYWNtLm9yZz4+IHdyb3RlOg0KPiAg ICAgPg0KPiAgICAgPj4gSGkgRXJpYywNCj4gICAgID4+DQo+ICAgICA+PiBQbGVhc2Ugc2VlIGlu bGluZS4NCj4gICAgID4+DQo+ICAgICA+PiBPbiAwOS8xMC8yMDE4IDAzOjI1IEFNLCBFcmljIFJl c2NvcmxhIHdyb3RlOg0KPiAgICAgPj4+IE9uIFNhdCwgU2VwIDgsIDIwMTggYXQgMjozMSBQTSwg TWFyYyBQZXRpdC1IdWd1ZW5pbg0KPiAgICAgPHBldGl0aHVnQGFjbS5vcmcgPG1haWx0bzpwZXRp dGh1Z0BhY20ub3JnPj4NCj4gICAgID4+PiB3cm90ZToNCj4gICAgID4+Pg0KPiAgICAgPj4+PiBI aSBFcmljLA0KPiAgICAgPj4+Pg0KPiAgICAgPj4+PiBBcG9sb2dpZXMgZm9yIHRoZSBkZWxheSBp biBnZXR0aW5nIGJhY2sgdG8gdGhhdC4NCj4gICAgID4+Pj4NCj4gICAgID4+Pj4gSSB0aGluayB0 aGF0IHRoZXJlIGlzIHNvbWUgbWlzdW5kZXJzdGFuZGluZyBpbiB3aGF0IFNUVU5iaXMgaXMNCj4g ICAgIHRyeWluZyB0bw0KPiAgICAgPj4+PiBkbywgc28gcGxlYXNlIHNlZSBteSBjb21tZW50cyBp bmxpbmUuDQo+ICAgICA+Pj4+DQo+ICAgICA+Pj4+IE9uIDA2LzE4LzIwMTggMTA6NDMgQU0sIEVy aWMgUmVzY29ybGEgd3JvdGU6DQo+ICAgICA+Pj4+PiBIaSBmb2xrcywNCj4gICAgID4+Pj4+DQo+ ICAgICA+Pj4+PiBJJ3ZlIHJldmlld2VkIHRoZSBuZXcgdmVyc2lvbiwgYnV0IEkgZG9uJ3QgdGhp bmsgdGhhdCB0aGUgYmlkZG93bg0KPiAgICAgPj4+Pj4gZGlzY3Vzc2lvbiBtYWtlcyBtdWNoIHNl bnNlLg0KPiAgICAgPj4+Pj4NCj4gICAgID4+Pj4+IFRvIHJlY2FwLCB0aGVyZSBhcmUgdHdvIGhh c2hlcyBoZXJlOg0KPiAgICAgPj4+Pj4NCj4gICAgID4+Pj4+IC0gVGhlIGhhc2ggd2hpY2ggeW91 IHVzZSB0byBzdG9yZSB0aGUgcGFzc3dvcmQgd2l0aCAoY3VycmVudGx5DQo+ICAgICBtb3N0bHkN Cj4gICAgID4+Pj4gTUQ1KQ0KPiAgICAgPj4+Pj4gLSBUaGUgaGFzaCB5b3UgdXNlIHRvIGNvbXB1 dGUgdGhlIE1BQyAoY3VycmVudGx5IFNIQS0xKS4NCj4gICAgID4+Pj4+DQo+ICAgICA+Pj4+PiBG aXJzdCwgbGV0J3Mgc3RpcHVsYXRlIHRoYXQgTUQ1IGlzbid0IGEgZ3JlYXQgY2hvaWNlIGhlcmUs DQo+ICAgICB0aG91Z2ggU0hBLTENCj4gICAgID4+Pj4+IGlzbid0IGEgZ3JlYXQgY2hvaWNlDQo+ ICAgICA+Pj4+PiBlaXRoZXIgZm9yIHB3ZCBoYXNoaW5nIFlvdSB3YW50IEFyZ29uIG9yIHRoZSBs aWtlLiBXaXRoIHRoYXQgc2FpZCwNCj4gICAgID4+Pj4gdGhlcmUncw0KPiAgICAgPj4+Pj4gbm8g c2Vuc2libGUNCj4gICAgID4+Pj4+IGJpZGRvd24gYXR0YWNrIG9uIHRoYXQgaGFzaCBiZWNhdXNl IGl0J3MgYSBwZXItc2VydmVyIGZlYXR1cmUsDQo+ICAgICBub3QgYQ0KPiAgICAgPj4+Pj4gcGVy LXRyYW5zYWN0aW9uDQo+ICAgICA+Pj4+PiBmZWF0dXJlLiBTbywgYXMgbG9uZyBhcyB0aGUgc2Vy dmVyIGhhcyBNRDUtaGFzaGVkIHBhc3N3b3JkcywgdGhlDQo+ICAgICA+Pj4+IHNpdHVhdGlvbg0K PiAgICAgPj4+Pj4gaXMgYmFkLg0KPiAgICAgPj4+Pg0KPiAgICAgPj4+PiBJbiBubyBwbGFjZSBp biBTVFVOYmlzIHdlIGFyZSBwcm9wb3NpbmcgdG8gdXNlIFNIQS0xIGZvciBwYXNzd29yZA0KPiAg ICAgPj4+PiBlbmNyeXB0aW9uLCBzbyBJIGFtIG5vdCBzdXJlIHdoZXJlIHRoYXQgY29tZSBmcm9t LsKgIFdoYXQgd2UNCj4gICAgIHByb3Bvc2UgaXM6DQo+ICAgICA+Pj4+DQo+ICAgICA+Pj4NCj4g ICAgID4+PiBZb3UncmUgcmlnaHQsIGl0J3MgU0hBLTI1NiwgYnV0IG15IGNyaXRpY2lzbXMgYXBw bHkgZXF1YWxseSB0aGVyZS4NCj4gICAgID4+DQo+ICAgICA+PiBTSEEtMjU2IHdhcyB3aGF0IHRo ZSBXRyBhZG9wdGVkLsKgIE91ciBhdHRlbXB0cyB0byBhZGQgb3RoZXIgcGFzc3dvcmRzDQo+ICAg ICA+PiBlbmNyeXB0aW9uIG1lY2hhbmlzbXMgd2VyZSBkZW5pZWQuwqAgSXQgaXMgdHJ1ZSB0aGF0 IEFyZ29uMiB3YXMNCj4gICAgIG5vdCBpbiB0aGF0DQo+ICAgICA+PiBsaXN0IChpbiBvdXIgZGVm ZW5zZSBBcmdvbjIgd2FzIG5vdCBrbm93biBiZWZvcmUgSnVseSAyMDE1KSwgYnV0DQo+ICAgICBJ IGRvIG5vdA0KPiAgICAgPj4gc2VlIHdoeSB0aGUgV0cgd291bGQgaGF2ZSBhY2NlcHRlZCB0aGF0 IG9uZSBvdmVyIHRoZSBvdGhlcnMuwqANCj4gICAgIEFueXdheSBpdCBpcw0KPiAgICAgPj4gdG9v IGxhdGUgdG8gZml4IHRoaXMsIGFzIGl0IGlzIG15IHVuZGVyc3RhbmRpbmcgdGhhdCB0aGUgV0cg ZG9lcw0KPiAgICAgbm90IGhhdmUNCj4gICAgID4+IGVub3VnaCBlbmVyZ3kgdG8gcmVhY2ggY29u c2Vuc3VzIG9uIGEgbmV3IHBhc3N3b3JkIGFsZ29yaXRobS7CoA0KPiAgICAgU29tZW9uZSBjYW4N Cj4gICAgID4+IGp1c3Qgd3JpdGUgYSBkcmFmdCBhZGRpbmcgQXJnb24yIGFzIHBhc3N3b3JkIGVu Y3J5cHRpb24sIGFzIHdlDQo+ICAgICB3aWxsIGhhdmUgYQ0KPiAgICAgPj4gSUFOQSByZWdpc3Ry eSBmb3IgdGhhdC4NCj4gICAgID4+DQo+ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+PiAt IEVzdGFibGlzaCBhIHJlZ2lzdHJ5IGZvciBuZXcgcGFzc3dvcmQgYWxnb3JpdGhtcyAoc2VjdGlv bg0KPiAgICAgMTguNSksIHNvDQo+ICAgICA+Pj4+IGFsZ29yaXRobXMgbGlrZSBBcmdvbjIgY291 bGQgYmUgYWRkZWQgbGF0ZXIgKGJ1dCBub3RlIHRoYXQgb3VyIG93bg0KPiAgICAgPj4+PiBwcm9w b3NhbHMgdG8gYWRkIG1vcmUgcGFzc3dvcmQgYWxnb3JpdGhtcyB3ZXJlIHJlamVjdGVkIGJ5IHRo ZQ0KPiAgICAgd29ya2luZw0KPiAgICAgPj4+PiBncm91cCkuDQo+ICAgICA+Pj4+IC0gQWRkIGEg bmV3IHBhc3N3b3JkIGFsZ29yaXRobSB0byB0aGF0IHJlZ2lzdHJ5LCBuYW1lbHkgU0hBLTI1Ni4N Cj4gICAgID4+Pj4gLSBSZWdpc3RlciBNRDUgYXMgYW4gaW5pdGlhbCBwYXNzd29yZCBhbGdvcml0 aG0gZm9yIGJhY2t3YXJkDQo+ICAgICA+PiBjb21wYXRpYmlsaXR5DQo+ICAgICA+Pj4+IHB1cnBv c2UuDQo+ICAgICA+Pj4+DQo+ICAgICA+Pj4+IEFzIGZvciB0aGUgYmlkZG93biBwcm90ZWN0aW9u IGl0c2VsZiwgaXQgaXMgbXkgcmVjb2xsZWN0aW9uIHRoYXQgaXQNCj4gICAgID4+Pj4gaGFwcGVu ZWQgbW9yZSBvciBsZXNzIGxpa2UgdGhhdDoNCj4gICAgID4+Pj4NCj4gICAgID4+Pj4NCj4gICAg ID4+Pj4gSU5ULiBNRUVUSU5HIFJPT00gLSBEQVkNCj4gICAgID4+Pj4NCj4gICAgID4+Pj4gT25l IG9mIHRoZSBjby1lZGl0b3JzIG9mIFNUVU5CaXMgc3RhbmRzIGF0IHRoZSBtaWNyb3Bob25lOg0K PiAgICAgPj4+Pg0KPiAgICAgPj4+PsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIENPLUVESVRPUg0KPiAgICAgPj4+PsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFdl IGFkZGVkIFNIQS0yNTYgcHJvdGVjdGlvbiBmb3IgcGFzc3dvcmRzDQo+ICAgICA+Pj4+wqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgaW4gU1RVTkJpcy4NCj4gICAgID4+Pj4NCj4gICAgID4+Pj7C oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTT01FT05FIChWLk8uKQ0K PiAgICAgPj4+PsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEFzIE1ENSBzdGlsbCBuZWVkIHRv IGJlIHN1cHBvcnRlZCwgeW91IG5lZWQgdG8gYWRkDQo+ICAgICA+Pj4+wqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgcHJvdGVjdGlvbiBmb3IgYmlkLWRvd24gYXR0YWNrcy4NCj4gICAgID4+Pj4N Cj4gICAgID4+Pj4gQ0xPU0UtVVAgb24gQ08tRURJVE9SIFJPTExJTkcgSElTIEVZRVMNCj4gICAg ID4+Pj4NCj4gICAgID4+Pj7CoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBDTy1FRElUT1INCj4gICAgID4+Pj7CoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBPSywgSSds bCB3b3JrIG9uIHRoYXQuDQo+ICAgICA+Pj4+DQo+ICAgICA+Pj4+IEZvdXIgdG8gZWlnaHQgbW9u dGhzIGhhcyBwYXNzZWQuDQo+ICAgICA+Pj4+DQo+ICAgICA+Pj4+IElOVC4gQU5PVEhFUiBNRUVU SU5HIFJPT00gLSBEQVkNCj4gICAgID4+Pj4NCj4gICAgID4+Pj4gVGhlIHNhbWUgY28tZWRpdG9y IG9mIFNUVU5CaXMgc3RhbmRzIGF0IHRoZSBtaWNyb3Bob25lOg0KPiAgICAgPj4+Pg0KPiAgICAg Pj4+PsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIENPLUVESVRPUg0K PiAgICAgPj4+PsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFdlIGFkZGVkIGEgbmljZSBtZWNo YW5pc20gdG8gcHJldmVudCBiaWQtZG93bg0KPiAgICAgPj4+PsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIGF0dGFja3Mgb24gcGFzc3dvcmRzLsKgIEFueSBjb21tZW50cz8NCj4gICAgID4+Pj4N Cj4gICAgID4+Pj7CoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBUSEUg Uk9PTQ0KPiAgICAgPj4+PsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIChzaWxlbmNlKQ0KPiAg ICAgPj4+Pg0KPiAgICAgPj4+PsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIENPLUVESVRPUg0KPiAgICAgPj4+PsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIE1vdmlu ZyBvbi4uLg0KPiAgICAgPj4+Pg0KPiAgICAgPj4+DQo+ICAgICA+Pj4gSSBkb24ndCBzZWUgaG93 IGFueSBvZiB0aGlzIGlzIHJlbGV2YW50IHRvIG15IHRlY2huaWNhbCBwb2ludHMNCj4gICAgIGFi b3ZlLg0KPiAgICAgPj4NCj4gICAgID4+IE15IHBvaW50IHdhcyB0aGF0IHdlLCB0aGUgY28tZWRp dG9ycywgZGlkIG5vdCBkZWNpZGUgb24gYWRkaW5nDQo+ICAgICBiaWQtZG93bg0KPiAgICAgPj4g cHJvdGVjdGlvbiwgc29tZW9uZSBhc2tlZCB1cyB0byBkbyBzbyBhbmQgbm8tb25lIGluIHRoZSBX RyBzYXcNCj4gICAgIGFueSBwcm9ibGVtDQo+ICAgICA+PiB3aXRoIHRoYXQuwqAgVGhlIHJlYXNv bnMgdGhhdCBwZXJzb24gd2FudGVkIHRoYXQgYXJlIG5vdCBrbm93biB0bw0KPiAgICAgdXMgYnV0 LCBhcw0KPiAgICAgPj4geW91IGluc2lzdCwgaGVyZSdzIG9uZSByZWFzb24gSSBjYW4gdGhpbmsg b2Y6DQo+ICAgICA+Pg0KPiAgICAgPj4gSXQgaXMgYSBmYWN0IHRoYXQsIGZvciBvcGVyYXRpb25h bCByZWFzb25zLCBhIHBhc3N3b3JkIGRhdGFiYXNlDQo+ICAgICBjYW5ub3QgYmUNCj4gICAgID4+ IHJlLWVuY3J5cHRlZCBhdCBvbmNlLsKgIEFsc28gZm9yIG9wZXJhdGlvbmFsIHJlYXNvbnMsIHRo ZSBNRDUgcGFzc3dvcmQNCj4gICAgID4+IGNhbm5vdCBiZSBpbW1lZGlhdGVseSByZW1vdmVkIGZy b20gdGhlIGRhdGFiYXNlIGFzIHNvb24gdGhlIHVzZXINCj4gICAgIHN1Ym1pdHRlZA0KPiAgICAg Pj4gYSBuZXcgb25lLsKgIEluIGZhY3QsIGFuZCBmb3IgcXVpdGUgc29tZSB0aW1lLCBib3RoIGVu Y3J5cHRlZA0KPiAgICAgdmFyaWFudHMgb2YNCj4gICAgID4+IHRoZSBzYW1lIHBhc3N3b3JkIG1h eSBoYXZlIHRvIGJlIGtlcHQgaW4gdGhhdCBkYXRhYmFzZSwgYmVjYXVzZSBhDQo+ICAgICBzaW5n bGUNCj4gICAgID4+IHVzZXIgbWF5IHVzZSBhIG1peCBvZiBkZXZpY2VzLCBzb21lIG9mIHRoZW0g dGhhdCB1c2UgYW4gUkZDIDUzODkNCj4gICAgIGNsaWVudCwNCj4gICAgID4+IHNvbWUgdGhhdCB1 c2UgYSBTVFVOYmlzIGNsaWVudC7CoCBJdCBpcyB1cCB0byB0aGUgU1RVTiBzZXJ2ZXIgb3duZXIg dG8NCj4gICAgID4+IGRlY2lkZSBob3cgbG9uZyB0aGUgbWlncmF0aW9uIHRvIFNUVU5iaXMgd2ls bCB0YWtlIGFuZCB3aGVuIGl0DQo+ICAgICB3aWxsIGJlDQo+ICAgICA+PiBhY2NlcHRhYmxlIHRv IHJlamVjdCBhbGwgUkZDIDUzODkgKGkuZS4gTUQ1KSBjbGllbnRzICh0aGF0DQo+ICAgICBtaWdy YXRpb24gdGltZQ0KPiAgICAgPj4gY2FuIGJlIHB1cnBvc2VseSByZWR1Y2VkIHRvIDAgc2Vjb25k cyBidXQgdGhhdCdzIHRoZSBjaG9pY2UgYW5kDQo+ICAgICA+PiByZXNwb25zaWJpbGl0eSBvZiB0 aGUgb3duZXIgb2YgdGhlIHNlcnZlcikuDQo+ICAgICA+Pg0KPiAgICAgPj4gTWVhbndoaWxlIHdl IHN0aWxsIG5lZWQgdG8gYmUgc3VyZSB0aGF0IGlmIHRoZSBTVFVOIGNsaWVudCBpcw0KPiAgICAg aW1wbGVtZW50aW5nDQo+ICAgICA+PiBTVFVOYmlzIGl0IHVuY29uZGl0aW9uYWxseSBnZXRzIHRo ZSBhZGRpdGlvbmFsIHByb3RlY3Rpb24gb2YgdGhlIG5ldw0KPiAgICAgPj4gcGFzc3dvcmQgZW5j cnlwdGlvbiBhbGdvcml0aG0uwqAgVGhhdCdzIHdoZXJlIHRoZSBiaWRkb3duDQo+ICAgICBwcm90 ZWN0aW9uIGtpY2tzDQo+ICAgICA+PiBpbiwgYnkgcHJldmVudGluZyBhbiBvbmxpbmUgYXR0YWNr ZXIgdG8gaGF2ZSB0aGUgc2VydmVyDQo+ICAgICBtaXNpZGVudGlmeWluZyBhDQo+ICAgICA+PiBT VFVOYmlzIGNsaWVudCBhcyBhbiBSRkMgNTM4OSBjbGllbnQsIGJ5IHByZXZlbnRpbmcgYW4gb25s aW5lDQo+ICAgICBhdHRhY2tlciB0bw0KPiAgICAgPj4gaGF2ZSB0aGUgY2xpZW50IG1pc2lkZW50 aWZ5aW5nIGEgU1RVTmJpcyBzZXJ2ZXIgYXMgYSBSRkMgNTM4OQ0KPiAgICAgc2VydmVyLCBhbmQN Cj4gICAgID4+IGhhdmluZyBib3RoIHRoZW0gdXNlIHRoZSBNRDUgZW5jcnlwdGVkIHBhc3N3b3Jk IGluc3RlYWQgb2YgdGhlDQo+ICAgICBTSEEtMjU2DQo+ICAgICA+PiBlbmNyeXB0ZWQgcGFzc3dv cmQsIGFsbCBvZiB0aGF0IGVhc2lseSBkb25lIGJ5IHN0cmlwcGluZyB0aGUNCj4gICAgIHVucHJv dGVjdGVkDQo+ICAgICA+PiA0MDEgcmVzcG9uc2Ugb2YgdGhlIG5ldyBTVFVOYmlzIFBBU1NXT1JE LUFMR09SSVRITVMgYXR0cmlidXRlLg0KPiAgICAgPj4NCj4gICAgID4+Pg0KPiAgICAgPj4+DQo+ ICAgICA+Pj4NCj4gICAgID4+Pj4+IFRoZSBzZWNvbmQgdG9waWMgaXMgdGhlIGhhc2ggdXNlZCB0 byBjb21wdXRlIHRoZSBNQUMuIEhvd2V2ZXIsDQo+ICAgICBJIGRvbid0DQo+ICAgICA+Pj4+IHNl ZQ0KPiAgICAgPj4+Pj4gaG93DQo+ICAgICA+Pj4+PiB0aGlzIGdpdmVzIHlvdSBzZW5zaWJsZSBi aWRkb3duIHByb3RlY3Rpb24gYmVjYXVzZSB0aGF0IGhhc2gNCj4gICAgIGlzIGFsc28NCj4gICAg ID4+IHVzZWQNCj4gICAgID4+Pj4+IHRvIGNvbXB1dGUNCj4gICAgID4+Pj4+IE1BQyBvdmVyIHRo ZSBuZWdvdGlhdGlvbjogYW4gYXR0YWNrZXIgd2hvIGhhcyBjb21wcm9taXNlZCBhDQo+ICAgICBN QUMgd2hpY2gNCj4gICAgID4+IHRoZQ0KPiAgICAgPj4+Pj4gc2VydmVyDQo+ICAgICA+Pj4+PiBz dXBwb3J0cyB3aWxsIHF1aXRlIGxpa2VseSBiZSBhYmxlIHRvIGZvcmdlIGEgTUFDIG92ZXIgdGhl DQo+ICAgICB0cmFuc2NyaXB0DQo+ICAgICA+PiBhcw0KPiAgICAgPj4+Pj4gd2VsbC4gVGhpcyBp cywNCj4gICAgID4+Pj4+IEkgc3VwcG9zZSwgcG90ZW50aWFsbHkgdXNlZnVsIGFzIGEgZGVmZW5z ZSBhZ2FpbnN0IHNvbWUgb3RoZXINCj4gICAgIHdlYWtuZXNzDQo+ICAgICA+Pj4+PiAoZS5nLiwN Cj4gICAgID4+Pj4+IHZlcnNpb24gIyksIGJ1dCBJIGRvbid0IHJlYWxseSBzZWUgaG93IHRoZSBj dXJyZW50IGRlc2lnbg0KPiAgICAgaGVscHMgYWdhaW5zdA0KPiAgICAgPj4+Pj4gYXR0YWNrcyBv biB0aGUNCj4gICAgID4+Pj4+IE1BQy4NCj4gICAgID4+Pj4NCj4gICAgID4+Pj4gVGhlcmUgaXMg bm8gYmlkZG93biBhdHRhY2sgcHJvdGVjdGlvbiBmb3IgdGhlIE1BQywgYXMgc3RhdGVkIGluDQo+ ICAgICBTZWN0aW9uDQo+ICAgICA+Pj4+IDE2LjM6DQo+ICAgICA+Pj4+DQo+ICAgICA+Pj4+ICJU aGUgYmlkLWRvd24gcHJvdGVjdGlvbiBtZWNoYW5pc20gZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1l bnQNCj4gICAgIGlzIG5ldywNCj4gICAgID4+Pj7CoCBhbmQgdGh1cyBjYW5ub3QgY3VycmVudGx5 IHByb3RlY3QgYWdhaW5zdCBhIGJpZC1kb3duIGF0dGFjayB0aGF0DQo+ICAgICA+Pj4+wqAgbG93 ZXJzIHRoZSBzdHJlbmd0aCBvZiB0aGUgaGFzaCBhbGdvcml0aG0gdG8gSE1BQy1TSEExLiINCj4g ICAgID4+Pj4NCj4gICAgID4+Pj4gV2hhdCB3ZSBwdXQgaW4gcGxhY2UgaXMgYSBwbGFuIGZvciAq ZnV0dXJlKiB2ZXJzaW9ucyBvZiBTVFVOIHRvIGdldA0KPiAgICAgPj4+PiBiaWRkb3duIHByb3Rl Y3Rpb24gZm9yIHRoZSBNQUMuwqAgVGhhdCdzIGl0LCBubyBtb3JlLCBubyBsZXNzLg0KPiAgICAg Pj4+Pg0KPiAgICAgPj4+DQo+ICAgICA+Pj4gWWVzLCBidXQgSSBkb24ndCBiZWxpZXZlIHRoYXQg dGhpcyB3aWxsIHByb3ZpZGUgYmlkLWRvd24NCj4gICAgIHByb3RlY3Rpb24gZm9yDQo+ICAgICA+ PiB0aGUNCj4gICAgID4+PiBNQUMgaW4gdGhlIGZ1dHVyZSBmb3IgdGhlIHJlYXNvbnMgSSBpbmRp Y2F0ZSBhYm92ZS4NCj4gICAgID4+Pg0KPiAgICAgPj4+IElmIHlvdSB0aGluayB0aGlzIGRvZXMg c29tZXRoaW5nIHVzZWZ1bCwgcGxlYXNlIHNob3cgbWUgYW4NCj4gICAgIGV4YW1wbGUgYXR0YWNr DQo+ICAgICA+Pj4gYW5kIGhvdyB0aGlzIGZpeGVzIGl0LiBOb3RlIHRoYXQgaXQncyBub3QgZ2Vu ZXJhbGx5IHVzZWZ1bCB0bw0KPiAgICAganVzdCBiaWQNCj4gICAgID4+IGRvd24NCj4gICAgID4+ PiB0aGUgTUFDIGl0c2VsZiB1bmxlc3MgdGhlIE1BQyB5b3UgYmlkIGRvd24gdG8gaXMgd2VhayBl bm91Z2ggdG8NCj4gICAgIGV4cGxvaXQNCj4gICAgID4+IGluDQo+ICAgICA+Pj4gc29tZSBvdGhl ciB3YXkuDQo+ICAgICA+Pg0KPiAgICAgPj4gSSBkbyBub3Qga25vdyB3aGF0IHdlYWtuZXNzZXMg d2lsbCBiZSBkaXNjb3ZlcmVkIGluIHRoZSBmdXR1cmUuwqANCj4gICAgIEkgYW0gYWxzbw0KPiAg ICAgPj4gcHJldHR5IHN1cmUgdGhhdCB0aGUgY29zdCBvZiBub3QgdXNpbmcgdGhhdCBtZWNoYW5p c20gaXMgdmVyeQ0KPiAgICAgY2xvc2UgdG8gMC4NCj4gICAgID4+IFdoYXQgSSBhbSBzdXJlIG9m IGlzIHRoYXQgdGhlIGNvc3Qgb2YgcmVlbmdpbmVlcmluZyBhIG5ldyBiaWRkb3duDQo+ICAgICA+ PiBwcm90ZWN0aW9uIG1lY2hhbmlzbSBpZiB3ZSBldmVyIG5lZWQgaXQgd2lsbCBiZSBoaWdoLsKg IFdlIGFscmVhZHkNCj4gICAgIHdlbnQNCj4gICAgID4+IHRocm91Z2ggdGhlIHBhaW5zIG9mIGRl c2lnbmluZyBvbmUgZm9yIHRoZSBwYXNzd29yZCBhbGdvcml0aG0sIHNvDQo+ICAgICB3aHkgbm90 DQo+ICAgICA+PiBleHRlbmQgaXQgc28gaXQgY2FuIGJlIHVzZWQgaW4gdGhlIGFmdGVybWF0aCBv ZiB0aGUgbmV4dCBTbm93ZGVuDQo+ICAgICBmYWNlcGFsbQ0KPiAgICAgPj4gbW9tZW50Pw0KPiAg ICAgPj4NCj4gICAgID4+PiBBZ2FpbiwgaGFwcHkgdG8gaGF2ZSBhIGNhbGwgdG8gd2FsayB0aG91 Z2ggdGhpcyBpZiB0aGF0DQo+ICAgICA+Pj4gaGVscHMuDQo+ICAgICA+Pj4NCj4gICAgID4+PiAt RWtyDQo+ICAgICA+Pj4NCj4gICAgID4+Pg0KPiAgICAgPj4+DQo+ICAgICA+Pj4NCj4gICAgID4+ Pj4+DQo+ICAgICA+Pj4+PiBZb3UgbWlnaHQgdGhpbmsgdGhhdCB0aGVyZSB3YXMgYSBNQUMgd2hp Y2ggd2FzIGVhc2llciB0bw0KPiAgICAgcmV2ZXJzZSB0bw0KPiAgICAgPj4gZmluZA0KPiAgICAg Pj4+Pj4gdGhlIG9yaWdpbmFsDQo+ICAgICA+Pj4+PiBwYXNzd29yZCwgYnV0IHRoZSBkZWZlbnNl IHlvdSBoYXZlIGhlcmUgZG9lc24ndCBoZWxwIHdpdGggdGhhdA0KPiAgICAgYmVjYXVzZQ0KPiAg ICAgPj4+PiB0aGUNCj4gICAgID4+Pj4+IG9uLXBhdGggYXR0YWNrZXIgY2FuIGRvIGEgYmlkLWRv d24gYW5kIHVzZSB0aGUgY2xpZW50IGFzIGEgTUFDDQo+ICAgICBvcmFjbGUNCj4gICAgID4+IGZv cg0KPiAgICAgPj4+Pj4gYW55IE1BQyB0aGUgY2xpZW50IHN1cHBvcnRzLg0KPiAgICAgPj4+Pj4N Cj4gICAgID4+Pj4+IFNvLCBJIHN0aWxsIGRvbid0IHVuZGVyc3RhbmQgd2hhdCB0aGlzIGlzIHN1 cHBvc2VkIHRvIGRvLiBIYXBweSB0bw0KPiAgICAgPj4gaGF2ZSBhDQo+ICAgICA+Pj4+PiBjYWxs IGlmIHlvdQ0KPiAgICAgPj4+Pj4gdGhpbmsgdGhhdCBoZWxwcw0KPiAgICAgPj4+Pj4NCj4gICAg ID4+Pj4+IC1Fa3INCj4gICAgID4+Pj4+DQo+ICAgICA+Pj4+Pg0KPiAgICAgPj4+Pj4NCj4gICAg ID4+Pj4+DQo+ICAgICA+Pj4+PiBPbiBNb24sIEp1biAxOCwgMjAxOCBhdCAzOjQwIEFNLCBHb256 YWxvIENhbWFyaWxsbyA8DQo+ICAgICA+Pj4+PiBHb256YWxvLkNhbWFyaWxsb0Blcmljc3Nvbi5j b20NCj4gICAgIDxtYWlsdG86R29uemFsby5DYW1hcmlsbG9AZXJpY3Nzb24uY29tPj4gd3JvdGU6 DQo+ICAgICA+Pj4+Pg0KPiAgICAgPj4+Pj4+IE1hcmMsIEVyaWMsDQo+ICAgICA+Pj4+Pj4NCj4g ICAgID4+Pj4+PiB3aGF0IGlzIHRoZSBzdGF0dXMgb2YgdGhpcyBkaXNjdXNzaW9uPw0KPiAgICAg Pj4+Pj4+DQo+ICAgICA+Pj4+Pj4gVGhhbmtzLA0KPiAgICAgPj4+Pj4+DQo+ICAgICA+Pj4+Pj4g R29uemFsbw0KPiAgICAgPj4+Pj4+DQo+ICAgICA+Pj4+Pj4gT24gMDQvMDUvMjAxOCAyOjM1IEFN LCBFcmljIFJlc2NvcmxhIHdyb3RlOg0KPiAgICAgPj4+Pj4+Pg0KPiAgICAgPj4+Pj4+Pg0KPiAg ICAgPj4+Pj4+PiBPbiBNb24sIEFwciAyMywgMjAxOCBhdCAxMToxNiBBTSwgTWFyYyBQZXRpdC1I dWd1ZW5pbiA8DQo+ICAgICA+Pj4+IHBldGl0aHVnQGFjbS5vcmcgPG1haWx0bzpwZXRpdGh1Z0Bh Y20ub3JnPg0KPiAgICAgPj4+Pj4+PiA8bWFpbHRvOnBldGl0aHVnQGFjbS5vcmcgPG1haWx0bzpw ZXRpdGh1Z0BhY20ub3JnPj4+IHdyb3RlOg0KPiAgICAgPj4+Pj4+Pg0KPiAgICAgPj4+Pj4+PsKg IMKgIMKgT24gMDQvMjIvMjAxOCAwNToyMiBQTSwgRXJpYyBSZXNjb3JsYSB3cm90ZToNCj4gICAg ID4+Pj4+Pj7CoCDCoCDCoD4gT24gU3VuLCBBcHIgMjIsIDIwMTggYXQgMjowMiBQTSwgTWFyYyBQ ZXRpdC1IdWd1ZW5pbiA8DQo+ICAgICA+Pj4+Pj4gcGV0aXRodWdAYWNtLm9yZyA8bWFpbHRvOnBl dGl0aHVnQGFjbS5vcmc+DQo+ICAgICA8bWFpbHRvOnBldGl0aHVnQGFjbS5vcmcgPG1haWx0bzpw ZXRpdGh1Z0BhY20ub3JnPj4+DQo+ICAgICA+Pj4+Pj4+wqAgwqAgwqA+IHdyb3RlOg0KPiAgICAg Pj4+Pj4+PsKgIMKgIMKgPg0KPiAgICAgPj4+Pj4+PsKgIMKgIMKgPj4NCj4gICAgID4+Pj4+Pj7C oCDCoCDCoD4+Pj7CoCDCoCDCoCBGb3IgYSByZXF1ZXN0IG9yIGluZGljYXRpb24gbWVzc2FnZSwg dGhlIGFnZW50DQo+ICAgICBNVVNUDQo+ICAgICA+Pj4+Pj4gaW5jbHVkZSB0aGUNCj4gICAgID4+ Pj4+Pj7CoCDCoCDCoD4+Pj7CoCDCoCDCoCBVU0VSTkFNRSwgTUVTU0FHRS1JTlRFR1JJVFktU0hB MjU2LCBhbmQNCj4gICAgID4+IE1FU1NBR0UtSU5URUdSSVRZDQo+ICAgICA+Pj4+Pj4+wqAgwqAg wqA+PiBhdHRyaWJ1dGVzDQo+ICAgICA+Pj4+Pj4+wqAgwqAgwqA+Pj4+wqAgwqAgwqAgaW4gdGhl IG1lc3NhZ2UgdW5sZXNzIHRoZSBhZ2VudCBrbm93cyBmcm9tIGFuDQo+ICAgICBleHRlcm5hbA0K PiAgICAgPj4+Pj4+IGluZGljYXRpb24NCj4gICAgID4+Pj4+Pj7CoCDCoCDCoD4+Pj7CoCDCoCDC oCB3aGljaCBtZXNzYWdlIGludGVncml0eSBhbGdvcml0aG0gaXMgc3VwcG9ydGVkDQo+ICAgICBi eSBib3RoDQo+ICAgICA+Pj4+Pj4gYWdlbnRzLsKgIEluDQo+ICAgICA+Pj4+Pj4+wqAgwqAgwqA+ Pj4+wqAgwqAgwqAgdGhpcyBjYXNlIGVpdGhlciBNRVNTQUdFLUlOVEVHUklUWSBvcg0KPiAgICAg Pj4+Pj4+IE1FU1NBR0UtSU5URUdSSVRZLVNIQTI1NiBNVVNUDQo+ICAgICA+Pj4+Pj4+wqAgwqAg wqA+Pj4+wqAgwqAgwqAgYmUgaW5jbHVkZWQgaW4gYWRkaXRpb24gdG8gVVNFUk5BTUUuwqAgVGhl IEhNQUMNCj4gICAgIGZvciB0aGUNCj4gICAgID4+Pj4+PiBNRVNTQUdFLQ0KPiAgICAgPj4+Pj4+ PsKgIMKgIMKgPj4+DQo+ICAgICA+Pj4+Pj4+wqAgwqAgwqA+Pj4gVGhpcyB0ZXh0IGFwcGVhcnMg dG8gY29uZmxpY3Qgd2l0aCBTIDcuMyBvZg0KPiAgICAgNTI0NS1iaXMsIHdoaWNoDQo+ICAgICA+ Pj4+IHNheXM6DQo+ICAgICA+Pj4+Pj4+wqAgwqAgwqA+Pg0KPiAgICAgPj4+Pj4+PsKgIMKgIMKg Pj4gW3RleHQgbWlzc2luZ10NCj4gICAgID4+Pj4+Pj7CoCDCoCDCoD4+DQo+ICAgICA+Pj4+Pj4+ wqAgwqAgwqA+PiBIbW0sIG5vLCBSRkMyNDViaXMgaXMgc3RpbGwgcmVmZXJlbmNpbmcgUkZDNTM4 OSwgc28gdGhlDQo+ICAgICA+Pj4+IHByb2NlZHVyZQ0KPiAgICAgPj4+Pj4+IGZvcg0KPiAgICAg Pj4+Pj4+PsKgIMKgIMKgPj4gc3R1bmJpcyBkb2VzIG5vdCBhcHBseS4NCj4gICAgID4+Pj4+Pj7C oCDCoCDCoD4+DQo+ICAgICA+Pj4+Pj4+wqAgwqAgwqA+DQo+ICAgICA+Pj4+Pj4+wqAgwqAgwqA+ IEkgaGVhciB3aGF0IHlvdSdyZSBzYXlpbmcsIGJ1dCBwdWJsaXNoaW5nIHR3bw0KPiAgICAgZG9j dW1lbnRzIGF0IHRoZQ0KPiAgICAgPj4+Pj4+IHNhbWUgdGltZQ0KPiAgICAgPj4+Pj4+PsKgIMKg IMKgPiB3aGljaA0KPiAgICAgPj4+Pj4+PsKgIMKgIMKgPiBtYWtlIGNvbnRyYXJ5IHJlY29tbWVu ZGF0aW9ucyBhYm91dCB0aGUgc2FtZSBiYXNpYw0KPiAgICAgcHJvdG9jb2wgaXMNCj4gICAgID4+ Pj4+PiB1bi1nb29kLg0KPiAgICAgPj4+Pj4+Pg0KPiAgICAgPj4+Pj4+PsKgIMKgIMKgU3VyZSwg YnV0IHdvdWxkbid0IGl0IGJlIHNpbXBsZXIgdG8gaGF2ZSByZmM1MjQ1YmlzDQo+ICAgICB1c2lu ZyBzdHVuYmlzDQo+ICAgICA+Pj4+Pj4+wqAgwqAgwqBhbmQgaGF2ZSB0aGVtIHVwZGF0aW5nIHRo ZWlyIHRleHQsIG1vcmUgdGhhbiBhZGRpbmcgc29tZQ0KPiAgICAgdG9ydHVvdXMNCj4gICAgID4+ Pj4+Pj7CoCDCoCDCoHRleHQgaW4gc3R1bmJpcz8NCj4gICAgID4+Pj4+Pj4NCj4gICAgID4+Pj4+ Pj7CoCDCoCDCoD4NCj4gICAgID4+Pj4+Pj7CoCDCoCDCoD4NCj4gICAgID4+Pj4+Pj7CoCDCoCDC oD4+PsKgIMKgIMKgIFRoZSBTVFVOIHVzYWdlIG11c3Qgc3BlY2lmeSB3aGljaCB0cmFuc3BvcnQN Cj4gICAgIHByb3RvY29sIGlzDQo+ICAgICA+Pj4+Pj4gdXNlZCwgYW5kDQo+ICAgICA+Pj4+Pj4+ wqAgwqAgwqA+PiBob3cNCj4gICAgID4+Pj4+Pj7CoCDCoCDCoD4+Pj7CoCDCoCDCoCB0aGUgYWdl bnQgZGV0ZXJtaW5lcyB0aGUgSVAgYWRkcmVzcyBhbmQgcG9ydA0KPiAgICAgb2YgdGhlDQo+ICAg ICA+Pj4+Pj4gcmVjaXBpZW50Lg0KPiAgICAgPj4+Pj4+PsKgIMKgIMKgPj4+PsKgIMKgIMKgIFNl Y3Rpb24gOCBkZXNjcmliZXMgYSBETlMtYmFzZWQgbWV0aG9kIG9mDQo+ICAgICBkZXRlcm1pbmlu Zw0KPiAgICAgPj4gdGhlDQo+ICAgICA+Pj4+Pj4gSVANCj4gICAgID4+Pj4+Pj7CoCDCoCDCoD4+ IGFkZHJlc3MNCj4gICAgID4+Pj4+Pj7CoCDCoCDCoD4+Pj7CoCDCoCDCoCBhbmQgcG9ydCBvZiBh IHNlcnZlciB0aGF0IGEgdXNhZ2UgbWF5IGVsZWN0IHRvDQo+ICAgICB1c2UuDQo+ICAgICA+PiBT VFVODQo+ICAgICA+Pj4+Pj4gbWF5IGJlDQo+ICAgICA+Pj4+Pj4+wqAgwqAgwqA+PiB1c2VkDQo+ ICAgICA+Pj4+Pj4+wqAgwqAgwqA+Pj4+wqAgwqAgwqAgd2l0aCBhbnljYXN0IGFkZHJlc3Nlcywg YnV0IG9ubHkgd2l0aCBVRFAgYW5kDQo+ICAgICBpbiB1c2FnZXMNCj4gICAgID4+Pj4+PiB3aGVy ZQ0KPiAgICAgPj4+Pj4+PsKgIMKgIMKgPj4+PsKgIMKgIMKgIGF1dGhlbnRpY2F0aW9uIGlzIG5v dCB1c2VkLg0KPiAgICAgPj4+Pj4+PsKgIMKgIMKgPj4+DQo+ICAgICA+Pj4+Pj4+wqAgwqAgwqA+ Pj4gV2h5IHRoaXMgcmVzdHJpY3Rpb24/IFlvdSBzaG91bGQgYmUgYWJsZSB0byB1c2UNCj4gICAg IGFueWNhc3Qgd2l0aA0KPiAgICAgPj4+Pj4+IGxvbmctdGVybQ0KPiAgICAgPj4+Pj4+PsKgIMKg IMKgPj4+IEFVVEggZm9yIChzYXkpIFRVUk4uDQo+ICAgICA+Pj4+Pj4+wqAgwqAgwqA+Pg0KPiAg ICAgPj4+Pj4+PsKgIMKgIMKgPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi9iZWhhdmUvY3VycmVudC8NCj4gICAgID4+Pj4+PiBtc2cwMzU4Mi5odG1sDQo+ICAgICA+Pj4+ Pj4+wqAgwqAgwqA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9iZWhhdmUv Y3VycmVudC8NCj4gICAgID4+Pj4gbXNnMDM1ODIuaHRtbD4NCj4gICAgID4+Pj4+Pj7CoCDCoCDC oD4+DQo+ICAgICA+Pj4+Pj4+wqAgwqAgwqA+PiBJIHRoaW5rIHRoYXQgdGhlIGRlY2lzaW9uIG9m IHBlcm1pdHRpbmcgQW55Y2FzdA0KPiAgICAgc2hvdWxkIGJlIGxlZnQNCj4gICAgID4+Pj4gdG8N Cj4gICAgID4+Pj4+PiBlYWNoDQo+ICAgICA+Pj4+Pj4+wqAgwqAgwqA+PiBTVFVOIFVzYWdlLsKg IEJhc2ljIFNUVU4gVXNhZ2UgZG9lcyBub3QgdXNlDQo+ICAgICBhdXRoZW50aWNhdGlvbiBhbmQN Cj4gICAgID4+Pj4gdXNlDQo+ICAgICA+Pj4+Pj4gb25seSBhDQo+ICAgICA+Pj4+Pj4+wqAgwqAg wqA+PiBvbmUgcm91bmQgdHJpcCBmb3IgdGhlIEJpbmRpbmcgdHJhbnNhY3Rpb24sIHNvDQo+ICAg ICBVbmljYXN0IGNhbiBiZQ0KPiAgICAgPj4+Pj4+IHVzZWQuDQo+ICAgICA+Pj4+Pj4+wqAgwqAg wqA+Pg0KPiAgICAgPj4+Pj4+PsKgIMKgIMKgPg0KPiAgICAgPj4+Pj4+PsKgIMKgIMKgPj4gT1RP SCwgVFVSTiBhbmQgSUNFIHNob3VsZCBwcm9iYWJseSBzYXkgc29tZXRoaW5nDQo+ICAgICBhYm91 dCB0aGF0LA0KPiAgICAgPj4gc28NCj4gICAgID4+Pj4gSQ0KPiAgICAgPj4+Pj4+IGFkZGVkIGEN Cj4gICAgID4+Pj4+Pj7CoCDCoCDCoD4+IG5ldyBidWxsZXQgcG9pbnQgaW4gU2VjdGlvbiAxMzoN Cj4gICAgID4+Pj4+Pj7CoCDCoCDCoD4+DQo+ICAgICA+Pj4+Pj4+wqAgwqAgwqA+PsKgIMKgIG/C oCBJZiBBbnljYXN0IGFkZHJlc3NlcyBjYW4gYmUgdXNlZCBmb3IgdGhlIHNlcnZlcg0KPiAgICAg aW4gY2FzZQ0KPiAgICAgPj4+PiBUQ1ANCj4gICAgID4+Pj4+PiBvcg0KPiAgICAgPj4+Pj4+PsKg IMKgIMKgPj7CoCDCoCDCoCDCoFRMUy1vdmVyLVRDUCwgb3IgYXV0aGVudGljYXRpb24gYXJlIHVz ZWQuDQo+ICAgICA+Pj4+Pj4+wqAgwqAgwqA+Pg0KPiAgICAgPj4+Pj4+PsKgIMKgIMKgPg0KPiAg ICAgPj4+Pj4+PsKgIMKgIMKgPiBBcmUgeW91IGxlYXZpbmcgdGhpcyB0ZXh0IGluPyBUaGF0IHNl ZW1zIHZlcnkgY29uZnVzaW5nLg0KPiAgICAgPj4+Pj4+Pg0KPiAgICAgPj4+Pj4+PsKgIMKgIMKg SW4gaXNvbGF0aW9uIHllcywgYnV0IEkgdGhpbmsgaXQgbWFrZXMgc2Vuc2Ugd2hpY2ggdGhlIHRl eHQNCj4gICAgID4+IGJlZm9yZQ0KPiAgICAgPj4+Pj4+PsKgIMKgIMKgdGhlIGJ1bGxldCBwb2lu dHM6DQo+ICAgICA+Pj4+Pj4+DQo+ICAgICA+Pj4+Pj4+wqAgwqAgwqAgwqAgQSBTVFVOIHVzYWdl IGRlZmluZXMgaG93IFNUVU4gaXMgYWN0dWFsbHkgdXRpbGl6ZWQgLS0NCj4gICAgIHdoZW4gdG8N Cj4gICAgID4+Pj4gc2VuZA0KPiAgICAgPj4+Pj4+PsKgIMKgIMKgIMKgIHJlcXVlc3RzLCB3aGF0 IHRvIGRvIHdpdGggdGhlIHJlc3BvbnNlcywgYW5kIHdoaWNoDQo+ICAgICBvcHRpb25hbA0KPiAg ICAgPj4+Pj4+PsKgIMKgIMKgIMKgIHByb2NlZHVyZXMgZGVmaW5lZCBoZXJlIChvciBpbiBhbiBl eHRlbnNpb24gdG8gU1RVTikNCj4gICAgIGFyZSB0byBiZQ0KPiAgICAgPj4+Pj4+IHVzZWQuDQo+ ICAgICA+Pj4+Pj4+wqAgwqAgwqAgwqAgQSB1c2FnZSBhbHNvIGRlZmluZXM6DQo+ICAgICA+Pj4+ Pj4+DQo+ICAgICA+Pj4+Pj4+wqAgwqAgwqBbLi4uXQ0KPiAgICAgPj4+Pj4+Pg0KPiAgICAgPj4+ Pj4+PsKgIMKgIMKgIMKgIG/CoCBJZiBBbnljYXN0IGFkZHJlc3NlcyBjYW4gYmUgdXNlZCBmb3Ig dGhlIHNlcnZlciBpbg0KPiAgICAgY2FzZSBUQ1ANCj4gICAgID4+Pj4gb3INCj4gICAgID4+Pj4+ Pj7CoCDCoCDCoCDCoCDCoCDCoFRMUy1vdmVyLVRDUCwgb3IgYXV0aGVudGljYXRpb24gYXJlIHVz ZWQuDQo+ICAgICA+Pj4+Pj4+DQo+ICAgICA+Pj4+Pj4+DQo+ICAgICA+Pj4+Pj4+IFdoYXQgaXMg dGhlIG5lZWQgZm9yIHRoZSByZXN0cmljdGlvbiBhdCBhbGwuDQo+ICAgICA+Pj4+Pj4+DQo+ICAg ICA+Pj4+Pj4+DQo+ICAgICA+Pj4+Pj4+DQo+ICAgICA+Pj4+Pj4+wqAgwqAgwqA+Pj4+wqAgwqAg wqAgdHJhbnNhY3Rpb24gb3ZlciBVRFAgb3IgRFRMUy1vdmVyLVVEUCBpcyBhbHNvDQo+ICAgICA+ PiBjb25zaWRlcmVkDQo+ICAgICA+Pj4+Pj4gZmFpbGVkIGlmDQo+ICAgICA+Pj4+Pj4+wqAgwqAg wqA+Pj4+wqAgwqAgwqAgdGhlcmUgaGFzIGJlZW4gYSBoYXJkIElDTVAgZXJyb3IgW1JGQzExMjJd LsKgIEZvcg0KPiAgICAgPj4gZXhhbXBsZSwNCj4gICAgID4+Pj4+PiBhc3N1bWluZw0KPiAgICAg Pj4+Pj4+PsKgIMKgIMKgPj4gYW4NCj4gICAgID4+Pj4+Pj7CoCDCoCDCoD4+Pj7CoCDCoCDCoCBS VE8gb2YgNTAwbXMsIHJlcXVlc3RzIHdvdWxkIGJlIHNlbnQgYXQgdGltZXMNCj4gICAgIDAgbXMs IDUwMA0KPiAgICAgPj4+Pj4+IG1zLCAxNTAwDQo+ICAgICA+Pj4+Pj4+wqAgwqAgwqA+PiBtcywN Cj4gICAgID4+Pj4+Pj7CoCDCoCDCoD4+Pj7CoCDCoCDCoCAzNTAwIG1zLCA3NTAwIG1zLCAxNTUw MCBtcywgYW5kIDMxNTAwIG1zLsKgIElmIHRoZQ0KPiAgICAgPj4gY2xpZW50DQo+ICAgICA+Pj4+ Pj4gaGFzIG5vdA0KPiAgICAgPj4+Pj4+PsKgIMKgIMKgPj4+PsKgIMKgIMKgIHJlY2VpdmVkIGEg cmVzcG9uc2UgYWZ0ZXIgMzk1MDAgbXMsIHRoZSBjbGllbnQNCj4gICAgIHdpbGwNCj4gICAgID4+ Pj4+PiBjb25zaWRlciB0aGUNCj4gICAgID4+Pj4+Pj7CoCDCoCDCoD4+Pj7CoCDCoCDCoCB0cmFu c2FjdGlvbiB0byBoYXZlIHRpbWVkIG91dC4NCj4gICAgID4+Pj4+Pj7CoCDCoCDCoD4+Pg0KPiAg ICAgPj4+Pj4+PsKgIMKgIMKgPj4+IEkgbm90ZSB0aGF0IHRoZXNlIHJlY29tbWVuZGF0aW9ucyBu b3cgc2VlbSBjcmF6aWx5DQo+ICAgICBsb25nLiBJDQo+ICAgICA+Pj4+Pj4gYXNzdW1lIHRoZQ0K PiAgICAgPj4+Pj4+PsKgIMKgIMKgPj4+IFdHIGhhZCBjb25zZW5zdXMgb24gdGhpcywgYnV0IEkg d2FudGVkIHRvIG5vdGUgaXQuDQo+ICAgICA+Pj4+Pj4+wqAgwqAgwqA+Pg0KPiAgICAgPj4+Pj4+ PsKgIMKgIMKgPj4gTm90IGp1c3QgdGhlIFdHLCBhbHNvIHRoZSBJRVNHIHRoYXQgYXBwcm92ZWQg UkZDIDUzODkNCj4gICAgIHRvbyBhcywNCj4gICAgID4+Pj4gYnV0DQo+ICAgICA+Pj4+Pj4gZm9y IHRoZQ0KPiAgICAgPj4+Pj4+PsKgIMKgIMKgPj4gYWRkaXRpb24gb2YgIm9yIERUTFMtb3Zlci1V RFAiLCB0aGlzIGlzIHRoZSBzYW1lIHRleHQNCj4gICAgIHRoYW4gaW4NCj4gICAgID4+Pj4gUkZD DQo+ICAgICA+Pj4+Pj4gNTM4OS4NCj4gICAgID4+Pj4+Pj7CoCDCoCDCoD4+DQo+ICAgICA+Pj4+ Pj4+wqAgwqAgwqA+DQo+ICAgICA+Pj4+Pj4+wqAgwqAgwqA+IFllcywgSSBrbm93LiBNeSBwb2lu dCBpcyB0aGF0IHdoaWxlIHRoZXkgbWlnaHQgaGF2ZSBiZWUNCj4gICAgID4+IHNlbnNpYmxlDQo+ ICAgICA+Pj4+Pj4gd2hlbg0KPiAgICAgPj4+Pj4+PsKgIMKgIMKgPiA1Mzg5IHdhcyBwdWJsaXNo ZWQgdGhleSAqbm93KiBzZWVtIGNyYXppbHkgbG9uZy4gRGlkDQo+ICAgICB0aGUgV0cNCj4gICAg ID4+Pj4+PiBleHBsaWNpdGx5DQo+ICAgICA+Pj4+Pj4+wqAgwqAgwqA+IGRlY2lkZSBub3QgdG8g dXBkYXRlIHRoZW0/DQo+ICAgICA+Pj4+Pj4+DQo+ICAgICA+Pj4+Pj4+wqAgwqAgwqBObywgbm9i b2R5IGV2ZXIgc3VnZ2VzdGVkIHRoYXQgdGhlcmUgd2FzIGFuIGlzc3VlIHRoZXJlLg0KPiAgICAg Pj4+Pj4+Pg0KPiAgICAgPj4+Pj4+Pg0KPiAgICAgPj4+Pj4+PiBPSywgd2VsbCwgdGhpcyBzZWVt cyBsaWtlIGl0IHNob3VsZCBiZSBjb25zaWRlcmVkLCB0aGVuLA0KPiAgICAgYmVjYXVzZSB0aGlz DQo+ICAgICA+Pj4+Pj4+IGRvZXNuJ3QNCj4gICAgID4+Pj4+Pj4gbWF0Y2ggbW9kZXJuIHByYWN0 aWNlLg0KPiAgICAgPj4+Pj4+Pg0KPiAgICAgPj4+Pj4+Pg0KPiAgICAgPj4+Pj4+Pg0KPiAgICAg Pj4+Pj4+PsKgIMKgIMKgPiBUaGlzIHdvdWxkIGJlIGdvb2QgdG8gZXhwbGFpbi4NCj4gICAgID4+ Pj4+Pj4NCj4gICAgID4+Pj4+Pj7CoCDCoCDCoE5ldyB0ZXh0Og0KPiAgICAgPj4+Pj4+Pg0KPiAg ICAgPj4+Pj4+PsKgIMKgIMKgIMKgIFsuLi5dDQo+ICAgICA+Pj4+Pj4+wqAgwqAgwqAgwqAgY29u dGFpbmluZyB0aGUgc3ViamVjdEFsdE5hbWUgb2YgdGhhdCBjZXJ0aWZpY2F0ZS7CoA0KPiAgICAg VGhlIHRlc3QNCj4gICAgID4+IG9uDQo+ICAgICA+Pj4+Pj4gdGhlDQo+ICAgICA+Pj4+Pj4+wqAg wqAgwqAgwqAgTUVTU0FHRS1JTlRFR1JJVFktU0hBMjU2IGF0dHJpYnV0ZSBpbmRpY2F0ZXMgdGhh dCB0aGUNCj4gICAgID4+Pj4gdHJhbnNhY3Rpb24NCj4gICAgID4+Pj4+PiBpcw0KPiAgICAgPj4+ Pj4+PsKgIMKgIMKgIMKgIGF1dGhlbnRpY2F0ZWQgYW5kIHRoYXQgdGhlIGNsaWVudCBpbXBsZW1l bnRzIHRoaXMNCj4gICAgID4+IHNwZWNpZmljYXRpb24NCj4gICAgID4+Pj4+PiBhbmQNCj4gICAg ID4+Pj4+Pj7CoCDCoCDCoCDCoCBzbyBjYW4gcHJvY2VzcyB0aGUgQUxURVJOQVRFLURPTUFJTiBh dHRyaWJ1dGUuDQo+ICAgICA+Pj4+Pj4+DQo+ICAgICA+Pj4+Pj4+DQo+ICAgICA+Pj4+Pj4+IEFs bCByaWdodC4NCj4gICAgID4+Pj4+Pj4NCj4gICAgID4+Pj4+Pj4NCj4gICAgID4+Pj4+Pj7CoCDC oCDCoD4NCj4gICAgID4+Pj4+Pj7CoCDCoCDCoD4NCj4gICAgID4+Pj4+Pj7CoCDCoCDCoD4+Pj7C oCDCoCDCoCBvwqAgV2hhdCBhdXRoZW50aWNhdGlvbiBhbmQgbWVzc2FnZS1pbnRlZ3JpdHkNCj4g ICAgIG1lY2hhbmlzbXMNCj4gICAgID4+Pj4+PiBhcmUgdXNlZC4NCj4gICAgID4+Pj4+Pj7CoCDC oCDCoD4+Pj4NCj4gICAgID4+Pj4+Pj7CoCDCoCDCoD4+Pj7CoCDCoCDCoCBvwqAgVGhlIGNvbnNp ZGVyYXRpb25zIGFyb3VuZCBtYW51YWwgdnMuDQo+ICAgICBhdXRvbWF0aWMga2V5DQo+ICAgICA+ Pj4+Pj4gZGVyaXZhdGlvbg0KPiAgICAgPj4+Pj4+PsKgIMKgIMKgPj4gZm9yDQo+ICAgICA+Pj4+ Pj4+wqAgwqAgwqA+Pj4+wqAgwqAgwqAgwqAgwqB0aGUgaW50ZWdyaXR5IG1lY2hhbmlzbSwgYXMg ZGlzY3Vzc2VkIGluDQo+ICAgICBbUkZDNDEwN10uDQo+ICAgICA+Pj4+Pj4+wqAgwqAgwqA+Pj4+ DQo+ICAgICA+Pj4+Pj4+wqAgwqAgwqA+Pj4+wqAgwqAgwqAgb8KgIFdoYXQgbWVjaGFuaXNtcyBh cmUgdXNlZCB0byBkaXN0aW5ndWlzaCBTVFVODQo+ICAgICA+PiBtZXNzYWdlcw0KPiAgICAgPj4+ Pj4+IGZyb20gb3RoZXINCj4gICAgID4+Pj4+Pj7CoCDCoCDCoD4+Pg0KPiAgICAgPj4+Pj4+PsKg IMKgIMKgPj4+IFdoeSBpcyB0aGlzIHJlcXVpcmVkPyBJdCBzZWVtcyBsaWtlIHRoYXQncyBhIGdl bmVyaWMNCj4gICAgIFNUVU4NCj4gICAgID4+Pj4+PiBmZWF0dXJlLg0KPiAgICAgPj4+Pj4+PsKg IMKgIMKgPj4NCj4gICAgID4+Pj4+Pj7CoCDCoCDCoD4+IFRoYXQgdGV4dCBpcyBpZGVudGljYWwg dG8gdGhlIHRleHQgaW4gUkZDIDUzODkuwqAgUkZDDQo+ICAgICA1NzY0Lzc5ODMNCj4gICAgID4+ Pj4gaXMNCj4gICAgID4+Pj4+PiBvbmUgc3VjaA0KPiAgICAgPj4+Pj4+PsKgIMKgIMKgPj4gbWVj aGFuaXNtLCBidXQgdGhlcmUgaXMgbm90aGluZyB0aGF0IHByZXZlbnQgYW5vdGhlcg0KPiAgICAg cHJvdG9jb2wNCj4gICAgID4+Pj4+PiBzdGFjayB0byB1c2UNCj4gICAgID4+Pj4+Pj7CoCDCoCDC oD4+IGEgZGlmZmVyZW50IG1lY2hhbmlzbSAoaW5mZXJlbmNlLCBzaGltLCBldGMuLi4pDQo+ICAg ICA+Pj4+Pj4+wqAgwqAgwqA+Pg0KPiAgICAgPj4+Pj4+PsKgIMKgIMKgPg0KPiAgICAgPj4+Pj4+ PsKgIMKgIMKgPiBCdXQgdWx0aW1hdGVseSBubyBtYXR0ZXIgd2hhdCB0aGUgb3RoZXIgcHJvdG9j b2wNCj4gICAgIHByb3ZpZGVzIGZvcg0KPiAgICAgPj4+Pj4+IGRlbXV4LCBTVFVODQo+ICAgICA+ Pj4+Pj4+wqAgwqAgwqA+IGhhcyBpdHMNCj4gICAgID4+Pj4+Pj7CoCDCoCDCoD4gb3duIGRlbXV4 Lg0KPiAgICAgPj4+Pj4+Pg0KPiAgICAgPj4+Pj4+PsKgIMKgIMKgSW4gZmFjdCBJIHRoaW5rIHRo YXQgdGhlIHJlYXNvbiBmb3IgdGhhdCBpdGVtIHdhcyBiZWNhdXNlDQo+ICAgICA+Pj4+Pj4+wqAg wqAgwqBGSU5HRVJQUklOVCBjYW4gYWxzbyBiZSB1c2VkIHRvIGRlbXV4IFNUVU4gdHJhZmZpYywg YnV0DQo+ICAgICBpdCBpcw0KPiAgICAgPj4+Pj4+PsKgIMKgIMKgb3B0aW9uYWwuwqAgU28gYW4g U1RVTiBVc2FnZSBuZWVkcyB0byB0ZWxsIGlmIEZJTkdFUlBSSU5UIGlzDQo+ICAgICA+Pj4+Pj4+ wqAgwqAgwqBtYW5kYXRvcnkgKGxpa2UgaW4gSUNFKS4NCj4gICAgID4+Pj4+Pj4NCj4gICAgID4+ Pj4+Pj4NCj4gICAgID4+Pj4+Pj4gVGhpcyBzaG91bGQgYmUgZXhwbGFpbmVkLg0KPiAgICAgPj4+ Pj4+Pg0KPiAgICAgPj4+Pj4+Pg0KPiAgICAgPj4+Pj4+PsKgIMKgIMKgPj4+DQo+ICAgICA+Pj4+ Pj4+wqAgwqAgwqA+Pj4+wqAgwqAgwqAgdGhhdCBpcyBub3QgcmVhZGlseSBzdWJqZWN0IHRvIG9m ZmxpbmUgZGljdGlvbmFyeQ0KPiAgICAgPj4+PiBhdHRhY2tzLg0KPiAgICAgPj4+Pj4+PsKgIMKg IMKgPj4+PsKgIMKgIMKgIFByb3RlY3Rpb24gb2YgdGhlIGNoYW5uZWwgaXRzZWxmLCB1c2luZyBU TFMgb3INCj4gICAgIERUTFMsDQo+ICAgICA+Pj4+Pj4gbWl0aWdhdGVzDQo+ICAgICA+Pj4+Pj4+ wqAgwqAgwqA+PiB0aGVzZQ0KPiAgICAgPj4+Pj4+PsKgIMKgIMKgPj4+PsKgIMKgIMKgIGF0dGFj a3MuDQo+ICAgICA+Pj4+Pj4+wqAgwqAgwqA+Pj4+DQo+ICAgICA+Pj4+Pj4+wqAgwqAgwqA+Pj4+ wqAgwqAgwqAgU1RVTiBzdXBwb3J0cyBib3RoIE1FU1NBR0UtSU5URUdSSVRZIGFuZA0KPiAgICAg Pj4+Pj4+PsKgIMKgIMKgTUVTU0FHRS1JTlRFR1JJVFktU0hBMjU2LA0KPiAgICAgPj4+Pj4+PsKg IMKgIMKgPj4+PsKgIMKgIMKgIHdoaWNoIGlzIHN1YmplY3QgdG8gYmlkIGRvd24gYXR0YWNrcyBi eSBhbiBvbi1wYXRoDQo+ICAgICA+Pj4+Pj4gYXR0YWNrZXIuDQo+ICAgICA+Pj4+Pj4+wqAgwqAg wqA+Pj4NCj4gICAgID4+Pj4+Pj7CoCDCoCDCoD4+PiBCeSBhbiBvbi1wYXRoIGF0dGFja2VyIHdo byBjYW4gZm9yZ2UgSE1BQy1TSEExIGluDQo+ICAgICByZWFsLXRpbWU/DQo+ICAgICA+Pj4+Pj4+ wqAgwqAgwqBUaGF0J3MgYQ0KPiAgICAgPj4+Pj4+PsKgIMKgIMKgPj4+IHByZXR0eSBzZXJpb3Vz IGFkdmVyc2FyeSwgc28geW91IHNob3VsZCBjbGFyaWZ5IGhlcmUNCj4gICAgID4+Pj4+Pj7CoCDC oCDCoD4+Pg0KPiAgICAgPj4+Pj4+PsKgIMKgIMKgPj4NCj4gICAgID4+Pj4+Pj7CoCDCoCDCoD4+ IE5ldyB0ZXh0Og0KPiAgICAgPj4+Pj4+PsKgIMKgIMKgPj4NCj4gICAgID4+Pj4+Pj7CoCDCoCDC oD4+wqAgwqAgU1RVTiBzdXBwb3J0cyBib3RoIE1FU1NBR0UtSU5URUdSSVRZIGFuZA0KPiAgICAg Pj4+Pj4+IE1FU1NBR0UtSU5URUdSSVRZLVNIQTI1NiwNCj4gICAgID4+Pj4+Pj7CoCDCoCDCoD4+ wqAgwqAgd2hpY2ggaXMgc3ViamVjdCB0byBiaWQgZG93biBhdHRhY2tzIGJ5IGFuIG9uLXBhdGgN Cj4gICAgIGF0dGFja2VyDQo+ICAgICA+Pj4+Pj4gdGhhdA0KPiAgICAgPj4+Pj4+PsKgIMKgIMKg Pj7CoCDCoCB3b3VsZCBzdHJpcCB0aGUgTUVTU0FHRS1JTlRFR1JJVFktU0hBMjU2IGF0dHJpYnV0 ZQ0KPiAgICAgbGVhdmluZw0KPiAgICAgPj4+Pj4+PsKgIMKgIMKgb25seSB0aGUNCj4gICAgID4+ Pj4+Pj7CoCDCoCDCoD4+wqAgwqAgTUVTU0FHRS1JTlRFR1JJVFkgYXR0cmlidXRlIGFuZCBleHBs b2l0aW5nIGEgcG90ZW50aWFsDQo+ICAgICA+Pj4+Pj4+wqAgwqAgwqB2dWxuZXJhYmlsaXR5Lg0K PiAgICAgPj4+Pj4+PsKgIMKgIMKgPj7CoCDCoCBQcm90ZWN0aW9uIG9mIHRoZSBjaGFubmVsIGl0 c2VsZiwgdXNpbmcgVExTIG9yIERUTFMsDQo+ICAgICA+Pj4+IG1pdGlnYXRlcw0KPiAgICAgPj4+ Pj4+PsKgIMKgIMKgdGhlc2UNCj4gICAgID4+Pj4+Pj7CoCDCoCDCoD4+wqAgwqAgYXR0YWNrcy7C oCBUaW1lbHkgcmVtb3ZhbCBvZiB0aGUgc3VwcG9ydCBvZg0KPiAgICAgPj4gTUVTU0FHRS1JTlRF R1JJVFkNCj4gICAgID4+Pj4+PiBpbiBhDQo+ICAgICA+Pj4+Pj4+wqAgwqAgwqA+PsKgIMKgIGZ1 dHVyZSB2ZXJzaW9uIG9mIFNUVU4gaXMgbmVjZXNzYXJ5Lg0KPiAgICAgPj4+Pj4+PsKgIMKgIMKg Pj4NCj4gICAgID4+Pj4+Pj7CoCDCoCDCoD4NCj4gICAgID4+Pj4+Pj7CoCDCoCDCoD4gSSBzdGls bCBkb24ndCB1bmRlcnN0YW5kIHRoZSBjYXBhYmlsaXRpZXMgeW91IHNlZW0gdG8NCj4gICAgIGJl bGlldmUNCj4gICAgID4+IHRoZQ0KPiAgICAgPj4+Pj4+PsKgIMKgIMKgYXR0YWNrZXINCj4gICAg ID4+Pj4+Pj7CoCDCoCDCoD4gaGFzLg0KPiAgICAgPj4+Pj4+PsKgIMKgIMKgPiBDYW4geW91IGRl c2NyaWJlIHRoZSBleGFjdCBhdHRhY2suDQo+ICAgICA+Pj4+Pj4+wqAgwqAgwqA+DQo+ICAgICA+ Pj4+Pj4+DQo+ICAgICA+Pj4+Pj4+wqAgwqAgwqAxLiBWdWxuZXJhYmlsaXR5IGlzIGZvdW5kIGlu IEhNQUMtU0hBMQ0KPiAgICAgPj4+Pj4+PsKgIMKgIMKgMi4gQ2xpZW50IEFsaWNlIHN0aWxsIHN1 cHBvcnRzIE0tSSBhbmQgTS1JLTI1NiwgZG9lcyBub3QNCj4gICAgIGtub3cNCj4gICAgID4+IHdo YXQNCj4gICAgID4+Pj4+Pj7CoCDCoCDCoHZlcnNpb24gb2YgU1RVTiBzZXJ2ZXIgQm9iIHN1cHBv cnRzIGFuZCBzbyBzZW5kIGJvdGguDQo+ICAgICA+Pj4+Pj4+wqAgwqAgwqAzLiBPbi1wYXRoIGF0 dGFja2VyIHJlbW92ZXMgTS1JLTI1Ni4NCj4gICAgID4+Pj4+Pj7CoCDCoCDCoDUuIHN0dW5iaXMg c2VydmVyIEJvYiB0aGlua3MgdGhhdCBBbGljZSBpcyBhbiBSRkMgNTM4OQ0KPiAgICAgY2xpZW50 IGFuZA0KPiAgICAgPj4+Pj4+PsKgIMKgIMKgY29udGludWUgd2l0aCB0aGF0IHByb3RvY29sLg0K PiAgICAgPj4+Pj4+Pg0KPiAgICAgPj4+Pj4+Pg0KPiAgICAgPj4+Pj4+PiBUaGlzIHNlZW1zIGxp a2UgYW4gZXh0cmVtZWx5IHdlYWsgYXR0YWNrLiBJbiBnZW5lcmFsLCBhbnkNCj4gICAgIHByb3Rv Y29sIG9mDQo+ICAgICA+Pj4+Pj4+IHRoaXMgdHlwZSBpcyBhcyBzdHJvbmcNCj4gICAgID4+Pj4+ Pj4gYXMgdGhlIHdlYWtlc3QgaW50ZWdyaXR5IGFsZ29yaXRobSBpdCBzdXBwb3J0cywgc28gaXQn cyBub3QNCj4gICAgIHRoYXQgdGhlDQo+ICAgICA+Pj4+Pj4+IHByb3RvY29sIGhhcyBhIGRvd25n cmFkZQ0KPiAgICAgPj4+Pj4+PiBhdHRhY2ssIGJ1dCByYXRoZXIgdGhhdCB0aGUgbWluaW11bSBh bGdvcml0aG0gc3VwcG9ydGVkIGlzDQo+ICAgICBvbmUgeW91DQo+ICAgICA+Pj4+IGRvbid0DQo+ ICAgICA+Pj4+Pj4+IHRydXN0IGFzIG11Y2gNCj4gICAgID4+Pj4+Pj4gYXMgeW91IG1pZ2h0IGxp a2UuDQo+ICAgICA+Pj4+Pj4+DQo+ICAgICA+Pj4+Pj4+IC1Fa3INCj4gICAgID4+Pj4+Pj4NCj4g ICAgID4+Pj4+Pj4NCj4gICAgID4+Pj4+Pj7CoCDCoCDCoC0tDQo+ICAgICA+Pg0KPiANCj4gDQo+ IA0KPiAgICAgLS0gDQo+ICAgICBNYXJjIFBldGl0LUh1Z3VlbmluDQo+ICAgICBFbWFpbDogbWFy Y0BwZXRpdC1odWd1ZW5pbi5vcmcgPG1haWx0bzptYXJjQHBldGl0LWh1Z3VlbmluLm9yZz4NCj4g ICAgIEJsb2c6IGh0dHBzOi8vbWFyYy5wZXRpdC1odWd1ZW5pbi5vcmcNCj4gICAgIFByb2ZpbGU6 IGh0dHBzOi8vd3d3LmxpbmtlZGluLmNvbS9pbi9wZXRpdGh1Zw0KPiANCg== From nobody Mon Nov 19 07:07:05 2018 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2A31286E7 for ; Mon, 19 Nov 2018 07:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 QyDIpuXXTDGO for ; Mon, 19 Nov 2018 07:06:53 -0800 (PST) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::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 EFDEF130DD6 for ; Mon, 19 Nov 2018 07:06:37 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id e5-v6so26434337lja.4 for ; Mon, 19 Nov 2018 07:06:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=shilDdOMRnL0V0ndh7IBCVt86Uqg/O5sn1dF6dVrwaw=; b=vOmOkp9T5IQE6h0tFuycgNjncliXZZ11tq8Dd4keXAR+4BJ+GemJRWclf5iZPwlQDo waHX+eiAkBt435c3d5tIEy1uzcWpCtfpP03Ovp3L0X6kJaUovGuQcg5haQUtkA9+X9ta jeLSd2gHMaqwDotm77m0ThrHigmVrAMopD+vZtSoMV4SwJ3j5fOA5/8kFTNBWUZ64PpW E1dZADEINFIoBMeWNRM+D6zJrDkM9vLrNO3lrpd5FXBeroMRi0LYi5AcrNoMCT01dcNy QbbQqH/tU3VtHSXn5xL9CvaE28AZxv7w1TZOJeGbFrDjgvoUbR1Sf8lKPBd80+FoDqNK zz2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=shilDdOMRnL0V0ndh7IBCVt86Uqg/O5sn1dF6dVrwaw=; b=is9aUQp2vefMYlG04QL8WKssm9hl0ro0T7BfAaTOC+w6rdT5fRN0L0JrmDJiyg5ncy d4VFUJWDMX4hX7bu4jEUw62kysawkuWNADS1Uaausw73+kWHeFyTwMZAIjDStlVpsYjR R3YFkVBq9uoX+ynBukDmoF8wPodWdCGmDtknO+09MbiVLKz6HKrVFDWoMZbwGLXMh6AJ IKouTwNdSeySbzqIY1yj5Q8zbx/qgFPIw2Iq5Rrtea3MKgH3rbwtXyLa7fuxFPNcFsnl c80AB7twb+V5beY7Ib2GkX3M3M0KHrt+xADGH+hgwN+KsyFUO0suLOuJ9eMNY9mu8396 OYsw== X-Gm-Message-State: AGRZ1gIoR9MvFn0gTM2ur6mQLYDyaxTXhekIUhUw6wyBZ/igPelRs9NF Cky+VjQEY8JfBr+3k5eh/8pfid2CdD2iH9CqobIoMA== X-Google-Smtp-Source: AJdET5cFge1dyhUarM9mDB0aN2XS07SRxRFiBsy+tdP/RruQVPrp8Ousm5WFGMKjddCgqKBTMF/JxpaD4HXplUyej7s= X-Received: by 2002:a2e:91d1:: with SMTP id u17-v6mr11515837ljg.160.1542639995952; Mon, 19 Nov 2018 07:06:35 -0800 (PST) MIME-Version: 1.0 References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> <02569943-db8f-654e-7322-49bc1f1a1163@acm.org> <235b838f-2800-2cd0-8b01-947e70837619@ericsson.com> <472563ee-5fc3-655d-8e31-138cc774e608@acm.org> In-Reply-To: From: Eric Rescorla Date: Mon, 19 Nov 2018 07:05:58 -0800 Message-ID: To: Gonzalo Camarillo Cc: Spencer Dawkins , Marc Petit-Huguenin , tram-chairs@ietf.org, tram@ietf.org, tasveren@rbbn.com, IESG , draft-ietf-tram-stunbis@ietf.org Content-Type: multipart/alternative; boundary="000000000000f9b442057b05dc02" Archived-At: Subject: Re: [tram] Eric Rescorla's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 19 Nov 2018 15:06:58 -0000 --000000000000f9b442057b05dc02 Content-Type: text/plain; charset="UTF-8" Not really. I have not received any response to my mail of Oct 23. As before, I'm happy to have a call, but I believe we're reaching the limits of what can be accomplished by email. -Ekr On Mon, Nov 19, 2018 at 6:35 AM Gonzalo Camarillo < gonzalo.camarillo@ericsson.com> wrote: > Hi Spencer, > > what is the status of this? Are the authors and the document shepherd > working with the relevant ADs on the discusses? > > https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/ballot/ > > Cheers, > > Gonzalo > > On 24-Oct-18 16:40, Spencer Dawkins at IETF wrote: > > Hi, Marc, > > > > On Wed, Oct 24, 2018 at 3:44 AM Marc Petit-Huguenin > > wrote: > > > > Hi Spencer, > > > > I sent my answers to Eric Rescorla questions on 2018-10-07 following > > an in-person meeting with my co-author, but never got a response > > back. Because there was no change proposed by Eric I went ahead and > > published -19 a couple of weeks after that, with the text agreed in > > response to Adam's and Benjamin's comments. > > > > https://www.ietf.org/mail-archive/web/tram/current/msg02635.html > > > > > > Ah - I wonder if that was what had happened. > > > > It sounds like you did the right thing, and that Eric has now responded, > > which is also the right thing to do. > > > > Thanks for helping me understand. > > > > Spencer > > > > > > On 10/23/18 7:28 PM, Spencer Dawkins at IETF wrote: > > > Hi, Marc, > > > > > > I see that a -19 has been submitted, but didn't see a reply from > > Eric in > > > this thread. Do you think that you've converged? > > > > > > (I saw an offer of a conference call, so thought an out-of-band > > > conversation might have happened) > > > > > > Thanks, > > > > > > Spencer > > > > > > On Sun, Oct 7, 2018 at 9:35 AM Marc Petit-Huguenin > > > wrote: > > > > > >> Hi Eric, > > >> > > >> Please see inline. > > >> > > >> On 09/10/2018 03:25 AM, Eric Rescorla wrote: > > >>> On Sat, Sep 8, 2018 at 2:31 PM, Marc Petit-Huguenin > > > > > >>> wrote: > > >>> > > >>>> Hi Eric, > > >>>> > > >>>> Apologies for the delay in getting back to that. > > >>>> > > >>>> I think that there is some misunderstanding in what STUNbis is > > trying to > > >>>> do, so please see my comments inline. > > >>>> > > >>>> On 06/18/2018 10:43 AM, Eric Rescorla wrote: > > >>>>> Hi folks, > > >>>>> > > >>>>> I've reviewed the new version, but I don't think that the > biddown > > >>>>> discussion makes much sense. > > >>>>> > > >>>>> To recap, there are two hashes here: > > >>>>> > > >>>>> - The hash which you use to store the password with (currently > > mostly > > >>>> MD5) > > >>>>> - The hash you use to compute the MAC (currently SHA-1). > > >>>>> > > >>>>> First, let's stipulate that MD5 isn't a great choice here, > > though SHA-1 > > >>>>> isn't a great choice > > >>>>> either for pwd hashing You want Argon or the like. With that > said, > > >>>> there's > > >>>>> no sensible > > >>>>> biddown attack on that hash because it's a per-server feature, > > not a > > >>>>> per-transaction > > >>>>> feature. So, as long as the server has MD5-hashed passwords, > the > > >>>> situation > > >>>>> is bad. > > >>>> > > >>>> In no place in STUNbis we are proposing to use SHA-1 for > password > > >>>> encryption, so I am not sure where that come from. What we > > propose is: > > >>>> > > >>> > > >>> You're right, it's SHA-256, but my criticisms apply equally > there. > > >> > > >> SHA-256 was what the WG adopted. Our attempts to add other > passwords > > >> encryption mechanisms were denied. It is true that Argon2 was > > not in that > > >> list (in our defense Argon2 was not known before July 2015), but > > I do not > > >> see why the WG would have accepted that one over the others. > > Anyway it is > > >> too late to fix this, as it is my understanding that the WG does > > not have > > >> enough energy to reach consensus on a new password algorithm. > > Someone can > > >> just write a draft adding Argon2 as password encryption, as we > > will have a > > >> IANA registry for that. > > >> > > >>> > > >>> > > >>>> - Establish a registry for new password algorithms (section > > 18.5), so > > >>>> algorithms like Argon2 could be added later (but note that our > own > > >>>> proposals to add more password algorithms were rejected by the > > working > > >>>> group). > > >>>> - Add a new password algorithm to that registry, namely SHA-256. > > >>>> - Register MD5 as an initial password algorithm for backward > > >> compatibility > > >>>> purpose. > > >>>> > > >>>> As for the biddown protection itself, it is my recollection > that it > > >>>> happened more or less like that: > > >>>> > > >>>> > > >>>> INT. MEETING ROOM - DAY > > >>>> > > >>>> One of the co-editors of STUNBis stands at the microphone: > > >>>> > > >>>> CO-EDITOR > > >>>> We added SHA-256 protection for passwords > > >>>> in STUNBis. > > >>>> > > >>>> SOMEONE (V.O.) > > >>>> As MD5 still need to be supported, you need to > add > > >>>> protection for bid-down attacks. > > >>>> > > >>>> CLOSE-UP on CO-EDITOR ROLLING HIS EYES > > >>>> > > >>>> CO-EDITOR > > >>>> OK, I'll work on that. > > >>>> > > >>>> Four to eight months has passed. > > >>>> > > >>>> INT. ANOTHER MEETING ROOM - DAY > > >>>> > > >>>> The same co-editor of STUNBis stands at the microphone: > > >>>> > > >>>> CO-EDITOR > > >>>> We added a nice mechanism to prevent bid-down > > >>>> attacks on passwords. Any comments? > > >>>> > > >>>> THE ROOM > > >>>> (silence) > > >>>> > > >>>> CO-EDITOR > > >>>> Moving on... > > >>>> > > >>> > > >>> I don't see how any of this is relevant to my technical points > > above. > > >> > > >> My point was that we, the co-editors, did not decide on adding > > bid-down > > >> protection, someone asked us to do so and no-one in the WG saw > > any problem > > >> with that. The reasons that person wanted that are not known to > > us but, as > > >> you insist, here's one reason I can think of: > > >> > > >> It is a fact that, for operational reasons, a password database > > cannot be > > >> re-encrypted at once. Also for operational reasons, the MD5 > password > > >> cannot be immediately removed from the database as soon the user > > submitted > > >> a new one. In fact, and for quite some time, both encrypted > > variants of > > >> the same password may have to be kept in that database, because a > > single > > >> user may use a mix of devices, some of them that use an RFC 5389 > > client, > > >> some that use a STUNbis client. It is up to the STUN server > owner to > > >> decide how long the migration to STUNbis will take and when it > > will be > > >> acceptable to reject all RFC 5389 (i.e. MD5) clients (that > > migration time > > >> can be purposely reduced to 0 seconds but that's the choice and > > >> responsibility of the owner of the server). > > >> > > >> Meanwhile we still need to be sure that if the STUN client is > > implementing > > >> STUNbis it unconditionally gets the additional protection of the > new > > >> password encryption algorithm. That's where the biddown > > protection kicks > > >> in, by preventing an online attacker to have the server > > misidentifying a > > >> STUNbis client as an RFC 5389 client, by preventing an online > > attacker to > > >> have the client misidentifying a STUNbis server as a RFC 5389 > > server, and > > >> having both them use the MD5 encrypted password instead of the > > SHA-256 > > >> encrypted password, all of that easily done by stripping the > > unprotected > > >> 401 response of the new STUNbis PASSWORD-ALGORITHMS attribute. > > >> > > >>> > > >>> > > >>> > > >>>>> The second topic is the hash used to compute the MAC. However, > > I don't > > >>>> see > > >>>>> how > > >>>>> this gives you sensible biddown protection because that hash > > is also > > >> used > > >>>>> to compute > > >>>>> MAC over the negotiation: an attacker who has compromised a > > MAC which > > >> the > > >>>>> server > > >>>>> supports will quite likely be able to forge a MAC over the > > transcript > > >> as > > >>>>> well. This is, > > >>>>> I suppose, potentially useful as a defense against some other > > weakness > > >>>>> (e.g., > > >>>>> version #), but I don't really see how the current design > > helps against > > >>>>> attacks on the > > >>>>> MAC. > > >>>> > > >>>> There is no biddown attack protection for the MAC, as stated in > > Section > > >>>> 16.3: > > >>>> > > >>>> "The bid-down protection mechanism described in this document > > is new, > > >>>> and thus cannot currently protect against a bid-down attack > that > > >>>> lowers the strength of the hash algorithm to HMAC-SHA1." > > >>>> > > >>>> What we put in place is a plan for *future* versions of STUN to > get > > >>>> biddown protection for the MAC. That's it, no more, no less. > > >>>> > > >>> > > >>> Yes, but I don't believe that this will provide bid-down > > protection for > > >> the > > >>> MAC in the future for the reasons I indicate above. > > >>> > > >>> If you think this does something useful, please show me an > > example attack > > >>> and how this fixes it. Note that it's not generally useful to > > just bid > > >> down > > >>> the MAC itself unless the MAC you bid down to is weak enough to > > exploit > > >> in > > >>> some other way. > > >> > > >> I do not know what weaknesses will be discovered in the future. > > I am also > > >> pretty sure that the cost of not using that mechanism is very > > close to 0. > > >> What I am sure of is that the cost of reengineering a new biddown > > >> protection mechanism if we ever need it will be high. We already > > went > > >> through the pains of designing one for the password algorithm, so > > why not > > >> extend it so it can be used in the aftermath of the next Snowden > > facepalm > > >> moment? > > >> > > >>> Again, happy to have a call to walk though this if that > > >>> helps. > > >>> > > >>> -Ekr > > >>> > > >>> > > >>> > > >>> > > >>>>> > > >>>>> You might think that there was a MAC which was easier to > > reverse to > > >> find > > >>>>> the original > > >>>>> password, but the defense you have here doesn't help with that > > because > > >>>> the > > >>>>> on-path attacker can do a bid-down and use the client as a MAC > > oracle > > >> for > > >>>>> any MAC the client supports. > > >>>>> > > >>>>> So, I still don't understand what this is supposed to do. > Happy to > > >> have a > > >>>>> call if you > > >>>>> think that helps > > >>>>> > > >>>>> -Ekr > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> On Mon, Jun 18, 2018 at 3:40 AM, Gonzalo Camarillo < > > >>>>> Gonzalo.Camarillo@ericsson.com > > > wrote: > > >>>>> > > >>>>>> Marc, Eric, > > >>>>>> > > >>>>>> what is the status of this discussion? > > >>>>>> > > >>>>>> Thanks, > > >>>>>> > > >>>>>> Gonzalo > > >>>>>> > > >>>>>> On 04/05/2018 2:35 AM, Eric Rescorla wrote: > > >>>>>>> > > >>>>>>> > > >>>>>>> On Mon, Apr 23, 2018 at 11:16 AM, Marc Petit-Huguenin < > > >>>> petithug@acm.org > > >>>>>>> >> wrote: > > >>>>>>> > > >>>>>>> On 04/22/2018 05:22 PM, Eric Rescorla wrote: > > >>>>>>> > On Sun, Apr 22, 2018 at 2:02 PM, Marc Petit-Huguenin < > > >>>>>> petithug@acm.org > > >> > > >>>>>>> > wrote: > > >>>>>>> > > > >>>>>>> >> > > >>>>>>> >>>> For a request or indication message, the agent > > MUST > > >>>>>> include the > > >>>>>>> >>>> USERNAME, MESSAGE-INTEGRITY-SHA256, and > > >> MESSAGE-INTEGRITY > > >>>>>>> >> attributes > > >>>>>>> >>>> in the message unless the agent knows from an > > external > > >>>>>> indication > > >>>>>>> >>>> which message integrity algorithm is supported > > by both > > >>>>>> agents. In > > >>>>>>> >>>> this case either MESSAGE-INTEGRITY or > > >>>>>> MESSAGE-INTEGRITY-SHA256 MUST > > >>>>>>> >>>> be included in addition to USERNAME. The HMAC > > for the > > >>>>>> MESSAGE- > > >>>>>>> >>> > > >>>>>>> >>> This text appears to conflict with S 7.3 of > > 5245-bis, which > > >>>> says: > > >>>>>>> >> > > >>>>>>> >> [text missing] > > >>>>>>> >> > > >>>>>>> >> Hmm, no, RFC245bis is still referencing RFC5389, so > the > > >>>> procedure > > >>>>>> for > > >>>>>>> >> stunbis does not apply. > > >>>>>>> >> > > >>>>>>> > > > >>>>>>> > I hear what you're saying, but publishing two > > documents at the > > >>>>>> same time > > >>>>>>> > which > > >>>>>>> > make contrary recommendations about the same basic > > protocol is > > >>>>>> un-good. > > >>>>>>> > > >>>>>>> Sure, but wouldn't it be simpler to have rfc5245bis > > using stunbis > > >>>>>>> and have them updating their text, more than adding some > > tortuous > > >>>>>>> text in stunbis? > > >>>>>>> > > >>>>>>> > > > >>>>>>> > > > >>>>>>> >>> The STUN usage must specify which transport > > protocol is > > >>>>>> used, and > > >>>>>>> >> how > > >>>>>>> >>>> the agent determines the IP address and port > > of the > > >>>>>> recipient. > > >>>>>>> >>>> Section 8 describes a DNS-based method of > > determining > > >> the > > >>>>>> IP > > >>>>>>> >> address > > >>>>>>> >>>> and port of a server that a usage may elect to > > use. > > >> STUN > > >>>>>> may be > > >>>>>>> >> used > > >>>>>>> >>>> with anycast addresses, but only with UDP and > > in usages > > >>>>>> where > > >>>>>>> >>>> authentication is not used. > > >>>>>>> >>> > > >>>>>>> >>> Why this restriction? You should be able to use > > anycast with > > >>>>>> long-term > > >>>>>>> >>> AUTH for (say) TURN. > > >>>>>>> >> > > >>>>>>> >> https://www.ietf.org/mail-archive/web/behave/current/ > > >>>>>> msg03582.html > > >>>>>>> > >>>> msg03582.html> > > >>>>>>> >> > > >>>>>>> >> I think that the decision of permitting Anycast > > should be left > > >>>> to > > >>>>>> each > > >>>>>>> >> STUN Usage. Basic STUN Usage does not use > > authentication and > > >>>> use > > >>>>>> only a > > >>>>>>> >> one round trip for the Binding transaction, so > > Unicast can be > > >>>>>> used. > > >>>>>>> >> > > >>>>>>> > > > >>>>>>> >> OTOH, TURN and ICE should probably say something > > about that, > > >> so > > >>>> I > > >>>>>> added a > > >>>>>>> >> new bullet point in Section 13: > > >>>>>>> >> > > >>>>>>> >> o If Anycast addresses can be used for the server > > in case > > >>>> TCP > > >>>>>> or > > >>>>>>> >> TLS-over-TCP, or authentication are used. > > >>>>>>> >> > > >>>>>>> > > > >>>>>>> > Are you leaving this text in? That seems very > confusing. > > >>>>>>> > > >>>>>>> In isolation yes, but I think it makes sense which the > text > > >> before > > >>>>>>> the bullet points: > > >>>>>>> > > >>>>>>> A STUN usage defines how STUN is actually utilized -- > > when to > > >>>> send > > >>>>>>> requests, what to do with the responses, and which > > optional > > >>>>>>> procedures defined here (or in an extension to STUN) > > are to be > > >>>>>> used. > > >>>>>>> A usage also defines: > > >>>>>>> > > >>>>>>> [...] > > >>>>>>> > > >>>>>>> o If Anycast addresses can be used for the server in > > case TCP > > >>>> or > > >>>>>>> TLS-over-TCP, or authentication are used. > > >>>>>>> > > >>>>>>> > > >>>>>>> What is the need for the restriction at all. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> >>>> transaction over UDP or DTLS-over-UDP is also > > >> considered > > >>>>>> failed if > > >>>>>>> >>>> there has been a hard ICMP error [RFC1122]. > For > > >> example, > > >>>>>> assuming > > >>>>>>> >> an > > >>>>>>> >>>> RTO of 500ms, requests would be sent at times > > 0 ms, 500 > > >>>>>> ms, 1500 > > >>>>>>> >> ms, > > >>>>>>> >>>> 3500 ms, 7500 ms, 15500 ms, and 31500 ms. If > the > > >> client > > >>>>>> has not > > >>>>>>> >>>> received a response after 39500 ms, the client > > will > > >>>>>> consider the > > >>>>>>> >>>> transaction to have timed out. > > >>>>>>> >>> > > >>>>>>> >>> I note that these recommendations now seem crazily > > long. I > > >>>>>> assume the > > >>>>>>> >>> WG had consensus on this, but I wanted to note it. > > >>>>>>> >> > > >>>>>>> >> Not just the WG, also the IESG that approved RFC 5389 > > too as, > > >>>> but > > >>>>>> for the > > >>>>>>> >> addition of "or DTLS-over-UDP", this is the same text > > than in > > >>>> RFC > > >>>>>> 5389. > > >>>>>>> >> > > >>>>>>> > > > >>>>>>> > Yes, I know. My point is that while they might have bee > > >> sensible > > >>>>>> when > > >>>>>>> > 5389 was published they *now* seem crazily long. Did > > the WG > > >>>>>> explicitly > > >>>>>>> > decide not to update them? > > >>>>>>> > > >>>>>>> No, nobody ever suggested that there was an issue there. > > >>>>>>> > > >>>>>>> > > >>>>>>> OK, well, this seems like it should be considered, then, > > because this > > >>>>>>> doesn't > > >>>>>>> match modern practice. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > This would be good to explain. > > >>>>>>> > > >>>>>>> New text: > > >>>>>>> > > >>>>>>> [...] > > >>>>>>> containing the subjectAltName of that certificate. > > The test > > >> on > > >>>>>> the > > >>>>>>> MESSAGE-INTEGRITY-SHA256 attribute indicates that the > > >>>> transaction > > >>>>>> is > > >>>>>>> authenticated and that the client implements this > > >> specification > > >>>>>> and > > >>>>>>> so can process the ALTERNATE-DOMAIN attribute. > > >>>>>>> > > >>>>>>> > > >>>>>>> All right. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > > >>>>>>> > > > >>>>>>> >>>> o What authentication and message-integrity > > mechanisms > > >>>>>> are used. > > >>>>>>> >>>> > > >>>>>>> >>>> o The considerations around manual vs. > > automatic key > > >>>>>> derivation > > >>>>>>> >> for > > >>>>>>> >>>> the integrity mechanism, as discussed in > > [RFC4107]. > > >>>>>>> >>>> > > >>>>>>> >>>> o What mechanisms are used to distinguish STUN > > >> messages > > >>>>>> from other > > >>>>>>> >>> > > >>>>>>> >>> Why is this required? It seems like that's a generic > > STUN > > >>>>>> feature. > > >>>>>>> >> > > >>>>>>> >> That text is identical to the text in RFC 5389. RFC > > 5764/7983 > > >>>> is > > >>>>>> one such > > >>>>>>> >> mechanism, but there is nothing that prevent another > > protocol > > >>>>>> stack to use > > >>>>>>> >> a different mechanism (inference, shim, etc...) > > >>>>>>> >> > > >>>>>>> > > > >>>>>>> > But ultimately no matter what the other protocol > > provides for > > >>>>>> demux, STUN > > >>>>>>> > has its > > >>>>>>> > own demux. > > >>>>>>> > > >>>>>>> In fact I think that the reason for that item was because > > >>>>>>> FINGERPRINT can also be used to demux STUN traffic, but > > it is > > >>>>>>> optional. So an STUN Usage needs to tell if FINGERPRINT > is > > >>>>>>> mandatory (like in ICE). > > >>>>>>> > > >>>>>>> > > >>>>>>> This should be explained. > > >>>>>>> > > >>>>>>> > > >>>>>>> >>> > > >>>>>>> >>>> that is not readily subject to offline > dictionary > > >>>> attacks. > > >>>>>>> >>>> Protection of the channel itself, using TLS or > > DTLS, > > >>>>>> mitigates > > >>>>>>> >> these > > >>>>>>> >>>> attacks. > > >>>>>>> >>>> > > >>>>>>> >>>> STUN supports both MESSAGE-INTEGRITY and > > >>>>>>> MESSAGE-INTEGRITY-SHA256, > > >>>>>>> >>>> which is subject to bid down attacks by an > on-path > > >>>>>> attacker. > > >>>>>>> >>> > > >>>>>>> >>> By an on-path attacker who can forge HMAC-SHA1 in > > real-time? > > >>>>>>> That's a > > >>>>>>> >>> pretty serious adversary, so you should clarify here > > >>>>>>> >>> > > >>>>>>> >> > > >>>>>>> >> New text: > > >>>>>>> >> > > >>>>>>> >> STUN supports both MESSAGE-INTEGRITY and > > >>>>>> MESSAGE-INTEGRITY-SHA256, > > >>>>>>> >> which is subject to bid down attacks by an on-path > > attacker > > >>>>>> that > > >>>>>>> >> would strip the MESSAGE-INTEGRITY-SHA256 attribute > > leaving > > >>>>>>> only the > > >>>>>>> >> MESSAGE-INTEGRITY attribute and exploiting a > potential > > >>>>>>> vulnerability. > > >>>>>>> >> Protection of the channel itself, using TLS or > DTLS, > > >>>> mitigates > > >>>>>>> these > > >>>>>>> >> attacks. Timely removal of the support of > > >> MESSAGE-INTEGRITY > > >>>>>> in a > > >>>>>>> >> future version of STUN is necessary. > > >>>>>>> >> > > >>>>>>> > > > >>>>>>> > I still don't understand the capabilities you seem to > > believe > > >> the > > >>>>>>> attacker > > >>>>>>> > has. > > >>>>>>> > Can you describe the exact attack. > > >>>>>>> > > > >>>>>>> > > >>>>>>> 1. Vulnerability is found in HMAC-SHA1 > > >>>>>>> 2. Client Alice still supports M-I and M-I-256, does not > > know > > >> what > > >>>>>>> version of STUN server Bob supports and so send both. > > >>>>>>> 3. On-path attacker removes M-I-256. > > >>>>>>> 5. stunbis server Bob thinks that Alice is an RFC 5389 > > client and > > >>>>>>> continue with that protocol. > > >>>>>>> > > >>>>>>> > > >>>>>>> This seems like an extremely weak attack. In general, any > > protocol of > > >>>>>>> this type is as strong > > >>>>>>> as the weakest integrity algorithm it supports, so it's not > > that the > > >>>>>>> protocol has a downgrade > > >>>>>>> attack, but rather that the minimum algorithm supported is > > one you > > >>>> don't > > >>>>>>> trust as much > > >>>>>>> as you might like. > > >>>>>>> > > >>>>>>> -Ekr > > >>>>>>> > > >>>>>>> > > >>>>>>> -- > > >> > > > > > > > > -- > > Marc Petit-Huguenin > > Email: marc@petit-huguenin.org > > Blog: https://marc.petit-huguenin.org > > Profile: https://www.linkedin.com/in/petithug > > > --000000000000f9b442057b05dc02 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Not really. I have not received any response to my ma= il of Oct 23. As before, I'm happy to have a call, but I believe we'= ;re reaching the limits of what can be accomplished by email.
-Ekr


<= div dir=3D"ltr">On Mon, Nov 19, 2018 at 6:35 AM Gonzalo Camarillo <gonzalo.camarillo@ericsson.com= > wrote:
Hi Spencer,

what is the status of this? Are the authors and the document shepherd
working with the relevant ADs on the discusses?

https://datatracker.ietf.org/doc/= draft-ietf-tram-stun-pmtud/ballot/

Cheers,

Gonzalo

On 24-Oct-18 16:40, Spencer Dawkins at IETF wrote:
> Hi, Marc,=C2=A0
>
> On Wed, Oct 24, 2018 at 3:44 AM Marc Petit-Huguenin <petithug@acm.org
> <mailto:petit= hug@acm.org>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hi Spencer,
>
>=C2=A0 =C2=A0 =C2=A0I sent my answers to Eric Rescorla questions on 201= 8-10-07 following
>=C2=A0 =C2=A0 =C2=A0an in-person meeting with my co-author, but never g= ot a response
>=C2=A0 =C2=A0 =C2=A0back.=C2=A0 Because there was no change proposed by= Eric I went ahead and
>=C2=A0 =C2=A0 =C2=A0published -19 a couple of weeks after that, with th= e text agreed in
>=C2=A0 =C2=A0 =C2=A0response to Adam's and Benjamin's comments.=
>
>=C2=A0 =C2=A0 =C2=A0https://www.= ietf.org/mail-archive/web/tram/current/msg02635.html
>
>
> Ah - I wonder if that was what had happened.=C2=A0
>
> It sounds like you did the right thing, and that Eric has now responde= d,
> which is also the right thing to do.=C2=A0
>
> Thanks for helping me understand.
>
> Spencer
> =C2=A0
>
>=C2=A0 =C2=A0 =C2=A0On 10/23/18 7:28 PM, Spencer Dawkins at IETF wrote:=
>=C2=A0 =C2=A0 =C2=A0> Hi, Marc,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> I see that a -19 has been submitted, but didn&= #39;t see a reply from
>=C2=A0 =C2=A0 =C2=A0Eric in
>=C2=A0 =C2=A0 =C2=A0> this thread. Do you think that you've conv= erged?
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> (I saw an offer of a conference call, so thoug= ht an out-of-band
>=C2=A0 =C2=A0 =C2=A0> conversation might have happened)
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Thanks,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Spencer
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> On Sun, Oct 7, 2018 at 9:35 AM Marc Petit-Hugu= enin
>=C2=A0 =C2=A0 =C2=A0<petithug@acm.org <mailto:petithug@acm.org>> wrote:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>> Hi Eric,
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> Please see inline.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> On 09/10/2018 03:25 AM, Eric Rescorla wrot= e:
>=C2=A0 =C2=A0 =C2=A0>>> On Sat, Sep 8, 2018 at 2:31 PM, Marc P= etit-Huguenin
>=C2=A0 =C2=A0 =C2=A0<petithug@acm.org <mailto:petithug@acm.org>>
>=C2=A0 =C2=A0 =C2=A0>>> wrote:
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>> Hi Eric,
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> Apologies for the delay in getting= back to that.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> I think that there is some misunde= rstanding in what STUNbis is
>=C2=A0 =C2=A0 =C2=A0trying to
>=C2=A0 =C2=A0 =C2=A0>>>> do, so please see my comments inli= ne.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> On 06/18/2018 10:43 AM, Eric Resco= rla wrote:
>=C2=A0 =C2=A0 =C2=A0>>>>> Hi folks,
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> I've reviewed the new vers= ion, but I don't think that the biddown
>=C2=A0 =C2=A0 =C2=A0>>>>> discussion makes much sense. >=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> To recap, there are two hashes= here:
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> - The hash which you use to st= ore the password with (currently
>=C2=A0 =C2=A0 =C2=A0mostly
>=C2=A0 =C2=A0 =C2=A0>>>> MD5)
>=C2=A0 =C2=A0 =C2=A0>>>>> - The hash you use to compute = the MAC (currently SHA-1).
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> First, let's stipulate tha= t MD5 isn't a great choice here,
>=C2=A0 =C2=A0 =C2=A0though SHA-1
>=C2=A0 =C2=A0 =C2=A0>>>>> isn't a great choice
>=C2=A0 =C2=A0 =C2=A0>>>>> either for pwd hashing You wan= t Argon or the like. With that said,
>=C2=A0 =C2=A0 =C2=A0>>>> there's
>=C2=A0 =C2=A0 =C2=A0>>>>> no sensible
>=C2=A0 =C2=A0 =C2=A0>>>>> biddown attack on that hash be= cause it's a per-server feature,
>=C2=A0 =C2=A0 =C2=A0not a
>=C2=A0 =C2=A0 =C2=A0>>>>> per-transaction
>=C2=A0 =C2=A0 =C2=A0>>>>> feature. So, as long as the se= rver has MD5-hashed passwords, the
>=C2=A0 =C2=A0 =C2=A0>>>> situation
>=C2=A0 =C2=A0 =C2=A0>>>>> is bad.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> In no place in STUNbis we are prop= osing to use SHA-1 for password
>=C2=A0 =C2=A0 =C2=A0>>>> encryption, so I am not sure where= that come from.=C2=A0 What we
>=C2=A0 =C2=A0 =C2=A0propose is:
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>> You're right, it's SHA-256, bu= t my criticisms apply equally there.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> SHA-256 was what the WG adopted.=C2=A0 Our= attempts to add other passwords
>=C2=A0 =C2=A0 =C2=A0>> encryption mechanisms were denied.=C2=A0 I= t is true that Argon2 was
>=C2=A0 =C2=A0 =C2=A0not in that
>=C2=A0 =C2=A0 =C2=A0>> list (in our defense Argon2 was not known = before July 2015), but
>=C2=A0 =C2=A0 =C2=A0I do not
>=C2=A0 =C2=A0 =C2=A0>> see why the WG would have accepted that on= e over the others.=C2=A0
>=C2=A0 =C2=A0 =C2=A0Anyway it is
>=C2=A0 =C2=A0 =C2=A0>> too late to fix this, as it is my understa= nding that the WG does
>=C2=A0 =C2=A0 =C2=A0not have
>=C2=A0 =C2=A0 =C2=A0>> enough energy to reach consensus on a new = password algorithm.=C2=A0
>=C2=A0 =C2=A0 =C2=A0Someone can
>=C2=A0 =C2=A0 =C2=A0>> just write a draft adding Argon2 as passwo= rd encryption, as we
>=C2=A0 =C2=A0 =C2=A0will have a
>=C2=A0 =C2=A0 =C2=A0>> IANA registry for that.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>> - Establish a registry for new pas= sword algorithms (section
>=C2=A0 =C2=A0 =C2=A018.5), so
>=C2=A0 =C2=A0 =C2=A0>>>> algorithms like Argon2 could be ad= ded later (but note that our own
>=C2=A0 =C2=A0 =C2=A0>>>> proposals to add more password alg= orithms were rejected by the
>=C2=A0 =C2=A0 =C2=A0working
>=C2=A0 =C2=A0 =C2=A0>>>> group).
>=C2=A0 =C2=A0 =C2=A0>>>> - Add a new password algorithm to = that registry, namely SHA-256.
>=C2=A0 =C2=A0 =C2=A0>>>> - Register MD5 as an initial passw= ord algorithm for backward
>=C2=A0 =C2=A0 =C2=A0>> compatibility
>=C2=A0 =C2=A0 =C2=A0>>>> purpose.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> As for the biddown protection itse= lf, it is my recollection that it
>=C2=A0 =C2=A0 =C2=A0>>>> happened more or less like that: >=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> INT. MEETING ROOM - DAY
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> One of the co-editors of STUNBis s= tands at the microphone:
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CO-EDITOR >=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 We added SHA-256 protection for passwords
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 in STUNBis.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SOMEONE (V.O= .)
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 As MD5 still need to be supported, you need to = add
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 protection for bid-down attacks.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> CLOSE-UP on CO-EDITOR ROLLING HIS = EYES
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CO-EDITOR >=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 OK, I'll work on that.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> Four to eight months has passed. >=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> INT. ANOTHER MEETING ROOM - DAY >=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> The same co-editor of STUNBis stan= ds at the microphone:
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CO-EDITOR >=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 We added a nice mechanism to prevent bid-down >=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 attacks on passwords.=C2=A0 Any comments?
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 THE ROOM
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 (silence)
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CO-EDITOR >=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Moving on...
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>> I don't see how any of this is rel= evant to my technical points
>=C2=A0 =C2=A0 =C2=A0above.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> My point was that we, the co-editors, did = not decide on adding
>=C2=A0 =C2=A0 =C2=A0bid-down
>=C2=A0 =C2=A0 =C2=A0>> protection, someone asked us to do so and = no-one in the WG saw
>=C2=A0 =C2=A0 =C2=A0any problem
>=C2=A0 =C2=A0 =C2=A0>> with that.=C2=A0 The reasons that person w= anted that are not known to
>=C2=A0 =C2=A0 =C2=A0us but, as
>=C2=A0 =C2=A0 =C2=A0>> you insist, here's one reason I can th= ink of:
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> It is a fact that, for operational reasons= , a password database
>=C2=A0 =C2=A0 =C2=A0cannot be
>=C2=A0 =C2=A0 =C2=A0>> re-encrypted at once.=C2=A0 Also for opera= tional reasons, the MD5 password
>=C2=A0 =C2=A0 =C2=A0>> cannot be immediately removed from the dat= abase as soon the user
>=C2=A0 =C2=A0 =C2=A0submitted
>=C2=A0 =C2=A0 =C2=A0>> a new one.=C2=A0 In fact, and for quite so= me time, both encrypted
>=C2=A0 =C2=A0 =C2=A0variants of
>=C2=A0 =C2=A0 =C2=A0>> the same password may have to be kept in t= hat database, because a
>=C2=A0 =C2=A0 =C2=A0single
>=C2=A0 =C2=A0 =C2=A0>> user may use a mix of devices, some of the= m that use an RFC 5389
>=C2=A0 =C2=A0 =C2=A0client,
>=C2=A0 =C2=A0 =C2=A0>> some that use a STUNbis client.=C2=A0 It i= s up to the STUN server owner to
>=C2=A0 =C2=A0 =C2=A0>> decide how long the migration to STUNbis w= ill take and when it
>=C2=A0 =C2=A0 =C2=A0will be
>=C2=A0 =C2=A0 =C2=A0>> acceptable to reject all RFC 5389 (i.e. MD= 5) clients (that
>=C2=A0 =C2=A0 =C2=A0migration time
>=C2=A0 =C2=A0 =C2=A0>> can be purposely reduced to 0 seconds but = that's the choice and
>=C2=A0 =C2=A0 =C2=A0>> responsibility of the owner of the server)= .
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> Meanwhile we still need to be sure that if= the STUN client is
>=C2=A0 =C2=A0 =C2=A0implementing
>=C2=A0 =C2=A0 =C2=A0>> STUNbis it unconditionally gets the additi= onal protection of the new
>=C2=A0 =C2=A0 =C2=A0>> password encryption algorithm.=C2=A0 That&= #39;s where the biddown
>=C2=A0 =C2=A0 =C2=A0protection kicks
>=C2=A0 =C2=A0 =C2=A0>> in, by preventing an online attacker to ha= ve the server
>=C2=A0 =C2=A0 =C2=A0misidentifying a
>=C2=A0 =C2=A0 =C2=A0>> STUNbis client as an RFC 5389 client, by p= reventing an online
>=C2=A0 =C2=A0 =C2=A0attacker to
>=C2=A0 =C2=A0 =C2=A0>> have the client misidentifying a STUNbis s= erver as a RFC 5389
>=C2=A0 =C2=A0 =C2=A0server, and
>=C2=A0 =C2=A0 =C2=A0>> having both them use the MD5 encrypted pas= sword instead of the
>=C2=A0 =C2=A0 =C2=A0SHA-256
>=C2=A0 =C2=A0 =C2=A0>> encrypted password, all of that easily don= e by stripping the
>=C2=A0 =C2=A0 =C2=A0unprotected
>=C2=A0 =C2=A0 =C2=A0>> 401 response of the new STUNbis PASSWORD-A= LGORITHMS attribute.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> The second topic is the hash u= sed to compute the MAC. However,
>=C2=A0 =C2=A0 =C2=A0I don't
>=C2=A0 =C2=A0 =C2=A0>>>> see
>=C2=A0 =C2=A0 =C2=A0>>>>> how
>=C2=A0 =C2=A0 =C2=A0>>>>> this gives you sensible biddow= n protection because that hash
>=C2=A0 =C2=A0 =C2=A0is also
>=C2=A0 =C2=A0 =C2=A0>> used
>=C2=A0 =C2=A0 =C2=A0>>>>> to compute
>=C2=A0 =C2=A0 =C2=A0>>>>> MAC over the negotiation: an a= ttacker who has compromised a
>=C2=A0 =C2=A0 =C2=A0MAC which
>=C2=A0 =C2=A0 =C2=A0>> the
>=C2=A0 =C2=A0 =C2=A0>>>>> server
>=C2=A0 =C2=A0 =C2=A0>>>>> supports will quite likely be = able to forge a MAC over the
>=C2=A0 =C2=A0 =C2=A0transcript
>=C2=A0 =C2=A0 =C2=A0>> as
>=C2=A0 =C2=A0 =C2=A0>>>>> well. This is,
>=C2=A0 =C2=A0 =C2=A0>>>>> I suppose, potentially useful = as a defense against some other
>=C2=A0 =C2=A0 =C2=A0weakness
>=C2=A0 =C2=A0 =C2=A0>>>>> (e.g.,
>=C2=A0 =C2=A0 =C2=A0>>>>> version #), but I don't re= ally see how the current design
>=C2=A0 =C2=A0 =C2=A0helps against
>=C2=A0 =C2=A0 =C2=A0>>>>> attacks on the
>=C2=A0 =C2=A0 =C2=A0>>>>> MAC.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> There is no biddown attack protect= ion for the MAC, as stated in
>=C2=A0 =C2=A0 =C2=A0Section
>=C2=A0 =C2=A0 =C2=A0>>>> 16.3:
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> "The bid-down protection mech= anism described in this document
>=C2=A0 =C2=A0 =C2=A0is new,
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 and thus cannot currently pr= otect against a bid-down attack that
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 lowers the strength of the h= ash algorithm to HMAC-SHA1."
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> What we put in place is a plan for= *future* versions of STUN to get
>=C2=A0 =C2=A0 =C2=A0>>>> biddown protection for the MAC.=C2= =A0 That's it, no more, no less.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>> Yes, but I don't believe that this= will provide bid-down
>=C2=A0 =C2=A0 =C2=A0protection for
>=C2=A0 =C2=A0 =C2=A0>> the
>=C2=A0 =C2=A0 =C2=A0>>> MAC in the future for the reasons I in= dicate above.
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>> If you think this does something usefu= l, please show me an
>=C2=A0 =C2=A0 =C2=A0example attack
>=C2=A0 =C2=A0 =C2=A0>>> and how this fixes it. Note that it= 9;s not generally useful to
>=C2=A0 =C2=A0 =C2=A0just bid
>=C2=A0 =C2=A0 =C2=A0>> down
>=C2=A0 =C2=A0 =C2=A0>>> the MAC itself unless the MAC you bid = down to is weak enough to
>=C2=A0 =C2=A0 =C2=A0exploit
>=C2=A0 =C2=A0 =C2=A0>> in
>=C2=A0 =C2=A0 =C2=A0>>> some other way.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> I do not know what weaknesses will be disc= overed in the future.=C2=A0
>=C2=A0 =C2=A0 =C2=A0I am also
>=C2=A0 =C2=A0 =C2=A0>> pretty sure that the cost of not using tha= t mechanism is very
>=C2=A0 =C2=A0 =C2=A0close to 0.
>=C2=A0 =C2=A0 =C2=A0>> What I am sure of is that the cost of reen= gineering a new biddown
>=C2=A0 =C2=A0 =C2=A0>> protection mechanism if we ever need it wi= ll be high.=C2=A0 We already
>=C2=A0 =C2=A0 =C2=A0went
>=C2=A0 =C2=A0 =C2=A0>> through the pains of designing one for the= password algorithm, so
>=C2=A0 =C2=A0 =C2=A0why not
>=C2=A0 =C2=A0 =C2=A0>> extend it so it can be used in the afterma= th of the next Snowden
>=C2=A0 =C2=A0 =C2=A0facepalm
>=C2=A0 =C2=A0 =C2=A0>> moment?
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>> Again, happy to have a call to walk th= ough this if that
>=C2=A0 =C2=A0 =C2=A0>>> helps.
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>> -Ekr
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> You might think that there was= a MAC which was easier to
>=C2=A0 =C2=A0 =C2=A0reverse to
>=C2=A0 =C2=A0 =C2=A0>> find
>=C2=A0 =C2=A0 =C2=A0>>>>> the original
>=C2=A0 =C2=A0 =C2=A0>>>>> password, but the defense you = have here doesn't help with that
>=C2=A0 =C2=A0 =C2=A0because
>=C2=A0 =C2=A0 =C2=A0>>>> the
>=C2=A0 =C2=A0 =C2=A0>>>>> on-path attacker can do a bid-= down and use the client as a MAC
>=C2=A0 =C2=A0 =C2=A0oracle
>=C2=A0 =C2=A0 =C2=A0>> for
>=C2=A0 =C2=A0 =C2=A0>>>>> any MAC the client supports. >=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> So, I still don't understa= nd what this is supposed to do. Happy to
>=C2=A0 =C2=A0 =C2=A0>> have a
>=C2=A0 =C2=A0 =C2=A0>>>>> call if you
>=C2=A0 =C2=A0 =C2=A0>>>>> think that helps
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> -Ekr
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> On Mon, Jun 18, 2018 at 3:40 A= M, Gonzalo Camarillo <
>=C2=A0 =C2=A0 =C2=A0>>>>> Gonzalo.Camarillo@ericsson.com >=C2=A0 =C2=A0 =C2=A0<mailto:Gonzalo.Camarillo@ericsson.com>> wrot= e:
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> Marc, Eric,
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> what is the status of this= discussion?
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> Thanks,
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> Gonzalo
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> On 04/05/2018 2:35 AM, Eri= c Rescorla wrote:
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> On Mon, Apr 23, 2018 a= t 11:16 AM, Marc Petit-Huguenin <
>=C2=A0 =C2=A0 =C2=A0>>>> petithug@acm.org <mailto:petithug@acm.org>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> <mailto:petithug@acm.org <mailto:= petithug@acm.org&= gt;>> wrote:
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0On = 04/22/2018 05:22 PM, Eric Rescorla wrote:
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ; On Sun, Apr 22, 2018 at 2:02 PM, Marc Petit-Huguenin <
>=C2=A0 =C2=A0 =C2=A0>>>>>> petithug@acm.org <mailto:petithug@acm.org>
>=C2=A0 =C2=A0 =C2=A0<mailto:petithug@acm.org <mailto:petithug@acm.org>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ; wrote:
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 For a request or indication message, the = agent
>=C2=A0 =C2=A0 =C2=A0MUST
>=C2=A0 =C2=A0 =C2=A0>>>>>> include the
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 USERNAME, MESSAGE-INTEGRITY-SHA256, and >=C2=A0 =C2=A0 =C2=A0>> MESSAGE-INTEGRITY
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> attributes
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 in the message unless the agent knows fro= m an
>=C2=A0 =C2=A0 =C2=A0external
>=C2=A0 =C2=A0 =C2=A0>>>>>> indication
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 which message integrity algorithm is supp= orted
>=C2=A0 =C2=A0 =C2=A0by both
>=C2=A0 =C2=A0 =C2=A0>>>>>> agents.=C2=A0 In
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 this case either MESSAGE-INTEGRITY or
>=C2=A0 =C2=A0 =C2=A0>>>>>> MESSAGE-INTEGRITY-SHA256 M= UST
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 be included in addition to USERNAME.=C2= =A0 The HMAC
>=C2=A0 =C2=A0 =C2=A0for the
>=C2=A0 =C2=A0 =C2=A0>>>>>> MESSAGE-
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>> This text appears to conflict with S 7.3 of
>=C2=A0 =C2=A0 =C2=A05245-bis, which
>=C2=A0 =C2=A0 =C2=A0>>>> says:
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> [text missing]
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> Hmm, no, RFC245bis is still referencing RFC5389, so the
>=C2=A0 =C2=A0 =C2=A0>>>> procedure
>=C2=A0 =C2=A0 =C2=A0>>>>>> for
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> stunbis does not apply.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ; I hear what you're saying, but publishing two
>=C2=A0 =C2=A0 =C2=A0documents at the
>=C2=A0 =C2=A0 =C2=A0>>>>>> same time
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ; which
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ; make contrary recommendations about the same basic
>=C2=A0 =C2=A0 =C2=A0protocol is
>=C2=A0 =C2=A0 =C2=A0>>>>>> un-good.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0Sur= e, but wouldn't it be simpler to have rfc5245bis
>=C2=A0 =C2=A0 =C2=A0using stunbis
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0and= have them updating their text, more than adding some
>=C2=A0 =C2=A0 =C2=A0tortuous
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0tex= t in stunbis?
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>=C2=A0 =C2=A0 =C2=A0 The STUN usage must specify which transport >=C2=A0 =C2=A0 =C2=A0protocol is
>=C2=A0 =C2=A0 =C2=A0>>>>>> used, and
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> how
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 the agent determines the IP address and p= ort
>=C2=A0 =C2=A0 =C2=A0of the
>=C2=A0 =C2=A0 =C2=A0>>>>>> recipient.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 Section 8 describes a DNS-based method of=
>=C2=A0 =C2=A0 =C2=A0determining
>=C2=A0 =C2=A0 =C2=A0>> the
>=C2=A0 =C2=A0 =C2=A0>>>>>> IP
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> address
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 and port of a server that a usage may ele= ct to
>=C2=A0 =C2=A0 =C2=A0use.
>=C2=A0 =C2=A0 =C2=A0>> STUN
>=C2=A0 =C2=A0 =C2=A0>>>>>> may be
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> used
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 with anycast addresses, but only with UDP= and
>=C2=A0 =C2=A0 =C2=A0in usages
>=C2=A0 =C2=A0 =C2=A0>>>>>> where
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 authentication is not used.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>> Why this restriction? You should be able to use
>=C2=A0 =C2=A0 =C2=A0anycast with
>=C2=A0 =C2=A0 =C2=A0>>>>>> long-term
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>> AUTH for (say) TURN.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> https://www.ietf.org/mail-archive/web/beh= ave/current/
>=C2=A0 =C2=A0 =C2=A0>>>>>> msg03582.html
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0<= ;https://www.ietf.org/mail-archive/web/behave/c= urrent/
>=C2=A0 =C2=A0 =C2=A0>>>> msg03582.html>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> I think that the decision of permitting Anycast
>=C2=A0 =C2=A0 =C2=A0should be left
>=C2=A0 =C2=A0 =C2=A0>>>> to
>=C2=A0 =C2=A0 =C2=A0>>>>>> each
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> STUN Usage.=C2=A0 Basic STUN Usage does not use
>=C2=A0 =C2=A0 =C2=A0authentication and
>=C2=A0 =C2=A0 =C2=A0>>>> use
>=C2=A0 =C2=A0 =C2=A0>>>>>> only a
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> one round trip for the Binding transaction, so
>=C2=A0 =C2=A0 =C2=A0Unicast can be
>=C2=A0 =C2=A0 =C2=A0>>>>>> used.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> OTOH, TURN and ICE should probably say something
>=C2=A0 =C2=A0 =C2=A0about that,
>=C2=A0 =C2=A0 =C2=A0>> so
>=C2=A0 =C2=A0 =C2=A0>>>> I
>=C2=A0 =C2=A0 =C2=A0>>>>>> added a
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> new bullet point in Section 13:
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>=C2=A0 =C2=A0 o=C2=A0 If Anycast addresses can be used for the server<= br> >=C2=A0 =C2=A0 =C2=A0in case
>=C2=A0 =C2=A0 =C2=A0>>>> TCP
>=C2=A0 =C2=A0 =C2=A0>>>>>> or
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>=C2=A0 =C2=A0 =C2=A0 =C2=A0TLS-over-TCP, or authentication are used. >=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ; Are you leaving this text in? That seems very confusing.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0In = isolation yes, but I think it makes sense which the text
>=C2=A0 =C2=A0 =C2=A0>> before
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0the= bullet points:
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 A STUN usage defines how STUN is actually utilized --
>=C2=A0 =C2=A0 =C2=A0when to
>=C2=A0 =C2=A0 =C2=A0>>>> send
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 requests, what to do with the responses, and which
>=C2=A0 =C2=A0 =C2=A0optional
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 procedures defined here (or in an extension to STUN)
>=C2=A0 =C2=A0 =C2=A0are to be
>=C2=A0 =C2=A0 =C2=A0>>>>>> used.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 A usage also defines:
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0[..= .]
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 o=C2=A0 If Anycast addresses can be used for the server in
>=C2=A0 =C2=A0 =C2=A0case TCP
>=C2=A0 =C2=A0 =C2=A0>>>> or
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0TLS-over-TCP, or authentication are used.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> What is the need for t= he restriction at all.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 transaction over UDP or DTLS-over-UDP is = also
>=C2=A0 =C2=A0 =C2=A0>> considered
>=C2=A0 =C2=A0 =C2=A0>>>>>> failed if
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 there has been a hard ICMP error [RFC1122= ].=C2=A0 For
>=C2=A0 =C2=A0 =C2=A0>> example,
>=C2=A0 =C2=A0 =C2=A0>>>>>> assuming
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> an
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 RTO of 500ms, requests would be sent at t= imes
>=C2=A0 =C2=A0 =C2=A00 ms, 500
>=C2=A0 =C2=A0 =C2=A0>>>>>> ms, 1500
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> ms,
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 3500 ms, 7500 ms, 15500 ms, and 31500 ms.= =C2=A0 If the
>=C2=A0 =C2=A0 =C2=A0>> client
>=C2=A0 =C2=A0 =C2=A0>>>>>> has not
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 received a response after 39500 ms, the c= lient
>=C2=A0 =C2=A0 =C2=A0will
>=C2=A0 =C2=A0 =C2=A0>>>>>> consider the
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 transaction to have timed out.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>> I note that these recommendations now seem crazily
>=C2=A0 =C2=A0 =C2=A0long. I
>=C2=A0 =C2=A0 =C2=A0>>>>>> assume the
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>> WG had consensus on this, but I wanted to note it.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> Not just the WG, also the IESG that approved RFC 5389
>=C2=A0 =C2=A0 =C2=A0too as,
>=C2=A0 =C2=A0 =C2=A0>>>> but
>=C2=A0 =C2=A0 =C2=A0>>>>>> for the
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> addition of "or DTLS-over-UDP", this is the same text
>=C2=A0 =C2=A0 =C2=A0than in
>=C2=A0 =C2=A0 =C2=A0>>>> RFC
>=C2=A0 =C2=A0 =C2=A0>>>>>> 5389.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ; Yes, I know. My point is that while they might have bee
>=C2=A0 =C2=A0 =C2=A0>> sensible
>=C2=A0 =C2=A0 =C2=A0>>>>>> when
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ; 5389 was published they *now* seem crazily long. Did
>=C2=A0 =C2=A0 =C2=A0the WG
>=C2=A0 =C2=A0 =C2=A0>>>>>> explicitly
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ; decide not to update them?
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0No,= nobody ever suggested that there was an issue there.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> OK, well, this seems l= ike it should be considered, then,
>=C2=A0 =C2=A0 =C2=A0because this
>=C2=A0 =C2=A0 =C2=A0>>>>>>> doesn't
>=C2=A0 =C2=A0 =C2=A0>>>>>>> match modern practice.=
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ; This would be good to explain.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0New= text:
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 [...]
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 containing the subjectAltName of that certificate.=C2=A0
>=C2=A0 =C2=A0 =C2=A0The test
>=C2=A0 =C2=A0 =C2=A0>> on
>=C2=A0 =C2=A0 =C2=A0>>>>>> the
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 MESSAGE-INTEGRITY-SHA256 attribute indicates that the
>=C2=A0 =C2=A0 =C2=A0>>>> transaction
>=C2=A0 =C2=A0 =C2=A0>>>>>> is
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 authenticated and that the client implements this
>=C2=A0 =C2=A0 =C2=A0>> specification
>=C2=A0 =C2=A0 =C2=A0>>>>>> and
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 so can process the ALTERNATE-DOMAIN attribute.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> All right.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 o=C2=A0 What authentication and message-i= ntegrity
>=C2=A0 =C2=A0 =C2=A0mechanisms
>=C2=A0 =C2=A0 =C2=A0>>>>>> are used.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 o=C2=A0 The considerations around manual = vs.
>=C2=A0 =C2=A0 =C2=A0automatic key
>=C2=A0 =C2=A0 =C2=A0>>>>>> derivation
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> for
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the integrity mechanism, as = discussed in
>=C2=A0 =C2=A0 =C2=A0[RFC4107].
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 o=C2=A0 What mechanisms are used to disti= nguish STUN
>=C2=A0 =C2=A0 =C2=A0>> messages
>=C2=A0 =C2=A0 =C2=A0>>>>>> from other
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>> Why is this required? It seems like that's a generic
>=C2=A0 =C2=A0 =C2=A0STUN
>=C2=A0 =C2=A0 =C2=A0>>>>>> feature.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> That text is identical to the text in RFC 5389.=C2=A0 RFC
>=C2=A0 =C2=A0 =C2=A05764/7983
>=C2=A0 =C2=A0 =C2=A0>>>> is
>=C2=A0 =C2=A0 =C2=A0>>>>>> one such
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> mechanism, but there is nothing that prevent another
>=C2=A0 =C2=A0 =C2=A0protocol
>=C2=A0 =C2=A0 =C2=A0>>>>>> stack to use
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> a different mechanism (inference, shim, etc...)
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ; But ultimately no matter what the other protocol
>=C2=A0 =C2=A0 =C2=A0provides for
>=C2=A0 =C2=A0 =C2=A0>>>>>> demux, STUN
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ; has its
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ; own demux.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0In = fact I think that the reason for that item was because
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0FIN= GERPRINT can also be used to demux STUN traffic, but
>=C2=A0 =C2=A0 =C2=A0it is
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0opt= ional.=C2=A0 So an STUN Usage needs to tell if FINGERPRINT is
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0man= datory (like in ICE).
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> This should be explain= ed.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 that is not readily subject to offline di= ctionary
>=C2=A0 =C2=A0 =C2=A0>>>> attacks.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 Protection of the channel itself, using T= LS or
>=C2=A0 =C2=A0 =C2=A0DTLS,
>=C2=A0 =C2=A0 =C2=A0>>>>>> mitigates
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> these
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 attacks.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 STUN supports both MESSAGE-INTEGRITY and<= br> >=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0MES= SAGE-INTEGRITY-SHA256,
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 which is subject to bid down attacks by a= n on-path
>=C2=A0 =C2=A0 =C2=A0>>>>>> attacker.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>> By an on-path attacker who can forge HMAC-SHA1 in
>=C2=A0 =C2=A0 =C2=A0real-time?
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0Tha= t's a
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>> pretty serious adversary, so you should clarify here
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> New text:
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>=C2=A0 =C2=A0 STUN supports both MESSAGE-INTEGRITY and
>=C2=A0 =C2=A0 =C2=A0>>>>>> MESSAGE-INTEGRITY-SHA256,<= br> >=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>=C2=A0 =C2=A0 which is subject to bid down attacks by an on-path
>=C2=A0 =C2=A0 =C2=A0attacker
>=C2=A0 =C2=A0 =C2=A0>>>>>> that
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>=C2=A0 =C2=A0 would strip the MESSAGE-INTEGRITY-SHA256 attribute
>=C2=A0 =C2=A0 =C2=A0leaving
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0onl= y the
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>=C2=A0 =C2=A0 MESSAGE-INTEGRITY attribute and exploiting a potential >=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0vul= nerability.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>=C2=A0 =C2=A0 Protection of the channel itself, using TLS or DTLS,
>=C2=A0 =C2=A0 =C2=A0>>>> mitigates
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0the= se
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>=C2=A0 =C2=A0 attacks.=C2=A0 Timely removal of the support of
>=C2=A0 =C2=A0 =C2=A0>> MESSAGE-INTEGRITY
>=C2=A0 =C2=A0 =C2=A0>>>>>> in a
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>=C2=A0 =C2=A0 future version of STUN is necessary.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ; I still don't understand the capabilities you seem to
>=C2=A0 =C2=A0 =C2=A0believe
>=C2=A0 =C2=A0 =C2=A0>> the
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0att= acker
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ; has.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ; Can you describe the exact attack.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A01. = Vulnerability is found in HMAC-SHA1
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A02. = Client Alice still supports M-I and M-I-256, does not
>=C2=A0 =C2=A0 =C2=A0know
>=C2=A0 =C2=A0 =C2=A0>> what
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0ver= sion of STUN server Bob supports and so send both.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A03. = On-path attacker removes M-I-256.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A05. = stunbis server Bob thinks that Alice is an RFC 5389
>=C2=A0 =C2=A0 =C2=A0client and
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0con= tinue with that protocol.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> This seems like an ext= remely weak attack. In general, any
>=C2=A0 =C2=A0 =C2=A0protocol of
>=C2=A0 =C2=A0 =C2=A0>>>>>>> this type is as strong=
>=C2=A0 =C2=A0 =C2=A0>>>>>>> as the weakest integri= ty algorithm it supports, so it's not
>=C2=A0 =C2=A0 =C2=A0that the
>=C2=A0 =C2=A0 =C2=A0>>>>>>> protocol has a downgra= de
>=C2=A0 =C2=A0 =C2=A0>>>>>>> attack, but rather tha= t the minimum algorithm supported is
>=C2=A0 =C2=A0 =C2=A0one you
>=C2=A0 =C2=A0 =C2=A0>>>> don't
>=C2=A0 =C2=A0 =C2=A0>>>>>>> trust as much
>=C2=A0 =C2=A0 =C2=A0>>>>>>> as you might like.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> -Ekr
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0--<= br> >=C2=A0 =C2=A0 =C2=A0>>
>
>
>
>=C2=A0 =C2=A0 =C2=A0--
>=C2=A0 =C2=A0 =C2=A0Marc Petit-Huguenin
>=C2=A0 =C2=A0 =C2=A0Email: marc@petit-huguenin.org <mailto:marc@petit-huguenin.org> >=C2=A0 =C2=A0 =C2=A0Blog: https://marc.petit-huguenin.org
>=C2=A0 =C2=A0 =C2=A0Profile: https://www.linkedin.com/in/pet= ithug
>
--000000000000f9b442057b05dc02-- From nobody Mon Nov 19 12:57:03 2018 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722A3128BCC; Mon, 19 Nov 2018 12:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 PYSyM0XQg9n0; Mon, 19 Nov 2018 12:56:59 -0800 (PST) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::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 783AD130DD7; Mon, 19 Nov 2018 12:56:55 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id v15-v6so27352355ljh.13; Mon, 19 Nov 2018 12:56:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LJgcTbn3IqYg/Yt4tumeue6eI5qXYXHOLxUT8LvzoFA=; b=TzX41q2BYWEpfYRuM5lFQdLzAxKrT7Y2bzdq8h/jF+xNg8HeK6WzICX5x5WzAgvq5I Ndu6p4UQ7vhz9OSy4J8RYAqCxbaXvTjz+9Ajtad767qkxW2p9+xp9nBmX9ZmBXJMXUnW TkJKOiLR79XeKtr1xUQcbQxwZlz8Gf//GsUqyY5hCK40xVa7xrtw6nRSj6vJgFGNWrod 1uBUfcYyByzGCh8yQFl3cEq+SHd4pUMFpy9yM9Js9x3WHLpdjyIjgnPmP4bcIG9sfhsG uxRM2A+DkSetK8Bu0zmOpYzqR7DvdkFmaGLQfTFBR3Tn2PoldaSSFgmdoNVwa/VL9Bq3 dvHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LJgcTbn3IqYg/Yt4tumeue6eI5qXYXHOLxUT8LvzoFA=; b=o5DO9+bQSJWsyt8NGN9b54pL6s3dygW7nUXED2oeTlLUAAgbh7Uh96sk1NpEYo1OvN SSNFKt7TZmNrPC6p/z8aLRoY2iGwWYtLCSciXT2fpl3OOrUYLOpCV//7snA9udP8LEqH PoDyvkC0EskmFcKmYvbS+Yy53hq0qxXNGFWXXIMSGNONdL+w0xWcIkaDlXfM5jrphuhR rwOTEFfex9zKPsQCEu7xcECp1CWnvdlvr4nTN1kEJfmVFILj5+cdNE3ibeM7vPw/nvOm GlooIL1h1QPzl9C0rIRQ0l5OPweocNL4bxIN6jijZ7JrQrJfnbfqiqzamvUlIa1O6sVG srJg== X-Gm-Message-State: AGRZ1gJR1artoRpIDfwy5vgdFAdTeQo6uOA4mazMg27Sjku5d2OnRiKn x3DoONi02cudsq4BpmEoDlS994EeCaSw6pKbwOwy2g== X-Google-Smtp-Source: AJdET5fL2dGQXJRVODG3jiaRC26J05VLDP3Kb3/TLIkA44ZPu851h16iuz9EuS4AzSp7+CIZVhQjy7P67eepCivG3wU= X-Received: by 2002:a2e:197:: with SMTP id f23-v6mr12546541lji.144.1542661012997; Mon, 19 Nov 2018 12:56:52 -0800 (PST) MIME-Version: 1.0 References: <153834237082.13405.1228259718885034461.idtracker@ietfa.amsl.com> In-Reply-To: <153834237082.13405.1228259718885034461.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Mon, 19 Nov 2018 14:56:40 -0600 Message-ID: To: Adam Roach Cc: IESG , tram-chairs@ietf.org, draft-ietf-tram-stun-pmtud@ietf.org, Gonzalo Camarillo , "Asveren, Tolga" , tram@ietf.org Content-Type: multipart/alternative; boundary="000000000000b04c0d057b0ac11d" Archived-At: Subject: Re: [tram] Adam Roach's Discuss on draft-ietf-tram-stun-pmtud-10: (with DISCUSS and COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 19 Nov 2018 20:57:02 -0000 --000000000000b04c0d057b0ac11d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So, having been nudged on this one ... On Sun, Sep 30, 2018 at 4:19 PM Adam Roach wrote: > Adam Roach has entered the following ballot position for > draft-ietf-tram-stun-pmtud-10: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This seems like an interesting technique that warrants collection of > operational > experience. > > >From a process perspective, I think we have a bit of an issue, unless I'= ve > overlooked something relevant. This is proposed as a Standards-Track > document, > but it relies on the use of the PADDING attribute defined in RFC 5780. RF= C > 5780 is Experimental, so this is a formal downref. And RFC 5780 does not > appear in the downref registry [1], nor did the IETF last call [2] includ= e > a > request that the IETF community consider allowing such a refernce. > > >From a practical perspective, the mechanism described in this document > seems > like the kind of thing that it would be useful to gather operational > experience > with prior to putting it on the standards track. I have some operational > concerns (described below) that I think could be either proven out or > dispelled > by experimental deployment of the technology. > > My recommendation is to recategorize this mechanism as experimental, > adding some > text about the desire to gather operational experience. > > For avoidance of doubt: My DISCUSS is only on the process issue, and I'll > happily clear regardless of how this issue is rationalized (e.g., either = by > running IETF last call again, by reclassifying this mechanism as > experimental, > or perhaps some novel solution that I may not have thought of). Everythin= g > else is merely a recommendation. > I don't think I've seen a specific response to Adam's point here, which I believe is that one of (at least) three things should happen - - a second Last Call, explicitly calling out this downref, OR - approval as an Experimental RFC, which makes the downref issue go away, O= R - (and this didn't happen in this thread, but in some conversation, I remember that) Adam wondered if reusing the PADDING attribute was the right thing to do (and that was a question, not a concern, but relevant here, since if this document defined its own attribute, the downref would also go away). Any thoughts on this? Thanks, Spencer > ____ > [1] https://datatracker.ietf.org/doc/downref/ > [2] https://www.ietf.org/mail-archive/web/tram/current/msg02609.html > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > In the general case, STUN servers aren't aware of the signaling protocol > that is > in use. For example, when a TURN server is use with RTP and RTCP with a > session > set up via SIP, there is no requirement that the TURN server itself have > any > inherent knowledge of SIP or RTP or RTCP. From that perspective, the > following > text in section 4.2 is a bit confusing and/or problematic: > > Some application layer protocols may already have a way of > identifying each individual UDP packet, in which case these > identifiers SHOULD be used in the IDENTIFIERS attribute of the Report > Response. > > It seems odd that I would have to teach my TURN server about the protocol= s > I'm > using it with just so that it can identify the packets. > > This behavior, combined with the requirement that all behavior be > symmetrical > ("As a result of the fact that all endpoints implementing this > specification > are both clients and servers") leads me to believe that perhaps the use > cases > that drove this mechanism are tightly scoped to direct peer-to-peer uses > of ICE, > while the other common uses of STUN (e.g., public TURN servers used for > symmetric NAT traversal) were given no consideration. If that was > intentional, > then I think the abstract and introduction need to clearly describe the > scenarios the mechanism was defined for; and, more importantly, clarify > that it > does not work for the general case, including STUN servers used for NAT > traversal. > > I suspect that, once this mechanism begins to be deployed, the foregoing > limitations will cause operational difficulties, which may in turn sugges= t > changes to the mechanism that is currently defined, hence my suggestion > above > to recharacterize the mechanism as experimental. > > -------------------------------------------------------------------------= -- > > =C2=A74: > > > The Probing mechanism is used to discover the Path MTU in one > > direction only, from the client to the server. > > Nit: "...only: from..." > > > Two Probing mechanisms are described, a Simple Probing mechanism and > > Nit: "...described: a Simple..." > > > a more complete mechanism that can converge quicker and find an > > Nit: "...converge more quickly..." > > > appropriate PMTU in the presence of congestion. Additionally, the > > Nit: Please expand "PMTU" on first use. > > -------------------------------------------------------------------------= -- > > =C2=A74.2.5: > > > algorithm used for the FINGERPRINT attribute (i.e., the CRC-32 of the > > payload XOR'ed with the 32-bit value 0x5354554e [ITU.V42.2002]). > > The location of the citation in here implies that the XOR'ing described i= s > part > of V.42. Given that 0x53545554E is ASCII for "STUN," I'm pretty sure > that's not > part of the underlying CRC. Would suggest reworking as: > > algorithm used for the FINGERPRINT attribute (i.e., the CRC-32 > calculated per the algorithm defined in [ITU.V42.2002], such has > subsequently been XOR'ed with 32-bit value 0x5354554e). > > > --000000000000b04c0d057b0ac11d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So, having been nudged on this one ...=C2=A0

On Sun, Sep 30, 2018 at 4:19 PM Adam = Roach <adam@nostrum.com> wrot= e:
Adam Roach has entered the follo= wing ballot position for
draft-ietf-tram-stun-pmtud-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-i= etf-tram-stun-pmtud/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This seems like an interesting technique that warrants collection of operat= ional
experience.

>From a process perspective, I think we have a bit of an issue, unless I= 've
overlooked something relevant. This is proposed as a Standards-Track docume= nt,
but it relies on the use of the PADDING attribute defined in RFC 5780. RFC<= br> 5780 is Experimental, so this is a formal downref. And RFC 5780 does not appear in the downref registry [1], nor did the IETF last call [2] include = a
request that the IETF community consider allowing such a refernce.

>From a practical perspective, the mechanism described in this document = seems
like the kind of thing that it would be useful to gather operational experi= ence
with prior to putting it on the standards track. I have some operational concerns (described below) that I think could be either proven out or dispe= lled
by experimental deployment of the technology.

My recommendation is to recategorize this mechanism as experimental, adding= some
text about the desire to gather operational experience.

For avoidance of doubt: My DISCUSS is only on the process issue, and I'= ll
happily clear regardless of how this issue is rationalized (e.g., either by=
running IETF last call again, by reclassifying this mechanism as experiment= al,
or perhaps some novel solution that I may not have thought of). Everything<= br> else is merely a recommendation.

I don&= #39;t think I've seen a specific response to Adam's point here, whi= ch I believe is that one of (at least) three things should happen -

- a second Last Call, explicitly calling out this downref= , OR

- approval as an Experimental RFC, which make= s the downref issue go away, OR

- (and this didn&#= 39;t happen in this thread, but in some conversation, I remember that) Adam= wondered if reusing the PADDING attribute was the right thing to do (and t= hat was a question, not a concern, but relevant here, since if this documen= t defined its own attribute, the downref would also go away).
Any thoughts on this?

Thanks,

Spencer
=C2=A0
____
[1] https://datatracker.ietf.org/doc/downref/
[2] https://www.ietf.org/mail-archiv= e/web/tram/current/msg02609.html


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In the general case, STUN servers aren't aware of the signaling protoco= l that is
in use. For example, when a TURN server is use with RTP and RTCP with a ses= sion
set up via SIP, there is no requirement that the TURN server itself have an= y
inherent knowledge of SIP or RTP or RTCP. From that perspective, the follow= ing
text in section 4.2 is a bit confusing and/or problematic:

=C2=A0 =C2=A0Some application layer protocols may already have a way of
=C2=A0 =C2=A0identifying each individual UDP packet, in which case these =C2=A0 =C2=A0identifiers SHOULD be used in the IDENTIFIERS attribute of the= Report
=C2=A0 =C2=A0Response.

It seems odd that I would have to teach my TURN server about the protocols = I'm
using it with just so that it can identify the packets.

This behavior, combined with the requirement that all behavior be symmetric= al
("As a result of the fact that all endpoints implementing this specifi= cation
are both clients and servers") leads me to believe that perhaps the us= e cases
that drove this mechanism are tightly scoped to direct peer-to-peer uses of= ICE,
while the other common uses of STUN (e.g., public TURN servers used for
symmetric NAT traversal) were given no consideration. If that was intention= al,
then I think the abstract and introduction need to clearly describe the
scenarios the mechanism was defined for; and, more importantly, clarify tha= t it
does not work for the general case, including STUN servers used for NAT
traversal.

I suspect that, once this mechanism begins to be deployed, the foregoing limitations will cause operational difficulties, which may in turn suggest<= br> changes to the mechanism that is currently defined, hence my suggestion abo= ve
to recharacterize the mechanism as experimental.

---------------------------------------------------------------------------=

=C2=A74:

>=C2=A0 The Probing mechanism is used to discover the Path MTU in one >=C2=A0 direction only, from the client to the server.

Nit: "...only: from..."

>=C2=A0 Two Probing mechanisms are described, a Simple Probing mechanism= and

Nit: "...described: a Simple..."

>=C2=A0 a more complete mechanism that can converge quicker and find an<= br>
Nit: "...converge more quickly..."

>=C2=A0 appropriate PMTU in the presence of congestion.=C2=A0 Additional= ly, the

Nit: Please expand "PMTU" on first use.

---------------------------------------------------------------------------=

=C2=A74.2.5:

>=C2=A0 algorithm used for the FINGERPRINT attribute (i.e., the CRC-32 o= f the
>=C2=A0 payload XOR'ed with the 32-bit value 0x5354554e [ITU.V42.200= 2]).

The location of the citation in here implies that the XOR'ing described= is part
of V.42. Given that 0x53545554E is ASCII for "STUN," I'm pret= ty sure that's not
part of the underlying CRC. Would suggest reworking as:

=C2=A0 =C2=A0algorithm used for the FINGERPRINT attribute (i.e., the CRC-32=
=C2=A0 =C2=A0calculated per the algorithm defined in [ITU.V42.2002], such h= as
=C2=A0 =C2=A0subsequently been XOR'ed with 32-bit value 0x5354554e).

--000000000000b04c0d057b0ac11d-- From nobody Mon Nov 19 13:05:06 2018 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97284130DF3; Mon, 19 Nov 2018 13:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Svr9txtNL2uj; Mon, 19 Nov 2018 13:04:41 -0800 (PST) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 99D231292F1; Mon, 19 Nov 2018 13:04:40 -0800 (PST) Received: by mail-lf1-x12a.google.com with SMTP id e26so20572375lfc.2; Mon, 19 Nov 2018 13:04:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q3ha2Wz6fc3GQA4T//9M7q9MxSS4CbMdsWz3VM3bvS8=; b=JK0/QVisZTPChxjwJhHpiE67V9s5ncj2huBLFqBylO9fsnNHfQmkw+JRhSYg6JYrGV U08uS1IDsDf2yHDbdDvtTLy696fz4Wq+EFnbL+an0m/Btk+lbdDYf7RaCgLKtYQf6Foq wCMYQ0JxbrdeNd8y2b8PDOfvKB1iOTvRxyubcSIrbJC2zl3vHvTKo924P4P/H0ne/y0l TEGE7tf5dOUXOaHRoc0k5JrRu2jAR/qOMGJfV6plO4Jf7gsdhVgURnGPNJtX449xkL0T HCbuDj+5Nx8LvqRLU9m5PcGy1hFf9W3WG9K5+CeOUDcr0yU8c20O6Fx298SXEdubCuh5 DXCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Q3ha2Wz6fc3GQA4T//9M7q9MxSS4CbMdsWz3VM3bvS8=; b=ZkjYcV5DUXbt1mMKY/2MX9pFy13j1Qz2euubArS0qXOVQp1PdhDFarpPauDQuoKh5L dLgQpEj8Fp9RutGBhy3u5XFdDHZILZr/AjLS3AP62sZXSu8dYYWMfF1Hrt8cc3uLo215 ChsYxzMJHiF3lJfrXGcgLurncse99oylSC7Toy9C8vXgRUHrPIICuLay2POROffEzx+A AA3cbEazlzwZiSFHDpoo1jGjDqBHtkZDZX7d21SWygvN7A1NtQeXQNNURfkS6FVlnGS1 tobMtHzNmvCWlb8fiZP5br48hq0lMgSQP/OGIeus1fXPkhjy/vGJ1pFAst8FxEwpoNtO B0kw== X-Gm-Message-State: AGRZ1gI7Z2Ph7ooeQeHrbJelQdN5VtBgt/TWoGvqklwnR30aUzVCWdx4 EqKjzoIDEczLABJPTh1XTyGLCoJgy6VqWm+96sw= X-Google-Smtp-Source: AJdET5etA24aW7W34gkkFR0J/yIErKBy8cX48ozvSKJUb93BG6cg1v00g5BwPEqxKYCDhzLHWqdAQlZJP+gWwTFSwrI= X-Received: by 2002:a19:d145:: with SMTP id i66mr12202222lfg.97.1542661478526; Mon, 19 Nov 2018 13:04:38 -0800 (PST) MIME-Version: 1.0 References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> <02569943-db8f-654e-7322-49bc1f1a1163@acm.org> <235b838f-2800-2cd0-8b01-947e70837619@ericsson.com> <472563ee-5fc3-655d-8e31-138cc774e608@acm.org> In-Reply-To: From: Spencer Dawkins at IETF Date: Mon, 19 Nov 2018 15:04:25 -0600 Message-ID: To: Eric Rescorla Cc: Gonzalo Camarillo , Marc Petit-Huguenin , tram-chairs@ietf.org, tram@ietf.org, "Asveren, Tolga" , IESG , draft-ietf-tram-stunbis@ietf.org Content-Type: multipart/alternative; boundary="0000000000006fb46c057b0addf9" Archived-At: Subject: Re: [tram] Eric Rescorla's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 19 Nov 2018 21:04:47 -0000 --0000000000006fb46c057b0addf9 Content-Type: text/plain; charset="UTF-8" Hi, Gonzalo, On Mon, Nov 19, 2018 at 9:06 AM Eric Rescorla wrote: > Not really. I have not received any response to my mail of Oct 23. As > before, I'm happy to have a call, but I believe we're reaching the limits > of what can be accomplished by email. > Eric would know best (it being his Discuss), but this is also my understanding. I can add this to the agenda of the IESG informal telechat on November 29, if there hasn't been a call before then, but I don't have a reason to wait until then, if it's possible to talk sooner. Thanks, Spencer > > -Ekr > > > On Mon, Nov 19, 2018 at 6:35 AM Gonzalo Camarillo < > gonzalo.camarillo@ericsson.com> wrote: > >> Hi Spencer, >> >> what is the status of this? Are the authors and the document shepherd >> working with the relevant ADs on the discusses? >> >> https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/ballot/ >> >> Cheers, >> >> Gonzalo >> >> On 24-Oct-18 16:40, Spencer Dawkins at IETF wrote: >> > Hi, Marc, >> > >> > On Wed, Oct 24, 2018 at 3:44 AM Marc Petit-Huguenin > > > wrote: >> > >> > Hi Spencer, >> > >> > I sent my answers to Eric Rescorla questions on 2018-10-07 following >> > an in-person meeting with my co-author, but never got a response >> > back. Because there was no change proposed by Eric I went ahead and >> > published -19 a couple of weeks after that, with the text agreed in >> > response to Adam's and Benjamin's comments. >> > >> > https://www.ietf.org/mail-archive/web/tram/current/msg02635.html >> > >> > >> > Ah - I wonder if that was what had happened. >> > >> > It sounds like you did the right thing, and that Eric has now responded, >> > which is also the right thing to do. >> > >> > Thanks for helping me understand. >> > >> > Spencer >> > >> > >> > On 10/23/18 7:28 PM, Spencer Dawkins at IETF wrote: >> > > Hi, Marc, >> > > >> > > I see that a -19 has been submitted, but didn't see a reply from >> > Eric in >> > > this thread. Do you think that you've converged? >> > > >> > > (I saw an offer of a conference call, so thought an out-of-band >> > > conversation might have happened) >> > > >> > > Thanks, >> > > >> > > Spencer >> > > >> > > On Sun, Oct 7, 2018 at 9:35 AM Marc Petit-Huguenin >> > > wrote: >> > > >> > >> Hi Eric, >> > >> >> > >> Please see inline. >> > >> >> > >> On 09/10/2018 03:25 AM, Eric Rescorla wrote: >> > >>> On Sat, Sep 8, 2018 at 2:31 PM, Marc Petit-Huguenin >> > > >> > >>> wrote: >> > >>> >> > >>>> Hi Eric, >> > >>>> >> > >>>> Apologies for the delay in getting back to that. >> > >>>> >> > >>>> I think that there is some misunderstanding in what STUNbis is >> > trying to >> > >>>> do, so please see my comments inline. >> > >>>> >> > >>>> On 06/18/2018 10:43 AM, Eric Rescorla wrote: >> > >>>>> Hi folks, >> > >>>>> >> > >>>>> I've reviewed the new version, but I don't think that the >> biddown >> > >>>>> discussion makes much sense. >> > >>>>> >> > >>>>> To recap, there are two hashes here: >> > >>>>> >> > >>>>> - The hash which you use to store the password with (currently >> > mostly >> > >>>> MD5) >> > >>>>> - The hash you use to compute the MAC (currently SHA-1). >> > >>>>> >> > >>>>> First, let's stipulate that MD5 isn't a great choice here, >> > though SHA-1 >> > >>>>> isn't a great choice >> > >>>>> either for pwd hashing You want Argon or the like. With that >> said, >> > >>>> there's >> > >>>>> no sensible >> > >>>>> biddown attack on that hash because it's a per-server feature, >> > not a >> > >>>>> per-transaction >> > >>>>> feature. So, as long as the server has MD5-hashed passwords, >> the >> > >>>> situation >> > >>>>> is bad. >> > >>>> >> > >>>> In no place in STUNbis we are proposing to use SHA-1 for >> password >> > >>>> encryption, so I am not sure where that come from. What we >> > propose is: >> > >>>> >> > >>> >> > >>> You're right, it's SHA-256, but my criticisms apply equally >> there. >> > >> >> > >> SHA-256 was what the WG adopted. Our attempts to add other >> passwords >> > >> encryption mechanisms were denied. It is true that Argon2 was >> > not in that >> > >> list (in our defense Argon2 was not known before July 2015), but >> > I do not >> > >> see why the WG would have accepted that one over the others. >> > Anyway it is >> > >> too late to fix this, as it is my understanding that the WG does >> > not have >> > >> enough energy to reach consensus on a new password algorithm. >> > Someone can >> > >> just write a draft adding Argon2 as password encryption, as we >> > will have a >> > >> IANA registry for that. >> > >> >> > >>> >> > >>> >> > >>>> - Establish a registry for new password algorithms (section >> > 18.5), so >> > >>>> algorithms like Argon2 could be added later (but note that our >> own >> > >>>> proposals to add more password algorithms were rejected by the >> > working >> > >>>> group). >> > >>>> - Add a new password algorithm to that registry, namely >> SHA-256. >> > >>>> - Register MD5 as an initial password algorithm for backward >> > >> compatibility >> > >>>> purpose. >> > >>>> >> > >>>> As for the biddown protection itself, it is my recollection >> that it >> > >>>> happened more or less like that: >> > >>>> >> > >>>> >> > >>>> INT. MEETING ROOM - DAY >> > >>>> >> > >>>> One of the co-editors of STUNBis stands at the microphone: >> > >>>> >> > >>>> CO-EDITOR >> > >>>> We added SHA-256 protection for passwords >> > >>>> in STUNBis. >> > >>>> >> > >>>> SOMEONE (V.O.) >> > >>>> As MD5 still need to be supported, you need >> to add >> > >>>> protection for bid-down attacks. >> > >>>> >> > >>>> CLOSE-UP on CO-EDITOR ROLLING HIS EYES >> > >>>> >> > >>>> CO-EDITOR >> > >>>> OK, I'll work on that. >> > >>>> >> > >>>> Four to eight months has passed. >> > >>>> >> > >>>> INT. ANOTHER MEETING ROOM - DAY >> > >>>> >> > >>>> The same co-editor of STUNBis stands at the microphone: >> > >>>> >> > >>>> CO-EDITOR >> > >>>> We added a nice mechanism to prevent bid-down >> > >>>> attacks on passwords. Any comments? >> > >>>> >> > >>>> THE ROOM >> > >>>> (silence) >> > >>>> >> > >>>> CO-EDITOR >> > >>>> Moving on... >> > >>>> >> > >>> >> > >>> I don't see how any of this is relevant to my technical points >> > above. >> > >> >> > >> My point was that we, the co-editors, did not decide on adding >> > bid-down >> > >> protection, someone asked us to do so and no-one in the WG saw >> > any problem >> > >> with that. The reasons that person wanted that are not known to >> > us but, as >> > >> you insist, here's one reason I can think of: >> > >> >> > >> It is a fact that, for operational reasons, a password database >> > cannot be >> > >> re-encrypted at once. Also for operational reasons, the MD5 >> password >> > >> cannot be immediately removed from the database as soon the user >> > submitted >> > >> a new one. In fact, and for quite some time, both encrypted >> > variants of >> > >> the same password may have to be kept in that database, because a >> > single >> > >> user may use a mix of devices, some of them that use an RFC 5389 >> > client, >> > >> some that use a STUNbis client. It is up to the STUN server >> owner to >> > >> decide how long the migration to STUNbis will take and when it >> > will be >> > >> acceptable to reject all RFC 5389 (i.e. MD5) clients (that >> > migration time >> > >> can be purposely reduced to 0 seconds but that's the choice and >> > >> responsibility of the owner of the server). >> > >> >> > >> Meanwhile we still need to be sure that if the STUN client is >> > implementing >> > >> STUNbis it unconditionally gets the additional protection of the >> new >> > >> password encryption algorithm. That's where the biddown >> > protection kicks >> > >> in, by preventing an online attacker to have the server >> > misidentifying a >> > >> STUNbis client as an RFC 5389 client, by preventing an online >> > attacker to >> > >> have the client misidentifying a STUNbis server as a RFC 5389 >> > server, and >> > >> having both them use the MD5 encrypted password instead of the >> > SHA-256 >> > >> encrypted password, all of that easily done by stripping the >> > unprotected >> > >> 401 response of the new STUNbis PASSWORD-ALGORITHMS attribute. >> > >> >> > >>> >> > >>> >> > >>> >> > >>>>> The second topic is the hash used to compute the MAC. However, >> > I don't >> > >>>> see >> > >>>>> how >> > >>>>> this gives you sensible biddown protection because that hash >> > is also >> > >> used >> > >>>>> to compute >> > >>>>> MAC over the negotiation: an attacker who has compromised a >> > MAC which >> > >> the >> > >>>>> server >> > >>>>> supports will quite likely be able to forge a MAC over the >> > transcript >> > >> as >> > >>>>> well. This is, >> > >>>>> I suppose, potentially useful as a defense against some other >> > weakness >> > >>>>> (e.g., >> > >>>>> version #), but I don't really see how the current design >> > helps against >> > >>>>> attacks on the >> > >>>>> MAC. >> > >>>> >> > >>>> There is no biddown attack protection for the MAC, as stated in >> > Section >> > >>>> 16.3: >> > >>>> >> > >>>> "The bid-down protection mechanism described in this document >> > is new, >> > >>>> and thus cannot currently protect against a bid-down attack >> that >> > >>>> lowers the strength of the hash algorithm to HMAC-SHA1." >> > >>>> >> > >>>> What we put in place is a plan for *future* versions of STUN >> to get >> > >>>> biddown protection for the MAC. That's it, no more, no less. >> > >>>> >> > >>> >> > >>> Yes, but I don't believe that this will provide bid-down >> > protection for >> > >> the >> > >>> MAC in the future for the reasons I indicate above. >> > >>> >> > >>> If you think this does something useful, please show me an >> > example attack >> > >>> and how this fixes it. Note that it's not generally useful to >> > just bid >> > >> down >> > >>> the MAC itself unless the MAC you bid down to is weak enough to >> > exploit >> > >> in >> > >>> some other way. >> > >> >> > >> I do not know what weaknesses will be discovered in the future. >> > I am also >> > >> pretty sure that the cost of not using that mechanism is very >> > close to 0. >> > >> What I am sure of is that the cost of reengineering a new biddown >> > >> protection mechanism if we ever need it will be high. We already >> > went >> > >> through the pains of designing one for the password algorithm, so >> > why not >> > >> extend it so it can be used in the aftermath of the next Snowden >> > facepalm >> > >> moment? >> > >> >> > >>> Again, happy to have a call to walk though this if that >> > >>> helps. >> > >>> >> > >>> -Ekr >> > >>> >> > >>> >> > >>> >> > >>> >> > >>>>> >> > >>>>> You might think that there was a MAC which was easier to >> > reverse to >> > >> find >> > >>>>> the original >> > >>>>> password, but the defense you have here doesn't help with that >> > because >> > >>>> the >> > >>>>> on-path attacker can do a bid-down and use the client as a MAC >> > oracle >> > >> for >> > >>>>> any MAC the client supports. >> > >>>>> >> > >>>>> So, I still don't understand what this is supposed to do. >> Happy to >> > >> have a >> > >>>>> call if you >> > >>>>> think that helps >> > >>>>> >> > >>>>> -Ekr >> > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> On Mon, Jun 18, 2018 at 3:40 AM, Gonzalo Camarillo < >> > >>>>> Gonzalo.Camarillo@ericsson.com >> > > wrote: >> > >>>>> >> > >>>>>> Marc, Eric, >> > >>>>>> >> > >>>>>> what is the status of this discussion? >> > >>>>>> >> > >>>>>> Thanks, >> > >>>>>> >> > >>>>>> Gonzalo >> > >>>>>> >> > >>>>>> On 04/05/2018 2:35 AM, Eric Rescorla wrote: >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> On Mon, Apr 23, 2018 at 11:16 AM, Marc Petit-Huguenin < >> > >>>> petithug@acm.org >> > >>>>>>> >> wrote: >> > >>>>>>> >> > >>>>>>> On 04/22/2018 05:22 PM, Eric Rescorla wrote: >> > >>>>>>> > On Sun, Apr 22, 2018 at 2:02 PM, Marc Petit-Huguenin < >> > >>>>>> petithug@acm.org >> > >> >> > >>>>>>> > wrote: >> > >>>>>>> > >> > >>>>>>> >> >> > >>>>>>> >>>> For a request or indication message, the agent >> > MUST >> > >>>>>> include the >> > >>>>>>> >>>> USERNAME, MESSAGE-INTEGRITY-SHA256, and >> > >> MESSAGE-INTEGRITY >> > >>>>>>> >> attributes >> > >>>>>>> >>>> in the message unless the agent knows from an >> > external >> > >>>>>> indication >> > >>>>>>> >>>> which message integrity algorithm is supported >> > by both >> > >>>>>> agents. In >> > >>>>>>> >>>> this case either MESSAGE-INTEGRITY or >> > >>>>>> MESSAGE-INTEGRITY-SHA256 MUST >> > >>>>>>> >>>> be included in addition to USERNAME. The HMAC >> > for the >> > >>>>>> MESSAGE- >> > >>>>>>> >>> >> > >>>>>>> >>> This text appears to conflict with S 7.3 of >> > 5245-bis, which >> > >>>> says: >> > >>>>>>> >> >> > >>>>>>> >> [text missing] >> > >>>>>>> >> >> > >>>>>>> >> Hmm, no, RFC245bis is still referencing RFC5389, so >> the >> > >>>> procedure >> > >>>>>> for >> > >>>>>>> >> stunbis does not apply. >> > >>>>>>> >> >> > >>>>>>> > >> > >>>>>>> > I hear what you're saying, but publishing two >> > documents at the >> > >>>>>> same time >> > >>>>>>> > which >> > >>>>>>> > make contrary recommendations about the same basic >> > protocol is >> > >>>>>> un-good. >> > >>>>>>> >> > >>>>>>> Sure, but wouldn't it be simpler to have rfc5245bis >> > using stunbis >> > >>>>>>> and have them updating their text, more than adding some >> > tortuous >> > >>>>>>> text in stunbis? >> > >>>>>>> >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> >>> The STUN usage must specify which transport >> > protocol is >> > >>>>>> used, and >> > >>>>>>> >> how >> > >>>>>>> >>>> the agent determines the IP address and port >> > of the >> > >>>>>> recipient. >> > >>>>>>> >>>> Section 8 describes a DNS-based method of >> > determining >> > >> the >> > >>>>>> IP >> > >>>>>>> >> address >> > >>>>>>> >>>> and port of a server that a usage may elect to >> > use. >> > >> STUN >> > >>>>>> may be >> > >>>>>>> >> used >> > >>>>>>> >>>> with anycast addresses, but only with UDP and >> > in usages >> > >>>>>> where >> > >>>>>>> >>>> authentication is not used. >> > >>>>>>> >>> >> > >>>>>>> >>> Why this restriction? You should be able to use >> > anycast with >> > >>>>>> long-term >> > >>>>>>> >>> AUTH for (say) TURN. >> > >>>>>>> >> >> > >>>>>>> >> >> https://www.ietf.org/mail-archive/web/behave/current/ >> > >>>>>> msg03582.html >> > >>>>>>> > > >>>> msg03582.html> >> > >>>>>>> >> >> > >>>>>>> >> I think that the decision of permitting Anycast >> > should be left >> > >>>> to >> > >>>>>> each >> > >>>>>>> >> STUN Usage. Basic STUN Usage does not use >> > authentication and >> > >>>> use >> > >>>>>> only a >> > >>>>>>> >> one round trip for the Binding transaction, so >> > Unicast can be >> > >>>>>> used. >> > >>>>>>> >> >> > >>>>>>> > >> > >>>>>>> >> OTOH, TURN and ICE should probably say something >> > about that, >> > >> so >> > >>>> I >> > >>>>>> added a >> > >>>>>>> >> new bullet point in Section 13: >> > >>>>>>> >> >> > >>>>>>> >> o If Anycast addresses can be used for the server >> > in case >> > >>>> TCP >> > >>>>>> or >> > >>>>>>> >> TLS-over-TCP, or authentication are used. >> > >>>>>>> >> >> > >>>>>>> > >> > >>>>>>> > Are you leaving this text in? That seems very >> confusing. >> > >>>>>>> >> > >>>>>>> In isolation yes, but I think it makes sense which the >> text >> > >> before >> > >>>>>>> the bullet points: >> > >>>>>>> >> > >>>>>>> A STUN usage defines how STUN is actually utilized -- >> > when to >> > >>>> send >> > >>>>>>> requests, what to do with the responses, and which >> > optional >> > >>>>>>> procedures defined here (or in an extension to STUN) >> > are to be >> > >>>>>> used. >> > >>>>>>> A usage also defines: >> > >>>>>>> >> > >>>>>>> [...] >> > >>>>>>> >> > >>>>>>> o If Anycast addresses can be used for the server in >> > case TCP >> > >>>> or >> > >>>>>>> TLS-over-TCP, or authentication are used. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> What is the need for the restriction at all. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >>>> transaction over UDP or DTLS-over-UDP is also >> > >> considered >> > >>>>>> failed if >> > >>>>>>> >>>> there has been a hard ICMP error [RFC1122]. >> For >> > >> example, >> > >>>>>> assuming >> > >>>>>>> >> an >> > >>>>>>> >>>> RTO of 500ms, requests would be sent at times >> > 0 ms, 500 >> > >>>>>> ms, 1500 >> > >>>>>>> >> ms, >> > >>>>>>> >>>> 3500 ms, 7500 ms, 15500 ms, and 31500 ms. If >> the >> > >> client >> > >>>>>> has not >> > >>>>>>> >>>> received a response after 39500 ms, the client >> > will >> > >>>>>> consider the >> > >>>>>>> >>>> transaction to have timed out. >> > >>>>>>> >>> >> > >>>>>>> >>> I note that these recommendations now seem crazily >> > long. I >> > >>>>>> assume the >> > >>>>>>> >>> WG had consensus on this, but I wanted to note it. >> > >>>>>>> >> >> > >>>>>>> >> Not just the WG, also the IESG that approved RFC 5389 >> > too as, >> > >>>> but >> > >>>>>> for the >> > >>>>>>> >> addition of "or DTLS-over-UDP", this is the same text >> > than in >> > >>>> RFC >> > >>>>>> 5389. >> > >>>>>>> >> >> > >>>>>>> > >> > >>>>>>> > Yes, I know. My point is that while they might have >> bee >> > >> sensible >> > >>>>>> when >> > >>>>>>> > 5389 was published they *now* seem crazily long. Did >> > the WG >> > >>>>>> explicitly >> > >>>>>>> > decide not to update them? >> > >>>>>>> >> > >>>>>>> No, nobody ever suggested that there was an issue there. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> OK, well, this seems like it should be considered, then, >> > because this >> > >>>>>>> doesn't >> > >>>>>>> match modern practice. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> > This would be good to explain. >> > >>>>>>> >> > >>>>>>> New text: >> > >>>>>>> >> > >>>>>>> [...] >> > >>>>>>> containing the subjectAltName of that certificate. >> > The test >> > >> on >> > >>>>>> the >> > >>>>>>> MESSAGE-INTEGRITY-SHA256 attribute indicates that the >> > >>>> transaction >> > >>>>>> is >> > >>>>>>> authenticated and that the client implements this >> > >> specification >> > >>>>>> and >> > >>>>>>> so can process the ALTERNATE-DOMAIN attribute. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> All right. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> >>>> o What authentication and message-integrity >> > mechanisms >> > >>>>>> are used. >> > >>>>>>> >>>> >> > >>>>>>> >>>> o The considerations around manual vs. >> > automatic key >> > >>>>>> derivation >> > >>>>>>> >> for >> > >>>>>>> >>>> the integrity mechanism, as discussed in >> > [RFC4107]. >> > >>>>>>> >>>> >> > >>>>>>> >>>> o What mechanisms are used to distinguish >> STUN >> > >> messages >> > >>>>>> from other >> > >>>>>>> >>> >> > >>>>>>> >>> Why is this required? It seems like that's a generic >> > STUN >> > >>>>>> feature. >> > >>>>>>> >> >> > >>>>>>> >> That text is identical to the text in RFC 5389. RFC >> > 5764/7983 >> > >>>> is >> > >>>>>> one such >> > >>>>>>> >> mechanism, but there is nothing that prevent another >> > protocol >> > >>>>>> stack to use >> > >>>>>>> >> a different mechanism (inference, shim, etc...) >> > >>>>>>> >> >> > >>>>>>> > >> > >>>>>>> > But ultimately no matter what the other protocol >> > provides for >> > >>>>>> demux, STUN >> > >>>>>>> > has its >> > >>>>>>> > own demux. >> > >>>>>>> >> > >>>>>>> In fact I think that the reason for that item was >> because >> > >>>>>>> FINGERPRINT can also be used to demux STUN traffic, but >> > it is >> > >>>>>>> optional. So an STUN Usage needs to tell if >> FINGERPRINT is >> > >>>>>>> mandatory (like in ICE). >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> This should be explained. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >>> >> > >>>>>>> >>>> that is not readily subject to offline >> dictionary >> > >>>> attacks. >> > >>>>>>> >>>> Protection of the channel itself, using TLS or >> > DTLS, >> > >>>>>> mitigates >> > >>>>>>> >> these >> > >>>>>>> >>>> attacks. >> > >>>>>>> >>>> >> > >>>>>>> >>>> STUN supports both MESSAGE-INTEGRITY and >> > >>>>>>> MESSAGE-INTEGRITY-SHA256, >> > >>>>>>> >>>> which is subject to bid down attacks by an >> on-path >> > >>>>>> attacker. >> > >>>>>>> >>> >> > >>>>>>> >>> By an on-path attacker who can forge HMAC-SHA1 in >> > real-time? >> > >>>>>>> That's a >> > >>>>>>> >>> pretty serious adversary, so you should clarify here >> > >>>>>>> >>> >> > >>>>>>> >> >> > >>>>>>> >> New text: >> > >>>>>>> >> >> > >>>>>>> >> STUN supports both MESSAGE-INTEGRITY and >> > >>>>>> MESSAGE-INTEGRITY-SHA256, >> > >>>>>>> >> which is subject to bid down attacks by an on-path >> > attacker >> > >>>>>> that >> > >>>>>>> >> would strip the MESSAGE-INTEGRITY-SHA256 attribute >> > leaving >> > >>>>>>> only the >> > >>>>>>> >> MESSAGE-INTEGRITY attribute and exploiting a >> potential >> > >>>>>>> vulnerability. >> > >>>>>>> >> Protection of the channel itself, using TLS or >> DTLS, >> > >>>> mitigates >> > >>>>>>> these >> > >>>>>>> >> attacks. Timely removal of the support of >> > >> MESSAGE-INTEGRITY >> > >>>>>> in a >> > >>>>>>> >> future version of STUN is necessary. >> > >>>>>>> >> >> > >>>>>>> > >> > >>>>>>> > I still don't understand the capabilities you seem to >> > believe >> > >> the >> > >>>>>>> attacker >> > >>>>>>> > has. >> > >>>>>>> > Can you describe the exact attack. >> > >>>>>>> > >> > >>>>>>> >> > >>>>>>> 1. Vulnerability is found in HMAC-SHA1 >> > >>>>>>> 2. Client Alice still supports M-I and M-I-256, does not >> > know >> > >> what >> > >>>>>>> version of STUN server Bob supports and so send both. >> > >>>>>>> 3. On-path attacker removes M-I-256. >> > >>>>>>> 5. stunbis server Bob thinks that Alice is an RFC 5389 >> > client and >> > >>>>>>> continue with that protocol. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> This seems like an extremely weak attack. In general, any >> > protocol of >> > >>>>>>> this type is as strong >> > >>>>>>> as the weakest integrity algorithm it supports, so it's not >> > that the >> > >>>>>>> protocol has a downgrade >> > >>>>>>> attack, but rather that the minimum algorithm supported is >> > one you >> > >>>> don't >> > >>>>>>> trust as much >> > >>>>>>> as you might like. >> > >>>>>>> >> > >>>>>>> -Ekr >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> -- >> > >> >> > >> > >> > >> > -- >> > Marc Petit-Huguenin >> > Email: marc@petit-huguenin.org >> > Blog: https://marc.petit-huguenin.org >> > Profile: https://www.linkedin.com/in/petithug >> > >> > --0000000000006fb46c057b0addf9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Gonzalo,=C2=A0
On Mon, Nov 19, 2018 at 9:06 AM Eric Rescorla <ekr@rtfm.com> wrote:
Not really. I have not received any response= to my mail of Oct 23. As before, I'm happy to have a call, but I belie= ve we're reaching the limits of what can be accomplished by email.

Eric would know best (it being his = Discuss), but this is also my understanding.=C2=A0

I can add this to the agenda of the IESG informal telechat on November 29,= if there hasn't been a call before then, but I don't have a reason= to wait until then, if it's possible to talk sooner.

Thanks,

Spencer
=C2=A0

-Ekr
<= div>

On Mon,= Nov 19, 2018 at 6:35 AM Gonzalo Camarillo <gonzalo.camarillo@ericsson.com&= gt; wrote:
Hi Spencer,

what is the status of this? Are the authors and the document shepherd
working with the relevant ADs on the discusses?

https://datatracker.ietf.org/doc/= draft-ietf-tram-stun-pmtud/ballot/

Cheers,

Gonzalo

On 24-Oct-18 16:40, Spencer Dawkins at IETF wrote:
> Hi, Marc,=C2=A0
>
> On Wed, Oct 24, 2018 at 3:44 AM Marc Petit-Huguenin <petithug@acm.org
> <mailto:petit= hug@acm.org>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hi Spencer,
>
>=C2=A0 =C2=A0 =C2=A0I sent my answers to Eric Rescorla questions on 201= 8-10-07 following
>=C2=A0 =C2=A0 =C2=A0an in-person meeting with my co-author, but never g= ot a response
>=C2=A0 =C2=A0 =C2=A0back.=C2=A0 Because there was no change proposed by= Eric I went ahead and
>=C2=A0 =C2=A0 =C2=A0published -19 a couple of weeks after that, with th= e text agreed in
>=C2=A0 =C2=A0 =C2=A0response to Adam's and Benjamin's comments.=
>
>=C2=A0 =C2=A0 =C2=A0https://www.= ietf.org/mail-archive/web/tram/current/msg02635.html
>
>
> Ah - I wonder if that was what had happened.=C2=A0
>
> It sounds like you did the right thing, and that Eric has now responde= d,
> which is also the right thing to do.=C2=A0
>
> Thanks for helping me understand.
>
> Spencer
> =C2=A0
>
>=C2=A0 =C2=A0 =C2=A0On 10/23/18 7:28 PM, Spencer Dawkins at IETF wrote:=
>=C2=A0 =C2=A0 =C2=A0> Hi, Marc,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> I see that a -19 has been submitted, but didn&= #39;t see a reply from
>=C2=A0 =C2=A0 =C2=A0Eric in
>=C2=A0 =C2=A0 =C2=A0> this thread. Do you think that you've conv= erged?
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> (I saw an offer of a conference call, so thoug= ht an out-of-band
>=C2=A0 =C2=A0 =C2=A0> conversation might have happened)
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Thanks,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Spencer
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> On Sun, Oct 7, 2018 at 9:35 AM Marc Petit-Hugu= enin
>=C2=A0 =C2=A0 =C2=A0<petithug@acm.org <mailto:petithug@acm.org>> wrote:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>> Hi Eric,
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> Please see inline.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> On 09/10/2018 03:25 AM, Eric Rescorla wrot= e:
>=C2=A0 =C2=A0 =C2=A0>>> On Sat, Sep 8, 2018 at 2:31 PM, Marc P= etit-Huguenin
>=C2=A0 =C2=A0 =C2=A0<petithug@acm.org <mailto:petithug@acm.org>>
>=C2=A0 =C2=A0 =C2=A0>>> wrote:
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>> Hi Eric,
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> Apologies for the delay in getting= back to that.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> I think that there is some misunde= rstanding in what STUNbis is
>=C2=A0 =C2=A0 =C2=A0trying to
>=C2=A0 =C2=A0 =C2=A0>>>> do, so please see my comments inli= ne.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> On 06/18/2018 10:43 AM, Eric Resco= rla wrote:
>=C2=A0 =C2=A0 =C2=A0>>>>> Hi folks,
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> I've reviewed the new vers= ion, but I don't think that the biddown
>=C2=A0 =C2=A0 =C2=A0>>>>> discussion makes much sense. >=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> To recap, there are two hashes= here:
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> - The hash which you use to st= ore the password with (currently
>=C2=A0 =C2=A0 =C2=A0mostly
>=C2=A0 =C2=A0 =C2=A0>>>> MD5)
>=C2=A0 =C2=A0 =C2=A0>>>>> - The hash you use to compute = the MAC (currently SHA-1).
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> First, let's stipulate tha= t MD5 isn't a great choice here,
>=C2=A0 =C2=A0 =C2=A0though SHA-1
>=C2=A0 =C2=A0 =C2=A0>>>>> isn't a great choice
>=C2=A0 =C2=A0 =C2=A0>>>>> either for pwd hashing You wan= t Argon or the like. With that said,
>=C2=A0 =C2=A0 =C2=A0>>>> there's
>=C2=A0 =C2=A0 =C2=A0>>>>> no sensible
>=C2=A0 =C2=A0 =C2=A0>>>>> biddown attack on that hash be= cause it's a per-server feature,
>=C2=A0 =C2=A0 =C2=A0not a
>=C2=A0 =C2=A0 =C2=A0>>>>> per-transaction
>=C2=A0 =C2=A0 =C2=A0>>>>> feature. So, as long as the se= rver has MD5-hashed passwords, the
>=C2=A0 =C2=A0 =C2=A0>>>> situation
>=C2=A0 =C2=A0 =C2=A0>>>>> is bad.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> In no place in STUNbis we are prop= osing to use SHA-1 for password
>=C2=A0 =C2=A0 =C2=A0>>>> encryption, so I am not sure where= that come from.=C2=A0 What we
>=C2=A0 =C2=A0 =C2=A0propose is:
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>> You're right, it's SHA-256, bu= t my criticisms apply equally there.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> SHA-256 was what the WG adopted.=C2=A0 Our= attempts to add other passwords
>=C2=A0 =C2=A0 =C2=A0>> encryption mechanisms were denied.=C2=A0 I= t is true that Argon2 was
>=C2=A0 =C2=A0 =C2=A0not in that
>=C2=A0 =C2=A0 =C2=A0>> list (in our defense Argon2 was not known = before July 2015), but
>=C2=A0 =C2=A0 =C2=A0I do not
>=C2=A0 =C2=A0 =C2=A0>> see why the WG would have accepted that on= e over the others.=C2=A0
>=C2=A0 =C2=A0 =C2=A0Anyway it is
>=C2=A0 =C2=A0 =C2=A0>> too late to fix this, as it is my understa= nding that the WG does
>=C2=A0 =C2=A0 =C2=A0not have
>=C2=A0 =C2=A0 =C2=A0>> enough energy to reach consensus on a new = password algorithm.=C2=A0
>=C2=A0 =C2=A0 =C2=A0Someone can
>=C2=A0 =C2=A0 =C2=A0>> just write a draft adding Argon2 as passwo= rd encryption, as we
>=C2=A0 =C2=A0 =C2=A0will have a
>=C2=A0 =C2=A0 =C2=A0>> IANA registry for that.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>> - Establish a registry for new pas= sword algorithms (section
>=C2=A0 =C2=A0 =C2=A018.5), so
>=C2=A0 =C2=A0 =C2=A0>>>> algorithms like Argon2 could be ad= ded later (but note that our own
>=C2=A0 =C2=A0 =C2=A0>>>> proposals to add more password alg= orithms were rejected by the
>=C2=A0 =C2=A0 =C2=A0working
>=C2=A0 =C2=A0 =C2=A0>>>> group).
>=C2=A0 =C2=A0 =C2=A0>>>> - Add a new password algorithm to = that registry, namely SHA-256.
>=C2=A0 =C2=A0 =C2=A0>>>> - Register MD5 as an initial passw= ord algorithm for backward
>=C2=A0 =C2=A0 =C2=A0>> compatibility
>=C2=A0 =C2=A0 =C2=A0>>>> purpose.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> As for the biddown protection itse= lf, it is my recollection that it
>=C2=A0 =C2=A0 =C2=A0>>>> happened more or less like that: >=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> INT. MEETING ROOM - DAY
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> One of the co-editors of STUNBis s= tands at the microphone:
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CO-EDITOR >=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 We added SHA-256 protection for passwords
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 in STUNBis.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SOMEONE (V.O= .)
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 As MD5 still need to be supported, you need to = add
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 protection for bid-down attacks.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> CLOSE-UP on CO-EDITOR ROLLING HIS = EYES
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CO-EDITOR >=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 OK, I'll work on that.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> Four to eight months has passed. >=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> INT. ANOTHER MEETING ROOM - DAY >=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> The same co-editor of STUNBis stan= ds at the microphone:
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CO-EDITOR >=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 We added a nice mechanism to prevent bid-down >=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 attacks on passwords.=C2=A0 Any comments?
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 THE ROOM
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 (silence)
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CO-EDITOR >=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Moving on...
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>> I don't see how any of this is rel= evant to my technical points
>=C2=A0 =C2=A0 =C2=A0above.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> My point was that we, the co-editors, did = not decide on adding
>=C2=A0 =C2=A0 =C2=A0bid-down
>=C2=A0 =C2=A0 =C2=A0>> protection, someone asked us to do so and = no-one in the WG saw
>=C2=A0 =C2=A0 =C2=A0any problem
>=C2=A0 =C2=A0 =C2=A0>> with that.=C2=A0 The reasons that person w= anted that are not known to
>=C2=A0 =C2=A0 =C2=A0us but, as
>=C2=A0 =C2=A0 =C2=A0>> you insist, here's one reason I can th= ink of:
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> It is a fact that, for operational reasons= , a password database
>=C2=A0 =C2=A0 =C2=A0cannot be
>=C2=A0 =C2=A0 =C2=A0>> re-encrypted at once.=C2=A0 Also for opera= tional reasons, the MD5 password
>=C2=A0 =C2=A0 =C2=A0>> cannot be immediately removed from the dat= abase as soon the user
>=C2=A0 =C2=A0 =C2=A0submitted
>=C2=A0 =C2=A0 =C2=A0>> a new one.=C2=A0 In fact, and for quite so= me time, both encrypted
>=C2=A0 =C2=A0 =C2=A0variants of
>=C2=A0 =C2=A0 =C2=A0>> the same password may have to be kept in t= hat database, because a
>=C2=A0 =C2=A0 =C2=A0single
>=C2=A0 =C2=A0 =C2=A0>> user may use a mix of devices, some of the= m that use an RFC 5389
>=C2=A0 =C2=A0 =C2=A0client,
>=C2=A0 =C2=A0 =C2=A0>> some that use a STUNbis client.=C2=A0 It i= s up to the STUN server owner to
>=C2=A0 =C2=A0 =C2=A0>> decide how long the migration to STUNbis w= ill take and when it
>=C2=A0 =C2=A0 =C2=A0will be
>=C2=A0 =C2=A0 =C2=A0>> acceptable to reject all RFC 5389 (i.e. MD= 5) clients (that
>=C2=A0 =C2=A0 =C2=A0migration time
>=C2=A0 =C2=A0 =C2=A0>> can be purposely reduced to 0 seconds but = that's the choice and
>=C2=A0 =C2=A0 =C2=A0>> responsibility of the owner of the server)= .
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> Meanwhile we still need to be sure that if= the STUN client is
>=C2=A0 =C2=A0 =C2=A0implementing
>=C2=A0 =C2=A0 =C2=A0>> STUNbis it unconditionally gets the additi= onal protection of the new
>=C2=A0 =C2=A0 =C2=A0>> password encryption algorithm.=C2=A0 That&= #39;s where the biddown
>=C2=A0 =C2=A0 =C2=A0protection kicks
>=C2=A0 =C2=A0 =C2=A0>> in, by preventing an online attacker to ha= ve the server
>=C2=A0 =C2=A0 =C2=A0misidentifying a
>=C2=A0 =C2=A0 =C2=A0>> STUNbis client as an RFC 5389 client, by p= reventing an online
>=C2=A0 =C2=A0 =C2=A0attacker to
>=C2=A0 =C2=A0 =C2=A0>> have the client misidentifying a STUNbis s= erver as a RFC 5389
>=C2=A0 =C2=A0 =C2=A0server, and
>=C2=A0 =C2=A0 =C2=A0>> having both them use the MD5 encrypted pas= sword instead of the
>=C2=A0 =C2=A0 =C2=A0SHA-256
>=C2=A0 =C2=A0 =C2=A0>> encrypted password, all of that easily don= e by stripping the
>=C2=A0 =C2=A0 =C2=A0unprotected
>=C2=A0 =C2=A0 =C2=A0>> 401 response of the new STUNbis PASSWORD-A= LGORITHMS attribute.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> The second topic is the hash u= sed to compute the MAC. However,
>=C2=A0 =C2=A0 =C2=A0I don't
>=C2=A0 =C2=A0 =C2=A0>>>> see
>=C2=A0 =C2=A0 =C2=A0>>>>> how
>=C2=A0 =C2=A0 =C2=A0>>>>> this gives you sensible biddow= n protection because that hash
>=C2=A0 =C2=A0 =C2=A0is also
>=C2=A0 =C2=A0 =C2=A0>> used
>=C2=A0 =C2=A0 =C2=A0>>>>> to compute
>=C2=A0 =C2=A0 =C2=A0>>>>> MAC over the negotiation: an a= ttacker who has compromised a
>=C2=A0 =C2=A0 =C2=A0MAC which
>=C2=A0 =C2=A0 =C2=A0>> the
>=C2=A0 =C2=A0 =C2=A0>>>>> server
>=C2=A0 =C2=A0 =C2=A0>>>>> supports will quite likely be = able to forge a MAC over the
>=C2=A0 =C2=A0 =C2=A0transcript
>=C2=A0 =C2=A0 =C2=A0>> as
>=C2=A0 =C2=A0 =C2=A0>>>>> well. This is,
>=C2=A0 =C2=A0 =C2=A0>>>>> I suppose, potentially useful = as a defense against some other
>=C2=A0 =C2=A0 =C2=A0weakness
>=C2=A0 =C2=A0 =C2=A0>>>>> (e.g.,
>=C2=A0 =C2=A0 =C2=A0>>>>> version #), but I don't re= ally see how the current design
>=C2=A0 =C2=A0 =C2=A0helps against
>=C2=A0 =C2=A0 =C2=A0>>>>> attacks on the
>=C2=A0 =C2=A0 =C2=A0>>>>> MAC.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> There is no biddown attack protect= ion for the MAC, as stated in
>=C2=A0 =C2=A0 =C2=A0Section
>=C2=A0 =C2=A0 =C2=A0>>>> 16.3:
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> "The bid-down protection mech= anism described in this document
>=C2=A0 =C2=A0 =C2=A0is new,
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 and thus cannot currently pr= otect against a bid-down attack that
>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 lowers the strength of the h= ash algorithm to HMAC-SHA1."
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>> What we put in place is a plan for= *future* versions of STUN to get
>=C2=A0 =C2=A0 =C2=A0>>>> biddown protection for the MAC.=C2= =A0 That's it, no more, no less.
>=C2=A0 =C2=A0 =C2=A0>>>>
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>> Yes, but I don't believe that this= will provide bid-down
>=C2=A0 =C2=A0 =C2=A0protection for
>=C2=A0 =C2=A0 =C2=A0>> the
>=C2=A0 =C2=A0 =C2=A0>>> MAC in the future for the reasons I in= dicate above.
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>> If you think this does something usefu= l, please show me an
>=C2=A0 =C2=A0 =C2=A0example attack
>=C2=A0 =C2=A0 =C2=A0>>> and how this fixes it. Note that it= 9;s not generally useful to
>=C2=A0 =C2=A0 =C2=A0just bid
>=C2=A0 =C2=A0 =C2=A0>> down
>=C2=A0 =C2=A0 =C2=A0>>> the MAC itself unless the MAC you bid = down to is weak enough to
>=C2=A0 =C2=A0 =C2=A0exploit
>=C2=A0 =C2=A0 =C2=A0>> in
>=C2=A0 =C2=A0 =C2=A0>>> some other way.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> I do not know what weaknesses will be disc= overed in the future.=C2=A0
>=C2=A0 =C2=A0 =C2=A0I am also
>=C2=A0 =C2=A0 =C2=A0>> pretty sure that the cost of not using tha= t mechanism is very
>=C2=A0 =C2=A0 =C2=A0close to 0.
>=C2=A0 =C2=A0 =C2=A0>> What I am sure of is that the cost of reen= gineering a new biddown
>=C2=A0 =C2=A0 =C2=A0>> protection mechanism if we ever need it wi= ll be high.=C2=A0 We already
>=C2=A0 =C2=A0 =C2=A0went
>=C2=A0 =C2=A0 =C2=A0>> through the pains of designing one for the= password algorithm, so
>=C2=A0 =C2=A0 =C2=A0why not
>=C2=A0 =C2=A0 =C2=A0>> extend it so it can be used in the afterma= th of the next Snowden
>=C2=A0 =C2=A0 =C2=A0facepalm
>=C2=A0 =C2=A0 =C2=A0>> moment?
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>> Again, happy to have a call to walk th= ough this if that
>=C2=A0 =C2=A0 =C2=A0>>> helps.
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>> -Ekr
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> You might think that there was= a MAC which was easier to
>=C2=A0 =C2=A0 =C2=A0reverse to
>=C2=A0 =C2=A0 =C2=A0>> find
>=C2=A0 =C2=A0 =C2=A0>>>>> the original
>=C2=A0 =C2=A0 =C2=A0>>>>> password, but the defense you = have here doesn't help with that
>=C2=A0 =C2=A0 =C2=A0because
>=C2=A0 =C2=A0 =C2=A0>>>> the
>=C2=A0 =C2=A0 =C2=A0>>>>> on-path attacker can do a bid-= down and use the client as a MAC
>=C2=A0 =C2=A0 =C2=A0oracle
>=C2=A0 =C2=A0 =C2=A0>> for
>=C2=A0 =C2=A0 =C2=A0>>>>> any MAC the client supports. >=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> So, I still don't understa= nd what this is supposed to do. Happy to
>=C2=A0 =C2=A0 =C2=A0>> have a
>=C2=A0 =C2=A0 =C2=A0>>>>> call if you
>=C2=A0 =C2=A0 =C2=A0>>>>> think that helps
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> -Ekr
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>> On Mon, Jun 18, 2018 at 3:40 A= M, Gonzalo Camarillo <
>=C2=A0 =C2=A0 =C2=A0>>>>> Gonzalo.Camarillo@ericsson.com >=C2=A0 =C2=A0 =C2=A0<mailto:Gonzalo.Camarillo@ericsson.com>> wrot= e:
>=C2=A0 =C2=A0 =C2=A0>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> Marc, Eric,
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> what is the status of this= discussion?
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> Thanks,
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> Gonzalo
>=C2=A0 =C2=A0 =C2=A0>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>> On 04/05/2018 2:35 AM, Eri= c Rescorla wrote:
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> On Mon, Apr 23, 2018 a= t 11:16 AM, Marc Petit-Huguenin <
>=C2=A0 =C2=A0 =C2=A0>>>> petithug@acm.org <mailto:petithug@acm.org>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> <mailto:petithug@acm.org <mailto:= petithug@acm.org&= gt;>> wrote:
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0On = 04/22/2018 05:22 PM, Eric Rescorla wrote:
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ; On Sun, Apr 22, 2018 at 2:02 PM, Marc Petit-Huguenin <
>=C2=A0 =C2=A0 =C2=A0>>>>>> petithug@acm.org <mailto:petithug@acm.org>
>=C2=A0 =C2=A0 =C2=A0<mailto:petithug@acm.org <mailto:petithug@acm.org>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ; wrote:
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 For a request or indication message, the = agent
>=C2=A0 =C2=A0 =C2=A0MUST
>=C2=A0 =C2=A0 =C2=A0>>>>>> include the
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 USERNAME, MESSAGE-INTEGRITY-SHA256, and >=C2=A0 =C2=A0 =C2=A0>> MESSAGE-INTEGRITY
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> attributes
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 in the message unless the agent knows fro= m an
>=C2=A0 =C2=A0 =C2=A0external
>=C2=A0 =C2=A0 =C2=A0>>>>>> indication
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 which message integrity algorithm is supp= orted
>=C2=A0 =C2=A0 =C2=A0by both
>=C2=A0 =C2=A0 =C2=A0>>>>>> agents.=C2=A0 In
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 this case either MESSAGE-INTEGRITY or
>=C2=A0 =C2=A0 =C2=A0>>>>>> MESSAGE-INTEGRITY-SHA256 M= UST
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 be included in addition to USERNAME.=C2= =A0 The HMAC
>=C2=A0 =C2=A0 =C2=A0for the
>=C2=A0 =C2=A0 =C2=A0>>>>>> MESSAGE-
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>> This text appears to conflict with S 7.3 of
>=C2=A0 =C2=A0 =C2=A05245-bis, which
>=C2=A0 =C2=A0 =C2=A0>>>> says:
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> [text missing]
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> Hmm, no, RFC245bis is still referencing RFC5389, so the
>=C2=A0 =C2=A0 =C2=A0>>>> procedure
>=C2=A0 =C2=A0 =C2=A0>>>>>> for
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> stunbis does not apply.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ; I hear what you're saying, but publishing two
>=C2=A0 =C2=A0 =C2=A0documents at the
>=C2=A0 =C2=A0 =C2=A0>>>>>> same time
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ; which
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ; make contrary recommendations about the same basic
>=C2=A0 =C2=A0 =C2=A0protocol is
>=C2=A0 =C2=A0 =C2=A0>>>>>> un-good.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0Sur= e, but wouldn't it be simpler to have rfc5245bis
>=C2=A0 =C2=A0 =C2=A0using stunbis
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0and= have them updating their text, more than adding some
>=C2=A0 =C2=A0 =C2=A0tortuous
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0tex= t in stunbis?
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>=C2=A0 =C2=A0 =C2=A0 The STUN usage must specify which transport >=C2=A0 =C2=A0 =C2=A0protocol is
>=C2=A0 =C2=A0 =C2=A0>>>>>> used, and
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> how
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 the agent determines the IP address and p= ort
>=C2=A0 =C2=A0 =C2=A0of the
>=C2=A0 =C2=A0 =C2=A0>>>>>> recipient.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 Section 8 describes a DNS-based method of=
>=C2=A0 =C2=A0 =C2=A0determining
>=C2=A0 =C2=A0 =C2=A0>> the
>=C2=A0 =C2=A0 =C2=A0>>>>>> IP
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> address
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 and port of a server that a usage may ele= ct to
>=C2=A0 =C2=A0 =C2=A0use.
>=C2=A0 =C2=A0 =C2=A0>> STUN
>=C2=A0 =C2=A0 =C2=A0>>>>>> may be
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> used
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 with anycast addresses, but only with UDP= and
>=C2=A0 =C2=A0 =C2=A0in usages
>=C2=A0 =C2=A0 =C2=A0>>>>>> where
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 authentication is not used.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>> Why this restriction? You should be able to use
>=C2=A0 =C2=A0 =C2=A0anycast with
>=C2=A0 =C2=A0 =C2=A0>>>>>> long-term
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>> AUTH for (say) TURN.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> https://www.ietf.org/mail-archive/web/beh= ave/current/
>=C2=A0 =C2=A0 =C2=A0>>>>>> msg03582.html
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0<= ;https://www.ietf.org/mail-archive/web/behave/c= urrent/
>=C2=A0 =C2=A0 =C2=A0>>>> msg03582.html>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> I think that the decision of permitting Anycast
>=C2=A0 =C2=A0 =C2=A0should be left
>=C2=A0 =C2=A0 =C2=A0>>>> to
>=C2=A0 =C2=A0 =C2=A0>>>>>> each
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> STUN Usage.=C2=A0 Basic STUN Usage does not use
>=C2=A0 =C2=A0 =C2=A0authentication and
>=C2=A0 =C2=A0 =C2=A0>>>> use
>=C2=A0 =C2=A0 =C2=A0>>>>>> only a
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> one round trip for the Binding transaction, so
>=C2=A0 =C2=A0 =C2=A0Unicast can be
>=C2=A0 =C2=A0 =C2=A0>>>>>> used.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> OTOH, TURN and ICE should probably say something
>=C2=A0 =C2=A0 =C2=A0about that,
>=C2=A0 =C2=A0 =C2=A0>> so
>=C2=A0 =C2=A0 =C2=A0>>>> I
>=C2=A0 =C2=A0 =C2=A0>>>>>> added a
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> new bullet point in Section 13:
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>=C2=A0 =C2=A0 o=C2=A0 If Anycast addresses can be used for the server<= br> >=C2=A0 =C2=A0 =C2=A0in case
>=C2=A0 =C2=A0 =C2=A0>>>> TCP
>=C2=A0 =C2=A0 =C2=A0>>>>>> or
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>=C2=A0 =C2=A0 =C2=A0 =C2=A0TLS-over-TCP, or authentication are used. >=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ; Are you leaving this text in? That seems very confusing.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0In = isolation yes, but I think it makes sense which the text
>=C2=A0 =C2=A0 =C2=A0>> before
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0the= bullet points:
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 A STUN usage defines how STUN is actually utilized --
>=C2=A0 =C2=A0 =C2=A0when to
>=C2=A0 =C2=A0 =C2=A0>>>> send
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 requests, what to do with the responses, and which
>=C2=A0 =C2=A0 =C2=A0optional
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 procedures defined here (or in an extension to STUN)
>=C2=A0 =C2=A0 =C2=A0are to be
>=C2=A0 =C2=A0 =C2=A0>>>>>> used.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 A usage also defines:
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0[..= .]
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 o=C2=A0 If Anycast addresses can be used for the server in
>=C2=A0 =C2=A0 =C2=A0case TCP
>=C2=A0 =C2=A0 =C2=A0>>>> or
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0TLS-over-TCP, or authentication are used.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> What is the need for t= he restriction at all.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 transaction over UDP or DTLS-over-UDP is = also
>=C2=A0 =C2=A0 =C2=A0>> considered
>=C2=A0 =C2=A0 =C2=A0>>>>>> failed if
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 there has been a hard ICMP error [RFC1122= ].=C2=A0 For
>=C2=A0 =C2=A0 =C2=A0>> example,
>=C2=A0 =C2=A0 =C2=A0>>>>>> assuming
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> an
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 RTO of 500ms, requests would be sent at t= imes
>=C2=A0 =C2=A0 =C2=A00 ms, 500
>=C2=A0 =C2=A0 =C2=A0>>>>>> ms, 1500
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> ms,
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 3500 ms, 7500 ms, 15500 ms, and 31500 ms.= =C2=A0 If the
>=C2=A0 =C2=A0 =C2=A0>> client
>=C2=A0 =C2=A0 =C2=A0>>>>>> has not
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 received a response after 39500 ms, the c= lient
>=C2=A0 =C2=A0 =C2=A0will
>=C2=A0 =C2=A0 =C2=A0>>>>>> consider the
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 transaction to have timed out.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>> I note that these recommendations now seem crazily
>=C2=A0 =C2=A0 =C2=A0long. I
>=C2=A0 =C2=A0 =C2=A0>>>>>> assume the
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>> WG had consensus on this, but I wanted to note it.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> Not just the WG, also the IESG that approved RFC 5389
>=C2=A0 =C2=A0 =C2=A0too as,
>=C2=A0 =C2=A0 =C2=A0>>>> but
>=C2=A0 =C2=A0 =C2=A0>>>>>> for the
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> addition of "or DTLS-over-UDP", this is the same text
>=C2=A0 =C2=A0 =C2=A0than in
>=C2=A0 =C2=A0 =C2=A0>>>> RFC
>=C2=A0 =C2=A0 =C2=A0>>>>>> 5389.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ; Yes, I know. My point is that while they might have bee
>=C2=A0 =C2=A0 =C2=A0>> sensible
>=C2=A0 =C2=A0 =C2=A0>>>>>> when
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ; 5389 was published they *now* seem crazily long. Did
>=C2=A0 =C2=A0 =C2=A0the WG
>=C2=A0 =C2=A0 =C2=A0>>>>>> explicitly
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ; decide not to update them?
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0No,= nobody ever suggested that there was an issue there.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> OK, well, this seems l= ike it should be considered, then,
>=C2=A0 =C2=A0 =C2=A0because this
>=C2=A0 =C2=A0 =C2=A0>>>>>>> doesn't
>=C2=A0 =C2=A0 =C2=A0>>>>>>> match modern practice.=
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ; This would be good to explain.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0New= text:
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 [...]
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 containing the subjectAltName of that certificate.=C2=A0
>=C2=A0 =C2=A0 =C2=A0The test
>=C2=A0 =C2=A0 =C2=A0>> on
>=C2=A0 =C2=A0 =C2=A0>>>>>> the
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 MESSAGE-INTEGRITY-SHA256 attribute indicates that the
>=C2=A0 =C2=A0 =C2=A0>>>> transaction
>=C2=A0 =C2=A0 =C2=A0>>>>>> is
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 authenticated and that the client implements this
>=C2=A0 =C2=A0 =C2=A0>> specification
>=C2=A0 =C2=A0 =C2=A0>>>>>> and
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 so can process the ALTERNATE-DOMAIN attribute.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> All right.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 o=C2=A0 What authentication and message-i= ntegrity
>=C2=A0 =C2=A0 =C2=A0mechanisms
>=C2=A0 =C2=A0 =C2=A0>>>>>> are used.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 o=C2=A0 The considerations around manual = vs.
>=C2=A0 =C2=A0 =C2=A0automatic key
>=C2=A0 =C2=A0 =C2=A0>>>>>> derivation
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> for
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the integrity mechanism, as = discussed in
>=C2=A0 =C2=A0 =C2=A0[RFC4107].
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 o=C2=A0 What mechanisms are used to disti= nguish STUN
>=C2=A0 =C2=A0 =C2=A0>> messages
>=C2=A0 =C2=A0 =C2=A0>>>>>> from other
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>> Why is this required? It seems like that's a generic
>=C2=A0 =C2=A0 =C2=A0STUN
>=C2=A0 =C2=A0 =C2=A0>>>>>> feature.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> That text is identical to the text in RFC 5389.=C2=A0 RFC
>=C2=A0 =C2=A0 =C2=A05764/7983
>=C2=A0 =C2=A0 =C2=A0>>>> is
>=C2=A0 =C2=A0 =C2=A0>>>>>> one such
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> mechanism, but there is nothing that prevent another
>=C2=A0 =C2=A0 =C2=A0protocol
>=C2=A0 =C2=A0 =C2=A0>>>>>> stack to use
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> a different mechanism (inference, shim, etc...)
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ; But ultimately no matter what the other protocol
>=C2=A0 =C2=A0 =C2=A0provides for
>=C2=A0 =C2=A0 =C2=A0>>>>>> demux, STUN
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ; has its
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ; own demux.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0In = fact I think that the reason for that item was because
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0FIN= GERPRINT can also be used to demux STUN traffic, but
>=C2=A0 =C2=A0 =C2=A0it is
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0opt= ional.=C2=A0 So an STUN Usage needs to tell if FINGERPRINT is
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0man= datory (like in ICE).
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> This should be explain= ed.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 that is not readily subject to offline di= ctionary
>=C2=A0 =C2=A0 =C2=A0>>>> attacks.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 Protection of the channel itself, using T= LS or
>=C2=A0 =C2=A0 =C2=A0DTLS,
>=C2=A0 =C2=A0 =C2=A0>>>>>> mitigates
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> these
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 attacks.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 STUN supports both MESSAGE-INTEGRITY and<= br> >=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0MES= SAGE-INTEGRITY-SHA256,
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>>=C2=A0 =C2=A0 =C2=A0 which is subject to bid down attacks by a= n on-path
>=C2=A0 =C2=A0 =C2=A0>>>>>> attacker.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>> By an on-path attacker who can forge HMAC-SHA1 in
>=C2=A0 =C2=A0 =C2=A0real-time?
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0Tha= t's a
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>> pretty serious adversary, so you should clarify here
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;> New text:
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>=C2=A0 =C2=A0 STUN supports both MESSAGE-INTEGRITY and
>=C2=A0 =C2=A0 =C2=A0>>>>>> MESSAGE-INTEGRITY-SHA256,<= br> >=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>=C2=A0 =C2=A0 which is subject to bid down attacks by an on-path
>=C2=A0 =C2=A0 =C2=A0attacker
>=C2=A0 =C2=A0 =C2=A0>>>>>> that
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>=C2=A0 =C2=A0 would strip the MESSAGE-INTEGRITY-SHA256 attribute
>=C2=A0 =C2=A0 =C2=A0leaving
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0onl= y the
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>=C2=A0 =C2=A0 MESSAGE-INTEGRITY attribute and exploiting a potential >=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0vul= nerability.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>=C2=A0 =C2=A0 Protection of the channel itself, using TLS or DTLS,
>=C2=A0 =C2=A0 =C2=A0>>>> mitigates
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0the= se
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>=C2=A0 =C2=A0 attacks.=C2=A0 Timely removal of the support of
>=C2=A0 =C2=A0 =C2=A0>> MESSAGE-INTEGRITY
>=C2=A0 =C2=A0 =C2=A0>>>>>> in a
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>=C2=A0 =C2=A0 future version of STUN is necessary.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ; I still don't understand the capabilities you seem to
>=C2=A0 =C2=A0 =C2=A0believe
>=C2=A0 =C2=A0 =C2=A0>> the
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0att= acker
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ; has.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ; Can you describe the exact attack.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0>= ;
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A01. = Vulnerability is found in HMAC-SHA1
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A02. = Client Alice still supports M-I and M-I-256, does not
>=C2=A0 =C2=A0 =C2=A0know
>=C2=A0 =C2=A0 =C2=A0>> what
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0ver= sion of STUN server Bob supports and so send both.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A03. = On-path attacker removes M-I-256.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A05. = stunbis server Bob thinks that Alice is an RFC 5389
>=C2=A0 =C2=A0 =C2=A0client and
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0con= tinue with that protocol.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> This seems like an ext= remely weak attack. In general, any
>=C2=A0 =C2=A0 =C2=A0protocol of
>=C2=A0 =C2=A0 =C2=A0>>>>>>> this type is as strong=
>=C2=A0 =C2=A0 =C2=A0>>>>>>> as the weakest integri= ty algorithm it supports, so it's not
>=C2=A0 =C2=A0 =C2=A0that the
>=C2=A0 =C2=A0 =C2=A0>>>>>>> protocol has a downgra= de
>=C2=A0 =C2=A0 =C2=A0>>>>>>> attack, but rather tha= t the minimum algorithm supported is
>=C2=A0 =C2=A0 =C2=A0one you
>=C2=A0 =C2=A0 =C2=A0>>>> don't
>=C2=A0 =C2=A0 =C2=A0>>>>>>> trust as much
>=C2=A0 =C2=A0 =C2=A0>>>>>>> as you might like.
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>> -Ekr
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>
>=C2=A0 =C2=A0 =C2=A0>>>>>>>=C2=A0 =C2=A0 =C2=A0--<= br> >=C2=A0 =C2=A0 =C2=A0>>
>
>
>
>=C2=A0 =C2=A0 =C2=A0--
>=C2=A0 =C2=A0 =C2=A0Marc Petit-Huguenin
>=C2=A0 =C2=A0 =C2=A0Email: marc@petit-huguenin.org <mailto:marc@petit-huguenin.org> >=C2=A0 =C2=A0 =C2=A0Blog: https://marc.petit-huguenin.org
>=C2=A0 =C2=A0 =C2=A0Profile: https://www.linkedin.com/in/pet= ithug
>
--0000000000006fb46c057b0addf9-- From nobody Thu Nov 22 04:31:05 2018 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D7912DD85 for ; Thu, 22 Nov 2018 04:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.76 X-Spam-Level: X-Spam-Status: No, score=-5.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=OrQNJvZa; dkim=pass (1024-bit key) header.d=ericsson.com header.b=Yy+a2lRm Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMsyEYO5cGal for ; Thu, 22 Nov 2018 04:30:59 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 DB2BE129AB8 for ; Thu, 22 Nov 2018 04:30:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1542889856; x=1545481856; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=LfVuLdtVObYgyxLxinVhjyoWflI15FSf6ShaZKr1wBk=; b=OrQNJvZa1a+QA1NS1r8xsRtTu7j6VulOmtCfGA1zzowppnS7lHbh9rOxUdnxc3xi 4tz4w0u9q+/nT8x6jG9fJYhLavoYsLLSl2IbpPsZVhFJq/Ik5g6h5sbjVlea4mwe o064/LqTHH3lpAKwFADSv0BDowAy1sHj+K1rsPfwFZo=; X-AuditID: c1b4fb3a-45fff70000002747-aa-5bf6a180b828 Received: from ESESSMB505.ericsson.se (Unknown_Domain [153.88.183.123]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 9F.27.10055.081A6FB5; Thu, 22 Nov 2018 13:30:56 +0100 (CET) Received: from ESESSMR502.ericsson.se (153.88.183.110) by ESESSMB505.ericsson.se (153.88.183.193) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 22 Nov 2018 13:30:56 +0100 Received: from ESESSMB504.ericsson.se (153.88.183.165) by ESESSMR502.ericsson.se (153.88.183.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 22 Nov 2018 13:30:55 +0100 Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB504.ericsson.se (153.88.183.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 22 Nov 2018 13:30:55 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LfVuLdtVObYgyxLxinVhjyoWflI15FSf6ShaZKr1wBk=; b=Yy+a2lRm6jteknwR8lP3HPkKXtRB5t11HEPgVNk84TXJWgLXEVFl3o/1OqzeJJTk/WJB1L6rJcUP037COzj+Ppwa8/qMzox3p3BHjRBeRAljX5fnRK0XwrHeW08zbzbSapVCPmlKbcxMS3NBCymrqwgfBtGt086gezXS5bZtr1o= Received: from DB7PR07MB4934.eurprd07.prod.outlook.com (20.177.192.211) by DB7PR07MB3929.eurprd07.prod.outlook.com (52.134.100.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1382.7; Thu, 22 Nov 2018 12:30:53 +0000 Received: from DB7PR07MB4934.eurprd07.prod.outlook.com ([fe80::b1b5:857b:a4fb:d45d]) by DB7PR07MB4934.eurprd07.prod.outlook.com ([fe80::b1b5:857b:a4fb:d45d%3]) with mapi id 15.20.1361.015; Thu, 22 Nov 2018 12:30:53 +0000 From: Gonzalo Camarillo To: Spencer Dawkins at IETF , Eric Rescorla CC: Marc Petit-Huguenin , "tram-chairs@ietf.org" , "tram@ietf.org" , "Asveren, Tolga" , IESG , "draft-ietf-tram-stunbis@ietf.org" Thread-Topic: [tram] Eric Rescorla's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT) Thread-Index: AQHUgBUYh3SWjavZEkyxlhSdCV9H96VXMpYAgABkJoCABCeCgA== Date: Thu, 22 Nov 2018 12:30:53 +0000 Message-ID: <97c561a7-c33a-6121-00c4-09cd11646b98@ericsson.com> References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> <02569943-db8f-654e-7322-49bc1f1a1163@acm.org> <235b838f-2800-2cd0-8b01-947e70837619@ericsson.com> <472563ee-5fc3-655d-8e31-138cc774e608@acm.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [89.166.49.243] user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 x-clientproxiedby: HE1PR06CA0144.eurprd06.prod.outlook.com (2603:10a6:7:16::31) To DB7PR07MB4934.eurprd07.prod.outlook.com (2603:10a6:10:5b::19) authentication-results: spf=none (sender IP is ) smtp.mailfrom=gonzalo.camarillo@ericsson.com; x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB7PR07MB3929; 6:uP1gBf4HGSC2NVD9PwWB2VrDB8D7C7N+m57JYbGJF89AaH5ESjzbbhPwL1C/dsEdsQO3iy/Vh+c9g+cqeCs7ivuQjWBkeTLIT/fvfrTfULg0fOmzsDYndzrs0vIz143LlUMb8sioI6dj+JQvtUv18//1BCP/c/VqqhA3Z40QThithpKBiLIrP2cE6di5Gk8lc7XIt7bV5sxugROg8ZxvNUfEahKP2F0DLquZUiMz+06+QMlqpW1TSNhkaDMSHuZ3bVcNHmJnmHb3GytDXkE4lFcYRDopUCaA2uj9s9W3FjTqS/itrgsmpnc/U5NIfGfD63Vrj+y31bq5kDmaWEb1q4mUNCWI48wBWMsAFh5Z5IAd92m1ANzozmJQFTo83J4TxcFWlLRvS/ooRIH3bFgFTcAQtq494DKqsSvDDC7an53TqItm9ggmkkvjBwx7IkeLlVbEMte0jaDBN/ZHopOvaQ==; 5:Bc9qgfzyMkULj9woZby1vCnITUQnOIDXs8n2XLBocwqyuCp7DoZ+u6NtCA/Pag4sEFkYnRcjY6McHU4DXl1EHMSBf6Ym45RCKYWNedhnq+oo3ADEjn/sx5Xy7k7sBfPf9ExZHF8TI8lSzOGzVpggrCoA5qD/7OVIVoTACrKav6s=; 7:EunIdeWFkxvit5mPgyvK5dVHmVp4Ym7VOmd0ScRggMJ2/UuyYiUq1FN9U8tFUL8zyaRmoCmeH5NMhRafbLxW0CrbUavXqyO8DYXbvzhIYUk2L4knrQ8NoqQe7sh47ylSLFCbZyH5DnsL/PJcqDITkw== x-ms-office365-filtering-correlation-id: 96005516-6068-4860-391a-08d65076581c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:DB7PR07MB3929; x-ms-traffictypediagnostic: DB7PR07MB3929: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231442)(944501410)(52105112)(3002001)(10201501046)(148016)(149066)(150057)(6041310)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:DB7PR07MB3929; BCL:0; PCL:0; RULEID:; SRVR:DB7PR07MB3929; x-forefront-prvs: 0864A36BBF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(136003)(366004)(39860400002)(396003)(51444003)(51914003)(199004)(189003)(54094003)(252514010)(110136005)(39060400002)(54906003)(58126008)(4326008)(53946003)(6246003)(2906002)(11346002)(36756003)(486006)(446003)(2616005)(478600001)(476003)(71190400001)(71200400001)(4744004)(25786009)(6512007)(3260700006)(86362001)(93886005)(14444005)(31696002)(256004)(6306002)(551544002)(316002)(966005)(6486002)(105586002)(229853002)(66066001)(65956001)(64126003)(65806001)(68736007)(106356001)(76176011)(8936002)(2900100001)(81156014)(6436002)(81166006)(6116002)(5660300001)(52116002)(7736002)(3846002)(305945005)(65826007)(551934003)(386003)(6506007)(8676002)(53936002)(53546011)(26005)(99286004)(31686004)(97736004)(186003)(45080400002)(14454004)(102836004)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB3929; H:DB7PR07MB4934.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: yrEPoB2zkgNXQCW57QBkQyj5AcVvpjzpE51m+YQWKfoS8XYqyBEQDfQbFpW3g+VY+WeKvxivi0MxJBzn7JD4hRLRZMVh4UhAiAZfJ3KdIrqRFCamwYgZ8aKBfigT529jfgTXVLbVyvFK3UJnmRwe/q+lDvLCIdlEDQW5YRGmUmiAQQLu+pnIlaN9x88KXSNAtcXW80hZatC3OcP9lUZVGonmEpvKayG9GLFprn7N/WtEU+1MX28kqwHG7XHAj7jj7KESWuc8WLNej7pRoEY0a/2oljUbVwyPE8bRGfDCMYNAeFjQo8kPo9tmmFHqV6HFToLGeQ/CuHKCxe57sx/ztFor3ZIpg13mGAQkSJTKJ+o= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 96005516-6068-4860-391a-08d65076581c X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2018 12:30:53.7143 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB3929 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0yNcRjH+7330tl+HR09C5sO/qilm8Y7s5I/OCuNkCips7xdJpXzVq6z ymWRFEKduWVRqSTSTaHYqDk6nKa57uSU3KIZp3UZztubzX+f5/l+n+f5Pc9+HKm8R7tySSnp gi5Fm6xmHKiSjY17F2SVWqN8Ot8o+SP1Joav+PKU5YsnTpC8sfotwV8taiX52nIry5ePVjL8 cI2RWcZpTD0hmmb9W1ZTVjZKaFrPnUSaU5bD5Bo60mHpViE5KVPQeQfEOiRas61s2t1j5K7z w2NUFqrIIY8iew6wP1hu1FBHkQOnxA8RnD18m5IEJbYi6Pk+RxZsXPDBTMhBGQHPCs2s5KJw IQk3B9bIwikCfjR3k3LwHsHo5VZbL45jMA+5VYukAmccBQOWr7TkIfEBAhq67zOSMB0nwOvP vbTkd8aJYBoPlv3LobjuMSkPmw8VR6y0xAocCHce1LDyrEEWCvJfIkmwx2HwpCV/0oTwDBjp qiYkJrELvOq/SMhLYyhr7Z46gAo+WX7TMruB4VvfpEeFo2Egp29yZcBFCCrH6hi5qRbMh2qm ij3B0NuPZJ4Nzy/mIbngBQNdr25NmUIh92sjJbMRQe+4l8weMGG4wBQif/1/D9TbDkBid6ht 8ZbTGrjSU0rI7AZFeX2sfvIATtBZ0k9dQvQ1pBIFUdye4OfnJeiS4kQxNcUrRUi/iWzfqr1+ fEkTah8M6kCYQ2pHxZZca5SS1maKu7d3IOBItbPCFGRLKbZqd+8RdKkxuoxkQexAMzlK7aJY Hs9HKnGCNl3YJghpgu6fSnD2rlkozLfIO7yvytxWd3pF9KzRh0smAlbe+n3gJ55L9Kw+zT2P ic1inYNHtnjupzZf6o5zzDj/kWo7rh1yH+h1+/Un0n/eo7WL60MM0RnxEbRm/TSTqkmcXxI+ tMku273Ozmlf4Lvr5Jl1qq7bwRscjWmhPjv6V0UYVHNe7GyYcdDpbuefhWpKTNT6epA6UfsX 7syKiVIDAAA= Archived-At: Subject: Re: [tram] Eric Rescorla's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 22 Nov 2018 12:31:04 -0000 RXJpYywgU3BlbmNlciwgdGhhbmtzIGZvciB0aGUgc3RhdHVzIHVwZGF0ZSENCg0KQXV0aG9ycywg Y291bGQgeW91IHBsZWFzZSBsZXQgdXMga25vdyB3aGVuIHlvdSBwbGFuIHRvIGdldCB0byB0aGlz Pw0KDQpHb256YWxvDQoNCk9uIDE5LU5vdi0xOCAyMzowNCwgU3BlbmNlciBEYXdraW5zIGF0IElF VEYgd3JvdGU6DQo+IEhpLCBHb256YWxvLMKgDQo+IE9uIE1vbiwgTm92IDE5LCAyMDE4IGF0IDk6 MDYgQU0gRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tDQo+IDxtYWlsdG86ZWtyQHJ0Zm0uY29t Pj4gd3JvdGU6DQo+IA0KPiAgICAgTm90IHJlYWxseS4gSSBoYXZlIG5vdCByZWNlaXZlZCBhbnkg cmVzcG9uc2UgdG8gbXkgbWFpbCBvZiBPY3QgMjMuDQo+ICAgICBBcyBiZWZvcmUsIEknbSBoYXBw eSB0byBoYXZlIGEgY2FsbCwgYnV0IEkgYmVsaWV2ZSB3ZSdyZSByZWFjaGluZw0KPiAgICAgdGhl IGxpbWl0cyBvZiB3aGF0IGNhbiBiZSBhY2NvbXBsaXNoZWQgYnkgZW1haWwuDQo+IA0KPiANCj4g RXJpYyB3b3VsZCBrbm93IGJlc3QgKGl0IGJlaW5nIGhpcyBEaXNjdXNzKSwgYnV0IHRoaXMgaXMg YWxzbyBteQ0KPiB1bmRlcnN0YW5kaW5nLsKgDQo+IA0KPiBJIGNhbiBhZGQgdGhpcyB0byB0aGUg YWdlbmRhIG9mIHRoZSBJRVNHIGluZm9ybWFsIHRlbGVjaGF0IG9uIE5vdmVtYmVyDQo+IDI5LCBp ZiB0aGVyZSBoYXNuJ3QgYmVlbiBhIGNhbGwgYmVmb3JlIHRoZW4sIGJ1dCBJIGRvbid0IGhhdmUg YSByZWFzb24NCj4gdG8gd2FpdCB1bnRpbCB0aGVuLCBpZiBpdCdzIHBvc3NpYmxlIHRvIHRhbGsg c29vbmVyLg0KPiANCj4gVGhhbmtzLA0KPiANCj4gU3BlbmNlcg0KPiDCoA0KPiANCj4gDQo+ICAg ICAtRWtyDQo+IA0KPiANCj4gICAgIE9uIE1vbiwgTm92IDE5LCAyMDE4IGF0IDY6MzUgQU0gR29u emFsbyBDYW1hcmlsbG8NCj4gICAgIDxnb256YWxvLmNhbWFyaWxsb0Blcmljc3Nvbi5jb20NCj4g ICAgIDxtYWlsdG86Z29uemFsby5jYW1hcmlsbG9AZXJpY3Nzb24uY29tPj4gd3JvdGU6DQo+IA0K PiAgICAgICAgIEhpIFNwZW5jZXIsDQo+IA0KPiAgICAgICAgIHdoYXQgaXMgdGhlIHN0YXR1cyBv ZiB0aGlzPyBBcmUgdGhlIGF1dGhvcnMgYW5kIHRoZSBkb2N1bWVudA0KPiAgICAgICAgIHNoZXBo ZXJkDQo+ICAgICAgICAgd29ya2luZyB3aXRoIHRoZSByZWxldmFudCBBRHMgb24gdGhlIGRpc2N1 c3Nlcz8NCj4gDQo+ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi10cmFtLXN0dW4tcG10dWQvYmFsbG90Lw0KPiANCj4gICAgICAgICBDaGVlcnMsDQo+ IA0KPiAgICAgICAgIEdvbnphbG8NCj4gDQo+ICAgICAgICAgT24gMjQtT2N0LTE4IDE2OjQwLCBT cGVuY2VyIERhd2tpbnMgYXQgSUVURiB3cm90ZToNCj4gICAgICAgICA+IEhpLCBNYXJjLMKgDQo+ ICAgICAgICAgPg0KPiAgICAgICAgID4gT24gV2VkLCBPY3QgMjQsIDIwMTggYXQgMzo0NCBBTSBN YXJjIFBldGl0LUh1Z3VlbmluDQo+ICAgICAgICAgPHBldGl0aHVnQGFjbS5vcmcgPG1haWx0bzpw ZXRpdGh1Z0BhY20ub3JnPg0KPiAgICAgICAgID4gPG1haWx0bzpwZXRpdGh1Z0BhY20ub3JnIDxt YWlsdG86cGV0aXRodWdAYWNtLm9yZz4+PiB3cm90ZToNCj4gICAgICAgICA+DQo+ICAgICAgICAg PsKgIMKgIMKgSGkgU3BlbmNlciwNCj4gICAgICAgICA+DQo+ICAgICAgICAgPsKgIMKgIMKgSSBz ZW50IG15IGFuc3dlcnMgdG8gRXJpYyBSZXNjb3JsYSBxdWVzdGlvbnMgb24gMjAxOC0xMC0wNw0K PiAgICAgICAgIGZvbGxvd2luZw0KPiAgICAgICAgID7CoCDCoCDCoGFuIGluLXBlcnNvbiBtZWV0 aW5nIHdpdGggbXkgY28tYXV0aG9yLCBidXQgbmV2ZXIgZ290IGENCj4gICAgICAgICByZXNwb25z ZQ0KPiAgICAgICAgID7CoCDCoCDCoGJhY2suwqAgQmVjYXVzZSB0aGVyZSB3YXMgbm8gY2hhbmdl IHByb3Bvc2VkIGJ5IEVyaWMgSSB3ZW50DQo+ICAgICAgICAgYWhlYWQgYW5kDQo+ICAgICAgICAg PsKgIMKgIMKgcHVibGlzaGVkIC0xOSBhIGNvdXBsZSBvZiB3ZWVrcyBhZnRlciB0aGF0LCB3aXRo IHRoZSB0ZXh0DQo+ICAgICAgICAgYWdyZWVkIGluDQo+ICAgICAgICAgPsKgIMKgIMKgcmVzcG9u c2UgdG8gQWRhbSdzIGFuZCBCZW5qYW1pbidzIGNvbW1lbnRzLg0KPiAgICAgICAgID4NCj4gICAg ICAgICA+wqAgwqANCj4gICAgICAgICDCoGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvdHJhbS9jdXJyZW50L21zZzAyNjM1Lmh0bWwNCj4gICAgICAgICA+DQo+ICAgICAgICAg Pg0KPiAgICAgICAgID4gQWggLSBJIHdvbmRlciBpZiB0aGF0IHdhcyB3aGF0IGhhZCBoYXBwZW5l ZC7CoA0KPiAgICAgICAgID4NCj4gICAgICAgICA+IEl0IHNvdW5kcyBsaWtlIHlvdSBkaWQgdGhl IHJpZ2h0IHRoaW5nLCBhbmQgdGhhdCBFcmljIGhhcyBub3cNCj4gICAgICAgICByZXNwb25kZWQs DQo+ICAgICAgICAgPiB3aGljaCBpcyBhbHNvIHRoZSByaWdodCB0aGluZyB0byBkby7CoA0KPiAg ICAgICAgID4NCj4gICAgICAgICA+IFRoYW5rcyBmb3IgaGVscGluZyBtZSB1bmRlcnN0YW5kLg0K PiAgICAgICAgID4NCj4gICAgICAgICA+IFNwZW5jZXINCj4gICAgICAgICA+IMKgDQo+ICAgICAg ICAgPg0KPiAgICAgICAgID7CoCDCoCDCoE9uIDEwLzIzLzE4IDc6MjggUE0sIFNwZW5jZXIgRGF3 a2lucyBhdCBJRVRGIHdyb3RlOg0KPiAgICAgICAgID7CoCDCoCDCoD4gSGksIE1hcmMsDQo+ICAg ICAgICAgPsKgIMKgIMKgPg0KPiAgICAgICAgID7CoCDCoCDCoD4gSSBzZWUgdGhhdCBhIC0xOSBo YXMgYmVlbiBzdWJtaXR0ZWQsIGJ1dCBkaWRuJ3Qgc2VlIGENCj4gICAgICAgICByZXBseSBmcm9t DQo+ICAgICAgICAgPsKgIMKgIMKgRXJpYyBpbg0KPiAgICAgICAgID7CoCDCoCDCoD4gdGhpcyB0 aHJlYWQuIERvIHlvdSB0aGluayB0aGF0IHlvdSd2ZSBjb252ZXJnZWQ/DQo+ICAgICAgICAgPsKg IMKgIMKgPg0KPiAgICAgICAgID7CoCDCoCDCoD4gKEkgc2F3IGFuIG9mZmVyIG9mIGEgY29uZmVy ZW5jZSBjYWxsLCBzbyB0aG91Z2h0IGFuDQo+ICAgICAgICAgb3V0LW9mLWJhbmQNCj4gICAgICAg ICA+wqAgwqAgwqA+IGNvbnZlcnNhdGlvbiBtaWdodCBoYXZlIGhhcHBlbmVkKQ0KPiAgICAgICAg ID7CoCDCoCDCoD4NCj4gICAgICAgICA+wqAgwqAgwqA+IFRoYW5rcywNCj4gICAgICAgICA+wqAg wqAgwqA+DQo+ICAgICAgICAgPsKgIMKgIMKgPiBTcGVuY2VyDQo+ICAgICAgICAgPsKgIMKgIMKg Pg0KPiAgICAgICAgID7CoCDCoCDCoD4gT24gU3VuLCBPY3QgNywgMjAxOCBhdCA5OjM1IEFNIE1h cmMgUGV0aXQtSHVndWVuaW4NCj4gICAgICAgICA+wqAgwqAgwqA8cGV0aXRodWdAYWNtLm9yZyA8 bWFpbHRvOnBldGl0aHVnQGFjbS5vcmc+DQo+ICAgICAgICAgPG1haWx0bzpwZXRpdGh1Z0BhY20u b3JnIDxtYWlsdG86cGV0aXRodWdAYWNtLm9yZz4+PiB3cm90ZToNCj4gICAgICAgICA+wqAgwqAg wqA+DQo+ICAgICAgICAgPsKgIMKgIMKgPj4gSGkgRXJpYywNCj4gICAgICAgICA+wqAgwqAgwqA+ Pg0KPiAgICAgICAgID7CoCDCoCDCoD4+IFBsZWFzZSBzZWUgaW5saW5lLg0KPiAgICAgICAgID7C oCDCoCDCoD4+DQo+ICAgICAgICAgPsKgIMKgIMKgPj4gT24gMDkvMTAvMjAxOCAwMzoyNSBBTSwg RXJpYyBSZXNjb3JsYSB3cm90ZToNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4gT24gU2F0LCBTZXAg OCwgMjAxOCBhdCAyOjMxIFBNLCBNYXJjIFBldGl0LUh1Z3VlbmluDQo+ICAgICAgICAgPsKgIMKg IMKgPHBldGl0aHVnQGFjbS5vcmcgPG1haWx0bzpwZXRpdGh1Z0BhY20ub3JnPg0KPiAgICAgICAg IDxtYWlsdG86cGV0aXRodWdAYWNtLm9yZyA8bWFpbHRvOnBldGl0aHVnQGFjbS5vcmc+Pj4NCj4g ICAgICAgICA+wqAgwqAgwqA+Pj4gd3JvdGU6DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+DQo+ICAg ICAgICAgPsKgIMKgIMKgPj4+PiBIaSBFcmljLA0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4NCj4g ICAgICAgICA+wqAgwqAgwqA+Pj4+IEFwb2xvZ2llcyBmb3IgdGhlIGRlbGF5IGluIGdldHRpbmcg YmFjayB0byB0aGF0Lg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4NCj4gICAgICAgICA+wqAgwqAg wqA+Pj4+IEkgdGhpbmsgdGhhdCB0aGVyZSBpcyBzb21lIG1pc3VuZGVyc3RhbmRpbmcgaW4gd2hh dA0KPiAgICAgICAgIFNUVU5iaXMgaXMNCj4gICAgICAgICA+wqAgwqAgwqB0cnlpbmcgdG8NCj4g ICAgICAgICA+wqAgwqAgwqA+Pj4+IGRvLCBzbyBwbGVhc2Ugc2VlIG15IGNvbW1lbnRzIGlubGlu ZS4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+PiBPbiAw Ni8xOC8yMDE4IDEwOjQzIEFNLCBFcmljIFJlc2NvcmxhIHdyb3RlOg0KPiAgICAgICAgID7CoCDC oCDCoD4+Pj4+IEhpIGZvbGtzLA0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+DQo+ICAgICAgICAg PsKgIMKgIMKgPj4+Pj4gSSd2ZSByZXZpZXdlZCB0aGUgbmV3IHZlcnNpb24sIGJ1dCBJIGRvbid0 IHRoaW5rDQo+ICAgICAgICAgdGhhdCB0aGUgYmlkZG93bg0KPiAgICAgICAgID7CoCDCoCDCoD4+ Pj4+IGRpc2N1c3Npb24gbWFrZXMgbXVjaCBzZW5zZS4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+ Pg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+IFRvIHJlY2FwLCB0aGVyZSBhcmUgdHdvIGhhc2hl cyBoZXJlOg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+ Pj4gLSBUaGUgaGFzaCB3aGljaCB5b3UgdXNlIHRvIHN0b3JlIHRoZSBwYXNzd29yZCB3aXRoDQo+ ICAgICAgICAgKGN1cnJlbnRseQ0KPiAgICAgICAgID7CoCDCoCDCoG1vc3RseQ0KPiAgICAgICAg ID7CoCDCoCDCoD4+Pj4gTUQ1KQ0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+IC0gVGhlIGhhc2gg eW91IHVzZSB0byBjb21wdXRlIHRoZSBNQUMgKGN1cnJlbnRseSBTSEEtMSkuDQo+ICAgICAgICAg PsKgIMKgIMKgPj4+Pj4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+PiBGaXJzdCwgbGV0J3Mgc3Rp cHVsYXRlIHRoYXQgTUQ1IGlzbid0IGEgZ3JlYXQgY2hvaWNlDQo+ICAgICAgICAgaGVyZSwNCj4g ICAgICAgICA+wqAgwqAgwqB0aG91Z2ggU0hBLTENCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+PiBp c24ndCBhIGdyZWF0IGNob2ljZQ0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+IGVpdGhlciBmb3Ig cHdkIGhhc2hpbmcgWW91IHdhbnQgQXJnb24gb3IgdGhlIGxpa2UuDQo+ICAgICAgICAgV2l0aCB0 aGF0IHNhaWQsDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+PiB0aGVyZSdzDQo+ICAgICAgICAgPsKg IMKgIMKgPj4+Pj4gbm8gc2Vuc2libGUNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+PiBiaWRkb3du IGF0dGFjayBvbiB0aGF0IGhhc2ggYmVjYXVzZSBpdCdzIGENCj4gICAgICAgICBwZXItc2VydmVy IGZlYXR1cmUsDQo+ICAgICAgICAgPsKgIMKgIMKgbm90IGENCj4gICAgICAgICA+wqAgwqAgwqA+ Pj4+PiBwZXItdHJhbnNhY3Rpb24NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+PiBmZWF0dXJlLiBT bywgYXMgbG9uZyBhcyB0aGUgc2VydmVyIGhhcyBNRDUtaGFzaGVkDQo+ICAgICAgICAgcGFzc3dv cmRzLCB0aGUNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+IHNpdHVhdGlvbg0KPiAgICAgICAgID7C oCDCoCDCoD4+Pj4+IGlzIGJhZC4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+DQo+ICAgICAgICAg PsKgIMKgIMKgPj4+PiBJbiBubyBwbGFjZSBpbiBTVFVOYmlzIHdlIGFyZSBwcm9wb3NpbmcgdG8g dXNlIFNIQS0xDQo+ICAgICAgICAgZm9yIHBhc3N3b3JkDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+ PiBlbmNyeXB0aW9uLCBzbyBJIGFtIG5vdCBzdXJlIHdoZXJlIHRoYXQgY29tZSBmcm9tLsKgDQo+ ICAgICAgICAgV2hhdCB3ZQ0KPiAgICAgICAgID7CoCDCoCDCoHByb3Bvc2UgaXM6DQo+ICAgICAg ICAgPsKgIMKgIMKgPj4+Pg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pg0KPiAgICAgICAgID7CoCDC oCDCoD4+PiBZb3UncmUgcmlnaHQsIGl0J3MgU0hBLTI1NiwgYnV0IG15IGNyaXRpY2lzbXMgYXBw bHkNCj4gICAgICAgICBlcXVhbGx5IHRoZXJlLg0KPiAgICAgICAgID7CoCDCoCDCoD4+DQo+ICAg ICAgICAgPsKgIMKgIMKgPj4gU0hBLTI1NiB3YXMgd2hhdCB0aGUgV0cgYWRvcHRlZC7CoCBPdXIg YXR0ZW1wdHMgdG8gYWRkDQo+ICAgICAgICAgb3RoZXIgcGFzc3dvcmRzDQo+ICAgICAgICAgPsKg IMKgIMKgPj4gZW5jcnlwdGlvbiBtZWNoYW5pc21zIHdlcmUgZGVuaWVkLsKgIEl0IGlzIHRydWUg dGhhdA0KPiAgICAgICAgIEFyZ29uMiB3YXMNCj4gICAgICAgICA+wqAgwqAgwqBub3QgaW4gdGhh dA0KPiAgICAgICAgID7CoCDCoCDCoD4+IGxpc3QgKGluIG91ciBkZWZlbnNlIEFyZ29uMiB3YXMg bm90IGtub3duIGJlZm9yZSBKdWx5DQo+ICAgICAgICAgMjAxNSksIGJ1dA0KPiAgICAgICAgID7C oCDCoCDCoEkgZG8gbm90DQo+ICAgICAgICAgPsKgIMKgIMKgPj4gc2VlIHdoeSB0aGUgV0cgd291 bGQgaGF2ZSBhY2NlcHRlZCB0aGF0IG9uZSBvdmVyIHRoZQ0KPiAgICAgICAgIG90aGVycy7CoA0K PiAgICAgICAgID7CoCDCoCDCoEFueXdheSBpdCBpcw0KPiAgICAgICAgID7CoCDCoCDCoD4+IHRv byBsYXRlIHRvIGZpeCB0aGlzLCBhcyBpdCBpcyBteSB1bmRlcnN0YW5kaW5nIHRoYXQNCj4gICAg ICAgICB0aGUgV0cgZG9lcw0KPiAgICAgICAgID7CoCDCoCDCoG5vdCBoYXZlDQo+ICAgICAgICAg PsKgIMKgIMKgPj4gZW5vdWdoIGVuZXJneSB0byByZWFjaCBjb25zZW5zdXMgb24gYSBuZXcgcGFz c3dvcmQNCj4gICAgICAgICBhbGdvcml0aG0uwqANCj4gICAgICAgICA+wqAgwqAgwqBTb21lb25l IGNhbg0KPiAgICAgICAgID7CoCDCoCDCoD4+IGp1c3Qgd3JpdGUgYSBkcmFmdCBhZGRpbmcgQXJn b24yIGFzIHBhc3N3b3JkDQo+ICAgICAgICAgZW5jcnlwdGlvbiwgYXMgd2UNCj4gICAgICAgICA+ wqAgwqAgwqB3aWxsIGhhdmUgYQ0KPiAgICAgICAgID7CoCDCoCDCoD4+IElBTkEgcmVnaXN0cnkg Zm9yIHRoYXQuDQo+ICAgICAgICAgPsKgIMKgIMKgPj4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4N Cj4gICAgICAgICA+wqAgwqAgwqA+Pj4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+IC0gRXN0YWJs aXNoIGEgcmVnaXN0cnkgZm9yIG5ldyBwYXNzd29yZCBhbGdvcml0aG1zDQo+ICAgICAgICAgKHNl Y3Rpb24NCj4gICAgICAgICA+wqAgwqAgwqAxOC41KSwgc28NCj4gICAgICAgICA+wqAgwqAgwqA+ Pj4+IGFsZ29yaXRobXMgbGlrZSBBcmdvbjIgY291bGQgYmUgYWRkZWQgbGF0ZXIgKGJ1dCBub3Rl DQo+ICAgICAgICAgdGhhdCBvdXIgb3duDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+PiBwcm9wb3Nh bHMgdG8gYWRkIG1vcmUgcGFzc3dvcmQgYWxnb3JpdGhtcyB3ZXJlDQo+ICAgICAgICAgcmVqZWN0 ZWQgYnkgdGhlDQo+ICAgICAgICAgPsKgIMKgIMKgd29ya2luZw0KPiAgICAgICAgID7CoCDCoCDC oD4+Pj4gZ3JvdXApLg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4gLSBBZGQgYSBuZXcgcGFzc3dv cmQgYWxnb3JpdGhtIHRvIHRoYXQgcmVnaXN0cnksDQo+ICAgICAgICAgbmFtZWx5IFNIQS0yNTYu DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+PiAtIFJlZ2lzdGVyIE1ENSBhcyBhbiBpbml0aWFsIHBh c3N3b3JkIGFsZ29yaXRobSBmb3INCj4gICAgICAgICBiYWNrd2FyZA0KPiAgICAgICAgID7CoCDC oCDCoD4+IGNvbXBhdGliaWxpdHkNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+IHB1cnBvc2UuDQo+ ICAgICAgICAgPsKgIMKgIMKgPj4+Pg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4gQXMgZm9yIHRo ZSBiaWRkb3duIHByb3RlY3Rpb24gaXRzZWxmLCBpdCBpcyBteQ0KPiAgICAgICAgIHJlY29sbGVj dGlvbiB0aGF0IGl0DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+PiBoYXBwZW5lZCBtb3JlIG9yIGxl c3MgbGlrZSB0aGF0Og0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4NCj4gICAgICAgICA+wqAgwqAg wqA+Pj4+DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+PiBJTlQuIE1FRVRJTkcgUk9PTSAtIERBWQ0K PiAgICAgICAgID7CoCDCoCDCoD4+Pj4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+IE9uZSBvZiB0 aGUgY28tZWRpdG9ycyBvZiBTVFVOQmlzIHN0YW5kcyBhdCB0aGUNCj4gICAgICAgICBtaWNyb3Bo b25lOg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+wqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgQ08tRURJVE9SDQo+ICAgICAg ICAgPsKgIMKgIMKgPj4+PsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFdlIGFkZGVkIFNIQS0y NTYgcHJvdGVjdGlvbiBmb3INCj4gICAgICAgICBwYXNzd29yZHMNCj4gICAgICAgICA+wqAgwqAg wqA+Pj4+wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaW4gU1RVTkJpcy4NCj4gICAgICAgICA+ wqAgwqAgwqA+Pj4+DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+PsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIFNPTUVPTkUgKFYuTy4pDQo+ICAgICAgICAgPsKgIMKgIMKg Pj4+PsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEFzIE1ENSBzdGlsbCBuZWVkIHRvIGJlIHN1 cHBvcnRlZCwNCj4gICAgICAgICB5b3UgbmVlZCB0byBhZGQNCj4gICAgICAgICA+wqAgwqAgwqA+ Pj4+wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcHJvdGVjdGlvbiBmb3IgYmlkLWRvd24gYXR0 YWNrcy4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+PiBD TE9TRS1VUCBvbiBDTy1FRElUT1IgUk9MTElORyBISVMgRVlFUw0KPiAgICAgICAgID7CoCDCoCDC oD4+Pj4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgQ08tRURJVE9SDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+PsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIE9LLCBJJ2xsIHdvcmsgb24gdGhhdC4NCj4gICAgICAgICA+wqAg wqAgwqA+Pj4+DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+PiBGb3VyIHRvIGVpZ2h0IG1vbnRocyBo YXMgcGFzc2VkLg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4NCj4gICAgICAgICA+wqAgwqAgwqA+ Pj4+IElOVC4gQU5PVEhFUiBNRUVUSU5HIFJPT00gLSBEQVkNCj4gICAgICAgICA+wqAgwqAgwqA+ Pj4+DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+PiBUaGUgc2FtZSBjby1lZGl0b3Igb2YgU1RVTkJp cyBzdGFuZHMgYXQgdGhlIG1pY3JvcGhvbmU6DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pg0KPiAg ICAgICAgID7CoCDCoCDCoD4+Pj7CoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBDTy1FRElUT1INCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+wqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgV2UgYWRkZWQgYSBuaWNlIG1lY2hhbmlzbSB0byBwcmV2ZW50DQo+ICAgICAgICAg YmlkLWRvd24NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgYXR0YWNrcyBvbiBwYXNzd29yZHMuwqAgQW55IGNvbW1lbnRzPw0KPiAgICAgICAgID7CoCDC oCDCoD4+Pj4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgVEhFIFJPT00NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+wqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgKHNpbGVuY2UpDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pg0K PiAgICAgICAgID7CoCDCoCDCoD4+Pj7CoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBDTy1FRElUT1INCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+wqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgTW92aW5nIG9uLi4uDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pg0KPiAgICAg ICAgID7CoCDCoCDCoD4+Pg0KPiAgICAgICAgID7CoCDCoCDCoD4+PiBJIGRvbid0IHNlZSBob3cg YW55IG9mIHRoaXMgaXMgcmVsZXZhbnQgdG8gbXkNCj4gICAgICAgICB0ZWNobmljYWwgcG9pbnRz DQo+ICAgICAgICAgPsKgIMKgIMKgYWJvdmUuDQo+ICAgICAgICAgPsKgIMKgIMKgPj4NCj4gICAg ICAgICA+wqAgwqAgwqA+PiBNeSBwb2ludCB3YXMgdGhhdCB3ZSwgdGhlIGNvLWVkaXRvcnMsIGRp ZCBub3QgZGVjaWRlIG9uDQo+ICAgICAgICAgYWRkaW5nDQo+ICAgICAgICAgPsKgIMKgIMKgYmlk LWRvd24NCj4gICAgICAgICA+wqAgwqAgwqA+PiBwcm90ZWN0aW9uLCBzb21lb25lIGFza2VkIHVz IHRvIGRvIHNvIGFuZCBuby1vbmUgaW4gdGhlDQo+ICAgICAgICAgV0cgc2F3DQo+ICAgICAgICAg PsKgIMKgIMKgYW55IHByb2JsZW0NCj4gICAgICAgICA+wqAgwqAgwqA+PiB3aXRoIHRoYXQuwqAg VGhlIHJlYXNvbnMgdGhhdCBwZXJzb24gd2FudGVkIHRoYXQgYXJlIG5vdA0KPiAgICAgICAgIGtu b3duIHRvDQo+ICAgICAgICAgPsKgIMKgIMKgdXMgYnV0LCBhcw0KPiAgICAgICAgID7CoCDCoCDC oD4+IHlvdSBpbnNpc3QsIGhlcmUncyBvbmUgcmVhc29uIEkgY2FuIHRoaW5rIG9mOg0KPiAgICAg ICAgID7CoCDCoCDCoD4+DQo+ICAgICAgICAgPsKgIMKgIMKgPj4gSXQgaXMgYSBmYWN0IHRoYXQs IGZvciBvcGVyYXRpb25hbCByZWFzb25zLCBhIHBhc3N3b3JkDQo+ICAgICAgICAgZGF0YWJhc2UN Cj4gICAgICAgICA+wqAgwqAgwqBjYW5ub3QgYmUNCj4gICAgICAgICA+wqAgwqAgwqA+PiByZS1l bmNyeXB0ZWQgYXQgb25jZS7CoCBBbHNvIGZvciBvcGVyYXRpb25hbCByZWFzb25zLA0KPiAgICAg ICAgIHRoZSBNRDUgcGFzc3dvcmQNCj4gICAgICAgICA+wqAgwqAgwqA+PiBjYW5ub3QgYmUgaW1t ZWRpYXRlbHkgcmVtb3ZlZCBmcm9tIHRoZSBkYXRhYmFzZSBhcyBzb29uDQo+ICAgICAgICAgdGhl IHVzZXINCj4gICAgICAgICA+wqAgwqAgwqBzdWJtaXR0ZWQNCj4gICAgICAgICA+wqAgwqAgwqA+ PiBhIG5ldyBvbmUuwqAgSW4gZmFjdCwgYW5kIGZvciBxdWl0ZSBzb21lIHRpbWUsIGJvdGgNCj4g ICAgICAgICBlbmNyeXB0ZWQNCj4gICAgICAgICA+wqAgwqAgwqB2YXJpYW50cyBvZg0KPiAgICAg ICAgID7CoCDCoCDCoD4+IHRoZSBzYW1lIHBhc3N3b3JkIG1heSBoYXZlIHRvIGJlIGtlcHQgaW4g dGhhdCBkYXRhYmFzZSwNCj4gICAgICAgICBiZWNhdXNlIGENCj4gICAgICAgICA+wqAgwqAgwqBz aW5nbGUNCj4gICAgICAgICA+wqAgwqAgwqA+PiB1c2VyIG1heSB1c2UgYSBtaXggb2YgZGV2aWNl cywgc29tZSBvZiB0aGVtIHRoYXQgdXNlIGFuDQo+ICAgICAgICAgUkZDIDUzODkNCj4gICAgICAg ICA+wqAgwqAgwqBjbGllbnQsDQo+ICAgICAgICAgPsKgIMKgIMKgPj4gc29tZSB0aGF0IHVzZSBh IFNUVU5iaXMgY2xpZW50LsKgIEl0IGlzIHVwIHRvIHRoZSBTVFVODQo+ICAgICAgICAgc2VydmVy IG93bmVyIHRvDQo+ICAgICAgICAgPsKgIMKgIMKgPj4gZGVjaWRlIGhvdyBsb25nIHRoZSBtaWdy YXRpb24gdG8gU1RVTmJpcyB3aWxsIHRha2UgYW5kDQo+ICAgICAgICAgd2hlbiBpdA0KPiAgICAg ICAgID7CoCDCoCDCoHdpbGwgYmUNCj4gICAgICAgICA+wqAgwqAgwqA+PiBhY2NlcHRhYmxlIHRv IHJlamVjdCBhbGwgUkZDIDUzODkgKGkuZS4gTUQ1KSBjbGllbnRzICh0aGF0DQo+ICAgICAgICAg PsKgIMKgIMKgbWlncmF0aW9uIHRpbWUNCj4gICAgICAgICA+wqAgwqAgwqA+PiBjYW4gYmUgcHVy cG9zZWx5IHJlZHVjZWQgdG8gMCBzZWNvbmRzIGJ1dCB0aGF0J3MgdGhlDQo+ICAgICAgICAgY2hv aWNlIGFuZA0KPiAgICAgICAgID7CoCDCoCDCoD4+IHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBvd25l ciBvZiB0aGUgc2VydmVyKS4NCj4gICAgICAgICA+wqAgwqAgwqA+Pg0KPiAgICAgICAgID7CoCDC oCDCoD4+IE1lYW53aGlsZSB3ZSBzdGlsbCBuZWVkIHRvIGJlIHN1cmUgdGhhdCBpZiB0aGUgU1RV Tg0KPiAgICAgICAgIGNsaWVudCBpcw0KPiAgICAgICAgID7CoCDCoCDCoGltcGxlbWVudGluZw0K PiAgICAgICAgID7CoCDCoCDCoD4+IFNUVU5iaXMgaXQgdW5jb25kaXRpb25hbGx5IGdldHMgdGhl IGFkZGl0aW9uYWwNCj4gICAgICAgICBwcm90ZWN0aW9uIG9mIHRoZSBuZXcNCj4gICAgICAgICA+ wqAgwqAgwqA+PiBwYXNzd29yZCBlbmNyeXB0aW9uIGFsZ29yaXRobS7CoCBUaGF0J3Mgd2hlcmUg dGhlIGJpZGRvd24NCj4gICAgICAgICA+wqAgwqAgwqBwcm90ZWN0aW9uIGtpY2tzDQo+ICAgICAg ICAgPsKgIMKgIMKgPj4gaW4sIGJ5IHByZXZlbnRpbmcgYW4gb25saW5lIGF0dGFja2VyIHRvIGhh dmUgdGhlIHNlcnZlcg0KPiAgICAgICAgID7CoCDCoCDCoG1pc2lkZW50aWZ5aW5nIGENCj4gICAg ICAgICA+wqAgwqAgwqA+PiBTVFVOYmlzIGNsaWVudCBhcyBhbiBSRkMgNTM4OSBjbGllbnQsIGJ5 IHByZXZlbnRpbmcgYW4NCj4gICAgICAgICBvbmxpbmUNCj4gICAgICAgICA+wqAgwqAgwqBhdHRh Y2tlciB0bw0KPiAgICAgICAgID7CoCDCoCDCoD4+IGhhdmUgdGhlIGNsaWVudCBtaXNpZGVudGlm eWluZyBhIFNUVU5iaXMgc2VydmVyIGFzIGENCj4gICAgICAgICBSRkMgNTM4OQ0KPiAgICAgICAg ID7CoCDCoCDCoHNlcnZlciwgYW5kDQo+ICAgICAgICAgPsKgIMKgIMKgPj4gaGF2aW5nIGJvdGgg dGhlbSB1c2UgdGhlIE1ENSBlbmNyeXB0ZWQgcGFzc3dvcmQgaW5zdGVhZA0KPiAgICAgICAgIG9m IHRoZQ0KPiAgICAgICAgID7CoCDCoCDCoFNIQS0yNTYNCj4gICAgICAgICA+wqAgwqAgwqA+PiBl bmNyeXB0ZWQgcGFzc3dvcmQsIGFsbCBvZiB0aGF0IGVhc2lseSBkb25lIGJ5DQo+ICAgICAgICAg c3RyaXBwaW5nIHRoZQ0KPiAgICAgICAgID7CoCDCoCDCoHVucHJvdGVjdGVkDQo+ICAgICAgICAg PsKgIMKgIMKgPj4gNDAxIHJlc3BvbnNlIG9mIHRoZSBuZXcgU1RVTmJpcyBQQVNTV09SRC1BTEdP UklUSE1TDQo+ICAgICAgICAgYXR0cmlidXRlLg0KPiAgICAgICAgID7CoCDCoCDCoD4+DQo+ICAg ICAgICAgPsKgIMKgIMKgPj4+DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+DQo+ICAgICAgICAgPsKg IMKgIMKgPj4+DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4gVGhlIHNlY29uZCB0b3BpYyBpcyB0 aGUgaGFzaCB1c2VkIHRvIGNvbXB1dGUgdGhlDQo+ICAgICAgICAgTUFDLiBIb3dldmVyLA0KPiAg ICAgICAgID7CoCDCoCDCoEkgZG9uJ3QNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+IHNlZQ0KPiAg ICAgICAgID7CoCDCoCDCoD4+Pj4+IGhvdw0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+IHRoaXMg Z2l2ZXMgeW91IHNlbnNpYmxlIGJpZGRvd24gcHJvdGVjdGlvbiBiZWNhdXNlDQo+ICAgICAgICAg dGhhdCBoYXNoDQo+ICAgICAgICAgPsKgIMKgIMKgaXMgYWxzbw0KPiAgICAgICAgID7CoCDCoCDC oD4+IHVzZWQNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+PiB0byBjb21wdXRlDQo+ICAgICAgICAg PsKgIMKgIMKgPj4+Pj4gTUFDIG92ZXIgdGhlIG5lZ290aWF0aW9uOiBhbiBhdHRhY2tlciB3aG8g aGFzDQo+ICAgICAgICAgY29tcHJvbWlzZWQgYQ0KPiAgICAgICAgID7CoCDCoCDCoE1BQyB3aGlj aA0KPiAgICAgICAgID7CoCDCoCDCoD4+IHRoZQ0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+IHNl cnZlcg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+IHN1cHBvcnRzIHdpbGwgcXVpdGUgbGlrZWx5 IGJlIGFibGUgdG8gZm9yZ2UgYSBNQUMNCj4gICAgICAgICBvdmVyIHRoZQ0KPiAgICAgICAgID7C oCDCoCDCoHRyYW5zY3JpcHQNCj4gICAgICAgICA+wqAgwqAgwqA+PiBhcw0KPiAgICAgICAgID7C oCDCoCDCoD4+Pj4+IHdlbGwuIFRoaXMgaXMsDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4gSSBz dXBwb3NlLCBwb3RlbnRpYWxseSB1c2VmdWwgYXMgYSBkZWZlbnNlIGFnYWluc3QNCj4gICAgICAg ICBzb21lIG90aGVyDQo+ICAgICAgICAgPsKgIMKgIMKgd2Vha25lc3MNCj4gICAgICAgICA+wqAg wqAgwqA+Pj4+PiAoZS5nLiwNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+PiB2ZXJzaW9uICMpLCBi dXQgSSBkb24ndCByZWFsbHkgc2VlIGhvdyB0aGUgY3VycmVudA0KPiAgICAgICAgIGRlc2lnbg0K PiAgICAgICAgID7CoCDCoCDCoGhlbHBzIGFnYWluc3QNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+ PiBhdHRhY2tzIG9uIHRoZQ0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+IE1BQy4NCj4gICAgICAg ICA+wqAgwqAgwqA+Pj4+DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+PiBUaGVyZSBpcyBubyBiaWRk b3duIGF0dGFjayBwcm90ZWN0aW9uIGZvciB0aGUgTUFDLCBhcw0KPiAgICAgICAgIHN0YXRlZCBp bg0KPiAgICAgICAgID7CoCDCoCDCoFNlY3Rpb24NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+IDE2 LjM6DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4gIlRo ZSBiaWQtZG93biBwcm90ZWN0aW9uIG1lY2hhbmlzbSBkZXNjcmliZWQgaW4gdGhpcw0KPiAgICAg ICAgIGRvY3VtZW50DQo+ICAgICAgICAgPsKgIMKgIMKgaXMgbmV3LA0KPiAgICAgICAgID7CoCDC oCDCoD4+Pj7CoCBhbmQgdGh1cyBjYW5ub3QgY3VycmVudGx5IHByb3RlY3QgYWdhaW5zdCBhIGJp ZC1kb3duDQo+ICAgICAgICAgYXR0YWNrIHRoYXQNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+wqAg bG93ZXJzIHRoZSBzdHJlbmd0aCBvZiB0aGUgaGFzaCBhbGdvcml0aG0gdG8gSE1BQy1TSEExLiIN Cj4gICAgICAgICA+wqAgwqAgwqA+Pj4+DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+PiBXaGF0IHdl IHB1dCBpbiBwbGFjZSBpcyBhIHBsYW4gZm9yICpmdXR1cmUqIHZlcnNpb25zDQo+ICAgICAgICAg b2YgU1RVTiB0byBnZXQNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+IGJpZGRvd24gcHJvdGVjdGlv biBmb3IgdGhlIE1BQy7CoCBUaGF0J3MgaXQsIG5vIG1vcmUsDQo+ICAgICAgICAgbm8gbGVzcy4N Cj4gICAgICAgICA+wqAgwqAgwqA+Pj4+DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+DQo+ICAgICAg ICAgPsKgIMKgIMKgPj4+IFllcywgYnV0IEkgZG9uJ3QgYmVsaWV2ZSB0aGF0IHRoaXMgd2lsbCBw cm92aWRlIGJpZC1kb3duDQo+ICAgICAgICAgPsKgIMKgIMKgcHJvdGVjdGlvbiBmb3INCj4gICAg ICAgICA+wqAgwqAgwqA+PiB0aGUNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4gTUFDIGluIHRoZSBm dXR1cmUgZm9yIHRoZSByZWFzb25zIEkgaW5kaWNhdGUgYWJvdmUuDQo+ICAgICAgICAgPsKgIMKg IMKgPj4+DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+IElmIHlvdSB0aGluayB0aGlzIGRvZXMgc29t ZXRoaW5nIHVzZWZ1bCwgcGxlYXNlIHNob3cgbWUgYW4NCj4gICAgICAgICA+wqAgwqAgwqBleGFt cGxlIGF0dGFjaw0KPiAgICAgICAgID7CoCDCoCDCoD4+PiBhbmQgaG93IHRoaXMgZml4ZXMgaXQu IE5vdGUgdGhhdCBpdCdzIG5vdCBnZW5lcmFsbHkNCj4gICAgICAgICB1c2VmdWwgdG8NCj4gICAg ICAgICA+wqAgwqAgwqBqdXN0IGJpZA0KPiAgICAgICAgID7CoCDCoCDCoD4+IGRvd24NCj4gICAg ICAgICA+wqAgwqAgwqA+Pj4gdGhlIE1BQyBpdHNlbGYgdW5sZXNzIHRoZSBNQUMgeW91IGJpZCBk b3duIHRvIGlzIHdlYWsNCj4gICAgICAgICBlbm91Z2ggdG8NCj4gICAgICAgICA+wqAgwqAgwqBl eHBsb2l0DQo+ICAgICAgICAgPsKgIMKgIMKgPj4gaW4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4g c29tZSBvdGhlciB3YXkuDQo+ICAgICAgICAgPsKgIMKgIMKgPj4NCj4gICAgICAgICA+wqAgwqAg wqA+PiBJIGRvIG5vdCBrbm93IHdoYXQgd2Vha25lc3NlcyB3aWxsIGJlIGRpc2NvdmVyZWQgaW4g dGhlDQo+ICAgICAgICAgZnV0dXJlLsKgDQo+ICAgICAgICAgPsKgIMKgIMKgSSBhbSBhbHNvDQo+ ICAgICAgICAgPsKgIMKgIMKgPj4gcHJldHR5IHN1cmUgdGhhdCB0aGUgY29zdCBvZiBub3QgdXNp bmcgdGhhdCBtZWNoYW5pc20NCj4gICAgICAgICBpcyB2ZXJ5DQo+ICAgICAgICAgPsKgIMKgIMKg Y2xvc2UgdG8gMC4NCj4gICAgICAgICA+wqAgwqAgwqA+PiBXaGF0IEkgYW0gc3VyZSBvZiBpcyB0 aGF0IHRoZSBjb3N0IG9mIHJlZW5naW5lZXJpbmcgYQ0KPiAgICAgICAgIG5ldyBiaWRkb3duDQo+ ICAgICAgICAgPsKgIMKgIMKgPj4gcHJvdGVjdGlvbiBtZWNoYW5pc20gaWYgd2UgZXZlciBuZWVk IGl0IHdpbGwgYmUgaGlnaC7CoA0KPiAgICAgICAgIFdlIGFscmVhZHkNCj4gICAgICAgICA+wqAg wqAgwqB3ZW50DQo+ICAgICAgICAgPsKgIMKgIMKgPj4gdGhyb3VnaCB0aGUgcGFpbnMgb2YgZGVz aWduaW5nIG9uZSBmb3IgdGhlIHBhc3N3b3JkDQo+ICAgICAgICAgYWxnb3JpdGhtLCBzbw0KPiAg ICAgICAgID7CoCDCoCDCoHdoeSBub3QNCj4gICAgICAgICA+wqAgwqAgwqA+PiBleHRlbmQgaXQg c28gaXQgY2FuIGJlIHVzZWQgaW4gdGhlIGFmdGVybWF0aCBvZiB0aGUNCj4gICAgICAgICBuZXh0 IFNub3dkZW4NCj4gICAgICAgICA+wqAgwqAgwqBmYWNlcGFsbQ0KPiAgICAgICAgID7CoCDCoCDC oD4+IG1vbWVudD8NCj4gICAgICAgICA+wqAgwqAgwqA+Pg0KPiAgICAgICAgID7CoCDCoCDCoD4+ PiBBZ2FpbiwgaGFwcHkgdG8gaGF2ZSBhIGNhbGwgdG8gd2FsayB0aG91Z2ggdGhpcyBpZiB0aGF0 DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+IGhlbHBzLg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pg0K PiAgICAgICAgID7CoCDCoCDCoD4+PiAtRWtyDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+DQo+ICAg ICAgICAgPsKgIMKgIMKgPj4+DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+DQo+ICAgICAgICAgPsKg IMKgIMKgPj4+DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4NCj4gICAgICAgICA+wqAgwqAgwqA+ Pj4+PiBZb3UgbWlnaHQgdGhpbmsgdGhhdCB0aGVyZSB3YXMgYSBNQUMgd2hpY2ggd2FzIGVhc2ll ciB0bw0KPiAgICAgICAgID7CoCDCoCDCoHJldmVyc2UgdG8NCj4gICAgICAgICA+wqAgwqAgwqA+ PiBmaW5kDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4gdGhlIG9yaWdpbmFsDQo+ICAgICAgICAg PsKgIMKgIMKgPj4+Pj4gcGFzc3dvcmQsIGJ1dCB0aGUgZGVmZW5zZSB5b3UgaGF2ZSBoZXJlIGRv ZXNuJ3QgaGVscA0KPiAgICAgICAgIHdpdGggdGhhdA0KPiAgICAgICAgID7CoCDCoCDCoGJlY2F1 c2UNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+IHRoZQ0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+ IG9uLXBhdGggYXR0YWNrZXIgY2FuIGRvIGEgYmlkLWRvd24gYW5kIHVzZSB0aGUNCj4gICAgICAg ICBjbGllbnQgYXMgYSBNQUMNCj4gICAgICAgICA+wqAgwqAgwqBvcmFjbGUNCj4gICAgICAgICA+ wqAgwqAgwqA+PiBmb3INCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+PiBhbnkgTUFDIHRoZSBjbGll bnQgc3VwcG9ydHMuDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4NCj4gICAgICAgICA+wqAgwqAg wqA+Pj4+PiBTbywgSSBzdGlsbCBkb24ndCB1bmRlcnN0YW5kIHdoYXQgdGhpcyBpcyBzdXBwb3Nl ZA0KPiAgICAgICAgIHRvIGRvLiBIYXBweSB0bw0KPiAgICAgICAgID7CoCDCoCDCoD4+IGhhdmUg YQ0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+IGNhbGwgaWYgeW91DQo+ICAgICAgICAgPsKgIMKg IMKgPj4+Pj4gdGhpbmsgdGhhdCBoZWxwcw0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+DQo+ICAg ICAgICAgPsKgIMKgIMKgPj4+Pj4gLUVrcg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+DQo+ICAg ICAgICAgPsKgIMKgIMKgPj4+Pj4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pg0KPiAgICAgICAg ID7CoCDCoCDCoD4+Pj4+DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4gT24gTW9uLCBKdW4gMTgs IDIwMTggYXQgMzo0MCBBTSwgR29uemFsbyBDYW1hcmlsbG8gPA0KPiAgICAgICAgID7CoCDCoCDC oD4+Pj4+IEdvbnphbG8uQ2FtYXJpbGxvQGVyaWNzc29uLmNvbQ0KPiAgICAgICAgIDxtYWlsdG86 R29uemFsby5DYW1hcmlsbG9AZXJpY3Nzb24uY29tPg0KPiAgICAgICAgID7CoCDCoCDCoDxtYWls dG86R29uemFsby5DYW1hcmlsbG9AZXJpY3Nzb24uY29tDQo+ICAgICAgICAgPG1haWx0bzpHb256 YWxvLkNhbWFyaWxsb0Blcmljc3Nvbi5jb20+Pj4gd3JvdGU6DQo+ICAgICAgICAgPsKgIMKgIMKg Pj4+Pj4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4gTWFyYywgRXJpYywNCj4gICAgICAgICA+ wqAgwqAgwqA+Pj4+Pj4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4gd2hhdCBpcyB0aGUgc3Rh dHVzIG9mIHRoaXMgZGlzY3Vzc2lvbj8NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4NCj4gICAg ICAgICA+wqAgwqAgwqA+Pj4+Pj4gVGhhbmtzLA0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pg0K PiAgICAgICAgID7CoCDCoCDCoD4+Pj4+PiBHb256YWxvDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+ Pj4+DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+IE9uIDA0LzA1LzIwMTggMjozNSBBTSwgRXJp YyBSZXNjb3JsYSB3cm90ZToNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+DQo+ICAgICAgICAg PsKgIMKgIMKgPj4+Pj4+Pg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj4gT24gTW9uLCBBcHIg MjMsIDIwMTggYXQgMTE6MTYgQU0sIE1hcmMNCj4gICAgICAgICBQZXRpdC1IdWd1ZW5pbiA8DQo+ ICAgICAgICAgPsKgIMKgIMKgPj4+PiBwZXRpdGh1Z0BhY20ub3JnIDxtYWlsdG86cGV0aXRodWdA YWNtLm9yZz4NCj4gICAgICAgICA8bWFpbHRvOnBldGl0aHVnQGFjbS5vcmcgPG1haWx0bzpwZXRp dGh1Z0BhY20ub3JnPj4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+IDxtYWlsdG86cGV0aXRo dWdAYWNtLm9yZyA8bWFpbHRvOnBldGl0aHVnQGFjbS5vcmc+DQo+ICAgICAgICAgPG1haWx0bzpw ZXRpdGh1Z0BhY20ub3JnIDxtYWlsdG86cGV0aXRodWdAYWNtLm9yZz4+Pj4gd3JvdGU6DQo+ICAg ICAgICAgPsKgIMKgIMKgPj4+Pj4+Pg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDC oE9uIDA0LzIyLzIwMTggMDU6MjIgUE0sIEVyaWMgUmVzY29ybGEgd3JvdGU6DQo+ICAgICAgICAg PsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKgPiBPbiBTdW4sIEFwciAyMiwgMjAxOCBhdCAyOjAyIFBN LCBNYXJjDQo+ICAgICAgICAgUGV0aXQtSHVndWVuaW4gPA0KPiAgICAgICAgID7CoCDCoCDCoD4+ Pj4+PiBwZXRpdGh1Z0BhY20ub3JnIDxtYWlsdG86cGV0aXRodWdAYWNtLm9yZz4NCj4gICAgICAg ICA8bWFpbHRvOnBldGl0aHVnQGFjbS5vcmcgPG1haWx0bzpwZXRpdGh1Z0BhY20ub3JnPj4NCj4g ICAgICAgICA+wqAgwqAgwqA8bWFpbHRvOnBldGl0aHVnQGFjbS5vcmcgPG1haWx0bzpwZXRpdGh1 Z0BhY20ub3JnPg0KPiAgICAgICAgIDxtYWlsdG86cGV0aXRodWdAYWNtLm9yZyA8bWFpbHRvOnBl dGl0aHVnQGFjbS5vcmc+Pj4+DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKgPiB3 cm90ZToNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqA+DQo+ICAgICAgICAgPsKg IMKgIMKgPj4+Pj4+PsKgIMKgIMKgPj4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+wqAgwqAg wqA+Pj4+wqAgwqAgwqAgRm9yIGEgcmVxdWVzdCBvciBpbmRpY2F0aW9uIG1lc3NhZ2UsDQo+ICAg ICAgICAgdGhlIGFnZW50DQo+ICAgICAgICAgPsKgIMKgIMKgTVVTVA0KPiAgICAgICAgID7CoCDC oCDCoD4+Pj4+PiBpbmNsdWRlIHRoZQ0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDC oD4+Pj7CoCDCoCDCoCBVU0VSTkFNRSwgTUVTU0FHRS1JTlRFR1JJVFktU0hBMjU2LCBhbmQNCj4g ICAgICAgICA+wqAgwqAgwqA+PiBNRVNTQUdFLUlOVEVHUklUWQ0KPiAgICAgICAgID7CoCDCoCDC oD4+Pj4+Pj7CoCDCoCDCoD4+IGF0dHJpYnV0ZXMNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+ wqAgwqAgwqA+Pj4+wqAgwqAgwqAgaW4gdGhlIG1lc3NhZ2UgdW5sZXNzIHRoZSBhZ2VudA0KPiAg ICAgICAgIGtub3dzIGZyb20gYW4NCj4gICAgICAgICA+wqAgwqAgwqBleHRlcm5hbA0KPiAgICAg ICAgID7CoCDCoCDCoD4+Pj4+PiBpbmRpY2F0aW9uDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+ PsKgIMKgIMKgPj4+PsKgIMKgIMKgIHdoaWNoIG1lc3NhZ2UgaW50ZWdyaXR5IGFsZ29yaXRobSBp cw0KPiAgICAgICAgIHN1cHBvcnRlZA0KPiAgICAgICAgID7CoCDCoCDCoGJ5IGJvdGgNCj4gICAg ICAgICA+wqAgwqAgwqA+Pj4+Pj4gYWdlbnRzLsKgIEluDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+ Pj4+PsKgIMKgIMKgPj4+PsKgIMKgIMKgIHRoaXMgY2FzZSBlaXRoZXIgTUVTU0FHRS1JTlRFR1JJ VFkgb3INCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4gTUVTU0FHRS1JTlRFR1JJVFktU0hBMjU2 IE1VU1QNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqA+Pj4+wqAgwqAgwqAgYmUg aW5jbHVkZWQgaW4gYWRkaXRpb24gdG8NCj4gICAgICAgICBVU0VSTkFNRS7CoCBUaGUgSE1BQw0K PiAgICAgICAgID7CoCDCoCDCoGZvciB0aGUNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4gTUVT U0FHRS0NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqA+Pj4NCj4gICAgICAgICA+ wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqA+Pj4gVGhpcyB0ZXh0IGFwcGVhcnMgdG8gY29uZmxpY3Qg d2l0aCBTIDcuMyBvZg0KPiAgICAgICAgID7CoCDCoCDCoDUyNDUtYmlzLCB3aGljaA0KPiAgICAg ICAgID7CoCDCoCDCoD4+Pj4gc2F5czoNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+wqAgwqAg wqA+Pg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoD4+IFt0ZXh0IG1pc3Npbmdd DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKgPj4NCj4gICAgICAgICA+wqAgwqAg wqA+Pj4+Pj4+wqAgwqAgwqA+PiBIbW0sIG5vLCBSRkMyNDViaXMgaXMgc3RpbGwgcmVmZXJlbmNp bmcNCj4gICAgICAgICBSRkM1Mzg5LCBzbyB0aGUNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+IHBy b2NlZHVyZQ0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+PiBmb3INCj4gICAgICAgICA+wqAgwqAg wqA+Pj4+Pj4+wqAgwqAgwqA+PiBzdHVuYmlzIGRvZXMgbm90IGFwcGx5Lg0KPiAgICAgICAgID7C oCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoD4+DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKg IMKgPg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoD4gSSBoZWFyIHdoYXQgeW91 J3JlIHNheWluZywgYnV0IHB1Ymxpc2hpbmcgdHdvDQo+ICAgICAgICAgPsKgIMKgIMKgZG9jdW1l bnRzIGF0IHRoZQ0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+PiBzYW1lIHRpbWUNCj4gICAgICAg ICA+wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqA+IHdoaWNoDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+ Pj4+PsKgIMKgIMKgPiBtYWtlIGNvbnRyYXJ5IHJlY29tbWVuZGF0aW9ucyBhYm91dCB0aGUgc2Ft ZQ0KPiAgICAgICAgIGJhc2ljDQo+ICAgICAgICAgPsKgIMKgIMKgcHJvdG9jb2wgaXMNCj4gICAg ICAgICA+wqAgwqAgwqA+Pj4+Pj4gdW4tZ29vZC4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+ DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKgU3VyZSwgYnV0IHdvdWxkbid0IGl0 IGJlIHNpbXBsZXIgdG8gaGF2ZQ0KPiAgICAgICAgIHJmYzUyNDViaXMNCj4gICAgICAgICA+wqAg wqAgwqB1c2luZyBzdHVuYmlzDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKgYW5k IGhhdmUgdGhlbSB1cGRhdGluZyB0aGVpciB0ZXh0LCBtb3JlIHRoYW4NCj4gICAgICAgICBhZGRp bmcgc29tZQ0KPiAgICAgICAgID7CoCDCoCDCoHRvcnR1b3VzDQo+ICAgICAgICAgPsKgIMKgIMKg Pj4+Pj4+PsKgIMKgIMKgdGV4dCBpbiBzdHVuYmlzPw0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+ Pj4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqA+DQo+ICAgICAgICAgPsKgIMKg IMKgPj4+Pj4+PsKgIMKgIMKgPg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoD4+ PsKgIMKgIMKgIFRoZSBTVFVOIHVzYWdlIG11c3Qgc3BlY2lmeSB3aGljaA0KPiAgICAgICAgIHRy YW5zcG9ydA0KPiAgICAgICAgID7CoCDCoCDCoHByb3RvY29sIGlzDQo+ICAgICAgICAgPsKgIMKg IMKgPj4+Pj4+IHVzZWQsIGFuZA0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoD4+ IGhvdw0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoD4+Pj7CoCDCoCDCoCB0aGUg YWdlbnQgZGV0ZXJtaW5lcyB0aGUgSVAgYWRkcmVzcw0KPiAgICAgICAgIGFuZCBwb3J0DQo+ICAg ICAgICAgPsKgIMKgIMKgb2YgdGhlDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+IHJlY2lwaWVu dC4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqA+Pj4+wqAgwqAgwqAgU2VjdGlv biA4IGRlc2NyaWJlcyBhIEROUy1iYXNlZA0KPiAgICAgICAgIG1ldGhvZCBvZg0KPiAgICAgICAg ID7CoCDCoCDCoGRldGVybWluaW5nDQo+ICAgICAgICAgPsKgIMKgIMKgPj4gdGhlDQo+ICAgICAg ICAgPsKgIMKgIMKgPj4+Pj4+IElQDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKg Pj4gYWRkcmVzcw0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoD4+Pj7CoCDCoCDC oCBhbmQgcG9ydCBvZiBhIHNlcnZlciB0aGF0IGEgdXNhZ2UNCj4gICAgICAgICBtYXkgZWxlY3Qg dG8NCj4gICAgICAgICA+wqAgwqAgwqB1c2UuDQo+ICAgICAgICAgPsKgIMKgIMKgPj4gU1RVTg0K PiAgICAgICAgID7CoCDCoCDCoD4+Pj4+PiBtYXkgYmUNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+ Pj4+wqAgwqAgwqA+PiB1c2VkDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKgPj4+ PsKgIMKgIMKgIHdpdGggYW55Y2FzdCBhZGRyZXNzZXMsIGJ1dCBvbmx5DQo+ICAgICAgICAgd2l0 aCBVRFAgYW5kDQo+ICAgICAgICAgPsKgIMKgIMKgaW4gdXNhZ2VzDQo+ICAgICAgICAgPsKgIMKg IMKgPj4+Pj4+IHdoZXJlDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKgPj4+PsKg IMKgIMKgIGF1dGhlbnRpY2F0aW9uIGlzIG5vdCB1c2VkLg0KPiAgICAgICAgID7CoCDCoCDCoD4+ Pj4+Pj7CoCDCoCDCoD4+Pg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoD4+PiBX aHkgdGhpcyByZXN0cmljdGlvbj8gWW91IHNob3VsZCBiZSBhYmxlDQo+ICAgICAgICAgdG8gdXNl DQo+ICAgICAgICAgPsKgIMKgIMKgYW55Y2FzdCB3aXRoDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+ Pj4+IGxvbmctdGVybQ0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoD4+PiBBVVRI IGZvciAoc2F5KSBUVVJOLg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoD4+DQo+ ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKgPj4NCj4gICAgICAgICBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2JlaGF2ZS9jdXJyZW50Lw0KPiAgICAgICAgID7C oCDCoCDCoD4+Pj4+PiBtc2cwMzU4Mi5odG1sDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKg IMKgDQo+ICAgICAgICAgwqA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9i ZWhhdmUvY3VycmVudC8NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+IG1zZzAzNTgyLmh0bWw+DQo+ ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKgPj4NCj4gICAgICAgICA+wqAgwqAgwqA+ Pj4+Pj4+wqAgwqAgwqA+PiBJIHRoaW5rIHRoYXQgdGhlIGRlY2lzaW9uIG9mIHBlcm1pdHRpbmcg QW55Y2FzdA0KPiAgICAgICAgID7CoCDCoCDCoHNob3VsZCBiZSBsZWZ0DQo+ICAgICAgICAgPsKg IMKgIMKgPj4+PiB0bw0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+PiBlYWNoDQo+ICAgICAgICAg PsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKgPj4gU1RVTiBVc2FnZS7CoCBCYXNpYyBTVFVOIFVzYWdl IGRvZXMgbm90IHVzZQ0KPiAgICAgICAgID7CoCDCoCDCoGF1dGhlbnRpY2F0aW9uIGFuZA0KPiAg ICAgICAgID7CoCDCoCDCoD4+Pj4gdXNlDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+IG9ubHkg YQ0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoD4+IG9uZSByb3VuZCB0cmlwIGZv ciB0aGUgQmluZGluZyB0cmFuc2FjdGlvbiwgc28NCj4gICAgICAgICA+wqAgwqAgwqBVbmljYXN0 IGNhbiBiZQ0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+PiB1c2VkLg0KPiAgICAgICAgID7CoCDC oCDCoD4+Pj4+Pj7CoCDCoCDCoD4+DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKg Pg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoD4+IE9UT0gsIFRVUk4gYW5kIElD RSBzaG91bGQgcHJvYmFibHkgc2F5DQo+ICAgICAgICAgc29tZXRoaW5nDQo+ICAgICAgICAgPsKg IMKgIMKgYWJvdXQgdGhhdCwNCj4gICAgICAgICA+wqAgwqAgwqA+PiBzbw0KPiAgICAgICAgID7C oCDCoCDCoD4+Pj4gSQ0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+PiBhZGRlZCBhDQo+ICAgICAg ICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKgPj4gbmV3IGJ1bGxldCBwb2ludCBpbiBTZWN0aW9u IDEzOg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoD4+DQo+ICAgICAgICAgPsKg IMKgIMKgPj4+Pj4+PsKgIMKgIMKgPj7CoCDCoCBvwqAgSWYgQW55Y2FzdCBhZGRyZXNzZXMgY2Fu IGJlIHVzZWQgZm9yDQo+ICAgICAgICAgdGhlIHNlcnZlcg0KPiAgICAgICAgID7CoCDCoCDCoGlu IGNhc2UNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+IFRDUA0KPiAgICAgICAgID7CoCDCoCDCoD4+ Pj4+PiBvcg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoD4+wqAgwqAgwqAgwqBU TFMtb3Zlci1UQ1AsIG9yIGF1dGhlbnRpY2F0aW9uIGFyZSB1c2VkLg0KPiAgICAgICAgID7CoCDC oCDCoD4+Pj4+Pj7CoCDCoCDCoD4+DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKg Pg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoD4gQXJlIHlvdSBsZWF2aW5nIHRo aXMgdGV4dCBpbj8gVGhhdCBzZWVtcw0KPiAgICAgICAgIHZlcnkgY29uZnVzaW5nLg0KPiAgICAg ICAgID7CoCDCoCDCoD4+Pj4+Pj4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqBJ biBpc29sYXRpb24geWVzLCBidXQgSSB0aGluayBpdCBtYWtlcyBzZW5zZQ0KPiAgICAgICAgIHdo aWNoIHRoZSB0ZXh0DQo+ICAgICAgICAgPsKgIMKgIMKgPj4gYmVmb3JlDQo+ICAgICAgICAgPsKg IMKgIMKgPj4+Pj4+PsKgIMKgIMKgdGhlIGJ1bGxldCBwb2ludHM6DQo+ICAgICAgICAgPsKgIMKg IMKgPj4+Pj4+Pg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoCDCoCBBIFNUVU4g dXNhZ2UgZGVmaW5lcyBob3cgU1RVTiBpcyBhY3R1YWxseQ0KPiAgICAgICAgIHV0aWxpemVkIC0t DQo+ICAgICAgICAgPsKgIMKgIMKgd2hlbiB0bw0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4gc2Vu ZA0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoCDCoCByZXF1ZXN0cywgd2hhdCB0 byBkbyB3aXRoIHRoZSByZXNwb25zZXMsDQo+ICAgICAgICAgYW5kIHdoaWNoDQo+ICAgICAgICAg PsKgIMKgIMKgb3B0aW9uYWwNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqAgwqAg cHJvY2VkdXJlcyBkZWZpbmVkIGhlcmUgKG9yIGluIGFuIGV4dGVuc2lvbg0KPiAgICAgICAgIHRv IFNUVU4pDQo+ICAgICAgICAgPsKgIMKgIMKgYXJlIHRvIGJlDQo+ICAgICAgICAgPsKgIMKgIMKg Pj4+Pj4+IHVzZWQuDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKgIMKgIEEgdXNh Z2UgYWxzbyBkZWZpbmVzOg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj4NCj4gICAgICAgICA+ wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqBbLi4uXQ0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj4N Cj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqAgwqAgb8KgIElmIEFueWNhc3QgYWRk cmVzc2VzIGNhbiBiZSB1c2VkIGZvciB0aGUNCj4gICAgICAgICBzZXJ2ZXIgaW4NCj4gICAgICAg ICA+wqAgwqAgwqBjYXNlIFRDUA0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4gb3INCj4gICAgICAg ICA+wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqAgwqAgwqAgwqBUTFMtb3Zlci1UQ1AsIG9yIGF1dGhl bnRpY2F0aW9uIGFyZSB1c2VkLg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj4NCj4gICAgICAg ICA+wqAgwqAgwqA+Pj4+Pj4+DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PiBXaGF0IGlzIHRo ZSBuZWVkIGZvciB0aGUgcmVzdHJpY3Rpb24gYXQgYWxsLg0KPiAgICAgICAgID7CoCDCoCDCoD4+ Pj4+Pj4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+ Pj4+Pg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoD4+Pj7CoCDCoCDCoCB0cmFu c2FjdGlvbiBvdmVyIFVEUCBvcg0KPiAgICAgICAgIERUTFMtb3Zlci1VRFAgaXMgYWxzbw0KPiAg ICAgICAgID7CoCDCoCDCoD4+IGNvbnNpZGVyZWQNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4g ZmFpbGVkIGlmDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKgPj4+PsKgIMKgIMKg IHRoZXJlIGhhcyBiZWVuIGEgaGFyZCBJQ01QIGVycm9yDQo+ICAgICAgICAgW1JGQzExMjJdLsKg IEZvcg0KPiAgICAgICAgID7CoCDCoCDCoD4+IGV4YW1wbGUsDQo+ICAgICAgICAgPsKgIMKgIMKg Pj4+Pj4+IGFzc3VtaW5nDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKgPj4gYW4N Cj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqA+Pj4+wqAgwqAgwqAgUlRPIG9mIDUw MG1zLCByZXF1ZXN0cyB3b3VsZCBiZSBzZW50DQo+ICAgICAgICAgYXQgdGltZXMNCj4gICAgICAg ICA+wqAgwqAgwqAwIG1zLCA1MDANCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4gbXMsIDE1MDAN Cj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqA+PiBtcywNCj4gICAgICAgICA+wqAg wqAgwqA+Pj4+Pj4+wqAgwqAgwqA+Pj4+wqAgwqAgwqAgMzUwMCBtcywgNzUwMCBtcywgMTU1MDAg bXMsIGFuZA0KPiAgICAgICAgIDMxNTAwIG1zLsKgIElmIHRoZQ0KPiAgICAgICAgID7CoCDCoCDC oD4+IGNsaWVudA0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+PiBoYXMgbm90DQo+ICAgICAgICAg PsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKgPj4+PsKgIMKgIMKgIHJlY2VpdmVkIGEgcmVzcG9uc2Ug YWZ0ZXIgMzk1MDAgbXMsDQo+ICAgICAgICAgdGhlIGNsaWVudA0KPiAgICAgICAgID7CoCDCoCDC oHdpbGwNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4gY29uc2lkZXIgdGhlDQo+ICAgICAgICAg PsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKgPj4+PsKgIMKgIMKgIHRyYW5zYWN0aW9uIHRvIGhhdmUg dGltZWQgb3V0Lg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoD4+Pg0KPiAgICAg ICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoD4+PiBJIG5vdGUgdGhhdCB0aGVzZSByZWNvbW1l bmRhdGlvbnMgbm93IHNlZW0NCj4gICAgICAgICBjcmF6aWx5DQo+ICAgICAgICAgPsKgIMKgIMKg bG9uZy4gSQ0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+PiBhc3N1bWUgdGhlDQo+ICAgICAgICAg PsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKgPj4+IFdHIGhhZCBjb25zZW5zdXMgb24gdGhpcywgYnV0 IEkgd2FudGVkIHRvDQo+ICAgICAgICAgbm90ZSBpdC4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+ Pj4+wqAgwqAgwqA+Pg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoD4+IE5vdCBq dXN0IHRoZSBXRywgYWxzbyB0aGUgSUVTRyB0aGF0DQo+ICAgICAgICAgYXBwcm92ZWQgUkZDIDUz ODkNCj4gICAgICAgICA+wqAgwqAgwqB0b28gYXMsDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+PiBi dXQNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4gZm9yIHRoZQ0KPiAgICAgICAgID7CoCDCoCDC oD4+Pj4+Pj7CoCDCoCDCoD4+IGFkZGl0aW9uIG9mICJvciBEVExTLW92ZXItVURQIiwgdGhpcyBp cyB0aGUNCj4gICAgICAgICBzYW1lIHRleHQNCj4gICAgICAgICA+wqAgwqAgwqB0aGFuIGluDQo+ ICAgICAgICAgPsKgIMKgIMKgPj4+PiBSRkMNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4gNTM4 OS4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqA+Pg0KPiAgICAgICAgID7CoCDC oCDCoD4+Pj4+Pj7CoCDCoCDCoD4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqA+ IFllcywgSSBrbm93LiBNeSBwb2ludCBpcyB0aGF0IHdoaWxlIHRoZXkNCj4gICAgICAgICBtaWdo dCBoYXZlIGJlZQ0KPiAgICAgICAgID7CoCDCoCDCoD4+IHNlbnNpYmxlDQo+ICAgICAgICAgPsKg IMKgIMKgPj4+Pj4+IHdoZW4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqA+IDUz ODkgd2FzIHB1Ymxpc2hlZCB0aGV5ICpub3cqIHNlZW0gY3JhemlseQ0KPiAgICAgICAgIGxvbmcu IERpZA0KPiAgICAgICAgID7CoCDCoCDCoHRoZSBXRw0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+ PiBleHBsaWNpdGx5DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKgPiBkZWNpZGUg bm90IHRvIHVwZGF0ZSB0aGVtPw0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj4NCj4gICAgICAg ICA+wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqBObywgbm9ib2R5IGV2ZXIgc3VnZ2VzdGVkIHRoYXQg dGhlcmUgd2FzIGFuDQo+ICAgICAgICAgaXNzdWUgdGhlcmUuDQo+ICAgICAgICAgPsKgIMKgIMKg Pj4+Pj4+Pg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj4NCj4gICAgICAgICA+wqAgwqAgwqA+ Pj4+Pj4+IE9LLCB3ZWxsLCB0aGlzIHNlZW1zIGxpa2UgaXQgc2hvdWxkIGJlIGNvbnNpZGVyZWQs DQo+ICAgICAgICAgdGhlbiwNCj4gICAgICAgICA+wqAgwqAgwqBiZWNhdXNlIHRoaXMNCj4gICAg ICAgICA+wqAgwqAgwqA+Pj4+Pj4+IGRvZXNuJ3QNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+ IG1hdGNoIG1vZGVybiBwcmFjdGljZS4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+DQo+ICAg ICAgICAgPsKgIMKgIMKgPj4+Pj4+Pg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj4NCj4gICAg ICAgICA+wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqA+IFRoaXMgd291bGQgYmUgZ29vZCB0byBleHBs YWluLg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+ Pj4+wqAgwqAgwqBOZXcgdGV4dDoNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+DQo+ICAgICAg ICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKgIMKgIFsuLi5dDQo+ICAgICAgICAgPsKgIMKgIMKg Pj4+Pj4+PsKgIMKgIMKgIMKgIGNvbnRhaW5pbmcgdGhlIHN1YmplY3RBbHROYW1lIG9mIHRoYXQN Cj4gICAgICAgICBjZXJ0aWZpY2F0ZS7CoA0KPiAgICAgICAgID7CoCDCoCDCoFRoZSB0ZXN0DQo+ ICAgICAgICAgPsKgIMKgIMKgPj4gb24NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4gdGhlDQo+ ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKgIMKgIE1FU1NBR0UtSU5URUdSSVRZLVNI QTI1NiBhdHRyaWJ1dGUNCj4gICAgICAgICBpbmRpY2F0ZXMgdGhhdCB0aGUNCj4gICAgICAgICA+ wqAgwqAgwqA+Pj4+IHRyYW5zYWN0aW9uDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+IGlzDQo+ ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKgIMKgIGF1dGhlbnRpY2F0ZWQgYW5kIHRo YXQgdGhlIGNsaWVudA0KPiAgICAgICAgIGltcGxlbWVudHMgdGhpcw0KPiAgICAgICAgID7CoCDC oCDCoD4+IHNwZWNpZmljYXRpb24NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4gYW5kDQo+ICAg ICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKgIMKgIHNvIGNhbiBwcm9jZXNzIHRoZSBBTFRF Uk5BVEUtRE9NQUlOIGF0dHJpYnV0ZS4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+DQo+ICAg ICAgICAgPsKgIMKgIMKgPj4+Pj4+Pg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj4gQWxsIHJp Z2h0Lg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+ Pj4+DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKgPg0KPiAgICAgICAgID7CoCDC oCDCoD4+Pj4+Pj7CoCDCoCDCoD4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqA+ Pj4+wqAgwqAgwqAgb8KgIFdoYXQgYXV0aGVudGljYXRpb24gYW5kDQo+ICAgICAgICAgbWVzc2Fn ZS1pbnRlZ3JpdHkNCj4gICAgICAgICA+wqAgwqAgwqBtZWNoYW5pc21zDQo+ICAgICAgICAgPsKg IMKgIMKgPj4+Pj4+IGFyZSB1c2VkLg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDC oD4+Pj4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqA+Pj4+wqAgwqAgwqAgb8Kg IFRoZSBjb25zaWRlcmF0aW9ucyBhcm91bmQgbWFudWFsIHZzLg0KPiAgICAgICAgID7CoCDCoCDC oGF1dG9tYXRpYyBrZXkNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4gZGVyaXZhdGlvbg0KPiAg ICAgICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoD4+IGZvcg0KPiAgICAgICAgID7CoCDCoCDC oD4+Pj4+Pj7CoCDCoCDCoD4+Pj7CoCDCoCDCoCDCoCDCoHRoZSBpbnRlZ3JpdHkgbWVjaGFuaXNt LCBhcw0KPiAgICAgICAgIGRpc2N1c3NlZCBpbg0KPiAgICAgICAgID7CoCDCoCDCoFtSRkM0MTA3 XS4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqA+Pj4+DQo+ICAgICAgICAgPsKg IMKgIMKgPj4+Pj4+PsKgIMKgIMKgPj4+PsKgIMKgIMKgIG/CoCBXaGF0IG1lY2hhbmlzbXMgYXJl IHVzZWQgdG8NCj4gICAgICAgICBkaXN0aW5ndWlzaCBTVFVODQo+ICAgICAgICAgPsKgIMKgIMKg Pj4gbWVzc2FnZXMNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4gZnJvbSBvdGhlcg0KPiAgICAg ICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoD4+Pg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+ Pj7CoCDCoCDCoD4+PiBXaHkgaXMgdGhpcyByZXF1aXJlZD8gSXQgc2VlbXMgbGlrZSB0aGF0J3MN Cj4gICAgICAgICBhIGdlbmVyaWMNCj4gICAgICAgICA+wqAgwqAgwqBTVFVODQo+ICAgICAgICAg PsKgIMKgIMKgPj4+Pj4+IGZlYXR1cmUuDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKg IMKgPj4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqA+PiBUaGF0IHRleHQgaXMg aWRlbnRpY2FsIHRvIHRoZSB0ZXh0IGluIFJGQw0KPiAgICAgICAgIDUzODkuwqAgUkZDDQo+ICAg ICAgICAgPsKgIMKgIMKgNTc2NC83OTgzDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+PiBpcw0KPiAg ICAgICAgID7CoCDCoCDCoD4+Pj4+PiBvbmUgc3VjaA0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+ Pj7CoCDCoCDCoD4+IG1lY2hhbmlzbSwgYnV0IHRoZXJlIGlzIG5vdGhpbmcgdGhhdA0KPiAgICAg ICAgIHByZXZlbnQgYW5vdGhlcg0KPiAgICAgICAgID7CoCDCoCDCoHByb3RvY29sDQo+ICAgICAg ICAgPsKgIMKgIMKgPj4+Pj4+IHN0YWNrIHRvIHVzZQ0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+ Pj7CoCDCoCDCoD4+IGEgZGlmZmVyZW50IG1lY2hhbmlzbSAoaW5mZXJlbmNlLCBzaGltLCBldGMu Li4pDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKgPj4NCj4gICAgICAgICA+wqAg wqAgwqA+Pj4+Pj4+wqAgwqAgwqA+DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKg PiBCdXQgdWx0aW1hdGVseSBubyBtYXR0ZXIgd2hhdCB0aGUgb3RoZXIgcHJvdG9jb2wNCj4gICAg ICAgICA+wqAgwqAgwqBwcm92aWRlcyBmb3INCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4gZGVt dXgsIFNUVU4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqA+IGhhcyBpdHMNCj4g ICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqA+IG93biBkZW11eC4NCj4gICAgICAgICA+ wqAgwqAgwqA+Pj4+Pj4+DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKgSW4gZmFj dCBJIHRoaW5rIHRoYXQgdGhlIHJlYXNvbiBmb3IgdGhhdCBpdGVtDQo+ICAgICAgICAgd2FzIGJl Y2F1c2UNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqBGSU5HRVJQUklOVCBjYW4g YWxzbyBiZSB1c2VkIHRvIGRlbXV4IFNUVU4NCj4gICAgICAgICB0cmFmZmljLCBidXQNCj4gICAg ICAgICA+wqAgwqAgwqBpdCBpcw0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoG9w dGlvbmFsLsKgIFNvIGFuIFNUVU4gVXNhZ2UgbmVlZHMgdG8gdGVsbCBpZg0KPiAgICAgICAgIEZJ TkdFUlBSSU5UIGlzDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKgbWFuZGF0b3J5 IChsaWtlIGluIElDRSkuDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+Pg0KPiAgICAgICAgID7C oCDCoCDCoD4+Pj4+Pj4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+IFRoaXMgc2hvdWxkIGJl IGV4cGxhaW5lZC4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+DQo+ICAgICAgICAgPsKgIMKg IMKgPj4+Pj4+Pg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoD4+Pg0KPiAgICAg ICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoD4+Pj7CoCDCoCDCoCB0aGF0IGlzIG5vdCByZWFk aWx5IHN1YmplY3QgdG8NCj4gICAgICAgICBvZmZsaW5lIGRpY3Rpb25hcnkNCj4gICAgICAgICA+ wqAgwqAgwqA+Pj4+IGF0dGFja3MuDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKg Pj4+PsKgIMKgIMKgIFByb3RlY3Rpb24gb2YgdGhlIGNoYW5uZWwgaXRzZWxmLA0KPiAgICAgICAg IHVzaW5nIFRMUyBvcg0KPiAgICAgICAgID7CoCDCoCDCoERUTFMsDQo+ICAgICAgICAgPsKgIMKg IMKgPj4+Pj4+IG1pdGlnYXRlcw0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoD4+ IHRoZXNlDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKgPj4+PsKgIMKgIMKgIGF0 dGFja3MuDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKgPj4+Pg0KPiAgICAgICAg ID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoD4+Pj7CoCDCoCDCoCBTVFVOIHN1cHBvcnRzIGJvdGgg TUVTU0FHRS1JTlRFR1JJVFkgYW5kDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKg TUVTU0FHRS1JTlRFR1JJVFktU0hBMjU2LA0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDC oCDCoD4+Pj7CoCDCoCDCoCB3aGljaCBpcyBzdWJqZWN0IHRvIGJpZCBkb3duIGF0dGFja3MNCj4g ICAgICAgICBieSBhbiBvbi1wYXRoDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+IGF0dGFja2Vy Lg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoD4+Pg0KPiAgICAgICAgID7CoCDC oCDCoD4+Pj4+Pj7CoCDCoCDCoD4+PiBCeSBhbiBvbi1wYXRoIGF0dGFja2VyIHdobyBjYW4gZm9y Z2UNCj4gICAgICAgICBITUFDLVNIQTEgaW4NCj4gICAgICAgICA+wqAgwqAgwqByZWFsLXRpbWU/ DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKgVGhhdCdzIGENCj4gICAgICAgICA+ wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqA+Pj4gcHJldHR5IHNlcmlvdXMgYWR2ZXJzYXJ5LCBzbyB5 b3Ugc2hvdWxkDQo+ICAgICAgICAgY2xhcmlmeSBoZXJlDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+ Pj4+PsKgIMKgIMKgPj4+DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKgPj4NCj4g ICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqA+PiBOZXcgdGV4dDoNCj4gICAgICAgICA+ wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqA+Pg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDC oCDCoD4+wqAgwqAgU1RVTiBzdXBwb3J0cyBib3RoIE1FU1NBR0UtSU5URUdSSVRZIGFuZA0KPiAg ICAgICAgID7CoCDCoCDCoD4+Pj4+PiBNRVNTQUdFLUlOVEVHUklUWS1TSEEyNTYsDQo+ICAgICAg ICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKgPj7CoCDCoCB3aGljaCBpcyBzdWJqZWN0IHRvIGJp ZCBkb3duIGF0dGFja3MgYnkNCj4gICAgICAgICBhbiBvbi1wYXRoDQo+ICAgICAgICAgPsKgIMKg IMKgYXR0YWNrZXINCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4gdGhhdA0KPiAgICAgICAgID7C oCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoD4+wqAgwqAgd291bGQgc3RyaXAgdGhlIE1FU1NBR0UtSU5U RUdSSVRZLVNIQTI1Ng0KPiAgICAgICAgIGF0dHJpYnV0ZQ0KPiAgICAgICAgID7CoCDCoCDCoGxl YXZpbmcNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqBvbmx5IHRoZQ0KPiAgICAg ICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoD4+wqAgwqAgTUVTU0FHRS1JTlRFR1JJVFkgYXR0 cmlidXRlIGFuZA0KPiAgICAgICAgIGV4cGxvaXRpbmcgYSBwb3RlbnRpYWwNCj4gICAgICAgICA+ wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqB2dWxuZXJhYmlsaXR5Lg0KPiAgICAgICAgID7CoCDCoCDC oD4+Pj4+Pj7CoCDCoCDCoD4+wqAgwqAgUHJvdGVjdGlvbiBvZiB0aGUgY2hhbm5lbCBpdHNlbGYs IHVzaW5nDQo+ICAgICAgICAgVExTIG9yIERUTFMsDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+PiBt aXRpZ2F0ZXMNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqB0aGVzZQ0KPiAgICAg ICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoD4+wqAgwqAgYXR0YWNrcy7CoCBUaW1lbHkgcmVt b3ZhbCBvZiB0aGUgc3VwcG9ydCBvZg0KPiAgICAgICAgID7CoCDCoCDCoD4+IE1FU1NBR0UtSU5U RUdSSVRZDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+IGluIGENCj4gICAgICAgICA+wqAgwqAg wqA+Pj4+Pj4+wqAgwqAgwqA+PsKgIMKgIGZ1dHVyZSB2ZXJzaW9uIG9mIFNUVU4gaXMgbmVjZXNz YXJ5Lg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoD4+DQo+ICAgICAgICAgPsKg IMKgIMKgPj4+Pj4+PsKgIMKgIMKgPg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDC oD4gSSBzdGlsbCBkb24ndCB1bmRlcnN0YW5kIHRoZSBjYXBhYmlsaXRpZXMNCj4gICAgICAgICB5 b3Ugc2VlbSB0bw0KPiAgICAgICAgID7CoCDCoCDCoGJlbGlldmUNCj4gICAgICAgICA+wqAgwqAg wqA+PiB0aGUNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqBhdHRhY2tlcg0KPiAg ICAgICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoD4gaGFzLg0KPiAgICAgICAgID7CoCDCoCDC oD4+Pj4+Pj7CoCDCoCDCoD4gQ2FuIHlvdSBkZXNjcmliZSB0aGUgZXhhY3QgYXR0YWNrLg0KPiAg ICAgICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoD4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+ Pj4+DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKgMS4gVnVsbmVyYWJpbGl0eSBp cyBmb3VuZCBpbiBITUFDLVNIQTENCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqAy LiBDbGllbnQgQWxpY2Ugc3RpbGwgc3VwcG9ydHMgTS1JIGFuZA0KPiAgICAgICAgIE0tSS0yNTYs IGRvZXMgbm90DQo+ICAgICAgICAgPsKgIMKgIMKga25vdw0KPiAgICAgICAgID7CoCDCoCDCoD4+ IHdoYXQNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+wqAgwqAgwqB2ZXJzaW9uIG9mIFNUVU4g c2VydmVyIEJvYiBzdXBwb3J0cyBhbmQgc28NCj4gICAgICAgICBzZW5kIGJvdGguDQo+ICAgICAg ICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKgMy4gT24tcGF0aCBhdHRhY2tlciByZW1vdmVzIE0t SS0yNTYuDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKgIMKgNS4gc3R1bmJpcyBzZXJ2 ZXIgQm9iIHRoaW5rcyB0aGF0IEFsaWNlIGlzIGFuDQo+ICAgICAgICAgUkZDIDUzODkNCj4gICAg ICAgICA+wqAgwqAgwqBjbGllbnQgYW5kDQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+PsKgIMKg IMKgY29udGludWUgd2l0aCB0aGF0IHByb3RvY29sLg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+ Pj4NCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+DQo+ICAgICAgICAgPsKgIMKgIMKgPj4+Pj4+ PiBUaGlzIHNlZW1zIGxpa2UgYW4gZXh0cmVtZWx5IHdlYWsgYXR0YWNrLiBJbg0KPiAgICAgICAg IGdlbmVyYWwsIGFueQ0KPiAgICAgICAgID7CoCDCoCDCoHByb3RvY29sIG9mDQo+ICAgICAgICAg PsKgIMKgIMKgPj4+Pj4+PiB0aGlzIHR5cGUgaXMgYXMgc3Ryb25nDQo+ICAgICAgICAgPsKgIMKg IMKgPj4+Pj4+PiBhcyB0aGUgd2Vha2VzdCBpbnRlZ3JpdHkgYWxnb3JpdGhtIGl0IHN1cHBvcnRz LCBzbw0KPiAgICAgICAgIGl0J3Mgbm90DQo+ICAgICAgICAgPsKgIMKgIMKgdGhhdCB0aGUNCj4g ICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+IHByb3RvY29sIGhhcyBhIGRvd25ncmFkZQ0KPiAgICAg ICAgID7CoCDCoCDCoD4+Pj4+Pj4gYXR0YWNrLCBidXQgcmF0aGVyIHRoYXQgdGhlIG1pbmltdW0g YWxnb3JpdGhtDQo+ICAgICAgICAgc3VwcG9ydGVkIGlzDQo+ICAgICAgICAgPsKgIMKgIMKgb25l IHlvdQ0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4gZG9uJ3QNCj4gICAgICAgICA+wqAgwqAgwqA+ Pj4+Pj4+IHRydXN0IGFzIG11Y2gNCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+IGFzIHlvdSBt aWdodCBsaWtlLg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj4NCj4gICAgICAgICA+wqAgwqAg wqA+Pj4+Pj4+IC1Fa3INCj4gICAgICAgICA+wqAgwqAgwqA+Pj4+Pj4+DQo+ICAgICAgICAgPsKg IMKgIMKgPj4+Pj4+Pg0KPiAgICAgICAgID7CoCDCoCDCoD4+Pj4+Pj7CoCDCoCDCoC0tDQo+ICAg ICAgICAgPsKgIMKgIMKgPj4NCj4gICAgICAgICA+DQo+ICAgICAgICAgPg0KPiAgICAgICAgID4N Cj4gICAgICAgICA+wqAgwqAgwqAtLQ0KPiAgICAgICAgID7CoCDCoCDCoE1hcmMgUGV0aXQtSHVn dWVuaW4NCj4gICAgICAgICA+wqAgwqAgwqBFbWFpbDogbWFyY0BwZXRpdC1odWd1ZW5pbi5vcmcN Cj4gICAgICAgICA8bWFpbHRvOm1hcmNAcGV0aXQtaHVndWVuaW4ub3JnPiA8bWFpbHRvOm1hcmNA cGV0aXQtaHVndWVuaW4ub3JnDQo+ICAgICAgICAgPG1haWx0bzptYXJjQHBldGl0LWh1Z3Vlbmlu Lm9yZz4+DQo+ICAgICAgICAgPsKgIMKgIMKgQmxvZzogaHR0cHM6Ly9tYXJjLnBldGl0LWh1Z3Vl bmluLm9yZw0KPiAgICAgICAgID7CoCDCoCDCoFByb2ZpbGU6IGh0dHBzOi8vd3d3LmxpbmtlZGlu LmNvbS9pbi9wZXRpdGh1Zw0KPiAgICAgICAgID4NCj4gDQo= From nobody Fri Nov 23 05:28:08 2018 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5244F12F1A2; Fri, 23 Nov 2018 05:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.16 X-Spam-Level: X-Spam-Status: No, score=-19.16 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=logmein.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 BXMyoZF9cM-K; Fri, 23 Nov 2018 05:27:55 -0800 (PST) Received: from mx0b-001a0901.pphosted.com (mx0a-001a0901.pphosted.com [67.231.144.179]) (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 D173212E043; Fri, 23 Nov 2018 05:27:55 -0800 (PST) Received: from pps.filterd (m0074903.ppops.net [127.0.0.1]) by mx0a-001a0901.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id wANDNOY6009202; Fri, 23 Nov 2018 08:27:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=logmein.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=email; bh=aBBuHA6RyzpCyaoyrYiNsREkM1d5s5V48GwAXiv+h1U=; b=O3LqxMKNg7WNQrUGq8vJDLj1mo4lX0PTjCCIaejO37gFteT7TvxCb+ta+ZRzB1Fkn6Ul 8gSsa6ZkZer4dysfe0GUd6Xio7xhHK6fImaDCCuEbM6wvLZjBmLzXU+d6jsa+jsOwteH IVXeA/9g2MtS0GX9TTlZjxLJxKTpglyQy60= Received: from nam04-sn1-obe.outbound.protection.outlook.com (mail-sn1nam04lp0087.outbound.protection.outlook.com [216.32.180.87]) by mx0a-001a0901.pphosted.com with ESMTP id 2ntd6dfdq3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 23 Nov 2018 08:27:51 -0500 Received: from MWHPR15MB1200.namprd15.prod.outlook.com (10.175.2.142) by MWHPR15MB1695.namprd15.prod.outlook.com (10.175.142.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1339.21; Fri, 23 Nov 2018 13:27:47 +0000 Received: from MWHPR15MB1200.namprd15.prod.outlook.com ([fe80::190:b8da:412e:8be2]) by MWHPR15MB1200.namprd15.prod.outlook.com ([fe80::190:b8da:412e:8be2%4]) with mapi id 15.20.1339.031; Fri, 23 Nov 2018 13:27:47 +0000 From: Simon Perreault To: Spencer Dawkins at IETF , Adam Roach CC: IESG , "tram-chairs@ietf.org" , "draft-ietf-tram-stun-pmtud@ietf.org" , Gonzalo Camarillo , "Asveren, Tolga" , "tram@ietf.org" Thread-Topic: Adam Roach's Discuss on draft-ietf-tram-stun-pmtud-10: (with DISCUSS and COMMENT) Thread-Index: AQHUWQNKbxGEYwDhVEaOcLCOF8V9tqVX4rYAgAV4EwA= Date: Fri, 23 Nov 2018 13:27:46 +0000 Message-ID: References: <153834237082.13405.1228259718885034461.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [69.156.197.18] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1695; 6:sjwkj09alFRI4QvqprMrW1qADtt2/+41OxqXMxDKvYpphtbVgmfl6T5Nwg/03vOLeXrimJ3zGOgmqJgESrTsVgPS4RdZymCdZ+5FLN3nouXu+CPcs+di3MjXw8ljFpi+4U4aKGPmQnei3PokUKl52wI+dhXE4pxDHvfb+EiDsbOncaIsezPEmem98CjfZASzbVQ1blfZAU/zcmLLJMv5XHFMyU7dy4z7bkgRE/mXDTwihNiY2Go22RPQiKD0jnLY4HpA5PjVVrpStnrZfymouoRGDw75PA6WNbxJrlukbSAIS2XiRYvOAT0TviN/ZreBpvzlI0R6zMRwIr4uoAJYy1nNR1HKYp/VLlQurEnV/pQrtjPmVqI/oYff07bROZdDlXsyRoymwL2dyHfVlWAzPla3bHSJ7JfI+0Lxl2IVkNT05advpPQK45dCHzTid2xCIFm3Ufxyos7NkgeY6M/oeg==; 5:eAxbYS9T/2W4UsYG95gNt+gqt7pKM1uOwe8iZaRtyzytJd79Tzq5tZwe2z4lR5IIarAPSCArV6jh6e+2hB+WjQPhiTpJ5s04NFBg/sEvd1EbhkX4PzTH3QoE6eW5XML0fe1FjpH/XLNHbZKXk0Ac7qq/ThmbCt0E3uMh5zbbvLg=; 7:FZcPy9VK3gB9AsI+dhyD3NKIVLn6dIwqU1RBOv/gJmDXHPBSs/a/Y6RB7SaUIEq1TTjHbEEvkQA//PU0Hizz7Jenj2Gh5ZpmAgOR5cmLb+T3C9gU3N1dY90asrnUQ6toGrAXUvd0rFaDm/Fovsd60A== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 42250aae-5b76-4e8c-813e-08d65147752e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:MWHPR15MB1695; x-ms-traffictypediagnostic: MWHPR15MB1695: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231442)(944501410)(52105112)(10201501046)(3002001)(148016)(149066)(150057)(6041310)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:MWHPR15MB1695; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1695; x-forefront-prvs: 086597191B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(346002)(376002)(396003)(136003)(189003)(199004)(78642003)(478694002)(71200400001)(71190400001)(7736002)(6246003)(36756003)(6436002)(256004)(14444005)(3846002)(83716004)(6116002)(8936002)(476003)(110136005)(39060400002)(486006)(68736007)(2616005)(316002)(54906003)(53936002)(4326008)(33656002)(2906002)(66066001)(76176011)(6486002)(446003)(99286004)(11346002)(81156014)(8676002)(6512007)(81166006)(54896002)(6306002)(86362001)(82746002)(508600001)(105586002)(106356001)(2900100001)(25786009)(97736004)(14454004)(72206003)(102836004)(26005)(229853002)(186003)(6506007)(5660300001)(69594002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1695; H:MWHPR15MB1200.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: logmein.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: KlUC6pTlmZ3/BSNKoV93ER7MyxQTOOt/VUrINtJAcKbqhea9zbVgQRHX2GujWeJMUHkHq71sXm2bTHU5iTT0Fzr01L3+//yu/eCmUIQkQIbQ0oEyybnFkPcYqZIF357+5FAiPr1Kn48Babqc2szrGC4DzR0PhOf4MsQGaeyHXQMgQJj+iwDPJQ+U76JhrUfrri8Y30+NzilZ5pbq+s+Wdy4uOwbFL+/wM+oJYyCHlbTIZtJshkZ4bX7izf1gbm2D9tGc6VOH+MLFx/KexFjq46huLMMp0jg422auMee32qVpMpPZruNx1V7jdMUbjSZdc/9LrRfNrJ8BoM0ii/PSXmrAMJHZEj8kRMJbvJsrm74= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CA447D152E6543409FF54700A53335EDlogmeincom_" MIME-Version: 1.0 X-OriginatorOrg: logmein.com X-MS-Exchange-CrossTenant-Network-Message-Id: 42250aae-5b76-4e8c-813e-08d65147752e X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2018 13:27:46.8952 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84c4e5b0-26a0-4dac-b686-301d76713569 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1695 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-23_09:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [tram] Adam Roach's Discuss on draft-ietf-tram-stun-pmtud-10: (with DISCUSS and COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 23 Nov 2018 13:27:59 -0000 --_000_CA447D152E6543409FF54700A53335EDlogmeincom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KRElTQ1VTUzoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGhpcyBzZWVtcyBsaWtl IGFuIGludGVyZXN0aW5nIHRlY2huaXF1ZSB0aGF0IHdhcnJhbnRzIGNvbGxlY3Rpb24gb2Ygb3Bl cmF0aW9uYWwNCmV4cGVyaWVuY2UuDQoNCj5Gcm9tIGEgcHJvY2VzcyBwZXJzcGVjdGl2ZSwgSSB0 aGluayB3ZSBoYXZlIGEgYml0IG9mIGFuIGlzc3VlLCB1bmxlc3MgSSd2ZQ0Kb3Zlcmxvb2tlZCBz b21ldGhpbmcgcmVsZXZhbnQuIFRoaXMgaXMgcHJvcG9zZWQgYXMgYSBTdGFuZGFyZHMtVHJhY2sg ZG9jdW1lbnQsDQpidXQgaXQgcmVsaWVzIG9uIHRoZSB1c2Ugb2YgdGhlIFBBRERJTkcgYXR0cmli dXRlIGRlZmluZWQgaW4gUkZDIDU3ODAuIFJGQw0KNTc4MCBpcyBFeHBlcmltZW50YWwsIHNvIHRo aXMgaXMgYSBmb3JtYWwgZG93bnJlZi4gQW5kIFJGQyA1NzgwIGRvZXMgbm90DQphcHBlYXIgaW4g dGhlIGRvd25yZWYgcmVnaXN0cnkgWzFdLCBub3IgZGlkIHRoZSBJRVRGIGxhc3QgY2FsbCBbMl0g aW5jbHVkZSBhDQpyZXF1ZXN0IHRoYXQgdGhlIElFVEYgY29tbXVuaXR5IGNvbnNpZGVyIGFsbG93 aW5nIHN1Y2ggYSByZWZlcm5jZS4NCg0KPkZyb20gYSBwcmFjdGljYWwgcGVyc3BlY3RpdmUsIHRo ZSBtZWNoYW5pc20gZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQgc2VlbXMNCmxpa2UgdGhlIGtp bmQgb2YgdGhpbmcgdGhhdCBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gZ2F0aGVyIG9wZXJhdGlvbmFs IGV4cGVyaWVuY2UNCndpdGggcHJpb3IgdG8gcHV0dGluZyBpdCBvbiB0aGUgc3RhbmRhcmRzIHRy YWNrLiBJIGhhdmUgc29tZSBvcGVyYXRpb25hbA0KY29uY2VybnMgKGRlc2NyaWJlZCBiZWxvdykg dGhhdCBJIHRoaW5rIGNvdWxkIGJlIGVpdGhlciBwcm92ZW4gb3V0IG9yIGRpc3BlbGxlZA0KYnkg ZXhwZXJpbWVudGFsIGRlcGxveW1lbnQgb2YgdGhlIHRlY2hub2xvZ3kuDQoNCk15IHJlY29tbWVu ZGF0aW9uIGlzIHRvIHJlY2F0ZWdvcml6ZSB0aGlzIG1lY2hhbmlzbSBhcyBleHBlcmltZW50YWws IGFkZGluZyBzb21lDQp0ZXh0IGFib3V0IHRoZSBkZXNpcmUgdG8gZ2F0aGVyIG9wZXJhdGlvbmFs IGV4cGVyaWVuY2UuDQoNCkZvciBhdm9pZGFuY2Ugb2YgZG91YnQ6IE15IERJU0NVU1MgaXMgb25s eSBvbiB0aGUgcHJvY2VzcyBpc3N1ZSwgYW5kIEknbGwNCmhhcHBpbHkgY2xlYXIgcmVnYXJkbGVz cyBvZiBob3cgdGhpcyBpc3N1ZSBpcyByYXRpb25hbGl6ZWQgKGUuZy4sIGVpdGhlciBieQ0KcnVu bmluZyBJRVRGIGxhc3QgY2FsbCBhZ2FpbiwgYnkgcmVjbGFzc2lmeWluZyB0aGlzIG1lY2hhbmlz bSBhcyBleHBlcmltZW50YWwsDQpvciBwZXJoYXBzIHNvbWUgbm92ZWwgc29sdXRpb24gdGhhdCBJ IG1heSBub3QgaGF2ZSB0aG91Z2h0IG9mKS4gRXZlcnl0aGluZw0KZWxzZSBpcyBtZXJlbHkgYSBy ZWNvbW1lbmRhdGlvbi4NCg0KSSBkb24ndCB0aGluayBJJ3ZlIHNlZW4gYSBzcGVjaWZpYyByZXNw b25zZSB0byBBZGFtJ3MgcG9pbnQgaGVyZSwgd2hpY2ggSSBiZWxpZXZlIGlzIHRoYXQgb25lIG9m IChhdCBsZWFzdCkgdGhyZWUgdGhpbmdzIHNob3VsZCBoYXBwZW4gLQ0KDQotIGEgc2Vjb25kIExh c3QgQ2FsbCwgZXhwbGljaXRseSBjYWxsaW5nIG91dCB0aGlzIGRvd25yZWYsIE9SDQoNCi0gYXBw cm92YWwgYXMgYW4gRXhwZXJpbWVudGFsIFJGQywgd2hpY2ggbWFrZXMgdGhlIGRvd25yZWYgaXNz dWUgZ28gYXdheSwgT1INCg0KLSAoYW5kIHRoaXMgZGlkbid0IGhhcHBlbiBpbiB0aGlzIHRocmVh ZCwgYnV0IGluIHNvbWUgY29udmVyc2F0aW9uLCBJIHJlbWVtYmVyIHRoYXQpIEFkYW0gd29uZGVy ZWQgaWYgcmV1c2luZyB0aGUgUEFERElORyBhdHRyaWJ1dGUgd2FzIHRoZSByaWdodCB0aGluZyB0 byBkbyAoYW5kIHRoYXQgd2FzIGEgcXVlc3Rpb24sIG5vdCBhIGNvbmNlcm4sIGJ1dCByZWxldmFu dCBoZXJlLCBzaW5jZSBpZiB0aGlzIGRvY3VtZW50IGRlZmluZWQgaXRzIG93biBhdHRyaWJ1dGUs IHRoZSBkb3ducmVmIHdvdWxkIGFsc28gZ28gYXdheSkuDQoNCkFueSB0aG91Z2h0cyBvbiB0aGlz Pw0KDQpTcGVuY2VyLCBBZGFtLA0KDQpJIHNlZSBhbiBlYXN5IGZvdXJ0aCBvcHRpb246DQoNCi0g UHVsbCB0aGUgZGVmaW5pdGlvbiBvZiBQQURESU5HIGludG8gdGhpcyBkb2N1bWVudC4gRGVjbGFy ZSB0aGF0IHdlJ3ZlIGdhdGhlcmVkIHN1ZmZpY2llbnQgZXhwZXJpZW5jZSB3aXRoIFBBRERJTkcg dGhhdCBpdCBub3cgd2FycmFudHMgYmVpbmcgZWxldmF0ZWQgdG8gU3RhbmRhcmRzIFRyYWNrLiBU aGF0IGlzLCBpdCdzIGJlZW4gcHJvdmVuIHRvIHdvcmsuDQoNCknigJltIGZpbmUgd2l0aCB3aGF0 ZXZlciwgZm9yIHRoZSByZWNvcmQuDQoNClNpbW9uDQo= --_000_CA447D152E6543409FF54700A53335EDlogmeincom_ Content-Type: text/html; charset="utf-8" Content-ID: <4A089B3F899FEB41BF5167E714B488F0@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIu MHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSLUNBIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCkRJU0NVU1M6PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4N Cjxicj4NClRoaXMgc2VlbXMgbGlrZSBhbiBpbnRlcmVzdGluZyB0ZWNobmlxdWUgdGhhdCB3YXJy YW50cyBjb2xsZWN0aW9uIG9mIG9wZXJhdGlvbmFsPGJyPg0KZXhwZXJpZW5jZS48YnI+DQo8YnI+ DQo8L3NwYW4+Jmd0O0Zyb20gYSBwcm9jZXNzIHBlcnNwZWN0aXZlLCBJIHRoaW5rIHdlIGhhdmUg YSBiaXQgb2YgYW4gaXNzdWUsIHVubGVzcyBJJ3ZlPGJyPg0Kb3Zlcmxvb2tlZCBzb21ldGhpbmcg cmVsZXZhbnQuIFRoaXMgaXMgcHJvcG9zZWQgYXMgYSBTdGFuZGFyZHMtVHJhY2sgZG9jdW1lbnQs PGJyPg0KYnV0IGl0IHJlbGllcyBvbiB0aGUgdXNlIG9mIHRoZSBQQURESU5HIGF0dHJpYnV0ZSBk ZWZpbmVkIGluIFJGQyA1NzgwLiBSRkM8YnI+DQo1NzgwIGlzIEV4cGVyaW1lbnRhbCwgc28gdGhp cyBpcyBhIGZvcm1hbCBkb3ducmVmLiBBbmQgUkZDIDU3ODAgZG9lcyBub3Q8YnI+DQphcHBlYXIg aW4gdGhlIGRvd25yZWYgcmVnaXN0cnkgWzFdLCBub3IgZGlkIHRoZSBJRVRGIGxhc3QgY2FsbCBb Ml0gaW5jbHVkZSBhPGJyPg0KcmVxdWVzdCB0aGF0IHRoZSBJRVRGIGNvbW11bml0eSBjb25zaWRl ciBhbGxvd2luZyBzdWNoIGEgcmVmZXJuY2UuPGJyPg0KPGJyPg0KJmd0O0Zyb20gYSBwcmFjdGlj YWwgcGVyc3BlY3RpdmUsIHRoZSBtZWNoYW5pc20gZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQg c2VlbXM8YnI+DQpsaWtlIHRoZSBraW5kIG9mIHRoaW5nIHRoYXQgaXQgd291bGQgYmUgdXNlZnVs IHRvIGdhdGhlciBvcGVyYXRpb25hbCBleHBlcmllbmNlPGJyPg0Kd2l0aCBwcmlvciB0byBwdXR0 aW5nIGl0IG9uIHRoZSBzdGFuZGFyZHMgdHJhY2suIEkgaGF2ZSBzb21lIG9wZXJhdGlvbmFsPGJy Pg0KY29uY2VybnMgKGRlc2NyaWJlZCBiZWxvdykgdGhhdCBJIHRoaW5rIGNvdWxkIGJlIGVpdGhl ciBwcm92ZW4gb3V0IG9yIGRpc3BlbGxlZDxicj4NCmJ5IGV4cGVyaW1lbnRhbCBkZXBsb3ltZW50 IG9mIHRoZSB0ZWNobm9sb2d5Ljxicj4NCjxicj4NCk15IHJlY29tbWVuZGF0aW9uIGlzIHRvIHJl Y2F0ZWdvcml6ZSB0aGlzIG1lY2hhbmlzbSBhcyBleHBlcmltZW50YWwsIGFkZGluZyBzb21lPGJy Pg0KdGV4dCBhYm91dCB0aGUgZGVzaXJlIHRvIGdhdGhlciBvcGVyYXRpb25hbCBleHBlcmllbmNl Ljxicj4NCjxicj4NCkZvciBhdm9pZGFuY2Ugb2YgZG91YnQ6IE15IERJU0NVU1MgaXMgb25seSBv biB0aGUgcHJvY2VzcyBpc3N1ZSwgYW5kIEknbGw8YnI+DQpoYXBwaWx5IGNsZWFyIHJlZ2FyZGxl c3Mgb2YgaG93IHRoaXMgaXNzdWUgaXMgcmF0aW9uYWxpemVkIChlLmcuLCBlaXRoZXIgYnk8YnI+ DQpydW5uaW5nIElFVEYgbGFzdCBjYWxsIGFnYWluLCBieSByZWNsYXNzaWZ5aW5nIHRoaXMgbWVj aGFuaXNtIGFzIGV4cGVyaW1lbnRhbCw8YnI+DQpvciBwZXJoYXBzIHNvbWUgbm92ZWwgc29sdXRp b24gdGhhdCBJIG1heSBub3QgaGF2ZSB0aG91Z2h0IG9mKS4gRXZlcnl0aGluZzxicj4NCmVsc2Ug aXMgbWVyZWx5IGEgcmVjb21tZW5kYXRpb24uPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzUuNHB0Ij5JIGRvbid0IHRoaW5rIEkndmUgc2VlbiBhIHNwZWNpZmljIHJlc3BvbnNl IHRvIEFkYW0ncyBwb2ludCBoZXJlLCB3aGljaCBJIGJlbGlldmUgaXMgdGhhdCBvbmUgb2YgKGF0 IGxlYXN0KSB0aHJlZSB0aGluZ3Mgc2hvdWxkIGhhcHBlbiAtPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPi0gYSBzZWNvbmQgTGFzdCBDYWxsLCBleHBs aWNpdGx5IGNhbGxpbmcgb3V0IHRoaXMgZG93bnJlZiwgT1I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+LSBhcHByb3ZhbCBhcyBhbiBFeHBlcmltZW50 YWwgUkZDLCB3aGljaCBtYWtlcyB0aGUgZG93bnJlZiBpc3N1ZSBnbyBhd2F5LCBPUjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM1LjRwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij4tIChhbmQgdGhpcyBk aWRuJ3QgaGFwcGVuIGluIHRoaXMgdGhyZWFkLCBidXQgaW4gc29tZSBjb252ZXJzYXRpb24sIEkg cmVtZW1iZXIgdGhhdCkgQWRhbSB3b25kZXJlZCBpZiByZXVzaW5nIHRoZSBQQURESU5HIGF0dHJp YnV0ZSB3YXMgdGhlIHJpZ2h0IHRoaW5nIHRvIGRvIChhbmQgdGhhdCB3YXMgYSBxdWVzdGlvbiwg bm90IGEgY29uY2VybiwgYnV0IHJlbGV2YW50DQogaGVyZSwgc2luY2UgaWYgdGhpcyBkb2N1bWVu dCBkZWZpbmVkIGl0cyBvd24gYXR0cmlidXRlLCB0aGUgZG93bnJlZiB3b3VsZCBhbHNvIGdvIGF3 YXkpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij5B bnkgdGhvdWdodHMgb24gdGhpcz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPlNwZW5jZXIsIEFkYW0sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIHNlZSBhbiBlYXN5IGZv dXJ0aCBvcHRpb246PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4tIFB1bGwgdGhlIGRlZmluaXRpb24gb2Yg UEFERElORyBpbnRvIHRoaXMgZG9jdW1lbnQuIERlY2xhcmUgdGhhdCB3ZSd2ZSBnYXRoZXJlZCBz dWZmaWNpZW50IGV4cGVyaWVuY2Ugd2l0aCBQQURESU5HIHRoYXQgaXQgbm93IHdhcnJhbnRzIGJl aW5nIGVsZXZhdGVkIHRvIFN0YW5kYXJkcyBUcmFjay4NCjwvc3Bhbj5UaGF0IGlzLCBpdCdzIGJl ZW4gcHJvdmVuIHRvIHdvcmsuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5J4oCZbSBmaW5lIHdpdGggd2hhdGV2ZXIsIGZvciB0aGUgcmVjb3JkLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+U2ltb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_CA447D152E6543409FF54700A53335EDlogmeincom_--