From nobody Mon Mar 2 04:06:56 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD373A098C; Mon, 2 Mar 2020 04:06:42 -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_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 WLvfDSmr80sm; Mon, 2 Mar 2020 04:06:40 -0800 (PST) Received: from FRA01-PR2-obe.outbound.protection.outlook.com (mail-eopbgr120093.outbound.protection.outlook.com [40.107.12.93]) (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 9F08F3A0997; Mon, 2 Mar 2020 04:06:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lJ66rxolOI/87gyuodxIgPxferUGgcEfr9j0Gg8T6DxLm/0XOvy+SjUnKINBH2Pn0VXg5klCGfVexWg0zGdX9mkgCSjayHBi0kQLIE1RUYkidyjZ3fKz2uuwDj21WqF9IHhrBh/sKvwJg4BhkCNmdH4Xk7TNFTDnm7/tI3r7uC9Z1V4SACINrD+dB+ol1HCbQqGdv9ZFOtsv7q5ajKwsuBZwHTRTCbr4ME9VNvVYthqyAbIjhC4JDVuo08a0kbSgq9cgv6iGiFVTOBH3qfMWtp4KN7OB3x7Bqx1M1Bs8rpzFDdHTHe2tmPux9C/xeMxDPjY4oGpR2yPe7xSO88zmig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=De7KxeOHK1MSFyCpVRDP3DOQzOqZFNuq3UzA0uiIKFI=; b=J10ptR5GGOB1ZADqeSJUCmubk0Xquk0U98FVSW65OCNoeURnX8XwQHSdONCi1h016mD2COWld59YMRqthvWUOUiiv6xLrKaIfBVxafTGYLVeEMSqSw0lwcNAwMHF3zX+dSR7mCy4bl+z2TYmRb2TfYZmNn5VqTUXIJMqhzQYXyOlX/TVl9TW1v4OQ57V7Rr/fcg14EWqWYlb9qgJvHhQ/bhq052Bd44t9z4jA2F2NsILZ1cJ7RMZG6z/WX9S7/hsHV6S1zue/tYrWrnT1eDBx84yvuyNpCqCTEgqmaIqVKANZfCg9cp2K2AR0/XRyDiR2754x1ZTgsFOjr3QkHtxrg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia-bell-labs.com; dmarc=pass action=none header.from=nokia-bell-labs.com; dkim=pass header.d=nokia-bell-labs.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=De7KxeOHK1MSFyCpVRDP3DOQzOqZFNuq3UzA0uiIKFI=; b=HTWiOqtYXHotbTMmAHZc1WwAA/TXcTLShOnCBmu8KAJqmCPEnX39h2c64tI9/3h7UwWDPG4EXnEKD1W21vSDIMIR7VwZjTJSmbN2sFypGDTJebr8x7a4bE0fXzyQjh7q1sLG+9vvN1lGfdiZSeHnYTJCplRZ5fbldHxWDJuYsTY= Received: from PR1PR07MB5100.eurprd07.prod.outlook.com (20.177.209.144) by PR1PR07MB5018.eurprd07.prod.outlook.com (20.177.209.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.9; Mon, 2 Mar 2020 12:06:37 +0000 Received: from PR1PR07MB5100.eurprd07.prod.outlook.com ([fe80::8d6a:cf42:5a57:6b77]) by PR1PR07MB5100.eurprd07.prod.outlook.com ([fe80::8d6a:cf42:5a57:6b77%3]) with mapi id 15.20.2793.011; Mon, 2 Mar 2020 12:06:37 +0000 From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" To: "Y. Richard Yang" , =?utf-8?B?U2Now7Zud8OkbGRlciwgSsO8cmdlbg==?= CC: IETF ALTO , The IESG , "alto-chairs@ietf.org" , "draft-ietf-alto-cost-calendar@ietf.org" , "ops-dir@ietf.org" , "secdir@ietf.org" Thread-Topic: [OPS-DIR] FW: [alto] I-D Action: draft-ietf-alto-cost-calendar-18.txt Thread-Index: AQHV7kWJSZL4nTuZ4Eij3NbOSl7FR6gwsCtAgAA6DwCAADSTgIAAtzAAgABHcQCAAxpjMA== Date: Mon, 2 Mar 2020 12:06:36 +0000 Message-ID: References: <158290102597.22328.2781470606904693361@ietfa.amsl.com> <20200228181749.lvstqfpxwatblmz7@anna.jacobs.jacobs-university.de> <20200229082139.5js3fxcmfrj4wo6m@anna.jacobs.jacobs-university.de> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=sabine.randriamasy@nokia-bell-labs.com; x-originating-ip: [131.228.2.2] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 77944c03-9355-430e-e4af-08d7bea22897 x-ms-traffictypediagnostic: PR1PR07MB5018: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 033054F29A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(39860400002)(366004)(136003)(376002)(346002)(396003)(199004)(189003)(9686003)(55016002)(966005)(33656002)(478600001)(8936002)(26005)(86362001)(71200400001)(2906002)(186003)(4326008)(8676002)(81166006)(110136005)(81156014)(54906003)(296002)(316002)(6506007)(53546011)(7696005)(5660300002)(52536014)(66556008)(66476007)(66446008)(64756008)(66946007)(76116006); DIR:OUT; SFP:1102; SCL:1; SRVR:PR1PR07MB5018; H:PR1PR07MB5100.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: nokia-bell-labs.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: B7eOT0vq3veh+/stYw8VrCsibbJKoMK37oyMIgH6RsCCv3ocgPnYCsxmz8Yuw1tqPfIygfoZq0Y5rMuM+97WpkKOIfCslP5wg/00uKfqx2Tzjz1aBwiD3tIn6L3IeMqCO15Ine4Z7fI/w8AV/Irrf1b5iKPlh/kL+/Ke8JuvMTXV/dAXeth+okHYaXuoVKy2zEmD4ayfGVCsvJovsWTO3LvbIK0Isj7LRLG2RkfkRLNKRtC1d5Wt5qVd5hAP1zx6DiatUtAaXdvnVOwOhmrukIl9glG86osGLNSnLVmE6ABwVnY8IxClzZQoyL2j3L4wV0oNOtkE43Tnnyjjgr89MXES5Jwl3QNzihgezLSKqXPlHTtIz9L7mSc9bDoSdJuI2xozWLQw+GuOyKtXJrafyvYznCbxUdbnsZPHY/219YTggESBf3i90AUSVcn/Cerur5OzDoJYMYSh1BXPz6cTOTtDpeBCWpYCVeX6ufRTCc74A+y7zVWFaXRn7EG7lvY0eKX/jML/YjMFJ8gRzLyEeA== x-ms-exchange-antispam-messagedata: dmSOd2q14Wy+zgE+1pRU9V0D5gm+JOejxdRdK8fJLxeo8n9cqVYUOPVRm07tduIkPhmcZWOtzXHPVbqDl4doM8e50W39Ph/ek7BKqakEnoJJ3Yh85/TeZr7cp99b9Sfps5TnjqLcq4L0ubtZOz1AzQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_PR1PR07MB5100E081D7EA9174CC64FE3195E70PR1PR07MB5100eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-Network-Message-Id: 77944c03-9355-430e-e4af-08d7bea22897 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2020 12:06:36.9864 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Ly1SxPpYNJH6nhTT3xcd6eAubDORN/4gE+mHMCIF6Y9KAFP/GNXXQctysnPC+XASoMVZDkaJ7/sIpWqVYSjypiTEWsBVqsTp7P2mLDpTw5KasctkUQXOELbz3CWLrZGp X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR1PR07MB5018 Archived-At: Subject: Re: [secdir] [OPS-DIR] FW: [alto] I-D Action: draft-ietf-alto-cost-calendar-18.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 12:06:43 -0000 --_000_PR1PR07MB5100E081D7EA9174CC64FE3195E70PR1PR07MB5100eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBKw7xyZ2VuLCBCYXJyeSBhbmQgYWxsLA0KDQpBIG5ldyB2ZXJzaW9uIGhhcyBiZWVuIHN1 Ym1pdHRlZCB0aGF0IGhvcGVmdWxseSBhZGRyZXNzZXMgSsO8cmdlbiBhbmQgQmFycnnigJlzIElF U0cgcmV2aWV3IGNvbW1lbnRzLg0KVGhhbmtzIGFnYWluIGZvciB5b3VyIGhlbHBmdWwgc3VnZ2Vz dGlvbnMuDQoNCg0KVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0 Og0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hbHRvLWNvc3QtY2Fs ZW5kYXItMTkNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1p ZXRmLWFsdG8tY29zdC1jYWxlbmRhci0xOQ0KDQoNCg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3Vz IHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtaWV0Zi1hbHRvLWNvc3QtY2FsZW5kYXItMTkNCg0KQmVzdCByZWdhcmRzLA0K U2FiaW5lIGFuZCBjby1hdXRob3JzLg0KDQoNCg0KDQpGcm9tOiBZLiBSaWNoYXJkIFlhbmcgPHly eUBjcy55YWxlLmVkdT4NClNlbnQ6IFNhdHVyZGF5LCBGZWJydWFyeSAyOSwgMjAyMCAxOjM3IFBN DQpUbzogU2Now7Zud8OkbGRlciwgSsO8cmdlbiA8Si5TY2hvZW53YWVsZGVyQGphY29icy11bml2 ZXJzaXR5LmRlPg0KQ2M6IElFVEYgQUxUTyA8YWx0b0BpZXRmLm9yZz47IFJhbmRyaWFtYXN5LCBT YWJpbmUgKE5va2lhIC0gRlIvUGFyaXMtU2FjbGF5KSA8c2FiaW5lLnJhbmRyaWFtYXN5QG5va2lh LWJlbGwtbGFicy5jb20+OyBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz47IGFsdG8tY2hhaXJzQGll dGYub3JnOyBkcmFmdC1pZXRmLWFsdG8tY29zdC1jYWxlbmRhckBpZXRmLm9yZzsgb3BzLWRpckBp ZXRmLm9yZzsgc2VjZGlyQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09QUy1ESVJdIEZXOiBbYWx0 b10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1hbHRvLWNvc3QtY2FsZW5kYXItMTgudHh0DQoNCg0K DQpPbiBTYXQsIEZlYiAyOSwgMjAyMCBhdCAzOjIxIEFNIFNjaMO2bnfDpGxkZXIsIErDvHJnZW4g PEouU2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTxtYWlsdG86Si5TY2hvZW53YWVs ZGVyQGphY29icy11bml2ZXJzaXR5LmRlPj4gd3JvdGU6DQpPbiBGcmksIEZlYiAyOCwgMjAyMCBh dCAwNDoyNjowMVBNIC0wNTAwLCBZLiBSaWNoYXJkIFlhbmcgd3JvdGU6DQo+IERlYXIgSsO8cmdl biwNCj4NCj4gQWx3YXlzIGV4Y2VsbGVudCBjb21tZW50cy4gUGxlYXNlIHNlZSBiZWxvdy4NCj4N Cj4gT24gRnJpLCBGZWIgMjgsIDIwMjAgYXQgMToxOCBQTSBTY2jDtm53w6RsZGVyLCBKw7xyZ2Vu IDwNCj4gSi5TY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPG1haWx0bzpKLlNjaG9l bndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+PiB3cm90ZToNCj4NCj4gPiBPbiBGcmksIEZl YiAyOCwgMjAyMCBhdCAwMzowMDozMVBNICswMDAwLCBSYW5kcmlhbWFzeSwgU2FiaW5lIChOb2tp YSAtDQo+ID4gRlIvUGFyaXMtU2FjbGF5KSB3cm90ZToNCj4gPiA+IERlYXIgSUVTRyByZXZpZXdl cnMsIErDvHJnZW4sIEJyaWFuLCBCYXJyeSwNCj4gPiA+DQo+ID4gPiBUaGFuayB5b3UgdmVyeSBt dWNoIGZvciB5b3VyIHJldmlldyBhbmQgc3VnZ2VzdGlvbnMuIFVwb24geW91ciBmZWVkYmFjaywN Cj4gPiB3ZSBoYXZlIHBvc3RlZCBhIG5ldyB2ZXJzaW9uIDE4LCB0aGF0IGhvcGVmdWxseSBhZGRy ZXNzZXMgeW91ciBjb21tZW50cy4NCj4gPiA+IEJlc2lkZXMsIHNvbWUgbG93ZXIvdXBwZXIgY2Fz ZSB0eXBvIGhhcm1vbml6YXRpb24gaGFzIGJlZW4gZG9uZSBvbg0KPiA+IGV4cHJlc3Npb25zIHN1 Y2ggYXMgIkNsaWVudCIsICJTZXJ2ZXIiLCAiY29zdCB0eXBlIi4NCj4gPiA+IFdlIGxvb2sgZm9y d2FyZCB0byBoYXZpbmcgeW91ciBmZWVkYmFjaywNCj4gPiA+DQo+ID4NCj4gPiBUaGFua3MgZm9y IHRoZSBjaGFuZ2VzLiBBbGwgbG9va3MgZ29vZCBidXQgSSBhbSBzdGlsbCBzdHJ1Z2dsaW5nIGEg Yml0DQo+ID4gd2l0aCB0aGUgdHlwZSBjaGFuZ2Ugb2YgdGhlIGNvc3QgZmllbGQuIFJldmlzaW9u IC0xOCBoYXMgdGhpcyBuZXcNCj4gPiB0ZXh0Og0KPiA+DQo+ID4gICAgWy4uLl0gVGhlcmVmb3Jl IHRoZSBpbXBsZW1lbnRvciBvZiB0aGlzIGV4dGVuc2lvbiBNVVNUIGNvbnNpZGVyDQo+ID4gICAg dGhhdCBhIGNvc3QgZW50cnkgaXMgYW4gYXJyYXkgb2YgdmFsdWVzLg0KPiA+DQo+ID4gSSBkbyBu b3QgcmVhbGx5IHVuZGVyc3RhbmQgd2hhdCB0aGlzIE1VU1QgdHJpZXMgdG8gYWNoaWV2ZSBvciB3 aGF0IHlvdQ0KPiA+IGV4cGVjdCBhbiBpbXBsZW1lbnRlciB0byBkbyBleGFjdGx5Lg0KPiA+DQo+ ID4gUkZDIDcyODUgc2VjdGlvbiAxMS4yLjMuNiBzYXlzOg0KPiA+DQo+ID4gICAgWy4uLl0gQW4g aW1wbGVtZW50YXRpb24gb2YgdGhlIHByb3RvY29sIGluIHRoaXMgZG9jdW1lbnQNCj4gPiAgICBT SE9VTEQgYXNzdW1lIHRoYXQgdGhlIGNvc3QgaXMgYSBKU09OTnVtYmVyIGFuZCBmYWlsIHRvIHBh cnNlIGlmIGl0DQo+ID4gICAgaXMgbm90LCB1bmxlc3MgdGhlIGltcGxlbWVudGF0aW9uIGlzIHVz aW5nIGFuIGV4dGVuc2lvbiB0byB0aGlzDQo+ID4gICAgZG9jdW1lbnQgdGhhdCBpbmRpY2F0ZXMg d2hlbiBhbmQgaG93IGNvc3RzIG9mIG90aGVyIGRhdGEgdHlwZXMgYXJlDQo+ID4gICAgc2lnbmFs ZWQuDQo+ID4NCj4gPiBJdCBtYXkgaGVscCB0byBzcGVsbCBvdXQgJ3doZW4gYW5kIGhvdyBjb3N0 cyBvZiBvdGhlciBkYXRhIHR5cGVzIGFyZQ0KPiA+IHNpZ25hbGVkJyBpbnN0ZWFkIG9mIHdyaXRp bmcgInRoZSBpbXBsZW1lbnRvciBbLi4uXSBNVVNUIGNvbnNpZGVyIi4gSWYNCj4gPiB0aGUgaWRl YSBpcyB0aGF0IHRoZSB1c2FnZSBvZiBhbiBhcnJheSBpcyBzaWduYWxlZCBieSB0aGUgdXNhZ2Ug b2YgYW4NCj4gPiBhcnJheSwgdGhlbiBzYXkgc28sIGlmIHRoZXJlIGlzIHNvbWUgb3RoZXIgd2F5 IHRvIHNpZ25hbCB0aGlzIGJlZm9yZSBJDQo+ID4gdHJ5IHRvIHBhcnNlLCB0aGVuIHNheSBzbyBh cyB3ZWxsLiBXZSBzaG91bGQgbm90IHJlbHkgb24gaW1wbGVtZW50ZXJzDQo+ID4gdG8gY29uc2lk ZXIgYW5kIGZpbmQgdGhlaXIgb3duIHNvbHV0aW9ucy4NCj4gPg0KPiA+IC9qcw0KPiA+DQo+ID4g UFM6IEkgZG8gbm90IGtub3cgbXVjaCBhYm91dCBBTFRPIGJ1dCBvdXQgb2YgY3VyaW9zaXR5OiBo YXMgaXQgYmVlbg0KPiA+ICAgICBjb25zaWRlcmVkIHRvIGFsbG9jYXRlIG5ldyAiY29zdC1tb2Rl IiB2YWx1ZXMgIm51bWVyaWNhbCoiIGFuZA0KPiA+ICAgICAib3JkaW5hbCoiIHRoYXQgc2lnbmFs IHRoYXQgdGhlIGNvc3QgZmllbGQgaXMgYSB2ZWN0b3Igb2YNCj4gPiAgICAgbnVtZXJpY2FsL29y ZGluYWwgdmFsdWVzIGFuZCBub3QganVzdCBhIHNjYWxhcj8NCj4gPg0KPiA+DQo+IEl0IGluZGVl ZCBjYW4gaGVscCBhIGxvdCBpZiB3ZSBjb3VsZCBpbnRyb2R1Y2UgYSBuZXcgY29zdCBtb2RlLCBi dXQgdGhlDQo+IGNoYW5nZSB3b3VsZCBiZQ0KPiBtb3JlIHN1YnN0YW50aWFsLg0KPg0KPiBMb29r aW5nIGF0IHlvdXIgcHJvcG9zYWwgb24gc3BlbGxpbmcgb3V0ICJ3aGVuIGFuZCBob3cgY29zdHMg b2Ygb3RoZXIgZGF0YQ0KPiB0eXBlcyBhcmUNCj4gc2lnbmFsZWQsIiB3aGljaCBpcyBhbiBleGNl bGxlbnQgc3VnZ2VzdGlvbi4gSG93IGRvZXMgdGhlIGZvbGxvd2luZyBsb29rOg0KPg0KPiAiLi4u IFRoZXJlZm9yZSB0aGUgaW1wbGVtZW50b3Igb2YgdGhpcyBleHRlbnNpb24gTVVTVCBjb25zaWRl ciB0aGF0IGEgY29zdA0KPiBlbnRyeSBpcyBhbg0KPiBhcnJheSBvZiB2YWx1ZXMuIFNwZWNpZmlj YWxseSwgYW4gaW1wbGVtZW50YXRpb24gb2YgdGhpcyBleHRlbnNpb24gTVVTVA0KPiBwYXJzZQ0K PiB0aGUgIm51bWJlci1vZi1pbnRlcnZhbHMiIGF0dHJpYnV0ZSBvZiB0aGUgImNhbGVuZGFyLWF0 dHJpYnV0ZXMiIGluIGFuIElSRA0KPiBlbnRyeQ0KPiBhbm5vdW5jaW5nIGEgc2VydmljZSBwcm92 aWRpbmcgQ29zdCBDYWxlbmRhci4gVGhlIGltcGxlbWVudGF0aW9uIHRoZW4gd2lsbA0KPiBrbm93 IHRoYXQgYSBjb3N0IGVudHJ5IG9mIHRoZSBzZXJ2aWNlIHdpbGwgYmUgYW4gYXJyYXkgb2YgdmFs dWVzLCBhbmQgdGhlDQo+IGV4cGVjdGVkDQo+IHNpemUgb2YgdGhlIGFycmF5IGlzIHRoYXQgc3Bl Y2lmaWVkIGJ5IHRoZSAibnVtYmVyLW9mLWludGVydmFscyIgYXR0cmlidXRlLg0KPg0KDQpTbyB0 aGUgc2lnbmFsIGlzIHRoZSAibnVtYmVyLW9mLWludGVydmFscyIgYXR0cmlidXRlLCB0aGlzIHdv cmtzIGZvcg0KbWUuIEkgdGhpbmsgaXQgaGVscHMgdG8gc3BlbGwgdGhpcyBvdXQuDQoNClllcy4g RXhhY3RseS4gVGhhbmtzIGEgbG90IGZvciB0aGUgaGVscCENCg0KUmljaGFyZA0KDQoNCi9qcw0K DQotLQ0KSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBC cmVtZW4gZ0dtYkgNClBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcg MSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCkZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAg ICAgPGh0dHBzOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCi0tDQpSaWNoYXJkDQo= --_000_PR1PR07MB5100E081D7EA9174CC64FE3195E70PR1PR07MB5100eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNv UGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCnAubXNvbm9ybWFs MCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9y bWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21z by1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlIiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPkRlYXIgSsO8cmdlbiwgQmFycnkgYW5kIGFsbCw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj5BIG5ldyB2ZXJzaW9uIGhhcyBiZWVuIHN1Ym1pdHRlZCB0aGF0 IGhvcGVmdWxseSBhZGRyZXNzZXMgSsO8cmdlbiBhbmQgQmFycnnigJlzIElFU0cgcmV2aWV3IGNv bW1lbnRzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhhbmtz IGFnYWluIGZvciB5b3VyIGhlbHBmdWwgc3VnZ2VzdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZXJlIGFyZSBhbHNvIGh0bWxp emVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1hbHRvLWNvc3QtY2FsZW5kYXItMTkiPjxzcGFuIGxhbmc9IkVOLVVTIj5odHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hbHRvLWNvc3QtY2FsZW5kYXItMTk8L3Nw YW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9odG1sL2RyYWZ0LWlldGYtYWx0by1jb3N0LWNhbGVuZGFyLTE5Ij48c3BhbiBsYW5nPSJFTi1V UyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWFsdG8t Y29zdC1jYWxlbmRhci0xOTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJFTi1VUyI+QSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxh YmxlIGF0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWFsdG8t Y29zdC1jYWxlbmRhci0xOSI+PHNwYW4gbGFuZz0iRU4tVVMiPmh0dHBzOi8vd3d3LmlldGYub3Jn L3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWFsdG8tY29zdC1jYWxlbmRhci0xOTwvc3Bhbj48L2E+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkJlc3Qg cmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5TYWJpbmUg YW5kIGNvLWF1dGhvcnMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gWS4gUmljaGFyZCBZYW5nICZsdDt5cnlAY3MueWFs ZS5lZHUmZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIEZlYnJ1YXJ5IDI5LCAyMDIw IDE6MzcgUE08YnI+DQo8Yj5Ubzo8L2I+IFNjaMO2bnfDpGxkZXIsIErDvHJnZW4gJmx0O0ouU2No b2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSZndDs8YnI+DQo8Yj5DYzo8L2I+IElFVEYg QUxUTyAmbHQ7YWx0b0BpZXRmLm9yZyZndDs7IFJhbmRyaWFtYXN5LCBTYWJpbmUgKE5va2lhIC0g RlIvUGFyaXMtU2FjbGF5KSAmbHQ7c2FiaW5lLnJhbmRyaWFtYXN5QG5va2lhLWJlbGwtbGFicy5j b20mZ3Q7OyBUaGUgSUVTRyAmbHQ7aWVzZ0BpZXRmLm9yZyZndDs7IGFsdG8tY2hhaXJzQGlldGYu b3JnOyBkcmFmdC1pZXRmLWFsdG8tY29zdC1jYWxlbmRhckBpZXRmLm9yZzsgb3BzLWRpckBpZXRm Lm9yZzsgc2VjZGlyQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT1BTLURJUl0g Rlc6IFthbHRvXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWFsdG8tY29zdC1jYWxlbmRhci0xOC50 eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTYXQsIEZlYiAy OSwgMjAyMCBhdCAzOjIxIEFNIFNjaMO2bnfDpGxkZXIsIErDvHJnZW4gJmx0OzxhIGhyZWY9Im1h aWx0bzpKLlNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUiPkouU2Nob2Vud2FlbGRl ckBqYWNvYnMtdW5pdmVyc2l0eS5kZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBGZWIgMjgsIDIw MjAgYXQgMDQ6MjY6MDFQTSAtMDUwMCwgWS4gUmljaGFyZCBZYW5nIHdyb3RlOjxicj4NCiZndDsg RGVhciBKw7xyZ2VuLDxicj4NCiZndDsgPGJyPg0KJmd0OyBBbHdheXMgZXhjZWxsZW50IGNvbW1l bnRzLiBQbGVhc2Ugc2VlIGJlbG93Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiBGcmksIEZlYiAy OCwgMjAyMCBhdCAxOjE4IFBNIFNjaMO2bnfDpGxkZXIsIErDvHJnZW4gJmx0Ozxicj4NCiZndDsg PGEgaHJlZj0ibWFpbHRvOkouU2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSIgdGFy Z2V0PSJfYmxhbmsiPkouU2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTwvYT4mZ3Q7 IHdyb3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IE9uIEZyaSwgRmViIDI4LCAyMDIwIGF0 IDAzOjAwOjMxUE0gJiM0MzswMDAwLCBSYW5kcmlhbWFzeSwgU2FiaW5lIChOb2tpYSAtPGJyPg0K Jmd0OyAmZ3Q7IEZSL1BhcmlzLVNhY2xheSkgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgRGVh ciBJRVNHIHJldmlld2VycywgSsO8cmdlbiwgQnJpYW4sIEJhcnJ5LDxicj4NCiZndDsgJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciByZXZp ZXcgYW5kIHN1Z2dlc3Rpb25zLiBVcG9uIHlvdXIgZmVlZGJhY2ssPGJyPg0KJmd0OyAmZ3Q7IHdl IGhhdmUgcG9zdGVkIGEgbmV3IHZlcnNpb24gMTgsIHRoYXQgaG9wZWZ1bGx5IGFkZHJlc3NlcyB5 b3VyIGNvbW1lbnRzLjxicj4NCiZndDsgJmd0OyAmZ3Q7IEJlc2lkZXMsIHNvbWUgbG93ZXIvdXBw ZXIgY2FzZSB0eXBvIGhhcm1vbml6YXRpb24gaGFzIGJlZW4gZG9uZSBvbjxicj4NCiZndDsgJmd0 OyBleHByZXNzaW9ucyBzdWNoIGFzICZxdW90O0NsaWVudCZxdW90OywgJnF1b3Q7U2VydmVyJnF1 b3Q7LCAmcXVvdDtjb3N0IHR5cGUmcXVvdDsuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgV2UgbG9vayBm b3J3YXJkIHRvIGhhdmluZyB5b3VyIGZlZWRiYWNrLDxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFRoYW5rcyBmb3IgdGhlIGNoYW5nZXMuIEFsbCBsb29r cyBnb29kIGJ1dCBJIGFtIHN0aWxsIHN0cnVnZ2xpbmcgYSBiaXQ8YnI+DQomZ3Q7ICZndDsgd2l0 aCB0aGUgdHlwZSBjaGFuZ2Ugb2YgdGhlIGNvc3QgZmllbGQuIFJldmlzaW9uIC0xOCBoYXMgdGhp cyBuZXc8YnI+DQomZ3Q7ICZndDsgdGV4dDo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsm bmJzcDsgJm5ic3A7IFsuLi5dIFRoZXJlZm9yZSB0aGUgaW1wbGVtZW50b3Igb2YgdGhpcyBleHRl bnNpb24gTVVTVCBjb25zaWRlcjxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgdGhhdCBhIGNv c3QgZW50cnkgaXMgYW4gYXJyYXkgb2YgdmFsdWVzLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyBJIGRvIG5vdCByZWFsbHkgdW5kZXJzdGFuZCB3aGF0IHRoaXMgTVVTVCB0cmllcyB0byBh Y2hpZXZlIG9yIHdoYXQgeW91PGJyPg0KJmd0OyAmZ3Q7IGV4cGVjdCBhbiBpbXBsZW1lbnRlciB0 byBkbyBleGFjdGx5Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBSRkMgNzI4NSBzZWN0 aW9uIDExLjIuMy42IHNheXM6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZu YnNwOyBbLi4uXSBBbiBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgcHJvdG9jb2wgaW4gdGhpcyBkb2N1 bWVudDxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgU0hPVUxEIGFzc3VtZSB0aGF0IHRoZSBj b3N0IGlzIGEgSlNPTk51bWJlciBhbmQgZmFpbCB0byBwYXJzZSBpZiBpdDxicj4NCiZndDsgJmd0 OyZuYnNwOyAmbmJzcDsgaXMgbm90LCB1bmxlc3MgdGhlIGltcGxlbWVudGF0aW9uIGlzIHVzaW5n IGFuIGV4dGVuc2lvbiB0byB0aGlzPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyBkb2N1bWVu dCB0aGF0IGluZGljYXRlcyB3aGVuIGFuZCBob3cgY29zdHMgb2Ygb3RoZXIgZGF0YSB0eXBlcyBh cmU8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7IHNpZ25hbGVkLjxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyBJdCBtYXkgaGVscCB0byBzcGVsbCBvdXQgJ3doZW4gYW5kIGhvdyBjb3N0 cyBvZiBvdGhlciBkYXRhIHR5cGVzIGFyZTxicj4NCiZndDsgJmd0OyBzaWduYWxlZCcgaW5zdGVh ZCBvZiB3cml0aW5nICZxdW90O3RoZSBpbXBsZW1lbnRvciBbLi4uXSBNVVNUIGNvbnNpZGVyJnF1 b3Q7LiBJZjxicj4NCiZndDsgJmd0OyB0aGUgaWRlYSBpcyB0aGF0IHRoZSB1c2FnZSBvZiBhbiBh cnJheSBpcyBzaWduYWxlZCBieSB0aGUgdXNhZ2Ugb2YgYW48YnI+DQomZ3Q7ICZndDsgYXJyYXks IHRoZW4gc2F5IHNvLCBpZiB0aGVyZSBpcyBzb21lIG90aGVyIHdheSB0byBzaWduYWwgdGhpcyBi ZWZvcmUgSTxicj4NCiZndDsgJmd0OyB0cnkgdG8gcGFyc2UsIHRoZW4gc2F5IHNvIGFzIHdlbGwu IFdlIHNob3VsZCBub3QgcmVseSBvbiBpbXBsZW1lbnRlcnM8YnI+DQomZ3Q7ICZndDsgdG8gY29u c2lkZXIgYW5kIGZpbmQgdGhlaXIgb3duIHNvbHV0aW9ucy48YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgL2pzPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFBTOiBJIGRvIG5vdCBr bm93IG11Y2ggYWJvdXQgQUxUTyBidXQgb3V0IG9mIGN1cmlvc2l0eTogaGFzIGl0IGJlZW48YnI+ DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2NvbnNpZGVyZWQgdG8gYWxsb2NhdGUgbmV3 ICZxdW90O2Nvc3QtbW9kZSZxdW90OyB2YWx1ZXMgJnF1b3Q7bnVtZXJpY2FsKiZxdW90OyBhbmQ8 YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O29yZGluYWwqJnF1b3Q7IHRo YXQgc2lnbmFsIHRoYXQgdGhlIGNvc3QgZmllbGQgaXMgYSB2ZWN0b3Igb2Y8YnI+DQomZ3Q7ICZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwO251bWVyaWNhbC9vcmRpbmFsIHZhbHVlcyBhbmQgbm90IGp1 c3QgYSBzY2FsYXI/PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyBJdCBp bmRlZWQgY2FuIGhlbHAgYSBsb3QgaWYgd2UgY291bGQgaW50cm9kdWNlIGEgbmV3IGNvc3QgbW9k ZSwgYnV0IHRoZTxicj4NCiZndDsgY2hhbmdlIHdvdWxkIGJlPGJyPg0KJmd0OyBtb3JlIHN1YnN0 YW50aWFsLjxicj4NCiZndDsgPGJyPg0KJmd0OyBMb29raW5nIGF0IHlvdXIgcHJvcG9zYWwgb24g c3BlbGxpbmcgb3V0ICZxdW90O3doZW4gYW5kIGhvdyBjb3N0cyBvZiBvdGhlciBkYXRhPGJyPg0K Jmd0OyB0eXBlcyBhcmU8YnI+DQomZ3Q7IHNpZ25hbGVkLCZxdW90OyB3aGljaCBpcyBhbiBleGNl bGxlbnQgc3VnZ2VzdGlvbi4gSG93IGRvZXMgdGhlIGZvbGxvd2luZyBsb29rOjxicj4NCiZndDsg PGJyPg0KJmd0OyAmcXVvdDsuLi4gVGhlcmVmb3JlIHRoZSBpbXBsZW1lbnRvciBvZiB0aGlzIGV4 dGVuc2lvbiBNVVNUIGNvbnNpZGVyIHRoYXQgYSBjb3N0PGJyPg0KJmd0OyBlbnRyeSBpcyBhbjxi cj4NCiZndDsgYXJyYXkgb2YgdmFsdWVzLiBTcGVjaWZpY2FsbHksIGFuIGltcGxlbWVudGF0aW9u IG9mIHRoaXMgZXh0ZW5zaW9uIE1VU1Q8YnI+DQomZ3Q7IHBhcnNlPGJyPg0KJmd0OyB0aGUgJnF1 b3Q7bnVtYmVyLW9mLWludGVydmFscyZxdW90OyBhdHRyaWJ1dGUgb2YgdGhlICZxdW90O2NhbGVu ZGFyLWF0dHJpYnV0ZXMmcXVvdDsgaW4gYW4gSVJEPGJyPg0KJmd0OyBlbnRyeTxicj4NCiZndDsg YW5ub3VuY2luZyBhIHNlcnZpY2UgcHJvdmlkaW5nIENvc3QgQ2FsZW5kYXIuIFRoZSBpbXBsZW1l bnRhdGlvbiB0aGVuIHdpbGw8YnI+DQomZ3Q7IGtub3cgdGhhdCBhIGNvc3QgZW50cnkgb2YgdGhl IHNlcnZpY2Ugd2lsbCBiZSBhbiBhcnJheSBvZiB2YWx1ZXMsIGFuZCB0aGU8YnI+DQomZ3Q7IGV4 cGVjdGVkPGJyPg0KJmd0OyBzaXplIG9mIHRoZSBhcnJheSBpcyB0aGF0IHNwZWNpZmllZCBieSB0 aGUgJnF1b3Q7bnVtYmVyLW9mLWludGVydmFscyZxdW90OyBhdHRyaWJ1dGUuPGJyPg0KJmd0OyA8 YnI+DQo8YnI+DQpTbyB0aGUgc2lnbmFsIGlzIHRoZSAmcXVvdDtudW1iZXItb2YtaW50ZXJ2YWxz JnF1b3Q7IGF0dHJpYnV0ZSwgdGhpcyB3b3JrcyBmb3I8YnI+DQptZS4gSSB0aGluayBpdCBoZWxw cyB0byBzcGVsbCB0aGlzIG91dC48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcy4gRXhhY3RseS4gVGhhbmtzIGEgbG90IGZvciB0 aGUgaGVscCE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+UmljaGFyZCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQovanM8YnI+DQo8YnI+DQotLSA8YnI+DQpKdWVy Z2VuIFNjaG9lbndhZWxkZXImbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O0phY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSDxicj4NClBob25lOiAmIzQzOzQ5IDQyMSAy MDAgMzU4NyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtDYW1wdXMgUmluZyAxIHwg Mjg3NTkgQnJlbWVuIHwgR2VybWFueTxicj4NCkZheDombmJzcDsgJm5ic3A7JiM0Mzs0OSA0MjEg MjAwIDMxMDMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0OzxhIGhyZWY9Imh0 dHBzOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmphY29icy11bml2ZXJzaXR5LmRlLzwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmljaGFyZDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_PR1PR07MB5100E081D7EA9174CC64FE3195E70PR1PR07MB5100eurp_-- From nobody Mon Mar 2 05:18:41 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0833A0B46; Mon, 2 Mar 2020 05:18:26 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.onmicrosoft.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 nHqN4M3C9ssG; Mon, 2 Mar 2020 05:18:24 -0800 (PST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2053.outbound.protection.outlook.com [40.107.20.53]) (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 D80CF3A0B45; Mon, 2 Mar 2020 05:18:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FHrJe2C7LTyPiYKy253fmeSM1le6GSrW+EqLRzvY7Go4V6mhj/2ntw5cQ2TG6e9aJwu/Q260htVqVhD8WzHf/A2EoB6Fe41/aWsvE0r+pd38BszlEHj3pceQpLgX3Vvf45qE5ZQu6MgLjkY9MQzPpgWgjtQMfiLwa9wDH1ZubHsjhZXKPpzjASbEJ6m9cAynWerCWOQZAvVAli6JJ/DWO+pyYPUMRiqe39/PMPILoWbnqGt1t90fq19qM9LjrjDxzmkX93lCrHbfL7Gn/bIn11zvwiGd6Lot87L3i5UyFxNSM08KAlBfxDyuwcLTqM06pz9MMjhebe5TGES3MEhPHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i370meDdV3VL1FT78ASwGkfRlSJcKpecSs6oLXa0Rrg=; b=GUZFaUIu2hYp/Mp2DR2xXYHdwRhT94m/APVr2wuMsKgcmphr7An/lw16e0FYd9Y2Unqv0NXqecICEUJhikk/0wcMNOFJBFZ65TRkLc5//1UOZ4FdHYsvVnBmGOE+S0+hlrBDtfgZvA5yVtM0ZcvhjQFE26BJ74fQHXhguMN4ZKtSeCfKgvy8wAJjoJree+YXxzc0OAGx+79pTRj85cExI4ZcGhr1SZkpH7uCTVMR1uNkpRrALU1PyqyJF3wu3QmFXwvpKauaHWWQQoPPNpp/tLR1gIMRc7hfYNNS+7JaLz6eTp7w82/fNIL2E+aTpH3qTzWoFjYXDsg995hHpLDhiw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i370meDdV3VL1FT78ASwGkfRlSJcKpecSs6oLXa0Rrg=; b=rIMqze3Pss42Iizc+l4KF/suKLZsJM7AHf5jbYgQvkP58lrkaGCoqX49zuRQNpKusOitIX+zN5pIgyAdo8woElikrZs/TmgKpOhcxl7JGn8JzuD1K/xwRKlNmiXuRzl4ovaP5/zRPBaTgZ3ZGr/m4t4I1iFH3TKKmLqkCMi3InM= Received: from AM4P190MB0004.EURP190.PROD.OUTLOOK.COM (10.172.221.19) by AM4P190MB0084.EURP190.PROD.OUTLOOK.COM (10.172.217.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.18; Mon, 2 Mar 2020 13:18:21 +0000 Received: from AM4P190MB0004.EURP190.PROD.OUTLOOK.COM ([fe80::b931:fce:e8b5:ec62]) by AM4P190MB0004.EURP190.PROD.OUTLOOK.COM ([fe80::b931:fce:e8b5:ec62%10]) with mapi id 15.20.2772.019; Mon, 2 Mar 2020 13:18:21 +0000 Received: from localhost (212.201.44.247) by AM0PR0202CA0006.eurprd02.prod.outlook.com (2603:10a6:208:1::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.14 via Frontend Transport; Mon, 2 Mar 2020 13:18:20 +0000 From: =?utf-8?B?U2Now7Zud8OkbGRlciwgSsO8cmdlbg==?= To: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" CC: "Y. Richard Yang" , IETF ALTO , The IESG , "alto-chairs@ietf.org" , "draft-ietf-alto-cost-calendar@ietf.org" , "ops-dir@ietf.org" , "secdir@ietf.org" Thread-Topic: [OPS-DIR] FW: [alto] I-D Action: draft-ietf-alto-cost-calendar-18.txt Thread-Index: AQHV7kWkb6d+ApV9CUmV4N7iECLLGqgwsCtAgAA6DwCAADSTgIAAtzAAgABHcQCAAxpjMIAAFbkA Date: Mon, 2 Mar 2020 13:18:21 +0000 Message-ID: <20200302131820.psgilinyjb5cafov@anna.jacobs.jacobs-university.de> References: <158290102597.22328.2781470606904693361@ietfa.amsl.com> <20200228181749.lvstqfpxwatblmz7@anna.jacobs.jacobs-university.de> <20200229082139.5js3fxcmfrj4wo6m@anna.jacobs.jacobs-university.de> In-Reply-To: Reply-To: =?utf-8?B?U2Now7Zud8OkbGRlciwgSsO8cmdlbg==?= Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: AM0PR0202CA0006.eurprd02.prod.outlook.com (2603:10a6:208:1::19) To AM4P190MB0004.EURP190.PROD.OUTLOOK.COM (2603:10a6:200:65::19) x-originating-ip: [212.201.44.247] authentication-results: spf=none (sender IP is ) smtp.mailfrom=J.Schoenwaelder@jacobs-university.de; x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ca6eece3-4e27-47e5-b8f7-08d7beac2de1 x-ms-traffictypediagnostic: AM4P190MB0084: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 033054F29A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400004)(366004)(346002)(396003)(136003)(376002)(189003)(199004)(54906003)(6486002)(5660300002)(81156014)(16526019)(6496006)(52116002)(186003)(8676002)(85202003)(8936002)(81166006)(4326008)(966005)(1076003)(478600001)(956004)(53546011)(66946007)(3450700001)(71200400001)(316002)(786003)(2906002)(26005)(6916009)(85182001)(66446008)(64756008)(66476007)(66556008)(86362001)(777600001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4P190MB0084; H:AM4P190MB0004.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: jacobs-university.de does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kLigQ+7VR3jVOXato335V3s9CLgg82xoMEkqxTglUqoomupN0dl7VPCJlvxfvvEHyy6wwTMENQcKtqi6hQyktdXhqefx4HGnCM4nBbF1yVw5syyqrqFQVPSIJFwuc3JYq7CB2bqMFxoSBpmt/9jc33JcgSMPxcz+/BEPgPUHRA4qkKQQPESfdzfWilKCfmPWFDtu09rV/d2ThEYT1u8xaMp6ItIX7vxbaouZsZaNWVxFhoyBXhxYUp+nDrUzFpLD7q9rEsGQCTKMozXi018xwLR38QRo0orYLFNJ6Q94+KBlI3HRZubIt0pLAT9+mhkWDxuDXU7I4E8SLjNvB7CPzM3awVHDE5RMLMfxnUpS5Z1WT8uoANn8oqNp0ORldwKNGoxi5NfI1z0YL01ipCWYdRXsixFyF/5Ha/YYnh3s2sp73R9B8er6JM75v4GDK0LaFg0PKPzRqsCVcuKMiqzemsA71PNruU9UvSOv3FkEikDat2y7Gk0tq67DbOkoyTUKVuEyyf/n6EuyDlt1A/WkcqCy+gbNGyZMQAUrAZovYfDtCH7qmtA/pNVfNKoyZt2h x-ms-exchange-antispam-messagedata: gsOtYh8Exo4yWo9GVWyVNF21sXRCick8u8hBCqTcQR8flfw9nBeH7v/GMXhpZBT+tnZ/m+AkVoPYNodyQSx+mZ3qh0nCdd0JpnHuF80+ddCY6as2gyRG84DlLlnKjTcGgTKIH/GQUuywJWXM4XLHGg== Content-Type: text/plain; charset="utf-8" Content-ID: <745FEDF653372345AD78F89C10D2E927@EURP190.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: ca6eece3-4e27-47e5-b8f7-08d7beac2de1 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2020 13:18:21.1103 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: I1hWW2wBKJFxJrtbObCEZWjUtGDruq8oqLYNlFuWdWk5oA3z6z6WbpRyyk1gPrwQmptg7JTY76Onf59DAxqrvg1te/G5d91ZJ5nIvLVlirI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4P190MB0084 Archived-At: Subject: Re: [secdir] [OPS-DIR] FW: [alto] I-D Action: draft-ietf-alto-cost-calendar-18.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 13:18:27 -0000 RGVhciBTYWJpbmUsDQoNCnRoaXMgdmVyc2lvbiBsb29rcyBnb29kIHRvIG1lLg0KDQovanMNCg0K T24gTW9uLCBNYXIgMDIsIDIwMjAgYXQgMTI6MDY6MzZQTSArMDAwMCwgUmFuZHJpYW1hc3ksIFNh YmluZSAoTm9raWEgLSBGUi9QYXJpcy1TYWNsYXkpIHdyb3RlOg0KPiBEZWFyIErDvHJnZW4sIEJh cnJ5IGFuZCBhbGwsDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIGhhcyBiZWVuIHN1Ym1pdHRlZCB0aGF0 IGhvcGVmdWxseSBhZGRyZXNzZXMgSsO8cmdlbiBhbmQgQmFycnnigJlzIElFU0cgcmV2aWV3IGNv bW1lbnRzLg0KPiBUaGFua3MgYWdhaW4gZm9yIHlvdXIgaGVscGZ1bCBzdWdnZXN0aW9ucy4NCj4g DQo+IA0KPiBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQo+ IA0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hbHRvLWNvc3QtY2Fs ZW5kYXItMTkNCj4gDQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJh ZnQtaWV0Zi1hbHRvLWNvc3QtY2FsZW5kYXItMTkNCj4gDQo+IA0KPiANCj4gQSBkaWZmIGZyb20g dGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiANCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtYWx0by1jb3N0LWNhbGVuZGFyLTE5DQo+ IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IFNhYmluZSBhbmQgY28tYXV0aG9ycy4NCj4gDQo+IA0KPiAN Cj4gDQo+IEZyb206IFkuIFJpY2hhcmQgWWFuZyA8eXJ5QGNzLnlhbGUuZWR1Pg0KPiBTZW50OiBT YXR1cmRheSwgRmVicnVhcnkgMjksIDIwMjAgMTozNyBQTQ0KPiBUbzogU2Now7Zud8OkbGRlciwg SsO8cmdlbiA8Si5TY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPg0KPiBDYzogSUVU RiBBTFRPIDxhbHRvQGlldGYub3JnPjsgUmFuZHJpYW1hc3ksIFNhYmluZSAoTm9raWEgLSBGUi9Q YXJpcy1TYWNsYXkpIDxzYWJpbmUucmFuZHJpYW1hc3lAbm9raWEtYmVsbC1sYWJzLmNvbT47IFRo ZSBJRVNHIDxpZXNnQGlldGYub3JnPjsgYWx0by1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYt YWx0by1jb3N0LWNhbGVuZGFyQGlldGYub3JnOyBvcHMtZGlyQGlldGYub3JnOyBzZWNkaXJAaWV0 Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtPUFMtRElSXSBGVzogW2FsdG9dIEktRCBBY3Rpb246IGRy YWZ0LWlldGYtYWx0by1jb3N0LWNhbGVuZGFyLTE4LnR4dA0KPiANCj4gDQo+IA0KPiBPbiBTYXQs IEZlYiAyOSwgMjAyMCBhdCAzOjIxIEFNIFNjaMO2bnfDpGxkZXIsIErDvHJnZW4gPEouU2Nob2Vu d2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTxtYWlsdG86Si5TY2hvZW53YWVsZGVyQGphY29i cy11bml2ZXJzaXR5LmRlPj4gd3JvdGU6DQo+IE9uIEZyaSwgRmViIDI4LCAyMDIwIGF0IDA0OjI2 OjAxUE0gLTA1MDAsIFkuIFJpY2hhcmQgWWFuZyB3cm90ZToNCj4gPiBEZWFyIErDvHJnZW4sDQo+ ID4NCj4gPiBBbHdheXMgZXhjZWxsZW50IGNvbW1lbnRzLiBQbGVhc2Ugc2VlIGJlbG93Lg0KPiA+ DQo+ID4gT24gRnJpLCBGZWIgMjgsIDIwMjAgYXQgMToxOCBQTSBTY2jDtm53w6RsZGVyLCBKw7xy Z2VuIDwNCj4gPiBKLlNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8bWFpbHRvOkou U2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4+IHdyb3RlOg0KPiA+DQo+ID4gPiBP biBGcmksIEZlYiAyOCwgMjAyMCBhdCAwMzowMDozMVBNICswMDAwLCBSYW5kcmlhbWFzeSwgU2Fi aW5lIChOb2tpYSAtDQo+ID4gPiBGUi9QYXJpcy1TYWNsYXkpIHdyb3RlOg0KPiA+ID4gPiBEZWFy IElFU0cgcmV2aWV3ZXJzLCBKw7xyZ2VuLCBCcmlhbiwgQmFycnksDQo+ID4gPiA+DQo+ID4gPiA+ IFRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIgcmV2aWV3IGFuZCBzdWdnZXN0aW9ucy4gVXBv biB5b3VyIGZlZWRiYWNrLA0KPiA+ID4gd2UgaGF2ZSBwb3N0ZWQgYSBuZXcgdmVyc2lvbiAxOCwg dGhhdCBob3BlZnVsbHkgYWRkcmVzc2VzIHlvdXIgY29tbWVudHMuDQo+ID4gPiA+IEJlc2lkZXMs IHNvbWUgbG93ZXIvdXBwZXIgY2FzZSB0eXBvIGhhcm1vbml6YXRpb24gaGFzIGJlZW4gZG9uZSBv bg0KPiA+ID4gZXhwcmVzc2lvbnMgc3VjaCBhcyAiQ2xpZW50IiwgIlNlcnZlciIsICJjb3N0IHR5 cGUiLg0KPiA+ID4gPiBXZSBsb29rIGZvcndhcmQgdG8gaGF2aW5nIHlvdXIgZmVlZGJhY2ssDQo+ ID4gPiA+DQo+ID4gPg0KPiA+ID4gVGhhbmtzIGZvciB0aGUgY2hhbmdlcy4gQWxsIGxvb2tzIGdv b2QgYnV0IEkgYW0gc3RpbGwgc3RydWdnbGluZyBhIGJpdA0KPiA+ID4gd2l0aCB0aGUgdHlwZSBj aGFuZ2Ugb2YgdGhlIGNvc3QgZmllbGQuIFJldmlzaW9uIC0xOCBoYXMgdGhpcyBuZXcNCj4gPiA+ IHRleHQ6DQo+ID4gPg0KPiA+ID4gICAgWy4uLl0gVGhlcmVmb3JlIHRoZSBpbXBsZW1lbnRvciBv ZiB0aGlzIGV4dGVuc2lvbiBNVVNUIGNvbnNpZGVyDQo+ID4gPiAgICB0aGF0IGEgY29zdCBlbnRy eSBpcyBhbiBhcnJheSBvZiB2YWx1ZXMuDQo+ID4gPg0KPiA+ID4gSSBkbyBub3QgcmVhbGx5IHVu ZGVyc3RhbmQgd2hhdCB0aGlzIE1VU1QgdHJpZXMgdG8gYWNoaWV2ZSBvciB3aGF0IHlvdQ0KPiA+ ID4gZXhwZWN0IGFuIGltcGxlbWVudGVyIHRvIGRvIGV4YWN0bHkuDQo+ID4gPg0KPiA+ID4gUkZD IDcyODUgc2VjdGlvbiAxMS4yLjMuNiBzYXlzOg0KPiA+ID4NCj4gPiA+ICAgIFsuLi5dIEFuIGlt cGxlbWVudGF0aW9uIG9mIHRoZSBwcm90b2NvbCBpbiB0aGlzIGRvY3VtZW50DQo+ID4gPiAgICBT SE9VTEQgYXNzdW1lIHRoYXQgdGhlIGNvc3QgaXMgYSBKU09OTnVtYmVyIGFuZCBmYWlsIHRvIHBh cnNlIGlmIGl0DQo+ID4gPiAgICBpcyBub3QsIHVubGVzcyB0aGUgaW1wbGVtZW50YXRpb24gaXMg dXNpbmcgYW4gZXh0ZW5zaW9uIHRvIHRoaXMNCj4gPiA+ICAgIGRvY3VtZW50IHRoYXQgaW5kaWNh dGVzIHdoZW4gYW5kIGhvdyBjb3N0cyBvZiBvdGhlciBkYXRhIHR5cGVzIGFyZQ0KPiA+ID4gICAg c2lnbmFsZWQuDQo+ID4gPg0KPiA+ID4gSXQgbWF5IGhlbHAgdG8gc3BlbGwgb3V0ICd3aGVuIGFu ZCBob3cgY29zdHMgb2Ygb3RoZXIgZGF0YSB0eXBlcyBhcmUNCj4gPiA+IHNpZ25hbGVkJyBpbnN0 ZWFkIG9mIHdyaXRpbmcgInRoZSBpbXBsZW1lbnRvciBbLi4uXSBNVVNUIGNvbnNpZGVyIi4gSWYN Cj4gPiA+IHRoZSBpZGVhIGlzIHRoYXQgdGhlIHVzYWdlIG9mIGFuIGFycmF5IGlzIHNpZ25hbGVk IGJ5IHRoZSB1c2FnZSBvZiBhbg0KPiA+ID4gYXJyYXksIHRoZW4gc2F5IHNvLCBpZiB0aGVyZSBp cyBzb21lIG90aGVyIHdheSB0byBzaWduYWwgdGhpcyBiZWZvcmUgSQ0KPiA+ID4gdHJ5IHRvIHBh cnNlLCB0aGVuIHNheSBzbyBhcyB3ZWxsLiBXZSBzaG91bGQgbm90IHJlbHkgb24gaW1wbGVtZW50 ZXJzDQo+ID4gPiB0byBjb25zaWRlciBhbmQgZmluZCB0aGVpciBvd24gc29sdXRpb25zLg0KPiA+ ID4NCj4gPiA+IC9qcw0KPiA+ID4NCj4gPiA+IFBTOiBJIGRvIG5vdCBrbm93IG11Y2ggYWJvdXQg QUxUTyBidXQgb3V0IG9mIGN1cmlvc2l0eTogaGFzIGl0IGJlZW4NCj4gPiA+ICAgICBjb25zaWRl cmVkIHRvIGFsbG9jYXRlIG5ldyAiY29zdC1tb2RlIiB2YWx1ZXMgIm51bWVyaWNhbCoiIGFuZA0K PiA+ID4gICAgICJvcmRpbmFsKiIgdGhhdCBzaWduYWwgdGhhdCB0aGUgY29zdCBmaWVsZCBpcyBh IHZlY3RvciBvZg0KPiA+ID4gICAgIG51bWVyaWNhbC9vcmRpbmFsIHZhbHVlcyBhbmQgbm90IGp1 c3QgYSBzY2FsYXI/DQo+ID4gPg0KPiA+ID4NCj4gPiBJdCBpbmRlZWQgY2FuIGhlbHAgYSBsb3Qg aWYgd2UgY291bGQgaW50cm9kdWNlIGEgbmV3IGNvc3QgbW9kZSwgYnV0IHRoZQ0KPiA+IGNoYW5n ZSB3b3VsZCBiZQ0KPiA+IG1vcmUgc3Vic3RhbnRpYWwuDQo+ID4NCj4gPiBMb29raW5nIGF0IHlv dXIgcHJvcG9zYWwgb24gc3BlbGxpbmcgb3V0ICJ3aGVuIGFuZCBob3cgY29zdHMgb2Ygb3RoZXIg ZGF0YQ0KPiA+IHR5cGVzIGFyZQ0KPiA+IHNpZ25hbGVkLCIgd2hpY2ggaXMgYW4gZXhjZWxsZW50 IHN1Z2dlc3Rpb24uIEhvdyBkb2VzIHRoZSBmb2xsb3dpbmcgbG9vazoNCj4gPg0KPiA+ICIuLi4g VGhlcmVmb3JlIHRoZSBpbXBsZW1lbnRvciBvZiB0aGlzIGV4dGVuc2lvbiBNVVNUIGNvbnNpZGVy IHRoYXQgYSBjb3N0DQo+ID4gZW50cnkgaXMgYW4NCj4gPiBhcnJheSBvZiB2YWx1ZXMuIFNwZWNp ZmljYWxseSwgYW4gaW1wbGVtZW50YXRpb24gb2YgdGhpcyBleHRlbnNpb24gTVVTVA0KPiA+IHBh cnNlDQo+ID4gdGhlICJudW1iZXItb2YtaW50ZXJ2YWxzIiBhdHRyaWJ1dGUgb2YgdGhlICJjYWxl bmRhci1hdHRyaWJ1dGVzIiBpbiBhbiBJUkQNCj4gPiBlbnRyeQ0KPiA+IGFubm91bmNpbmcgYSBz ZXJ2aWNlIHByb3ZpZGluZyBDb3N0IENhbGVuZGFyLiBUaGUgaW1wbGVtZW50YXRpb24gdGhlbiB3 aWxsDQo+ID4ga25vdyB0aGF0IGEgY29zdCBlbnRyeSBvZiB0aGUgc2VydmljZSB3aWxsIGJlIGFu IGFycmF5IG9mIHZhbHVlcywgYW5kIHRoZQ0KPiA+IGV4cGVjdGVkDQo+ID4gc2l6ZSBvZiB0aGUg YXJyYXkgaXMgdGhhdCBzcGVjaWZpZWQgYnkgdGhlICJudW1iZXItb2YtaW50ZXJ2YWxzIiBhdHRy aWJ1dGUuDQo+ID4NCj4gDQo+IFNvIHRoZSBzaWduYWwgaXMgdGhlICJudW1iZXItb2YtaW50ZXJ2 YWxzIiBhdHRyaWJ1dGUsIHRoaXMgd29ya3MgZm9yDQo+IG1lLiBJIHRoaW5rIGl0IGhlbHBzIHRv IHNwZWxsIHRoaXMgb3V0Lg0KPiANCj4gWWVzLiBFeGFjdGx5LiBUaGFua3MgYSBsb3QgZm9yIHRo ZSBoZWxwIQ0KPiANCj4gUmljaGFyZA0KPiANCj4gDQo+IC9qcw0KPiANCj4gLS0NCj4gSnVlcmdl biBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgN Cj4gUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkg QnJlbWVuIHwgR2VybWFueQ0KPiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRw czovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQo+IC0tDQo+IFJpY2hhcmQNCg0KLS0gDQpK dWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBn R21iSA0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3 NTkgQnJlbWVuIHwgR2VybWFueQ0KRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0 cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0K From nobody Mon Mar 2 05:30:43 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7AD33A0B9F; Mon, 2 Mar 2020 05:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 64y1Wcd4y3RJ; Mon, 2 Mar 2020 05:30:40 -0800 (PST) Received: from FRA01-MR2-obe.outbound.protection.outlook.com (mail-eopbgr90112.outbound.protection.outlook.com [40.107.9.112]) (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 B88023A0B9B; Mon, 2 Mar 2020 05:30:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QIEQUVmWUZksdeEDNpTfyt0o/OWY8TsgJVYxth28KSTKk2moGwlOjqrvcfz5/Sb4n0l97p7UcxfQYdyA9WJbzxPEoHWin7LWuK2uhi5jSlAXE9GIl3CvH0TOqH2Vj6jwGRr2e7SwCkXNsB+173Unlq9S11X2FuXJ7LODIIbgcdqiD8RIDZQ66RalHL1vQY9p/H2BwWlcubp2qDYN1IXlfAMTgTl/Z8oYJu9KUf3/4+b98dFCI6ECra33NA/Dwt0jmRgdhPiyw9YBpi8sLF98fw7mEM6IZZ0p0BVlPPjgp8IFOLDL35ikmSdmnl+ag9U7vcIlfvCnYR1NQjorXowP8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ELT1spj6UYN7YPO80ggO6gGdqPCqwsTuhWC/tS+jKl0=; b=BUNP7ilf92NCcva8D2+z/ygty+d8QdemnKgOQ0nNBIsozrhYjNFtZ1jxJePqnTbj07IFy3WlLhz3oAHfq9+IX66/UvzzlbesAINkCd2nHQUxswpVm6O0yxDbytv3g1zHb4ASzlS4eylAVKEat6Or2eNqNChcD4P2lyOv7UMrhBeYvU09yrKSHAIUwjt0CJkDMveJnRsbhewLbzKKalAjckK4rNDCYT9SL5tuKjA2W7uOnuJRX48GC3ZY64N3tZzdkB7PLKgnf75AGyBX0NdnlPGgbKyu5lI2BfZ2IIH6fEWSkFW2Mq9EC+8gYnshdii+KEGHLW2+RZolWsZNbSMDuA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia-bell-labs.com; dmarc=pass action=none header.from=nokia-bell-labs.com; dkim=pass header.d=nokia-bell-labs.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ELT1spj6UYN7YPO80ggO6gGdqPCqwsTuhWC/tS+jKl0=; b=XKooRL8G5babVlwKGktVzgaz/7ixfJrojdKEK3X1f/JsMLTNg/N7ulthF1j6YRYV2aS8Ryf/dn3j2Oz1SuBouNQEOYkXU92J5YA19NI0JSscVpjBvENK40ZMNbM4uFKp4brkxKM3HVqjyIEVA8zqW1A9eJazSGWQkQUmxYI1XNY= Received: from PR1PR07MB5100.eurprd07.prod.outlook.com (20.177.209.144) by PR1PR07MB5019.eurprd07.prod.outlook.com (20.177.211.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.11; Mon, 2 Mar 2020 13:30:37 +0000 Received: from PR1PR07MB5100.eurprd07.prod.outlook.com ([fe80::8d6a:cf42:5a57:6b77]) by PR1PR07MB5100.eurprd07.prod.outlook.com ([fe80::8d6a:cf42:5a57:6b77%3]) with mapi id 15.20.2793.011; Mon, 2 Mar 2020 13:30:37 +0000 From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" To: =?utf-8?B?U2Now7Zud8OkbGRlciwgSsO8cmdlbg==?= CC: "Y. Richard Yang" , IETF ALTO , The IESG , "alto-chairs@ietf.org" , "draft-ietf-alto-cost-calendar@ietf.org" , "ops-dir@ietf.org" , "secdir@ietf.org" Thread-Topic: [OPS-DIR] FW: [alto] I-D Action: draft-ietf-alto-cost-calendar-18.txt Thread-Index: AQHV7kWJSZL4nTuZ4Eij3NbOSl7FR6gwsCtAgAA6DwCAADSTgIAAtzAAgABHcQCAAxpjMIAAFbqAgAADKiA= Date: Mon, 2 Mar 2020 13:30:37 +0000 Message-ID: References: <158290102597.22328.2781470606904693361@ietfa.amsl.com> <20200228181749.lvstqfpxwatblmz7@anna.jacobs.jacobs-university.de> <20200229082139.5js3fxcmfrj4wo6m@anna.jacobs.jacobs-university.de> <20200302131820.psgilinyjb5cafov@anna.jacobs.jacobs-university.de> In-Reply-To: <20200302131820.psgilinyjb5cafov@anna.jacobs.jacobs-university.de> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=sabine.randriamasy@nokia-bell-labs.com; x-originating-ip: [131.228.2.2] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 83898eb2-bf18-45b4-8a68-08d7beade4af x-ms-traffictypediagnostic: PR1PR07MB5019: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 033054F29A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(376002)(346002)(39860400002)(136003)(396003)(366004)(189003)(199004)(33656002)(55016002)(71200400001)(76116006)(86362001)(2906002)(6916009)(4326008)(9686003)(53546011)(5660300002)(7696005)(54906003)(66446008)(64756008)(66556008)(66946007)(6506007)(186003)(966005)(66476007)(26005)(8676002)(52536014)(316002)(81166006)(8936002)(81156014)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:PR1PR07MB5019; H:PR1PR07MB5100.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: nokia-bell-labs.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jriXFuQJ1lAff90t0g7467XARXnwkXyFDjb39kNLKfnsxIR1N3grvCxKEwxEhkIbc6Z06OvzY7ysNU8WS11NLL2x6VUQFbYd56HjtsTiH+7zdUN0G/tiSjRjECdqJf5YMUrXapq0FSGOq9WAlem5ws/SYZvo9oxQMOt0EGB88ZGySKwSXopW2YarNluFiebYdPloTXQxRl3xWxFv9gavGf6dDi7PMQoxnk/E8hUjrm9TuCKgHkmW71HSjiRctCgFWHTHWviFEhAV0cwDmtPHM2KKM8A0tqOg+CfGwSm1Y1OHqVestnIZ+3AuhIkzpD79kKAf8jd5IYXUjSWmSSBoyJR6c6oadt7lU5JZDAcj34Q4Mvk/ZwnRsisdGi7Fu31TTf6TDKzz8KVjJG45kxbkSzCsd7R4AflbSXi5QEmbpjUosmBTdIvl/ZsaNQe4Hp2+F0AN7r4cCuKpLMKLekog1TZ1Y7nkRB2rw7ZqTV7k+V6mxU0LuBYPc814tbslfZjh5WQG9nOxntB1tpzJp5nj2w== x-ms-exchange-antispam-messagedata: 791yHs/8+eDyvuuGhpqsuZVYOqo4xbR7txGzxffFnd2I5wA789EUcHfd/sJLd4P2qhM5JeYfHCZwyWabQ6aKS8syMgMV6h6BjjN+hY243v2qpJ3gKE3UnPY5944RusTR7zOtTaimyGn0NlY2GuTf2A== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-Network-Message-Id: 83898eb2-bf18-45b4-8a68-08d7beade4af X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2020 13:30:37.0909 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wrWHJrnUFOub5lxaK+rG5gtCrbbKuUrYqiEIfXZD44ByEdE4omBRCSkEUBvw0tuwXuAQrS+F1PeeQbx4RRc0QmqyPLvPsydOIZObsJHW/OYdz4hdZek5wGKrEs+Qzz59 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR1PR07MB5019 Archived-At: Subject: Re: [secdir] [OPS-DIR] FW: [alto] I-D Action: draft-ietf-alto-cost-calendar-18.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 13:30:42 -0000 SGVsbG8gSsO8cmdlbiwNCg0KVGhhbmtzIGEgbG90LA0KQmVzdCByZWdhcmRzLA0KU2FiaW5lDQoN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFNjaMO2bnfDpGxkZXIsIErDvHJn ZW4gPEouU2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gDQpTZW50OiBNb25kYXks IE1hcmNoIDIsIDIwMjAgMjoxOCBQTQ0KVG86IFJhbmRyaWFtYXN5LCBTYWJpbmUgKE5va2lhIC0g RlIvUGFyaXMtU2FjbGF5KSA8c2FiaW5lLnJhbmRyaWFtYXN5QG5va2lhLWJlbGwtbGFicy5jb20+ DQpDYzogWS4gUmljaGFyZCBZYW5nIDx5cnlAY3MueWFsZS5lZHU+OyBJRVRGIEFMVE8gPGFsdG9A aWV0Zi5vcmc+OyBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz47IGFsdG8tY2hhaXJzQGlldGYub3Jn OyBkcmFmdC1pZXRmLWFsdG8tY29zdC1jYWxlbmRhckBpZXRmLm9yZzsgb3BzLWRpckBpZXRmLm9y Zzsgc2VjZGlyQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09QUy1ESVJdIEZXOiBbYWx0b10gSS1E IEFjdGlvbjogZHJhZnQtaWV0Zi1hbHRvLWNvc3QtY2FsZW5kYXItMTgudHh0DQoNCkRlYXIgU2Fi aW5lLA0KDQp0aGlzIHZlcnNpb24gbG9va3MgZ29vZCB0byBtZS4NCg0KL2pzDQoNCk9uIE1vbiwg TWFyIDAyLCAyMDIwIGF0IDEyOjA2OjM2UE0gKzAwMDAsIFJhbmRyaWFtYXN5LCBTYWJpbmUgKE5v a2lhIC0gRlIvUGFyaXMtU2FjbGF5KSB3cm90ZToNCj4gRGVhciBKw7xyZ2VuLCBCYXJyeSBhbmQg YWxsLA0KPiANCj4gQSBuZXcgdmVyc2lvbiBoYXMgYmVlbiBzdWJtaXR0ZWQgdGhhdCBob3BlZnVs bHkgYWRkcmVzc2VzIErDvHJnZW4gYW5kIEJhcnJ54oCZcyBJRVNHIHJldmlldyBjb21tZW50cy4N Cj4gVGhhbmtzIGFnYWluIGZvciB5b3VyIGhlbHBmdWwgc3VnZ2VzdGlvbnMuDQo+IA0KPiANCj4g VGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KPiANCj4gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYWx0by1jb3N0LWNhbGVuZGFyLTE5 DQo+IA0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYt YWx0by1jb3N0LWNhbGVuZGFyLTE5DQo+IA0KPiANCj4gDQo+IEEgZGlmZiBmcm9tIHRoZSBwcmV2 aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4gDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWFsdG8tY29zdC1jYWxlbmRhci0xOQ0KPiANCj4gQmVz dCByZWdhcmRzLA0KPiBTYWJpbmUgYW5kIGNvLWF1dGhvcnMuDQo+IA0KPiANCj4gDQo+IA0KPiBG cm9tOiBZLiBSaWNoYXJkIFlhbmcgPHlyeUBjcy55YWxlLmVkdT4NCj4gU2VudDogU2F0dXJkYXks IEZlYnJ1YXJ5IDI5LCAyMDIwIDE6MzcgUE0NCj4gVG86IFNjaMO2bnfDpGxkZXIsIErDvHJnZW4g PEouU2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4NCj4gQ2M6IElFVEYgQUxUTyA8 YWx0b0BpZXRmLm9yZz47IFJhbmRyaWFtYXN5LCBTYWJpbmUgKE5va2lhIC0gDQo+IEZSL1Bhcmlz LVNhY2xheSkgPHNhYmluZS5yYW5kcmlhbWFzeUBub2tpYS1iZWxsLWxhYnMuY29tPjsgVGhlIElF U0cgDQo+IDxpZXNnQGlldGYub3JnPjsgYWx0by1jaGFpcnNAaWV0Zi5vcmc7IA0KPiBkcmFmdC1p ZXRmLWFsdG8tY29zdC1jYWxlbmRhckBpZXRmLm9yZzsgb3BzLWRpckBpZXRmLm9yZzsgDQo+IHNl Y2RpckBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW09QUy1ESVJdIEZXOiBbYWx0b10gSS1EIEFj dGlvbjogDQo+IGRyYWZ0LWlldGYtYWx0by1jb3N0LWNhbGVuZGFyLTE4LnR4dA0KPiANCj4gDQo+ IA0KPiBPbiBTYXQsIEZlYiAyOSwgMjAyMCBhdCAzOjIxIEFNIFNjaMO2bnfDpGxkZXIsIErDvHJn ZW4gPEouU2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTxtYWlsdG86Si5TY2hvZW53 YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPj4gd3JvdGU6DQo+IE9uIEZyaSwgRmViIDI4LCAy MDIwIGF0IDA0OjI2OjAxUE0gLTA1MDAsIFkuIFJpY2hhcmQgWWFuZyB3cm90ZToNCj4gPiBEZWFy IErDvHJnZW4sDQo+ID4NCj4gPiBBbHdheXMgZXhjZWxsZW50IGNvbW1lbnRzLiBQbGVhc2Ugc2Vl IGJlbG93Lg0KPiA+DQo+ID4gT24gRnJpLCBGZWIgMjgsIDIwMjAgYXQgMToxOCBQTSBTY2jDtm53 w6RsZGVyLCBKw7xyZ2VuIDwgDQo+ID4gSi5TY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5 LmRlPG1haWx0bzpKLlNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+PiB3cm90ZToN Cj4gPg0KPiA+ID4gT24gRnJpLCBGZWIgMjgsIDIwMjAgYXQgMDM6MDA6MzFQTSArMDAwMCwgUmFu ZHJpYW1hc3ksIFNhYmluZSANCj4gPiA+IChOb2tpYSAtDQo+ID4gPiBGUi9QYXJpcy1TYWNsYXkp IHdyb3RlOg0KPiA+ID4gPiBEZWFyIElFU0cgcmV2aWV3ZXJzLCBKw7xyZ2VuLCBCcmlhbiwgQmFy cnksDQo+ID4gPiA+DQo+ID4gPiA+IFRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIgcmV2aWV3 IGFuZCBzdWdnZXN0aW9ucy4gVXBvbiB5b3VyIA0KPiA+ID4gPiBmZWVkYmFjaywNCj4gPiA+IHdl IGhhdmUgcG9zdGVkIGEgbmV3IHZlcnNpb24gMTgsIHRoYXQgaG9wZWZ1bGx5IGFkZHJlc3NlcyB5 b3VyIGNvbW1lbnRzLg0KPiA+ID4gPiBCZXNpZGVzLCBzb21lIGxvd2VyL3VwcGVyIGNhc2UgdHlw byBoYXJtb25pemF0aW9uIGhhcyBiZWVuIGRvbmUgDQo+ID4gPiA+IG9uDQo+ID4gPiBleHByZXNz aW9ucyBzdWNoIGFzICJDbGllbnQiLCAiU2VydmVyIiwgImNvc3QgdHlwZSIuDQo+ID4gPiA+IFdl IGxvb2sgZm9yd2FyZCB0byBoYXZpbmcgeW91ciBmZWVkYmFjaywNCj4gPiA+ID4NCj4gPiA+DQo+ ID4gPiBUaGFua3MgZm9yIHRoZSBjaGFuZ2VzLiBBbGwgbG9va3MgZ29vZCBidXQgSSBhbSBzdGls bCBzdHJ1Z2dsaW5nIGEgDQo+ID4gPiBiaXQgd2l0aCB0aGUgdHlwZSBjaGFuZ2Ugb2YgdGhlIGNv c3QgZmllbGQuIFJldmlzaW9uIC0xOCBoYXMgdGhpcyANCj4gPiA+IG5ldw0KPiA+ID4gdGV4dDoN Cj4gPiA+DQo+ID4gPiAgICBbLi4uXSBUaGVyZWZvcmUgdGhlIGltcGxlbWVudG9yIG9mIHRoaXMg ZXh0ZW5zaW9uIE1VU1QgY29uc2lkZXINCj4gPiA+ICAgIHRoYXQgYSBjb3N0IGVudHJ5IGlzIGFu IGFycmF5IG9mIHZhbHVlcy4NCj4gPiA+DQo+ID4gPiBJIGRvIG5vdCByZWFsbHkgdW5kZXJzdGFu ZCB3aGF0IHRoaXMgTVVTVCB0cmllcyB0byBhY2hpZXZlIG9yIHdoYXQgDQo+ID4gPiB5b3UgZXhw ZWN0IGFuIGltcGxlbWVudGVyIHRvIGRvIGV4YWN0bHkuDQo+ID4gPg0KPiA+ID4gUkZDIDcyODUg c2VjdGlvbiAxMS4yLjMuNiBzYXlzOg0KPiA+ID4NCj4gPiA+ICAgIFsuLi5dIEFuIGltcGxlbWVu dGF0aW9uIG9mIHRoZSBwcm90b2NvbCBpbiB0aGlzIGRvY3VtZW50DQo+ID4gPiAgICBTSE9VTEQg YXNzdW1lIHRoYXQgdGhlIGNvc3QgaXMgYSBKU09OTnVtYmVyIGFuZCBmYWlsIHRvIHBhcnNlIGlm IGl0DQo+ID4gPiAgICBpcyBub3QsIHVubGVzcyB0aGUgaW1wbGVtZW50YXRpb24gaXMgdXNpbmcg YW4gZXh0ZW5zaW9uIHRvIHRoaXMNCj4gPiA+ICAgIGRvY3VtZW50IHRoYXQgaW5kaWNhdGVzIHdo ZW4gYW5kIGhvdyBjb3N0cyBvZiBvdGhlciBkYXRhIHR5cGVzIGFyZQ0KPiA+ID4gICAgc2lnbmFs ZWQuDQo+ID4gPg0KPiA+ID4gSXQgbWF5IGhlbHAgdG8gc3BlbGwgb3V0ICd3aGVuIGFuZCBob3cg Y29zdHMgb2Ygb3RoZXIgZGF0YSB0eXBlcyANCj4gPiA+IGFyZSBzaWduYWxlZCcgaW5zdGVhZCBv ZiB3cml0aW5nICJ0aGUgaW1wbGVtZW50b3IgWy4uLl0gTVVTVCANCj4gPiA+IGNvbnNpZGVyIi4g SWYgdGhlIGlkZWEgaXMgdGhhdCB0aGUgdXNhZ2Ugb2YgYW4gYXJyYXkgaXMgc2lnbmFsZWQgDQo+ ID4gPiBieSB0aGUgdXNhZ2Ugb2YgYW4gYXJyYXksIHRoZW4gc2F5IHNvLCBpZiB0aGVyZSBpcyBz b21lIG90aGVyIHdheSANCj4gPiA+IHRvIHNpZ25hbCB0aGlzIGJlZm9yZSBJIHRyeSB0byBwYXJz ZSwgdGhlbiBzYXkgc28gYXMgd2VsbC4gV2UgDQo+ID4gPiBzaG91bGQgbm90IHJlbHkgb24gaW1w bGVtZW50ZXJzIHRvIGNvbnNpZGVyIGFuZCBmaW5kIHRoZWlyIG93biBzb2x1dGlvbnMuDQo+ID4g Pg0KPiA+ID4gL2pzDQo+ID4gPg0KPiA+ID4gUFM6IEkgZG8gbm90IGtub3cgbXVjaCBhYm91dCBB TFRPIGJ1dCBvdXQgb2YgY3VyaW9zaXR5OiBoYXMgaXQgYmVlbg0KPiA+ID4gICAgIGNvbnNpZGVy ZWQgdG8gYWxsb2NhdGUgbmV3ICJjb3N0LW1vZGUiIHZhbHVlcyAibnVtZXJpY2FsKiIgYW5kDQo+ ID4gPiAgICAgIm9yZGluYWwqIiB0aGF0IHNpZ25hbCB0aGF0IHRoZSBjb3N0IGZpZWxkIGlzIGEg dmVjdG9yIG9mDQo+ID4gPiAgICAgbnVtZXJpY2FsL29yZGluYWwgdmFsdWVzIGFuZCBub3QganVz dCBhIHNjYWxhcj8NCj4gPiA+DQo+ID4gPg0KPiA+IEl0IGluZGVlZCBjYW4gaGVscCBhIGxvdCBp ZiB3ZSBjb3VsZCBpbnRyb2R1Y2UgYSBuZXcgY29zdCBtb2RlLCBidXQgDQo+ID4gdGhlIGNoYW5n ZSB3b3VsZCBiZSBtb3JlIHN1YnN0YW50aWFsLg0KPiA+DQo+ID4gTG9va2luZyBhdCB5b3VyIHBy b3Bvc2FsIG9uIHNwZWxsaW5nIG91dCAid2hlbiBhbmQgaG93IGNvc3RzIG9mIA0KPiA+IG90aGVy IGRhdGEgdHlwZXMgYXJlIHNpZ25hbGVkLCIgd2hpY2ggaXMgYW4gZXhjZWxsZW50IHN1Z2dlc3Rp b24uIA0KPiA+IEhvdyBkb2VzIHRoZSBmb2xsb3dpbmcgbG9vazoNCj4gPg0KPiA+ICIuLi4gVGhl cmVmb3JlIHRoZSBpbXBsZW1lbnRvciBvZiB0aGlzIGV4dGVuc2lvbiBNVVNUIGNvbnNpZGVyIHRo YXQgDQo+ID4gYSBjb3N0IGVudHJ5IGlzIGFuIGFycmF5IG9mIHZhbHVlcy4gU3BlY2lmaWNhbGx5 LCBhbiBpbXBsZW1lbnRhdGlvbiANCj4gPiBvZiB0aGlzIGV4dGVuc2lvbiBNVVNUIHBhcnNlIHRo ZSAibnVtYmVyLW9mLWludGVydmFscyIgYXR0cmlidXRlIG9mIA0KPiA+IHRoZSAiY2FsZW5kYXIt YXR0cmlidXRlcyIgaW4gYW4gSVJEIGVudHJ5IGFubm91bmNpbmcgYSBzZXJ2aWNlIA0KPiA+IHBy b3ZpZGluZyBDb3N0IENhbGVuZGFyLiBUaGUgaW1wbGVtZW50YXRpb24gdGhlbiB3aWxsIGtub3cg dGhhdCBhIA0KPiA+IGNvc3QgZW50cnkgb2YgdGhlIHNlcnZpY2Ugd2lsbCBiZSBhbiBhcnJheSBv ZiB2YWx1ZXMsIGFuZCB0aGUgDQo+ID4gZXhwZWN0ZWQgc2l6ZSBvZiB0aGUgYXJyYXkgaXMgdGhh dCBzcGVjaWZpZWQgYnkgdGhlIA0KPiA+ICJudW1iZXItb2YtaW50ZXJ2YWxzIiBhdHRyaWJ1dGUu DQo+ID4NCj4gDQo+IFNvIHRoZSBzaWduYWwgaXMgdGhlICJudW1iZXItb2YtaW50ZXJ2YWxzIiBh dHRyaWJ1dGUsIHRoaXMgd29ya3MgZm9yIA0KPiBtZS4gSSB0aGluayBpdCBoZWxwcyB0byBzcGVs bCB0aGlzIG91dC4NCj4gDQo+IFllcy4gRXhhY3RseS4gVGhhbmtzIGEgbG90IGZvciB0aGUgaGVs cCENCj4gDQo+IFJpY2hhcmQNCj4gDQo+IA0KPiAvanMNCj4gDQo+IC0tDQo+IEp1ZXJnZW4gU2No b2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+IFBo b25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1l biB8IEdlcm1hbnkNCj4gRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cHM6Ly93 d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KPiAtLQ0KPiBSaWNoYXJkDQoNCi0tIA0KSnVlcmdl biBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgN ClBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJy ZW1lbiB8IEdlcm1hbnkNCkZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHBzOi8v d3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCg== From nobody Mon Mar 2 11:35:41 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 044563A0FD8; Mon, 2 Mar 2020 11:35:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christian Huitema via Datatracker To: Cc: tcpm@ietf.org, last-call@ietf.org, draft-ietf-tcpm-converters.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158317772769.27426.13946461846667728243@ietfa.amsl.com> Reply-To: Christian Huitema Date: Mon, 02 Mar 2020 11:35:28 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-tcpm-converters-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 19:35:36 -0000 Reviewer: Christian Huitema Review result: Not Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. In my opinion, this draft is not ready. The convert protocol enables clients to use a TCP proxy in an attempt to obtain better performance than on a direct connection between client and server. It is an alternative to the SOCKS 5 protocol. The client is configured with IP address of the proxy. Instead of establishing a direct connection to the server, it will establish a a "convert" connection to the proxy and proceed with an initial exchange according to the "convert" protocol. The proxy will then relay the connection to the server. I have doubts about the security properties of the proposed protocol, and in particular the weakness of the client authentication and the lack of proxy authentication. I also have reservations about the amount of quasi-marketing material in the lengthy introduction sections, and I would like to see more clarity on the management implications of address-rewriting scenarios. The client has to trust the proxy to correctly relay the connection, and also to not abuse its intermediate position and collect metadata or clear text data when relaying the TCP connections. The proxy has to make sure that it is only used by authorised clients. From the introduction, we infer that the protocol is meant to be deployed in constrained network, such as cellular network. The proxy would be deployed by the operator of the cellular network, which also provides the connectivity to the client. The privacy and security issues mostly arise when the client is connected to several networks, such as cellular and Wi-Fi. If the client is solely connected through the cellular network, the proxy is not obtaining any metadata or clear text data that would not be already observable by the network, and the proxy can verify that it is only used by authorized cellular network subscribers. However, the emphasis on providing TCP multipath between client and proxy let me think that the service is not restricted to just one network. I have some serious doubts about the security properties of the "convert" protocol. The protocol operates by configuring the IP address of the proxy in the clients. The protocol includes the possibility to authenticate a client by sending a clear text cookie when setting up the connection between client and proxy. This has all the (lack of) security of authentication with clear text passwords. The cookie can be observed if the client initiates a connection from outside the network controlled by the network operator, for example from a Wi-Fi hotspot. The protocol does not provides means for the client to authenticate the proxy. This is problematic, because the IP address of the proxy is statically configured. We have to assume that the proxy addresses can be disccovered by third parties. A client might try to issue a proxy connection from an unmanaged network. An attacker might arrange that packets bound to the proxy's IP are delivered to a system under the attacker's control, allowing the attacker to behave as a man-in-the-middle (MITM). The attacker could then observe the client's traffic and mount a variety of attacks. I think these security issues must be addressed before the draft is published. I understand that the authors may not want to develop a full security solution for what is presented as an experiment. Since this experimental draft describes a system designed for a close environment such as a cellular network, one way to address the issue would be to limit the use of the proxy service to addresses issued by the cellular network. This should be detailed in the security section. The introduction of the draft contains a long explanation describing what the authors perceive as "the problem". A lot of that looks like marketing material extollling the beauty of inserting TCP proxies in the communication path. The authors are of course entitled to their opinions, but the introduction presents opinions as facts, and publishing that as an RFC seems to assert that there is IETF consensus on these opinions. This is far from true. The draft justifies inserting proxies by explaining that it takes a long time for servers and clients to deploy the latest extensions to TCP, but experience shows that deployment is slowed when old network proxies do not support these extensions. Moreover, the draft asserts that the clients can benefit from using TCP extensions before they are deployed on the server, because the connections between them and the proxy can use these extensions. This is a rather questionable statement. For example, TCP multipath enables a connection to survive the loss of one of the paths between client and server by moving traffic to an alternate path. It is not clear at all that using an alternate path between a client and a proxy provides the same benefits. The draft would benefit from either presenting discussing enhancements versus ossification, and acknowledging that in most cases a direct connection between client and server provides better services than a connection mediated by a proxy. Or, if the authors do not want to say that, they could make the draft shorter and easier to read by removing most of the material in section 1 and 2, and simply stating that they present here a protocol for interacting with proxies that they think is superior to Socks 5. The presentation of the protocol only starts after 20 pages of introduction. Reducing that long presentation to 3 or 4 pages would markedly improve readability. When a client uses a proxy, the server will normally see the TCP connection as originating from the source address of a proxy. The draft supports that mode of operation, as explained in sections 4.3 and 4.4. There is a direct security implication here, because the client cannot be tracked by IP address. On one hand this may improve a client's privacy, but on the other hand this creates a management problem similar to that encountered with carrier grade NAT (CGN). In practice, network managers have to be able to identify the client who originated a specific TCP connection. For CGN, that translates into onerous logging requirements. This should be discussed in the security section. From nobody Tue Mar 3 01:27:03 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0B23A109C; Tue, 3 Mar 2020 01:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 YSn1wYoduLhC; Tue, 3 Mar 2020 01:26:59 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FDC93A1021; Tue, 3 Mar 2020 01:26:59 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 48Ws8w4gGcz10F4; Tue, 3 Mar 2020 10:26:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1583227616; bh=lpnzs+HchGbqbp8kdVrXrgi8hqcNZPGH9e5NtZHFBvc=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=IyBNSyTD6TlUcAk0qZXbxCI5SH5hr3O80VRHOryTMsZ1CBZ79U5ccSdUZYWJ5rikY ZBiN0NA7Fx1Og57ck25/4FZlPcuun5iGSHjDAO8i37eadTuaQZfgGCTHjjgPqSmr2x xliHHeIKnbwWXHweyMq2efAHdTfzCXUL5CuBBnFVXBA5nJPTQ6w9mdlgG63YMpL24K taS9mdGBHQltPCOMz6Jp6wG6suuFbnzdpPxGm/aDK51+DTZlFq+AmAfdQ+yS/HMnAJ ZgEdXNmKNo/FqDGS6mSQD6g/mq3bQMDQR1s8CKlz7OnyvU6Ko/E+4mblkNBcV9A5Ue TJr5PsusO+o5Q== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.54]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 48Ws8w3NYBzFpXL; Tue, 3 Mar 2020 10:26:56 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7D.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0487.000; Tue, 3 Mar 2020 10:26:56 +0100 From: To: Christian Huitema , "secdir@ietf.org" CC: "tcpm@ietf.org" , "last-call@ietf.org" , "draft-ietf-tcpm-converters.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-tcpm-converters-17 Thread-Index: AQHV8MnAn6rFgEwPTkmnFRtjTvxbCKg2gvew Date: Tue, 3 Mar 2020 09:26:55 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303145D64E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <158317772769.27426.13946461846667728243@ietfa.amsl.com> In-Reply-To: <158317772769.27426.13946461846667728243@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-tcpm-converters-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2020 09:27:02 -0000 SGkgQ2hyaXN0aWFuLA0KDQpUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuIA0KDQpQbGVhc2Ugc2Vl IGlubGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0t LQ0KPiBEZcKgOiBDaHJpc3RpYW4gSHVpdGVtYSB2aWEgRGF0YXRyYWNrZXIgW21haWx0bzpub3Jl cGx5QGlldGYub3JnXQ0KPiBFbnZvecOpwqA6IGx1bmRpIDIgbWFycyAyMDIwIDIwOjM1DQo+IMOA wqA6IHNlY2RpckBpZXRmLm9yZw0KPiBDY8KgOiB0Y3BtQGlldGYub3JnOyBsYXN0LWNhbGxAaWV0 Zi5vcmc7IGRyYWZ0LWlldGYtdGNwbS0NCj4gY29udmVydGVycy5hbGxAaWV0Zi5vcmcNCj4gT2Jq ZXTCoDogU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi10Y3BtLWNvbnZlcnRl cnMtMTcNCj4gDQo+IFJldmlld2VyOiBDaHJpc3RpYW4gSHVpdGVtYQ0KPiBSZXZpZXcgcmVzdWx0 OiBOb3QgUmVhZHkNCj4gDQo+IEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQg b2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3MNCj4gb25nb2luZyBlZmZvcnQgdG8NCj4gcmV2 aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuICBUaGVz ZSBjb21tZW50cw0KPiB3ZXJlIHdyaXR0ZW4NCj4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBv ZiB0aGUgc2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMuIERvY3VtZW50DQo+IGVkaXRvcnMgYW5kIFdH IGNoYWlycw0KPiBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhl ciBsYXN0IGNhbGwgY29tbWVudHMuDQo+IA0KPiBJbiBteSBvcGluaW9uLCB0aGlzIGRyYWZ0IGlz IG5vdCByZWFkeS4NCj4gDQo+IFRoZSBjb252ZXJ0IHByb3RvY29sIGVuYWJsZXMgY2xpZW50cyB0 byB1c2UgYSBUQ1AgcHJveHkgaW4gYW4gYXR0ZW1wdA0KPiB0byBvYnRhaW4gYmV0dGVyDQo+IHBl cmZvcm1hbmNlIHRoYW4gb24gYSBkaXJlY3QgY29ubmVjdGlvbiBiZXR3ZWVuIGNsaWVudCBhbmQg c2VydmVyLiBJdA0KPiBpcyBhbiBhbHRlcm5hdGl2ZQ0KPiB0byB0aGUgU09DS1MgNSBwcm90b2Nv bC4gVGhlIGNsaWVudCBpcyBjb25maWd1cmVkIHdpdGggSVAgYWRkcmVzcyBvZg0KPiB0aGUgcHJv eHkuIEluc3RlYWQNCj4gb2YgZXN0YWJsaXNoaW5nIGEgZGlyZWN0IGNvbm5lY3Rpb24gdG8gdGhl IHNlcnZlciwgaXQgd2lsbCBlc3RhYmxpc2ggYQ0KPiBhICJjb252ZXJ0Ig0KPiBjb25uZWN0aW9u IHRvIHRoZSBwcm94eSBhbmQgcHJvY2VlZCB3aXRoIGFuIGluaXRpYWwgZXhjaGFuZ2UgYWNjb3Jk aW5nDQo+IHRvIHRoZSAiY29udmVydCINCj4gcHJvdG9jb2wuIFRoZSBwcm94eSB3aWxsIHRoZW4g cmVsYXkgdGhlIGNvbm5lY3Rpb24gdG8gdGhlIHNlcnZlci4NCj4gDQo+IEkgaGF2ZSBkb3VidHMg YWJvdXQgdGhlIHNlY3VyaXR5IHByb3BlcnRpZXMgb2YgdGhlIHByb3Bvc2VkIHByb3RvY29sLA0K PiBhbmQgaW4NCj4gcGFydGljdWxhciB0aGUgd2Vha25lc3Mgb2YgdGhlIGNsaWVudCBhdXRoZW50 aWNhdGlvbiBhbmQgdGhlIGxhY2sgb2YNCj4gcHJveHkNCj4gYXV0aGVudGljYXRpb24uDQoNCltN ZWRdIFByb3h5IGF1dGhlbnRpY2F0aW9uIGFyZSBkaXNjdXNzZWQgaW4gU2VjdGlvbiA5LjUuIA0K DQpXZSBhbHNvIGhhdmUgdGhlIGZvbGxvd2luZyBpbiBTZWN0aW9uIDk6DQoNCiAgIFN0cm9uZ2Vy IG11dHVhbCBhdXRoZW50aWNhdGlvbiBzY2hlbWVzIE1VU1QgYmUgZGVmaW5lZCB0byB1c2UgdGhl DQogICBDb252ZXJ0IFByb3RvY29sIGluIG1vcmUgb3BlbiBuZXR3b3JrIGVudmlyb25tZW50cy4g IE9uZSBwb3NzaWJpbGl0eQ0KICAgaXMgdG8gdXNlIFRMUyB0byBwZXJmb3JtIG11dHVhbCBhdXRo ZW50aWNhdGlvbiBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kDQogICB0aGUgQ29udmVydGVyLiAgVGhh dCBpcywgdXNlIFRMUyB3aGVuIGEgQ2xpZW50IHJldHJpZXZlcyBhIENvb2tpZQ0KICAgZnJvbSB0 aGUgQ29udmVydGVyIGFuZCByZWx5IG9uIGNlcnRpZmljYXRlLWJhc2VkIGNsaWVudA0KICAgYXV0 aGVudGljYXRpb24sIHByZS1zaGFyZWQga2V5IGJhc2VkIFtSRkM0Mjc5XSBvciByYXcgcHVibGlj IGtleQ0KICAgYmFzZWQgY2xpZW50IGF1dGhlbnRpY2F0aW9uIFtSRkM3MjUwXSB0byBzZWN1cmUg dGhpcyBjb25uZWN0aW9uLiANCiANCg0KIEkgYWxzbyBoYXZlIHJlc2VydmF0aW9ucyBhYm91dCB0 aGUgYW1vdW50IG9mIHF1YXNpLQ0KPiBtYXJrZXRpbmcNCg0KW01lZF0gSSdtIGFmcmFpZCB0byBu b3QgdW5kZXJzdGFuZCB0aGlzIGNvbW1lbnQuIFRoaXMgc2VjdGlvbiBpbmNsdWRlcyB0ZWNobmlj YWwgZGV0YWlscy4gWW91IG1heSByZWZlciB0bywgZS5nLiwgDQpodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL21lZXRpbmcvMTA1L21hdGVyaWFscy9zbGlkZXMtMTA1LXRjcG0tMC1ydHQtY29u dmVydGVyLXBvYy1vdmVyLXJlYWwtNWctMDIgDQoNCj4gbWF0ZXJpYWwgaW4gdGhlIGxlbmd0aHkg aW50cm9kdWN0aW9uIHNlY3Rpb25zLCBhbmQgSSB3b3VsZCBsaWtlIHRvIHNlZQ0KPiBtb3JlIGNs YXJpdHkNCj4gb24gdGhlIG1hbmFnZW1lbnQgaW1wbGljYXRpb25zIG9mIGFkZHJlc3MtcmV3cml0 aW5nIHNjZW5hcmlvcy4NCg0KW01lZF0gU3VyZS4gVGhlc2UgbWF0dGVycyBhcmUgYWxyZWFkeSBk aXNjdXNzZWQgaW4gUkZDNjI2OS4gV2Ugd2lsbCBhZGQgYSBzdGF0ZW1lbnQgKHNlZSBhbHNvLCB5 b3VyIGxhc3QgcG9pbnQpLg0KDQo+IA0KPiBUaGUgY2xpZW50IGhhcyB0byB0cnVzdCB0aGUgcHJv eHkgdG8gY29ycmVjdGx5IHJlbGF5IHRoZSBjb25uZWN0aW9uLA0KPiBhbmQgYWxzbyB0byBub3QN Cj4gYWJ1c2UgaXRzIGludGVybWVkaWF0ZSBwb3NpdGlvbiBhbmQgY29sbGVjdCBtZXRhZGF0YSBv ciBjbGVhciB0ZXh0DQo+IGRhdGEgd2hlbiByZWxheWluZw0KPiB0aGUgVENQIGNvbm5lY3Rpb25z LiBUaGUgcHJveHkgaGFzIHRvIG1ha2Ugc3VyZSB0aGF0IGl0IGlzIG9ubHkgdXNlZA0KPiBieSBh dXRob3Jpc2VkDQo+IGNsaWVudHMuDQoNCltNZWRdIEFncmVlLiBTZWUgdGhlIGRpc2N1c3Npb24g aW4gU2VjdGlvbiA5LjUuDQoNCg0KIEZyb20gdGhlIGludHJvZHVjdGlvbiwgd2UgaW5mZXIgdGhh dCB0aGUgcHJvdG9jb2wgaXMgbWVhbnQgdG8NCj4gYmUgZGVwbG95ZWQgaW4NCj4gY29uc3RyYWlu ZWQgbmV0d29yaywgc3VjaCBhcyBjZWxsdWxhciBuZXR3b3JrLiBUaGUgcHJveHkgd291bGQgYmUN Cj4gZGVwbG95ZWQgYnkgdGhlDQo+IG9wZXJhdG9yIG9mIHRoZSBjZWxsdWxhciBuZXR3b3JrLCB3 aGljaCBhbHNvIHByb3ZpZGVzIHRoZSBjb25uZWN0aXZpdHkNCj4gdG8gdGhlIGNsaWVudC4NCj4g DQo+IFRoZSBwcml2YWN5IGFuZCBzZWN1cml0eSBpc3N1ZXMgbW9zdGx5IGFyaXNlIHdoZW4gdGhl IGNsaWVudCBpcw0KPiBjb25uZWN0ZWQgdG8gc2V2ZXJhbA0KPiBuZXR3b3Jrcywgc3VjaCBhcyBj ZWxsdWxhciBhbmQgV2ktRmkuIElmIHRoZSBjbGllbnQgaXMgc29sZWx5DQo+IGNvbm5lY3RlZCB0 aHJvdWdoIHRoZQ0KPiBjZWxsdWxhciBuZXR3b3JrLCB0aGUgcHJveHkgaXMgbm90IG9idGFpbmlu ZyBhbnkgbWV0YWRhdGEgb3IgY2xlYXINCj4gdGV4dCBkYXRhIHRoYXQNCj4gd291bGQgbm90IGJl IGFscmVhZHkgb2JzZXJ2YWJsZSBieSB0aGUgbmV0d29yaywgYW5kIHRoZSBwcm94eSBjYW4NCj4g dmVyaWZ5IHRoYXQgaXQgaXMNCj4gb25seSB1c2VkIGJ5IGF1dGhvcml6ZWQgY2VsbHVsYXIgbmV0 d29yayBzdWJzY3JpYmVycy4gSG93ZXZlciwgdGhlDQo+IGVtcGhhc2lzIG9uDQo+IHByb3ZpZGlu ZyBUQ1AgbXVsdGlwYXRoIGJldHdlZW4gY2xpZW50IGFuZCBwcm94eSBsZXQgbWUgdGhpbmsgdGhh dCB0aGUNCj4gc2VydmljZSBpcw0KPiBub3QgcmVzdHJpY3RlZCB0byBqdXN0IG9uZSBuZXR3b3Jr Lg0KDQpbTWVkXSBUaGUgYXNzdW1wdGlvbiBpcyBhcyBmb2xsb3dzIChTZWN0aW9uIDQuMSk6DQoN CiAgIFRyYW5zcG9ydCBDb252ZXJ0ZXJzIGNhbiBiZSBvcGVyYXRlZCBieSBuZXR3b3JrIG9wZXJh dG9ycyBvciB0aGlyZA0KICAgcGFydGllcy4gIE5ldmVydGhlbGVzcywgdGhpcyBkb2N1bWVudCBm b2N1c2VzIG9uIHRoZSBzaW5nbGUNCiAgIGFkbWluaXN0cmF0aXZlIGRlcGxveW1lbnQgY2FzZSB3 aGVyZSB0aGUgZW50aXR5IG9mZmVyaW5nIHRoZQ0KICAgY29ubmVjdGl2aXR5IHNlcnZpY2UgdG8g YSBjbGllbnQgaXMgYWxzbyB0aGUgZW50aXR5IHdoaWNoIG93bnMgYW5kDQogICBvcGVyYXRlcyB0 aGUgVHJhbnNwb3J0IENvbnZlcnRlci4NCg0KQWxzbyByZWl0ZXJhdGVkIGluIFNlY3Rpb24gOS4x Og0KDQogICBUaGlzIGRvY3VtZW50IGFzc3VtZXMgdGhhdCBhbGwgbmV0d29yayBhdHRhY2htZW50 cyBhcmUgbWFuYWdlZCBieSB0aGUNCiAgIHNhbWUgYWRtaW5pc3RyYXRpdmUgZW50aXR5Lg0KDQo+ IA0KPiBJIGhhdmUgc29tZSBzZXJpb3VzIGRvdWJ0cyBhYm91dCB0aGUgc2VjdXJpdHkgcHJvcGVy dGllcyBvZiB0aGUNCj4gImNvbnZlcnQiIHByb3RvY29sLg0KPiBUaGUgcHJvdG9jb2wgb3BlcmF0 ZXMgYnkgY29uZmlndXJpbmcgdGhlIElQIGFkZHJlc3Mgb2YgdGhlIHByb3h5IGluDQo+IHRoZSBj bGllbnRzLiBUaGUNCj4gcHJvdG9jb2wgaW5jbHVkZXMgdGhlIHBvc3NpYmlsaXR5IHRvIGF1dGhl bnRpY2F0ZSBhIGNsaWVudCBieSBzZW5kaW5nDQo+IGEgY2xlYXIgdGV4dA0KPiBjb29raWUgd2hl biBzZXR0aW5nIHVwIHRoZSBjb25uZWN0aW9uIGJldHdlZW4gY2xpZW50IGFuZCBwcm94eS4gVGhp cw0KPiBoYXMgYWxsIHRoZQ0KPiAobGFjayBvZikgc2VjdXJpdHkgb2YgYXV0aGVudGljYXRpb24g d2l0aCBjbGVhciB0ZXh0IHBhc3N3b3Jkcy4gVGhlDQo+IGNvb2tpZSBjYW4gYmUNCj4gb2JzZXJ2 ZWQgaWYgdGhlIGNsaWVudCBpbml0aWF0ZXMgYSBjb25uZWN0aW9uIGZyb20gb3V0c2lkZSB0aGUg bmV0d29yaw0KPiBjb250cm9sbGVkDQo+IGJ5IHRoZSBuZXR3b3JrIG9wZXJhdG9yLCBmb3IgZXhh bXBsZSBmcm9tIGEgV2ktRmkgaG90c3BvdC4NCg0KW01lZF0gVGhlIGRvY3VtZW50IGRpc2N1c3Nl cyB3aGF0IHRvIGRvIHdoZW4gc3Ryb25nIG11dHVhbCBhdXRoZW50aWNhdGlvbiBpcyBuZWVkZWQg KFNlY3Rpb24gOS4yKS4NCg0KPiANCj4gVGhlIHByb3RvY29sIGRvZXMgbm90IHByb3ZpZGVzIG1l YW5zIGZvciB0aGUgY2xpZW50IHRvIGF1dGhlbnRpY2F0ZQ0KPiB0aGUgcHJveHkuIFRoaXMNCj4g aXMgcHJvYmxlbWF0aWMsIGJlY2F1c2UgdGhlIElQIGFkZHJlc3Mgb2YgdGhlIHByb3h5IGlzIHN0 YXRpY2FsbHkNCj4gY29uZmlndXJlZC4NCg0KW01lZF0gV2UgZG9uJ3QgaGF2ZSBzdWNoIGFzc3Vt cHRpb24uIFRoZSBkb2N1bWVudCBzYXlzIHRoZSBmb2xsb3dpbmc6IA0KDQogICBUaGlzIGRvY3Vt ZW50IGFzc3VtZXMgYW4gZXhwbGljaXQgbW9kZWwgaW4gd2hpY2ggYSBjbGllbnQgaXMNCiAgIGNv bmZpZ3VyZWQgd2l0aCBvbmUgb3IgYSBsaXN0IG9mIFRyYW5zcG9ydCBDb252ZXJ0ZXJzIChzdGF0 aWNhbGx5IG9yDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBeXg0KICAgdGhyb3VnaCBwcm90b2NvbHMgc3VjaCBhcyBb SS1ELmJvdWNhZGFpci10Y3BtLWRoYy1jb252ZXJ0ZXJdKS4NCiAgIF5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXg0KICAgQ29uZmlndXJh dGlvbiBtZWFucyBhcmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4NCiAgIF5e Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl4g ICAgICAgICAgICAgICAgICAgDQoNCiBXZQ0KPiBoYXZlIHRvIGFzc3VtZSB0aGF0IHRoZSBwcm94 eSBhZGRyZXNzZXMgY2FuIGJlIGRpc2Njb3ZlcmVkIGJ5IHRoaXJkDQo+IHBhcnRpZXMuIEENCj4g Y2xpZW50IG1pZ2h0IHRyeSB0byBpc3N1ZSBhIHByb3h5IGNvbm5lY3Rpb24gZnJvbSBhbiB1bm1h bmFnZWQNCj4gbmV0d29yay4gQW4gYXR0YWNrZXINCj4gbWlnaHQgYXJyYW5nZSB0aGF0IHBhY2tl dHMgYm91bmQgdG8gdGhlIHByb3h5J3MgSVAgYXJlIGRlbGl2ZXJlZCB0byBhDQo+IHN5c3RlbSB1 bmRlcg0KPiB0aGUgYXR0YWNrZXIncyBjb250cm9sLCBhbGxvd2luZyB0aGUgYXR0YWNrZXIgdG8g YmVoYXZlIGFzIGEgbWFuLWluLQ0KPiB0aGUtbWlkZGxlIChNSVRNKS4NCj4gVGhlIGF0dGFja2Vy IGNvdWxkIHRoZW4gb2JzZXJ2ZSB0aGUgY2xpZW50J3MgdHJhZmZpYyBhbmQgbW91bnQgYQ0KPiB2 YXJpZXR5IG9mDQo+IGF0dGFja3MuDQoNCltNZWRdIFRoaXMgaXMgZGlzY3Vzc2VkIGluICJUcmFm ZmljIFRoZWZ0IiBzZWN0aW9uLiBDYW4geW91IHBsZWFzZSBpbmRpY2F0ZSB3aGF0IHdlIG5lZWQg dG8gc2F5IG1vcmU/IFRoYW5rIHlvdS4gDQoNCj4gDQo+IEkgdGhpbmsgdGhlc2Ugc2VjdXJpdHkg aXNzdWVzIG11c3QgYmUgYWRkcmVzc2VkIGJlZm9yZSB0aGUgZHJhZnQgaXMNCj4gcHVibGlzaGVk LiBJDQo+IHVuZGVyc3RhbmQgdGhhdCB0aGUgYXV0aG9ycyBtYXkgbm90IHdhbnQgdG8gZGV2ZWxv cCBhIGZ1bGwgc2VjdXJpdHkNCj4gc29sdXRpb24gZm9yDQo+IHdoYXQgaXMgcHJlc2VudGVkIGFz IGFuIGV4cGVyaW1lbnQuIFNpbmNlIHRoaXMgZXhwZXJpbWVudGFsIGRyYWZ0DQo+IGRlc2NyaWJl cyBhIHN5c3RlbQ0KPiBkZXNpZ25lZCBmb3IgYSBjbG9zZSBlbnZpcm9ubWVudCBzdWNoIGFzIGEg Y2VsbHVsYXIgbmV0d29yaywgb25lIHdheQ0KPiB0byBhZGRyZXNzIHRoZQ0KPiBpc3N1ZSB3b3Vs ZCBiZSB0byBsaW1pdCB0aGUgdXNlIG9mIHRoZSBwcm94eSBzZXJ2aWNlIHRvIGFkZHJlc3Nlcw0K PiBpc3N1ZWQgYnkgdGhlDQo+IGNlbGx1bGFyIG5ldHdvcmsuIFRoaXMgc2hvdWxkIGJlIGRldGFp bGVkIGluIHRoZSBzZWN1cml0eSBzZWN0aW9uLg0KPiANCj4gVGhlIGludHJvZHVjdGlvbiBvZiB0 aGUgZHJhZnQgY29udGFpbnMgYSBsb25nIGV4cGxhbmF0aW9uIGRlc2NyaWJpbmcNCj4gd2hhdCB0 aGUgYXV0aG9ycyBwZXJjZWl2ZSBhcw0KPiAidGhlIHByb2JsZW0iLg0KDQpbTWVkXSBUaGUgZG9j dW1lbnQgZG9lcyBub3QgcmVmbGVjdCBvdXIgb3BpbmlvbnMgYnV0IHRob3NlIG9mIHRoZSBXRy4N Cg0KIEEgbG90IG9mIHRoYXQgbG9va3MgbGlrZSBtYXJrZXRpbmcgbWF0ZXJpYWwgZXh0b2xsaW5n DQo+IHRoZSBiZWF1dHkgb2YgaW5zZXJ0aW5nDQo+IFRDUCBwcm94aWVzIGluIHRoZSBjb21tdW5p Y2F0aW9uIHBhdGguIA0KDQpbTWVkXSBUaGVzZSBhcmUgdGVjaG5pY2FsIGFyZ3VtZW50cywgbm90 IG1hcmtldGluZyBvbmVzLiBJJ2QgbGlrZSB3ZSBmb2N1cyBvbiB0ZWNobmljYWwgYXJndW1lbnQg cmF0aGVyIHRoYW4gbWFrZSBhc3N1bXB0aW9ucyBvbiB0aGUgaW50ZW50cyBvZiB0aGUgYXV0aG9y cy9XRy4gVGhhbmsgeW91LiAgDQoNClRoZSBhdXRob3JzIGFyZSBvZiBjb3Vyc2UNCj4gZW50aXRs ZWQgdG8gdGhlaXIgb3BpbmlvbnMsDQo+IGJ1dCB0aGUgaW50cm9kdWN0aW9uIHByZXNlbnRzIG9w aW5pb25zIGFzIGZhY3RzLCBhbmQgcHVibGlzaGluZyB0aGF0DQo+IGFzIGFuIFJGQyBzZWVtcyB0 byBhc3NlcnQNCj4gdGhhdCB0aGVyZSBpcyBJRVRGIGNvbnNlbnN1cyBvbiB0aGVzZSBvcGluaW9u cy4gVGhpcyBpcyBmYXIgZnJvbSB0cnVlLg0KPiBUaGUgZHJhZnQganVzdGlmaWVzDQo+IGluc2Vy dGluZyBwcm94aWVzIGJ5IGV4cGxhaW5pbmcgdGhhdCBpdCB0YWtlcyBhIGxvbmcgdGltZSBmb3Ig c2VydmVycw0KPiBhbmQgY2xpZW50cyB0byBkZXBsb3kNCj4gdGhlIGxhdGVzdCBleHRlbnNpb25z IHRvIFRDUCwgYnV0IGV4cGVyaWVuY2Ugc2hvd3MgdGhhdCBkZXBsb3ltZW50IGlzDQo+IHNsb3dl ZCB3aGVuIG9sZA0KPiBuZXR3b3JrIHByb3hpZXMgZG8gbm90IHN1cHBvcnQgdGhlc2UgZXh0ZW5z aW9ucy4NCg0KW01lZF0gQWdyZWUgdGhhdCBzb21lIHByb3hpZXMgbWF5IGJlIHByb2JsZW1hdGlj IGZvciBzb21lIGV4dGVuc2lvbnMgYnV0IHRoZSByZWFsaXR5IGlzIHRoYXQgKiogbWFueSBleHRl bnNpb25zICoqKiBhcmUgbm90IHN1cHBvcnRlZCBieSBzZXJ2ZXJzIGFzIHdlbGwgKE1QVENQLCBU Rk8sIFRDUGluYywgZm9yIGV4YW1wbGUpLiBBIGJhbGFuY2VkIGFwcHJvYWNoIHNob3VsZCBiZSBm b2xsb3dlZCBoZXJlLCBDaHJpc3RpYW4uIA0KDQpQbGVhc2Ugbm90ZToNCiogVGhlIGRvY3VtZW50 IHVzZXMgYW4gZXhwbGljaXQgbW9kZTogdGhhdCBpcyB0aGUgbmV0d29yayBpbmRpY2F0ZXMgZXhw bGljaXRseSB3aGF0IGlzIGRvaW5nLg0KKiBUaGUgaG9zdCBjYW4gY29udHJvbCB0aGUgY29ubmVj dGlvbnMgdGhhdCBpdCB3YW50cyB0byBiZSBhc3Npc3RlZCBieSB0aGUgbmV0d29ya3MuIA0KKiBU aGUgcHJvdG9jb2wgYWxsb3dzIHRvIHdpdGhkcmF3IHRoZSBjb252ZXJ0ZXIgZnJvbSB0aGUgcGF0 aCBpZiBhbiBleHRlbnNpb24gcmVxdWVzdGVkIGJ5IHRoZSBob3N0IGFyZSBzdXBwb3J0ZWQgYnkg dGhlIHNlcnZlci4gICAgDQoNCj4gDQo+IE1vcmVvdmVyLCB0aGUgZHJhZnQgYXNzZXJ0cyB0aGF0 IHRoZSBjbGllbnRzIGNhbiBiZW5lZml0IGZyb20gdXNpbmcNCj4gVENQIGV4dGVuc2lvbnMgYmVm b3JlIHRoZXkNCj4gYXJlIGRlcGxveWVkIG9uIHRoZSBzZXJ2ZXIsIGJlY2F1c2UgdGhlIGNvbm5l Y3Rpb25zIGJldHdlZW4gdGhlbSBhbmQNCj4gdGhlIHByb3h5IGNhbiB1c2UgdGhlc2UNCj4gZXh0 ZW5zaW9ucy4gVGhpcyBpcyBhIHJhdGhlciBxdWVzdGlvbmFibGUgc3RhdGVtZW50LiBGb3IgZXhh bXBsZSwgVENQDQo+IG11bHRpcGF0aCBlbmFibGVzIGENCj4gY29ubmVjdGlvbiB0byBzdXJ2aXZl IHRoZSBsb3NzIG9mIG9uZSBvZiB0aGUgcGF0aHMgYmV0d2VlbiBjbGllbnQgYW5kDQo+IHNlcnZl ciBieSBtb3ZpbmcgdHJhZmZpYw0KPiB0byBhbiBhbHRlcm5hdGUgcGF0aC4gSXQgaXMgbm90IGNs ZWFyIGF0IGFsbCB0aGF0IHVzaW5nIGFuIGFsdGVybmF0ZQ0KPiBwYXRoIGJldHdlZW4gYSBjbGll bnQgYW5kDQo+IGEgcHJveHkgcHJvdmlkZXMgdGhlIHNhbWUgYmVuZWZpdHMuDQoNCltNZWRdIExl dCdzIGNvbnNpZGVyIGEgaG9zdCBjb25uZWN0ZWQgdmlhIHR3byBhY2Nlc3MgbmV0d29ya3MuIElm IGEgcmVhY2hhYmlsaXR5IGlzc3VlIGlzIGVuY291bnRlcmVkIHdpdGggb25lIG9mIHRoZSBhY2Nl c3MgbmV0d29ya3MsIHRoZSBzaXR1YXRpb24gd291bGQgYmUgYXMgZm9sbG93czoNCg0KKiBubyBj b252ZXJ0OiB0aGUgY29ubmVjdGlvbiB3b24ndCBzdXJ2aXZlLiANCiogY29udmVydDogdGhlIGNv bm5lY3Rpb24gd2lsbCBzdXJ2aXZlcyBiZWNhdXNlIGFuIGFsdGVybmF0ZSBwYXRoIGNhbiBiZSB1 c2VkIChldmVuIGlmIHRoZSBzZXJ2ZXIgaXMgbm90IE1QVENQLWNhcGFibGUpLiANCg0KVGhhdCBp cyBhIGNvbmNyZXRlIGV4YW1wbGUgdGhhdCB3ZSBjYW4gYmVuZWZpdCBmcm9tIHRoZSB1c2Ugb2Yg dGhlIFRDUCBleHRlbnNpb24gYmVmb3JlIHRoZXkgYXJlIGRlcGxveWVkIGluIHRoZSBzZXJ2ZXIu IFRoZSBzYW1lIHJlYXNvbiBhcHBseSBpZiB0aGUgaG9zdHMgd2FudCB0byBhZ2dyZWdhdGUgdGhl IGxpbmtzIG9yIHRvIGdyYWIgbW9yZSByZXNvdXJjZXMgZm9ybSBhbiBhbHRlcm5hdGUgYWNjZXNz LCBldGMuIA0KDQpPZiBjb3Vyc2UsIGlmIHRoZSBpc3N1ZSBpcyBsb2NhdGVkIHVwc3RyZWFtIHRo ZXNlIGFjY2VzcyBuZXR3b3JrcyAocmVhZCB0aGUgQ29udmVydGVyKSwgd2UgY2FuJ3QgZG8gbXVj aCBpZiB0aGUgc2VydmVyIGlzIG5vdCBNUFRDUC1jYXBhYmxlLiBUaGF0J3Mgd2h5IHRoZSBwcm90 b2NvbCBpcyBkZXNpZ24gdG8gZW5jb3VyYWdlIHRoZSB1c2Ugb2YgYW4gZXh0ZW5zaW9uIG92ZXIg dGhlIGZ1bGwgcGF0aCBhbmQgdG8gd2l0aGRyYXcgdGhlIENvbnZlcnRlciB3aGVuIGl0IG1ha2Vz IHNlbnNlLg0KDQo+IA0KPiBUaGUgZHJhZnQgd291bGQgYmVuZWZpdCBmcm9tIGVpdGhlciBwcmVz ZW50aW5nIGRpc2N1c3NpbmcgZW5oYW5jZW1lbnRzDQo+IHZlcnN1cyBvc3NpZmljYXRpb24sIGFu ZA0KPiBhY2tub3dsZWRnaW5nIHRoYXQgaW4gbW9zdCBjYXNlcyBhIGRpcmVjdCBjb25uZWN0aW9u IGJldHdlZW4gY2xpZW50DQo+IGFuZCBzZXJ2ZXIgcHJvdmlkZXMgYmV0dGVyDQo+IHNlcnZpY2Vz IHRoYW4gYSBjb25uZWN0aW9uIG1lZGlhdGVkIGJ5IGEgcHJveHkuIA0KDQpbTWVkXSBJc24ndCB0 aGF0IGFscmVhZHkgY292ZXJlZCBieSB0aGUgZm9sbG93aW5nOg0KDQogICBUaGlzIGRvY3VtZW50 IGRvZXMgbm90IGFzc3VtZSB0aGF0IGFsbCB0aGUgdHJhZmZpYyBpcyBlbGlnaWJsZSB0byB0aGUN CiAgIG5ldHdvcmstYXNzaXN0ZWQgY29udmVyc2lvbiBzZXJ2aWNlLiAgT25seSBhIHN1YnNldCBv ZiB0aGUgdHJhZmZpYw0KICAgd2lsbCBiZSBmb3J3YXJkZWQgdG8gYSBUcmFuc3BvcnQgQ29udmVy dGVyIGFjY29yZGluZyB0byBhIHNldCBvZg0KICAgcG9saWNpZXMuICBUaGVzZSBwb2xpY2llcywg YW5kIGhvdyB0aGV5IGFyZSBjb21tdW5pY2F0ZWQgdG8NCiAgIGVuZHBvaW50cywgYXJlIG91dCBv ZiBzY29wZS4gIEZ1cnRoZXJtb3JlLCBpdCBpcyBwb3NzaWJsZSB0byBieXBhc3MNCiAgIHRoZSBU cmFuc3BvcnQgQ29udmVydGVyIHRvIGNvbm5lY3QgZGlyZWN0bHkgdG8gdGhlIHNlcnZlcnMgdGhh dA0KICAgXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl4NCiAgIGFscmVhZHkgc3VwcG9ydCB0aGUgcmVxdWlyZWQgVENQIGV4dGVuc2lv bihzKS4NCiAgIF5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eDQoN CkFuZA0KDQogICBUaGUgdXNlIG9mIGEgVHJhbnNwb3J0IENvbnZlcnRlciBtZWFucyB0aGF0IHRo ZXJlIGlzIG5vIGVuZC10by1lbmQNCiAgIHRyYW5zcG9ydCBjb25uZWN0aW9uIGJldHdlZW4gdGhl IGNsaWVudCBhbmQgc2VydmVyLiAgVGhpcyBjb3VsZA0KICAgcG90ZW50aWFsbHkgY3JlYXRlIHBy b2JsZW1zIGluIHNvbWUgc2NlbmFyaW9zIHN1Y2ggYXMgdGhvc2UgZGlzY3Vzc2VkDQogICBpbiBT ZWN0aW9uIDQgb2YgW1JGQzMxMzVdLg0KDQpBbmQgDQoNCiAgIFRoZSBtYWluIGFkdmFudGFnZSBv ZiBuZXR3b3JrLWFzc2lzdGVkIGNvbnZlcnNpb24gc2VydmljZXMgaXMgdGhhdA0KICAgdGhleSBl bmFibGUgbmV3IFRDUCBleHRlbnNpb25zIHRvIGJlIHVzZWQgb24gYSBzdWJzZXQgb2YgdGhlIHBh dGgNCiAgIGJldHdlZW4gZW5kcG9pbnRzLCB3aGljaCBlbmNvdXJhZ2VzIHRoZSBkZXBsb3ltZW50 IG9mIHRoZXNlDQogICBleHRlbnNpb25zLiAgRnVydGhlcm1vcmUsIHRoZSBUcmFuc3BvcnQgQ29u dmVydGVyIGFsbG93cyB0aGUgY2xpZW50DQogICBhbmQgdGhlIHNlcnZlciB0byBkaXJlY3RseSBu ZWdvdGlhdGUgVENQIGV4dGVuc2lvbnMgZm9yIHRoZSBzYWtlIG9mDQogICAgICAgICAgICAgICAg ICAgICBeXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl4NCiAg IG5hdGl2ZSBzdXBwb3J0IGFsb25nIHRoZSBmdWxsIHBhdGguDQogICBeXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl4NCg0KT3IsIGlmIHRoZSBhdXRob3JzIGRvDQo+IG5vdCB3YW50IHRv IHNheSB0aGF0LCB0aGV5DQo+IGNvdWxkIG1ha2UgdGhlIGRyYWZ0IHNob3J0ZXIgYW5kIGVhc2ll ciB0byByZWFkIGJ5IHJlbW92aW5nIG1vc3Qgb2YNCj4gdGhlIG1hdGVyaWFsIGluIHNlY3Rpb24N Cj4gMSBhbmQgMiwgYW5kIHNpbXBseSBzdGF0aW5nIHRoYXQgdGhleSBwcmVzZW50IGhlcmUgYSBw cm90b2NvbCBmb3INCj4gaW50ZXJhY3Rpbmcgd2l0aCBwcm94aWVzIHRoYXQNCj4gdGhleSB0aGlu ayBpcyBzdXBlcmlvciB0byBTb2NrcyA1LiBUaGUgcHJlc2VudGF0aW9uIG9mIHRoZSBwcm90b2Nv bA0KPiBvbmx5IHN0YXJ0cyBhZnRlciAyMCBwYWdlcw0KPiBvZiBpbnRyb2R1Y3Rpb24uIFJlZHVj aW5nIHRoYXQgbG9uZyBwcmVzZW50YXRpb24gdG8gMyBvciA0IHBhZ2VzIHdvdWxkDQo+IG1hcmtl ZGx5IGltcHJvdmUNCj4gcmVhZGFiaWxpdHkuDQo+IA0KPiBXaGVuIGEgY2xpZW50IHVzZXMgYSBw cm94eSwgdGhlIHNlcnZlciB3aWxsIG5vcm1hbGx5IHNlZSB0aGUgVENQDQo+IGNvbm5lY3Rpb24g YXMgb3JpZ2luYXRpbmcNCj4gZnJvbSB0aGUgc291cmNlIGFkZHJlc3Mgb2YgYSBwcm94eS4gVGhl IGRyYWZ0IHN1cHBvcnRzIHRoYXQgbW9kZSBvZg0KPiBvcGVyYXRpb24sIGFzIGV4cGxhaW5lZA0K PiBpbiBzZWN0aW9ucyA0LjMgYW5kIDQuNC4gVGhlcmUgaXMgYSBkaXJlY3Qgc2VjdXJpdHkgaW1w bGljYXRpb24gaGVyZSwNCj4gYmVjYXVzZSB0aGUNCj4gY2xpZW50IGNhbm5vdCBiZSB0cmFja2Vk IGJ5IElQIGFkZHJlc3MuIE9uIG9uZSBoYW5kIHRoaXMgbWF5IGltcHJvdmUgYQ0KPiBjbGllbnQn cyBwcml2YWN5LCBidXQNCj4gb24gdGhlIG90aGVyIGhhbmQgdGhpcyBjcmVhdGVzIGEgbWFuYWdl bWVudCBwcm9ibGVtIHNpbWlsYXIgdG8gdGhhdA0KPiBlbmNvdW50ZXJlZCB3aXRoDQo+IGNhcnJp ZXIgZ3JhZGUgTkFUIChDR04pLiBJbiBwcmFjdGljZSwgbmV0d29yayBtYW5hZ2VycyBoYXZlIHRv IGJlIGFibGUNCj4gdG8gaWRlbnRpZnkgdGhlIGNsaWVudA0KPiB3aG8gb3JpZ2luYXRlZCBhIHNw ZWNpZmljIFRDUCBjb25uZWN0aW9uLiBGb3IgQ0dOLCB0aGF0IHRyYW5zbGF0ZXMNCj4gaW50byBv bmVyb3VzIGxvZ2dpbmcNCj4gcmVxdWlyZW1lbnRzLiBUaGlzIHNob3VsZCBiZSBkaXNjdXNzZWQg aW4gdGhlIHNlY3VyaXR5IHNlY3Rpb24uDQo+IA0KPiANCg0KW01lZF0gQWdyZWUuIFdlIGF2b2lk ZWQgdG8gaW5jbHVkZSBzdWNoIGRldGFpbHMgYmVjYXVzZSB0aGVzZSBhcmUgZGVwbG95bWVudC1z cGVjaWZpYyAoZHJhZnQtbmFtLW1wdGNwLWRlcGxveW1lbnQtY29uc2lkZXJhdGlvbnMtMDEjc2Vj dGlvbi01LjYuNykuIEJ1dCBpZiB5b3UgdGhpbmsgdGhpcyBpcyB1c2VmdWwgdG8gcmVjb3JkLCB3 ZSBjYW4gcmVpbnNlcnQgdGhlIHRleHQ6DQoNClguWC4gIExvZ2dpbmcNCg0KICAgSWYgdGhlIENv bnZlcnRlciBpcyBjb25maWd1cmVkIHRvIGJlaGF2ZSBpbiB0aGUgYWRkcmVzcyBzaGFyaW5nIG1v ZGUsIHRoZQ0KICAgbG9nZ2luZyByZWNvbW1lbmRhdGlvbnMgZGlzY3Vzc2VkIGluIFNlY3Rpb24g NCBvZiBbUkZDNjg4OF0gbmVlZCB0bw0KICAgYmUgY29uc2lkZXJlZC4gIFNlY3VyaXR5LXJlbGF0 ZWQgaXNzdWVzIGVuY291bnRlcmVkIGluIGFkZHJlc3MNCiAgIHNoYXJpbmcgZW52aXJvbm1lbnRz IGFyZSBkb2N1bWVudGVkIGluIFNlY3Rpb24gMTMgb2YgW1JGQzYyNjldLiAgDQoNCg== From nobody Tue Mar 3 16:17:17 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBAD3A08FA; Tue, 3 Mar 2020 16:17:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stephen Farrell via Datatracker To: Cc: draft-ietf-tsvwg-datagram-plpmtud.all@ietf.org, last-call@ietf.org, tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158328103137.7648.9240148667630328703@ietfa.amsl.com> Reply-To: Stephen Farrell Date: Tue, 03 Mar 2020 16:17:11 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-tsvwg-datagram-plpmtud-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2020 00:17:13 -0000 Reviewer: Stephen Farrell Review result: Has Issues Hi, As Hilary Orman always nicely says: do not be alarmed, this is just a secdir review:-) I classed this as "has issues," but the issues below should be fairly easy to fix. Maybe all but 2 are real issues that say are worth fixing, if I'm right about 'em (but I'm also often wrong too:-) Cheers, S. - Abstract: This draft aims for proposed standard but is updating a BCP (RFC8085/BCP145). I'm happy to leave the process-lawyering for that to others. - 4.1: I'm not sure if this is recommending that PLs allow for padding outside of cryptographic protection. If so, that seems like an anti-pattern when considering the overall set of requirements one might envisage for a PL. If not, that's fine, but would it be worth stating that? - 4.4: Would you count the AEAD tag length in the MPS of an AEAD-encrypting PL or not? I assume not, and the tag length is counted as PL overhead even if sent as a sort-of trailer within the ciphertext? - 4.4: What'd be the MPS etc for an MP-TCP-like PL? Is that well-defined? - 4.5: (a nit) "The validation SHOULD utilize information that it is not simple for an off-path attacker to determine [RFC8085]." A SHOULD that's that vague seems likely prone to issues. Might be best to just s/SHOULD/ought/ or something like that. - 6.2.3: what if TLS record layer padding is being done as well? Probably just needs a mention, so people don't get their sums/APIs wrong. - 6.3: I am surprised that the QUIC description here is ready to be an RFC before QUIC itself. I do see there are normative references, but the potential for a breaking change still exists, and seems a bit unwise. (I'd suggest, holding this in the WG 'till the referenced QUIC drafts are in the RFC editor queue, or else taking that bit out and putting it into a new I-D.) - section 9: Ok this is a stretch so maybe not worth bothering with but... A PL doing all this may be emitting oddly sized padding octets from time to time that piggy-back on application data. That (number of padding octets and the pattern with which those are emitted) seems like a medium-nice covert channel e.g. for exfiltrating data, not necessarily to the packet destination but to anyone on-path who can observe the signal. From nobody Wed Mar 4 07:55:43 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5A43A11EE; Wed, 4 Mar 2020 07:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dP4X4bnAYW_B; Wed, 4 Mar 2020 07:55:29 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id D38933A1186; Wed, 4 Mar 2020 07:55:28 -0800 (PST) Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id D168F1B003B1; Wed, 4 Mar 2020 15:55:20 +0000 (GMT) To: Stephen Farrell , secdir@ietf.org Cc: draft-ietf-tsvwg-datagram-plpmtud.all@ietf.org, last-call@ietf.org, tsvwg@ietf.org References: <158328103137.7648.9240148667630328703@ietfa.amsl.com> From: Gorry Fairhurst Message-ID: Date: Wed, 4 Mar 2020 15:55:20 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <158328103137.7648.9240148667630328703@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-tsvwg-datagram-plpmtud-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2020 15:55:38 -0000 Thanks for this review Stephen. On 04/03/2020 00:17, Stephen Farrell via Datatracker wrote: > Reviewer: Stephen Farrell > Review result: Has Issues > > > Hi, > > As Hilary Orman always nicely says: do not be alarmed, > this is just a secdir review:-) > > I classed this as "has issues," but the issues below should be > fairly easy to fix. Maybe all but 2 are real issues that say are > worth fixing, if I'm right about 'em (but I'm also often wrong > too:-) > > Cheers, > S. > > - Abstract: This draft aims for proposed standard but is > updating a BCP (RFC8085/BCP145). I'm happy to leave the > process-lawyering for that to others. We spoke with our TSV ADs and they  don't see any issue with this. BCP and Standards track are equivalent. > - 4.1: I'm not sure if this is recommending that PLs allow for > padding outside of cryptographic protection. If so, that > seems like an anti-pattern when considering the overall set of > requirements one might envisage for a PL. If not, that's fine, > but would it be worth stating that? We suggest adding to the security considerations, see later. > - 4.4: Would you count the AEAD tag length in the MPS of an > AEAD-encrypting PL or not? I assume not, and the tag length > is counted as PL overhead even if sent as a sort-of trailer > within the ciphertext? Yes, all PL-overhead is included, but I think worth noting explicitly in Section 4.1 to avoid doubt. I suggest we add: OLD: Protocols that permit exchange of control messages (without an application data block) can generate a probe packet by extending a control message with padding data. NEW: Protocols that permit exchange of control messages (without an application data block) can generate a probe packet by extending a control message with padding data. The total size of a probe packet includes all headers and padding added to the payload data being sent (e.g., including protocol option fields, security-related fields such as an AEAD tag and TLS record layer padding). > - 4.4: What'd be the MPS etc for an MP-TCP-like PL? Is that > well-defined? For MP-TCP this isn't an issue, but each PL could have it's own issues and needs to work out what MPS means. > - 4.5: (a nit) "The validation SHOULD utilize information that > it is not simple for an off-path attacker to determine > [RFC8085]." A SHOULD that's that vague seems likely prone to > issues. Might be best to just s/SHOULD/ought/ or something > like that. RFC8085 does provide some examples, and this is a common-enough transport requirement to protect from DDOS. Could the SHOULD be retained and this be fixed by a more specific reference perhaps? (see Section 5.1 of [RFC8085]). > - 6.2.3: what if TLS record layer padding is being done as > well? Probably just needs a mention, so people don't get > their sums/APIs wrong. Agree. Please see proposeed text above and the proposed adds to the security considerations below. > - 6.3: I am surprised that the QUIC description here is ready > to be an RFC before QUIC itself. I do see there are > normative references, but the potential for a breaking change > still exists, and seems a bit unwise. (I'd suggest, holding > this in the WG 'till the referenced QUIC drafts are in the RFC > editor queue, or else taking that bit out and putting it into > a new I-D.) > > - section 9: Ok this is a stretch so maybe not worth bothering > with but... A PL doing all this may be emitting oddly sized > padding octets from time to time that piggy-back on > application data. That (number of padding octets and the > pattern with which those are emitted) seems like a medium-nice > covert channel e.g. for exfiltrating data, not necessarily to > the packet destination but to anyone on-path who can observe > the signal. I think this is useful. Security thoughts are always welcome. How about adding two extra paras to the Security Considerations, are these near?: "DPLPMTUD methods can introduce padding data to inflate the length of the datagram to the total size required for a probe packet. The total size of a probe packet includes all headers and padding added to the payload data being sent (e.g., including security-related fields such as an AEAD tag and TLS record layer padding). The value of the padding data does not influence the DPLPMTUD search algorithm, and therefore needs to be set consistent with the policy of the PL.  A secure PL MUST provide cryptographic protection for the padding if this is needed to satisfy the security requirements of that PL. A PL that implements this spec would send probe packets, whose size and frequency can be observed by the network. Designers of search algorithms need to consider whether the size of probe packets and the pattern of probing could result in a potential covert channel (e.g., for exfiltrating data to an on-path device or the endpoint of the connection). " Gorry > From nobody Wed Mar 4 18:41:47 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D983A0935; Wed, 4 Mar 2020 18:41:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 VZ5w7MddQroC; Wed, 4 Mar 2020 18:41:44 -0800 (PST) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 86A6A3A0934; Wed, 4 Mar 2020 18:41:40 -0800 (PST) Received: by mail-ed1-x52b.google.com with SMTP id g19so4833688eds.11; Wed, 04 Mar 2020 18:41:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=PCPZeEC2rfvPSfuuILrYiOlhBm3+URtTTEeC43KBKew=; b=lK/X/qpRWIbe4Aw2Du+9T1ki3WxiAcxEu1WT4BJzxLsrHxP0s3B4eOZIbiwoxWEHVy RI+GG93YCp3x1iQputf98jAdMv95J2YEiKK+JcNThvvLMXuT/HAkJ4G6dgQf7pQjiqz6 4FWSMlNo+cowjy13qc5XNS7PRT77UQCAPnf4VsIArKJsUlxxUIKNYnISFP86EcMsPA/r 5Rbpo+W4L1lYajNSQV0FkFgPhrGwqEdeDlP7LxJiCwI22t2Y70JN32oleNvGU4YKfK/3 TocPoGWFuKatxvbiISeTiCOZPYjFSxr2M8wrWpmCWoclyQfOZINE7TjXBPBxcIuQvMFx QlGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=PCPZeEC2rfvPSfuuILrYiOlhBm3+URtTTEeC43KBKew=; b=oXNqv9QSflmbmv2Xlhn54O+tQ8C4XFo/2ULvq0N6q5VJ+lwScpZzcjqmENCLT2efWZ 3ydCcNVOBQ6lhQiUSd90pp/TXb4pFVIgZbPNiaHT9yaeSAfR+/GKa/Fd02q0O5Bl4iqk RG7KGGyHgpzVBzHsT7vSzZK91TXg875r4po9JelFkh2ckSiE/asxo633h8jcj+D8f6Oc uUw77xVhc3MLk1eZU8YD/9lsvg7l0T6URXM5VVGJ5JmXY7aOwxf+AKevGMchW8ayX6Jp lZ8AcMnV3PrNk1kCdNqlzggDQ8zzT1QARakwlI9sevUEtPRefCexFvI6YzwUu5K94JPK 6llg== X-Gm-Message-State: ANhLgQ2Xlo1+dayPdftA1FXq2w0hofGuy4HAp61ZzUjhXsBA1YsxXcGg 85RAacoCznocSj28kL/730J9wGyP99ZmkYlaAAcWP13k9w0= X-Google-Smtp-Source: ADFU+vsiUj22M9dp8np+MH9C8liTPaohmaMWLdg5LSo0M8UY0u/+oj9Bjy+UuE0GEQUCTpGtFcn9avedNrQVcXPZqzc= X-Received: by 2002:a50:fc85:: with SMTP id f5mr5863338edq.294.1583376098653; Wed, 04 Mar 2020 18:41:38 -0800 (PST) MIME-Version: 1.0 From: Shawn Emery Date: Wed, 4 Mar 2020 19:41:27 -0700 Message-ID: To: secdir Cc: draft-gellens-lost-validation.all@ietf.org, last-call@ietf.org, Shawn Emery Content-Type: multipart/alternative; boundary="000000000000e7fbf905a012792e" Archived-At: Subject: [secdir] Review of draft-gellens-lost-validation-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 02:41:46 -0000 --000000000000e7fbf905a012792e Content-Type: text/plain; charset="UTF-8" Reviewer: Shawn M. Emery Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft specifies an IANA registry for the Location-to-Service Translation (LoST) Protocol Validation Service Tag under U-NAPTR. The security considerations section does exist and refers to RFC 3958 and 4848. I agree that this change does not introduce any new security considerations. General comments: None. Editorial comments: Abbreviations should be expanded in the title of the draft and when first used (in this case the Abstract). s/...// Shawn. -- --000000000000e7fbf905a012792e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Reviewer: Shawn M. Emery
Review result: Ready

I = have reviewed this document as part of the security directorate's
on= going effort to review all IETF documents being processed by the IESG.
T= hese comments were written primarily for the benefit of the security
are= a directors. Document editors and WG chairs should treat these
comments = just like any other last call comments.

This draft specifies an IANA= registry for the Location-to-Service Translation
(LoST) Protocol Valid= ation Service Tag under U-NAPTR.

The security considerations sectio= n does exist and refers to RFC 3958 and 4848.
I agree that this c= hange does not introduce any new security considerations.

General comments:

None.

Editorial comments:
<= /div>

Abbreviations should be expanded in the title of t= he draft and when first used (in this case the Abstract).
s/...//=

Shawn.
--
--000000000000e7fbf905a012792e-- From nobody Thu Mar 5 03:57:08 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDF23A1246 for ; Thu, 5 Mar 2020 03:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.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 j-lzGviD0h-5 for ; Thu, 5 Mar 2020 03:56:58 -0800 (PST) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 8A5D63A136E for ; Thu, 5 Mar 2020 03:56:58 -0800 (PST) Received: by mail-qt1-x82c.google.com with SMTP id a4so3851530qto.12 for ; Thu, 05 Mar 2020 03:56:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=zgcPhg9J3GtD8VyoZu0bP7QLZ0kZdgpami7jXpZgb+g=; b=TNT0to5B1pgGt3OvvIGygzxVbk5FePKB5eKAq1dlW7f/eRQ7KN0Txxz81igavBIpUQ NmWO8vlzPpd3xGSiVFKQpclgk6HaSxva7nyw/y7os+05TJ8LOs/kfWs5BnKhE0DJSdkx cQAbBhrwqiqMGel7PPmOM83lOAjyCDIjWmiMg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=zgcPhg9J3GtD8VyoZu0bP7QLZ0kZdgpami7jXpZgb+g=; b=jYMobbOuXNiRVwMk34BklopzkJHLibDuyEFUN5VX50VW4sU7aB2duYiLFTkDmTA23b fmBUsiFeYMVPgo5sCAr/7OnUEb7usKjFAQRMX2bNrv481O63sFqafWNbK+Ky6YwksaF+ Eh7pqDrqG9Oaqf/Ssi/SOXQRf+ad8KqvNHSijFXQcVCDicagZAHxF6L1TJbjgrR+P8E7 samAMu+5YiIch2kG6CApiCv0eSP5BOOTjkEezFS/Lhg9Lmlue5oYrjKZJngbYPTBhZQ9 NxNHuRmN6AwbVGYXNc5gm+ga8w1jLPVDkCIwZjs/BzxRTWbrP2OMbxnqZdfXKZHIz7en e/AQ== X-Gm-Message-State: ANhLgQ36bQCdgUXjypv7Q090TVP5P/xBeWeFN9xp5ED6hcWlPCLQWv0E njspwg7XD56SBlEXl6OFoAUs8ja7JkY= X-Google-Smtp-Source: ADFU+vtKcwNlJv3y/cllXQwYwBsBLhsjMspNem3oT6BvCPJ11a9/P2WfW/SR9oaDB3V4p9Bo/7rQRA== X-Received: by 2002:ac8:c4f:: with SMTP id l15mr6875561qti.177.1583409417548; Thu, 05 Mar 2020 03:56:57 -0800 (PST) Received: from [192.168.2.6] (pool-173-73-189-140.washdc.fios.verizon.net. [173.73.189.140]) by smtp.googlemail.com with ESMTPSA id j17sm16180116qth.27.2020.03.05.03.56.55 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 05 Mar 2020 03:56:56 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.7.6.170621 Date: Thu, 05 Mar 2020 06:57:35 -0500 From: Carl Wallace To: CC: , Message-ID: Thread-Topic: secdir review of draft-ietf-hip-native-nat-traversal References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-hip-native-nat-traversal X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 11:57:07 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This is an update to a review performed for -28 draft to cover text in current -30 version. The primary differences since that draft is the addition of clarifying text, mostly regarding differences with Legacy ICE-HIP and rationale for current draft. The new language is helpful. The draft is ready for publication. On 3/8/18, 8:26 PM, "Carl Wallace" wrote: >I have reviewed this document as part of the security directorate's >ongoing effort to review all IETF documents being processed by the IESG. >These comments were written primarily for the benefit of the security area >directors. Document editors and WG chairs should treat these comments just >like any other last call comments. > >This document specifies a new Network Address Translator (NAT) traversal >mode for the Host Identity Protocol (HIP). While I am not a HIP guy, it >seems ready for publication. It's well-written and the security >considerations section is thorough. The only bit that raised a question >was in section 4, which states "it should be noted that HIP version 2 >[RFC7401 ] instead of HIPv1 is >expected to be used with this NAT traversal mode". Earlier in the >document, it states the draft is based on HIPv2. Are there any >considerations worth noting in the cases where HIPv1 is used or should >section 4 be revised to require v2? > > From nobody Thu Mar 5 04:47:11 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E3C3A1410; Thu, 5 Mar 2020 04:47:09 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjYHh1X6R0mY; Thu, 5 Mar 2020 04:47:07 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84A4A3A140F; Thu, 5 Mar 2020 04:47:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DF420BE8A; Thu, 5 Mar 2020 12:47:01 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obLYNGWXirTg; Thu, 5 Mar 2020 12:47:01 +0000 (GMT) Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 948F0BE79; Thu, 5 Mar 2020 12:47:01 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1583412421; bh=lsSIHxf9DTfJcqxuHi4hZ2wxt14y2JsXZOZwp7YmYvY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=kyU2EBGbBWBPiV0Wi2kcHGdzsQC2OmlwGJQ19WKEwla3d/r9sAlln5VpWUQnbIul0 i2B8kQWMi0STzmLijaHhFWMeI1mDem6MVD8CLU8o7MiGc6KmpIlvDDZOX9SNiZfkJ5 220FKOiJD89jay9ksbuUAYI8b1CzlfDZeSZ2gVHM= To: Gorry Fairhurst , secdir@ietf.org Cc: draft-ietf-tsvwg-datagram-plpmtud.all@ietf.org, last-call@ietf.org, tsvwg@ietf.org References: <158328103137.7648.9240148667630328703@ietfa.amsl.com> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <5c00c98f-0e8b-a164-6c4e-7d4457249e81@cs.tcd.ie> Date: Thu, 5 Mar 2020 12:47:00 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ZA9oDIhSBPTmjRlDBXZFC7WFVJgMxmeEP" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-tsvwg-datagram-plpmtud-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 12:47:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ZA9oDIhSBPTmjRlDBXZFC7WFVJgMxmeEP Content-Type: multipart/mixed; boundary="o1vbn6Uv7op3qZNaquayNdZWrCa3MFGWj"; protected-headers="v1" From: Stephen Farrell To: Gorry Fairhurst , secdir@ietf.org Cc: draft-ietf-tsvwg-datagram-plpmtud.all@ietf.org, last-call@ietf.org, tsvwg@ietf.org Message-ID: <5c00c98f-0e8b-a164-6c4e-7d4457249e81@cs.tcd.ie> Subject: Re: Secdir last call review of draft-ietf-tsvwg-datagram-plpmtud-15 References: <158328103137.7648.9240148667630328703@ietfa.amsl.com> In-Reply-To: --o1vbn6Uv7op3qZNaquayNdZWrCa3MFGWj Content-Type: multipart/mixed; boundary="------------E448153B1A0399E13315C2D4" Content-Language: en-US This is a multi-part message in MIME format. --------------E448153B1A0399E13315C2D4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Gorry, On 04/03/2020 15:55, Gorry Fairhurst wrote: > Thanks for this review Stephen. >=20 > On 04/03/2020 00:17, Stephen Farrell via Datatracker wrote: >> Reviewer: Stephen Farrell Review result: Has Issues >>=20 >>=20 >> Hi, >>=20 >> As Hilary Orman always nicely says: do not be alarmed, this is just >> a secdir review:-) >>=20 >> I classed this as "has issues," but the issues below should be=20 >> fairly easy to fix. Maybe all but 2 are real issues that say are=20 >> worth fixing, if I'm right about 'em (but I'm also often wrong=20 >> too:-) >>=20 >> Cheers, S. >>=20 >> - Abstract: This draft aims for proposed standard but is updating a >> BCP (RFC8085/BCP145). I'm happy to leave the process-lawyering for >> that to others. > We spoke with our TSV ADs and they don't see any issue with this. > BCP and Standards track are equivalent. I'll leave you all to enjoy discussion of that in peace so;-) >> - 4.1: I'm not sure if this is recommending that PLs allow for=20 >> padding outside of cryptographic protection. If so, that seems like >> an anti-pattern when considering the overall set of requirements >> one might envisage for a PL. If not, that's fine, but would it be >> worth stating that? > We suggest adding to the security considerations, see later. Ack. >> - 4.4: Would you count the AEAD tag length in the MPS of an=20 >> AEAD-encrypting PL or not? I assume not, and the tag length is >> counted as PL overhead even if sent as a sort-of trailer within the >> ciphertext? >=20 > Yes, all PL-overhead is included, but I think worth noting explicitly > in Section 4.1 to avoid doubt. I suggest we add: >=20 > OLD: Protocols that permit exchange of control messages (without an > application data block) can generate a probe packet by extending a > control message with padding data.=20 > NEW: Protocols that permit > exchange of control messages (without an application data block) can > generate a probe packet by extending a control message with padding > data. The total size of a probe packet includes all headers and > padding added to the payload data being sent (e.g., including > protocol option fields, security-related fields such as an AEAD tag > and TLS record layer padding). I like the NEW text. But I'm still not clear if a 16 octet AEAD tag is to be subtracted from the MPS or not;-) I guess that'd depend on e.g. the specific ciphersuite in use and so could vary? That might be just me though - I've always found discussion about packet size limits ambiguous as some people do and some do not account for overhead when they talk about sizes. Maybe if you gave an example that'd make it crystal clear even for the likes of me? >=20 >> - 4.4: What'd be the MPS etc for an MP-TCP-like PL? Is that=20 >> well-defined? >=20 > For MP-TCP this isn't an issue, but each PL could have it's own > issues and needs to work out what MPS means. Ok. >=20 >> - 4.5: (a nit) "The validation SHOULD utilize information that it >> is not simple for an off-path attacker to determine [RFC8085]." A >> SHOULD that's that vague seems likely prone to issues. Might be >> best to just s/SHOULD/ought/ or something like that. >=20 > RFC8085 does provide some examples, and this is a common-enough=20 > transport requirement to protect from DDOS. Could the SHOULD be > retained and this be fixed by a more specific reference perhaps? >=20 > (see Section 5.1 of [RFC8085]). Yeah, that seems right. >=20 >> - 6.2.3: what if TLS record layer padding is being done as well? >> Probably just needs a mention, so people don't get their sums/APIs >> wrong. > Agree. Please see proposeed text above and the proposed adds to the=20 > security considerations below. Ack. >> - 6.3: I am surprised that the QUIC description here is ready to be >> an RFC before QUIC itself. I do see there are normative references, >> but the potential for a breaking change still exists, and seems a >> bit unwise. (I'd suggest, holding this in the WG 'till the >> referenced QUIC drafts are in the RFC editor queue, or else taking >> that bit out and putting it into a new I-D.) I'll leave that one so:-) It's not a security issue, so for the purposes of a secdir review, it oughtn't be a blocker of any sort. >>=20 >> - section 9: Ok this is a stretch so maybe not worth bothering with >> but... A PL doing all this may be emitting oddly sized padding >> octets from time to time that piggy-back on application data. That >> (number of padding octets and the pattern with which those are >> emitted) seems like a medium-nice covert channel e.g. for >> exfiltrating data, not necessarily to the packet destination but to >> anyone on-path who can observe the signal. >=20 > I think this is useful. Security thoughts are always welcome. How > about adding two extra paras to the Security Considerations, are > these near?: >=20 > "DPLPMTUD methods can introduce padding data to inflate the length > of the datagram to the total size required for a probe packet. The > total size of a probe packet includes all headers and padding added > to the payload data being sent (e.g., including security-related > fields such as an AEAD tag and TLS record layer padding). The value > of the padding data does not influence the DPLPMTUD search algorithm, > and therefore needs to be set consistent with the policy of the PL. > A secure PL MUST provide cryptographic protection for the padding if > this is needed to satisfy the security requirements of that PL. That seems almost ok:-) I'd maybe switch the last sentence around to say something like: "If a PL can make use of cryptographic confidentiality or data-integrity mechanisms, then adding anything (incl. padding) for DPLPMTUD that is not protected by those cryptographic mechanisms is an anti- pattern to be avoided, even if technically possible." > A PL that implements this spec would send probe packets, whose size > and frequency can be observed by the network. Designers of search > algorithms need to consider whether the size of probe packets and the > pattern of probing could result in a potential covert channel (e.g., > for exfiltrating data to an on-path device or the endpoint of the=20 > connection). " WFM, Thanks, S. >=20 > Gorry >=20 >>=20 --------------E448153B1A0399E13315C2D4 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------E448153B1A0399E13315C2D4-- --o1vbn6Uv7op3qZNaquayNdZWrCa3MFGWj-- --ZA9oDIhSBPTmjRlDBXZFC7WFVJgMxmeEP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl5g9MQACgkQWrL68XsX K+oULA/+IWqB90R+hP5I+ZKr78ad2+WtNXHTgBCfC4g6jdN1D/atYDwCI2cMxZLl VECRjbuCR+042h8wVNnQpLI4MzzVQEmSKKSqzoI7StAhLptCMCMZ6XbCGM/+nHmq /Lcs+7ygcoqa48c9CwgEtfstRFlgsxmylaAyFB0tyWe4bdgJ9c1gr5woG04zoPk7 469AoHX6GihMsmB/03lR/fX7Bkw/f5Fhcbp/+Ji+Kw6AxU+OuXauhw37LLsnwPW4 9h4qF+Hgz47ehXQMS6jFklUoOt7UYDVomSkZNgB7TooS6KzD8A0KevzY0Z4f9XvM fINRTYMc6blWKEox18nrU7SJRCneh1A3L5mUdr1uOGZR/0XGwqzI47OuIAiE2Hqn TaUTEmqxlfec7W0llg3H6IOtoipDFgeqc5S2BItzfCTPf9mRQALbg2vyUVUjT8wk WEnEq+z/qdQaxHfK7mIhO39eoJuAP/P94lWnJymF2r0fr73TUKf/KLnoPQKKoVFH lHFoutjrXDnFxrWCSsvKwJEJxYPI13LMresvACVwXOFqIl8I5vOxbRmyjvu/p99Z 2zBk0b854D5bPVPYgo3qQIadfGRPStX0PA/C7c/vQf4ptF8qXC5kHkR27uCRIMpE YkEhZ1Pkz3Uon/V3JFL+i03KxfqjeLud2MpiBI2xcT0LLfdp7Ig= =4Xpe -----END PGP SIGNATURE----- --ZA9oDIhSBPTmjRlDBXZFC7WFVJgMxmeEP-- From nobody Thu Mar 5 08:23:50 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5653A17D5; Thu, 5 Mar 2020 08:23:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.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 BwE5eMtssn2X; Thu, 5 Mar 2020 08:23:30 -0800 (PST) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 553203A17AC; Thu, 5 Mar 2020 08:23:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 29C67E2040; Thu, 5 Mar 2020 11:23:25 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 31276-10; Thu, 5 Mar 2020 11:23:24 -0500 (EST) Received: from securerf.ihtfp.org (unknown [192.168.2.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 2AEE1E203F; Thu, 5 Mar 2020 11:23:24 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1583425404; bh=8+geqgJTerw8jHpQsqSRhQINCuPf5pHZKsSr97PIET4=; h=From:To:Cc:Subject:Date; b=KboOAV3RlbJJRsHbW7jwpOTO8eXPAUgmbJyDcjUuDhzeqet+MKRFwwEmCoGUfY4Fu 7yZVB7wiaoPRnQeIMj9vC1Knkty6hNFmSvx/AOijpMoWg8W/lXyHY1KkzGYUnpArkS n4tlPWCHNxbRdQKilr/tf44RxYOF7o5L+ATzvUV8= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.15.2/Submit) id 025GNL2W023062; Thu, 5 Mar 2020 11:23:21 -0500 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Cc: git-chairs@ietf.org, mt@lowentropy.net, barbara.stark@att.com Date: Thu, 05 Mar 2020 11:23:20 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: [secdir] sec-dir review of draft-ietf-git-using-github-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 16:23:43 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: * Ready to publish Details: * Well written and possibly applicable well beyond the IETF! -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Mar 6 14:51:09 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 646E63A0CDA for ; Fri, 6 Mar 2020 14:51:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <158353506839.2240.4678289457833526679@ietfa.amsl.com> Date: Fri, 06 Mar 2020 14:51:08 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2020 22:51:09 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2020-03-12 Reviewer LC end Draft John Bradley 2020-02-28 draft-ietf-regext-data-escrow-05 Donald Eastlake 2020-02-27 draft-ietf-6tisch-msf-11 Steve Hanna 2020-03-06 draft-ietf-ippm-multipoint-alt-mark-06 Dan Harkins 2020-03-06 draft-ietf-alto-incr-update-sse-20 Charlie Kaufman 2020-02-20 draft-ietf-lpwan-coap-static-context-hc-13 David Waltermire 2020-02-25 draft-ietf-6man-icmp-limits-07 For telechat 2020-04-09 Reviewer LC end Draft Donald Eastlake R2019-11-14 draft-ietf-hip-dex-13 Last calls: Reviewer LC end Draft John Bradley 2020-02-28 draft-ietf-regext-data-escrow-05 Shaun Cooley 2019-11-12 draft-ietf-regext-login-security-10 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-09 Donald Eastlake R2019-11-14 draft-ietf-hip-dex-13 Donald Eastlake 2020-02-27 draft-ietf-6tisch-msf-11 Daniel Franke 2020-03-09 draft-ietf-regext-dnrd-objects-mapping-06 Phillip Hallam-Baker 2020-03-09 draft-ietf-calext-jscalendar-25 Steve Hanna 2020-03-06 draft-ietf-ippm-multipoint-alt-mark-06 Dan Harkins 2020-03-06 draft-ietf-alto-incr-update-sse-20 Leif Johansson 2020-02-28 draft-ietf-tcpm-converters-18 Charlie Kaufman R2019-09-02 draft-ietf-ecrit-data-only-ea-21 Charlie Kaufman 2020-02-20 draft-ietf-lpwan-coap-static-context-hc-13 Scott Kelly 2020-03-18 draft-ietf-sidrops-ov-egress-01 Stephen Kent 2020-03-16 draft-ietf-netmod-factory-default-14 Tero Kivinen 2020-03-13 draft-ietf-detnet-ip-05 Watson Ladd 2020-03-13 draft-ietf-detnet-mpls-05 Chris Lonvick 2020-03-13 draft-ietf-detnet-data-plane-framework-04 Aanchal Malhotra 2020-03-12 draft-ietf-bess-vpls-multihoming-05 Russ Mundy 2020-01-02 draft-ietf-dprive-bcp-op-08 Sandra Murphy 2019-10-04 draft-ietf-mpls-ldp-yang-06 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-11 Stefan Santesson 2020-01-27 draft-ietf-dots-architecture-17 Takeshi Takahashi 2020-02-06 draft-ietf-mmusic-t140-usage-data-channel-11 Tina Tsou 2020-02-06 draft-ietf-6lo-backbone-router-19 Sean Turner None draft-ietf-opsawg-sdi-02 Carl Wallace R2018-02-26 draft-ietf-hip-native-nat-traversal-30 David Waltermire 2020-02-25 draft-ietf-6man-icmp-limits-07 Klaas Wierenga 2020-02-21 draft-ietf-lamps-5480-ku-clarifications-02 Dacheng Zhang 2020-03-12 draft-nottingham-how-did-that-get-into-the-repo-01 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Next in the reviewer rotation: David Mandelberg Catherine Meadows Daniel Migault Adam Montville Kathleen Moriarty Russ Mundy Sandra Murphy Yoav Nir Magnus Nystrom Hilarie Orman From nobody Sat Mar 7 13:18:09 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7FA3A1A89 for ; Sat, 7 Mar 2020 13:18:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdm7TKaw3Y0q for ; Sat, 7 Mar 2020 13:18:06 -0800 (PST) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 594A33A1A8D for ; Sat, 7 Mar 2020 13:18:06 -0800 (PST) Received: by mail-ed1-x529.google.com with SMTP id g19so7125392eds.11 for ; Sat, 07 Mar 2020 13:18:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DZC+kiBBvYx7VzJqCU1KqTOr+HJB5Q1/F58/ECiu6q8=; b=WvXsrSIybAMIFMmI4gAYCT7DvuGBEqvttOcitL7NQcEYGt0P5q7MwF6Sgph3jqwbUP KWhX0E0fRGpduPQ5i7qjFzoZgluwCaRzDIlJzaZ8koiXgWsIu8Rt6v6hMDNK8na/rcUG 8TV/3pknRj5jQ9uom+TFgTxIgcowydlIwTMK8DgQzfq1DAbVLgvCF7cy7JbV/OcGDJXE XwelvKXYQv1VbcywCC9NEvkzCnNHFdTbTUmvFXvlH2U9NMGg2YlEnzkYZqVux2lmLH30 wXjPfZKOAk8+cm21Gs/zgIirnLdPBu4J3Ze3ehCt0ndbyZw3CZb+laW+RTCg30RMs53w WXmg== 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=DZC+kiBBvYx7VzJqCU1KqTOr+HJB5Q1/F58/ECiu6q8=; b=udqR471VplsRL/4MT4Ms/HTEa+8fwGOhIf6bjTft10VySJWe2VVdiqLd+i5SS1Ve58 4C0w1xR1Yuo3bBti0SZ7+gtUhgKzCC0iIHGLVLDjcunFgnjvLmW9EqDJLFUwVYgbGGqE iHjO3RhGIijwXFkrscAOmU5VGNBHDgTbGdvzxaJOOabLdNphPM+He69ogAabt42QRLzo +qYClAq43tjmQgBTBmOXnnkthn4JW8OSUieig1v1mQd8J36r4k/zqASNsYvCSiNX1KXY RmFFJIBs4g6cHRrzuQuTETK8nvAcwL+xx8m4eqyap3ykghD+KomEK9LDNBo9MO7vTRjl 9g0w== X-Gm-Message-State: ANhLgQ0BZNmtoo1EVEiOSHs9DyQLTU9oOW27ikYbaIc1QjGvSJglSeMz wrkj7ee3Mb8Lv+pa5342rthNJoX/T7J/b5qIF/j+Uw== X-Google-Smtp-Source: ADFU+vuactAe/0/87UREG74SboUPFHSrTfGh0oc2abVk8cTI5o2kph40S2/yg0ialzaKdka/gq7WpopZBfst20BBq2Q= X-Received: by 2002:a05:6402:128c:: with SMTP id w12mr10035578edv.368.1583615884404; Sat, 07 Mar 2020 13:18:04 -0800 (PST) MIME-Version: 1.0 References: <158281546210.2262.1845082722013562869@ietfa.amsl.com> In-Reply-To: <158281546210.2262.1845082722013562869@ietfa.amsl.com> From: CARLOS JESUS BERNARDOS CANO Date: Sat, 7 Mar 2020 22:17:46 +0100 Message-ID: To: Vincent Roca Cc: secdir , dmm , last-call@ietf.org, draft-ietf-dmm-pmipv6-dlif.all@ietf.org Content-Type: multipart/alternative; boundary="00000000000040472305a04a4e3b" Archived-At: Subject: Re: [secdir] Secdir telechat review of draft-ietf-dmm-pmipv6-dlif-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2020 21:18:08 -0000 --00000000000040472305a04a4e3b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Vincent, Thanks a lot for your review. Please see inline below for my comments. On Thu, Feb 27, 2020 at 3:57 PM Vincent Roca via Datatracker < noreply@ietf.org> wrote: > Reviewer: Vincent Roca > Review result: Has Nits > > Hello, > > I have reviewed this document as part of the security directorate=E2=80= =99s ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments ju= st > like any other last call comments. > > Summary: Has Nits > > Thank you for the clarification of the Security Considerations section. > I just have a minor comment and a typo. > > - It is said (section 6): > "The CMD SHOULD use a pacing approach to limit > this amplification risk." > I agree, but where do you intend to apply pacing? In the incoming queue > (i.e., > by delaying some PBU/PBA messages) or in the outgoing queue (i.e., to lim= it > output traffic), or both? It's a bit unclear. > [CB] I meant limiting the output traffic. I've clarified this in version -06 (to be submitted soon). > > - Typo: remove one "exist" in sentence: "there may exist multiple previou= s > (e.g., k) MAARs exist." > > [CB] Fixed, thanks. Thanks again for your comments. Carlos > Regards, Vincent > > > --00000000000040472305a04a4e3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Vincent,

Thanks a l= ot for your review. Please see inline below for my comments.
On Thu, F= eb 27, 2020 at 3:57 PM Vincent Roca via Datatracker <noreply@ietf.org> wrote:
Reviewer: Vincent Roca
Review result: Has Nits

Hello,

I have reviewed this document as part of the security directorate=E2=80=99s= ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors.=C2=A0 Document editors and WG chairs should treat these comments= just
like any other last call comments.

Summary: Has Nits

Thank you for the clarification of the Security Considerations section.
I just have a minor comment and a typo.

- It is said (section 6):
=C2=A0 "The CMD SHOULD use a pacing approach to limit
=C2=A0 =C2=A0this amplification risk."
I agree, but where do you intend to apply pacing? In the incoming queue (i.= e.,
by delaying some PBU/PBA messages) or in the outgoing queue (i.e., to limit=
output traffic), or both? It's a bit unclear.

=
[CB] I meant limiting the output traffic. I've clarified thi= s in version -06 (to be submitted soon).
=C2=A0

- Typo: remove one "exist" in sentence: "there may exist mul= tiple previous
(e.g., k) MAARs exist."

[CB] Fixed, thanks.

Thanks a= gain for your comments.

Carlos
=C2=A0
Regards,=C2=A0 =C2=A0 Vincent


--00000000000040472305a04a4e3b-- From nobody Sat Mar 7 16:16:06 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B503A0D1F; Sat, 7 Mar 2020 00:14:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Klaas Wierenga via Datatracker To: Cc: draft-ietf-lamps-5480-ku-clarifications.all@ietf.org, spasm@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158356889211.18182.3861551159795927490@ietfa.amsl.com> Reply-To: Klaas Wierenga Date: Sat, 07 Mar 2020 00:14:52 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-lamps-5480-ku-clarifications-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2020 08:14:52 -0000 X-List-Received-Date: Sat, 07 Mar 2020 08:14:52 -0000 Reviewer: Klaas Wierenga Review result: Ready Nice, clear and short document. From nobody Sat Mar 7 16:29:24 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 81AF63A1DA2; Sat, 7 Mar 2020 16:29:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Steve Hanna via Datatracker To: Cc: last-call@ietf.org, ippm@ietf.org, draft-ietf-ippm-multipoint-alt-mark.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.120.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158362735547.25505.12722503226926557935@ietfa.amsl.com> Reply-To: Steve Hanna Date: Sat, 07 Mar 2020 16:29:15 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-ippm-multipoint-alt-mark-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2020 00:29:16 -0000 Reviewer: Steve Hanna Review result: Ready Although I am naive with respect to IP Performance Management, I agree with the statements included in the Security Considerations section of this document. The measurement techniques described in this document seem to have fairly minimal security and privacy implications. The reference to the Security Considerations section of RFC 8321 (already included in this document) is a good way to expand on this topic. Therefore, I see no security or privacy concerns with approving this document. From nobody Sat Mar 7 17:36:47 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3230D3A0C7C; Fri, 6 Mar 2020 10:03:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1583517835; bh=JOtgQY52uXv7vwwIM94MHU+WNhhWeUJN8FT8d91yAEI=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=So0oU63exRuI1AALv0itEbqHZBUmk45scorGR+gpDWf7UacUfBEUm+He/e5VsgD/X dxms0RkBbxKiPHZc+8+bXFcKC6Oeq8fex8f1ZMROrFwVMmRc+YWYkZvWHzLRiPFK4R u+/7CnWZvGR/dWZLab8rPyt+MaaxgT8rPPILq4rU= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Mar 6 10:03:54 2020 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F8F3A0C70; Fri, 6 Mar 2020 10:03:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1583517834; bh=JOtgQY52uXv7vwwIM94MHU+WNhhWeUJN8FT8d91yAEI=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=X6sP74qqsDM2/FoFM+qdMfmyfVzYvR1g7nim2+rd9MLG4zohQKe6i+g0RdKJJL6cZ sjB4N/GhYXOdVrASIZv0ERRtiBgN2n0OFMdKVYiZmzbLKNsAXFE3oem/aMf0vHwZNq SKHZk/OW2xtRNteG7X61vgZDz3z2a7rxKX6JBMAs= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D31D3A0C70 for ; Fri, 6 Mar 2020 10:03:52 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Reply_to: Message-ID: <158351783223.2240.2634988287672846006@ietfa.amsl.com> Date: Fri, 06 Mar 2020 10:03:52 -0800 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Reply-To: iesg@ietf.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Sat, 07 Mar 2020 17:36:46 -0800 Subject: [secdir] [new-work] WG Review: Transport Layer Security (tls) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2020 18:04:00 -0000 The Transport Layer Security (tls) WG in the Security Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2020-03-16. Transport Layer Security (tls) ----------------------------------------------------------------------- Current status: Active WG Chairs: Christopher Wood Joseph Salowey Sean Turner Assigned Area Director: Benjamin Kaduk Security Area Directors: Benjamin Kaduk Roman Danyliw Mailing list: Address: tls@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/tls Archive: https://mailarchive.ietf.org/arch/browse/tls/ Group page: https://datatracker.ietf.org/group/tls/ Charter: https://datatracker.ietf.org/doc/charter-ietf-tls/ The TLS (Transport Layer Security) working group was established in 1996 to standardize a 'transport layer' security protocol. The basis for the work was SSL (Secure Socket Layer) v3.0 [RFC6101]. The TLS working group has completed a series of specifications that describe the TLS protocol v1.0 [RFC2246], v1.1 [RFC4346], v1.2 [RFC5346], and v1.3 [RFC8446], and DTLS (Datagram TLS) v1.0 [RFC4347], v1.2 [RFC6347], and v1.3 [draft-ietf-tls-dtls13], as well as extensions to the protocols and ciphersuites. The working group aims to achieve three goals. First, improve the applicability and suitability of the TLS family of protocols for use in emerging protocols and use cases. This includes extensions or changes that help protocols better use TLS as an authenticated key exchange protocol, or extensions that help protocols better leverage TLS security properties, such as Exported Authenticators. Extensions that focus specifically on protocol extensibility are also in scope. This goal also includes protocol changes that reduce TLS resource consumption without affecting security. Extensions that help reduce TLS handshake size meet this criterion. The second working group goal is to improve security, privacy, and deployability. This includes, for example, Delegated Credentials, Encrypted SNI, and GREASE (RFC 8701). Security and privacy goals will place emphasis on the following: - Encrypt the ClientHello SNI (Server Name Indication) and other application-sensitive extensions, such as ALPN (Application-Layer Protocol Negotiation). - Identify and mitigate other (long-term) user tracking or fingerprinting vectors enabled by TLS deployments and implementations. The third goal is to maintain current and previous version of the (D)TLS protocol as well as to specify general best practices for use of (D)TLS, extensions to (D)TLS, and cipher suites. This includes recommendations as to when a particular version should be deprecated. Changes or additions to older versions of (D)TLS whether via extensions or ciphersuites are discouraged and require significant justification to be taken on as work items. The working group will also place a priority in minimizing gratuitous changes to (D)TLS. Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Sun Mar 8 16:39:01 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C993A0BAC; Sun, 8 Mar 2020 16:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.694 X-Spam-Level: * X-Spam-Status: No, score=1.694 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_RELAY_MUA_TO_MX=3.595, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxiAxjWfe-ye; Sun, 8 Mar 2020 16:38:56 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 31CE83A0BB9; Sun, 8 Mar 2020 16:38:56 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sun, 8 Mar 2020 16:38:55 -0700 From: "Randall Gellens" To: "Shawn Emery" Cc: secdir , draft-gellens-lost-validation.all@ietf.org, last-call@ietf.org, "Shawn Emery" Date: Sun, 08 Mar 2020 16:38:54 -0700 X-Mailer: MailMate (1.13.1r5671) Message-ID: <492424B2-40EF-46FF-B4D1-C8664E01DAC9@coretechnologyconsulting.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [secdir] Review of draft-gellens-lost-validation-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2020 23:38:59 -0000 On 4 Mar 2020, at 18:41, Shawn Emery wrote: > Reviewer: Shawn M. Emery > Review result: Ready > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. > > This draft specifies an IANA registry for the Location-to-Service > Translation > (LoST) Protocol Validation Service Tag under U-NAPTR. > > The security considerations section does exist and refers to RFC 3958 > and > 4848. > I agree that this change does not introduce any new security > considerations. > > General comments: > > None. > > Editorial comments: > > Abbreviations should be expanded in the title of the draft and when > first > used (in this case the Abstract). > s/...// > > Shawn. > -- Thanks for your review, Shawn. Just to clarify, your suggestion is that "S-NAPTR" be expanded in the Abstract, e.g., by adding "(Straightforward Name Authority PoinTeR)". --Randall From nobody Sun Mar 8 20:19:30 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4133A0F5E; Sun, 8 Mar 2020 20:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ef-LXXH4hRBN; Sun, 8 Mar 2020 20:19:12 -0700 (PDT) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 BF9CB3A0F62; Sun, 8 Mar 2020 20:19:11 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id e25so10328202edq.5; Sun, 08 Mar 2020 20:19:11 -0700 (PDT) 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=OFlluxfMXKlh7knewDYz0FNUXQzFMlaw0dao+LyNVKA=; b=Nhw/FVEIJAb1VMeRG9gljLfuxA1RGyYaAJxrwqNTDCbfsZKVsR3WH1pN9GXCNeSr3c D9R/KDHJZxUiO9VKCFXHM8DN9T2JQhXdrX8DJ6EWx0k03hiUilOJrcM1qpf+s8Fft1yf 4LYoTfJuQKUKdrnwmP0NRxdSXg8M/cCQH1gBjRR+gGfadtNGYiCyGATFpRk/3+/nTo09 2YKdEo52JsOcrTtp0zBwMkJao3SSnBCFR2AUF8prJydgCNt8sYyBFnO6EH9AO/Fss81l ylOh8P+8BCqrpdhb5dCN/g67WmjXhK7xhDGmCq6k1IcyyIr+pGuDdsMWVOomcKsZ+GlF y4FA== 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=OFlluxfMXKlh7knewDYz0FNUXQzFMlaw0dao+LyNVKA=; b=OfY6GYvor+fK2IZe6VtoyjtKy8KE7cinK3Z5PTlCRoEQfUd8Q8UdLijkmWPyxT7efQ i0sy2TWELxmEbDPHonoYBv6I0R2Zaakh8kbcbJ5ab+ZMm0PJO3gXak7vWRKZwrm3HVVP 6LhKHt6k0s19GYmcnOBxSqaQDiwG35HaMn3is6ZWGU6tfFyzaopA8iU23s0rXE95KfBo k4/vq20mYhRghkV3YfLeqrxHO0MZNTsPTm01Zfes9iDwKBOXSa4ljLJ5gVHnxrl56mQb slA1/Ok0l9TSSa2Gnz13GwxVbMgDPCz0S2zJHJvsTwjZR+wGmOc0KNjYJIWuIAwB75m+ tirQ== X-Gm-Message-State: ANhLgQ1SWtB9YemiCSSaW+IQMIxAjtxpKF+8VNhzBRovCU/KyUfN1cZe thENuac22hLlK1twNRoRhUAjezaKk2i9Dpf5AvzJMteL X-Google-Smtp-Source: ADFU+vsh+tVwwxQi8rDdJeCWHWvqZIhT2Lg3mWsW/qge8x0EFFIepazc67oVwQHSxVkmwX7iDzp4lq8ioKk+HjrqRD8= X-Received: by 2002:a50:ce12:: with SMTP id y18mr14191447edi.62.1583723950077; Sun, 08 Mar 2020 20:19:10 -0700 (PDT) MIME-Version: 1.0 References: <492424B2-40EF-46FF-B4D1-C8664E01DAC9@coretechnologyconsulting.com> In-Reply-To: <492424B2-40EF-46FF-B4D1-C8664E01DAC9@coretechnologyconsulting.com> From: Shawn Emery Date: Sun, 8 Mar 2020 21:18:58 -0600 Message-ID: To: Randall Gellens Cc: draft-gellens-lost-validation.all@ietf.org, secdir Content-Type: multipart/alternative; boundary="00000000000077794505a06377a6" Archived-At: Subject: Re: [secdir] Review of draft-gellens-lost-validation-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 03:19:29 -0000 --00000000000077794505a06377a6 Content-Type: text/plain; charset="UTF-8" Yes, it's not listed as a well-known abbreviation in the RFC-editor's list. Could you also send me an update of the draft stemming from the Gen-ART comments? Thanks, Shawn. -- On Sun, Mar 8, 2020 at 5:38 PM Randall Gellens < rg+ietf@coretechnologyconsulting.com> wrote: > On 4 Mar 2020, at 18:41, Shawn Emery wrote: > > > Reviewer: Shawn M. Emery > > Review result: Ready > > > > I have reviewed this document as part of the security directorate's > > ongoing effort to review all IETF documents being processed by the > > IESG. > > These comments were written primarily for the benefit of the security > > area directors. Document editors and WG chairs should treat these > > comments just like any other last call comments. > > > > This draft specifies an IANA registry for the Location-to-Service > > Translation > > (LoST) Protocol Validation Service Tag under U-NAPTR. > > > > The security considerations section does exist and refers to RFC 3958 > > and > > 4848. > > I agree that this change does not introduce any new security > > considerations. > > > > General comments: > > > > None. > > > > Editorial comments: > > > > Abbreviations should be expanded in the title of the draft and when > > first > > used (in this case the Abstract). > > s/...// > > > > Shawn. > > -- > > Thanks for your review, Shawn. Just to clarify, your suggestion is that > "S-NAPTR" be expanded in the Abstract, e.g., by adding "(Straightforward > Name Authority PoinTeR)". > > --Randall > --00000000000077794505a06377a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Yes, it's not listed as a well-known abbrevia= tion in the RFC-editor's list.=C2=A0 Could you also send me an update o= f the draft stemming from the Gen-ART comments?

Th= anks,

Shawn.
--

On Sun, Mar 8, 2020= at 5:38 PM Randall Gellens <rg+ietf@coretechnologyconsulting.com&g= t; wrote:
On 4 M= ar 2020, at 18:41, Shawn Emery wrote:

> Reviewer: Shawn M. Emery
> Review result: Ready
>
> I have reviewed this document as part of the security directorate'= s
> ongoing effort to review all IETF documents being processed by the > IESG.
> These comments were written primarily for the benefit of the security<= br> > area directors. Document editors and WG chairs should treat these
> comments just like any other last call comments.
>
> This draft specifies an IANA registry for the Location-to-Service
> Translation
> (LoST) Protocol Validation Service Tag under U-NAPTR.
>
> The security considerations section does exist and refers to RFC 3958 =
> and
> 4848.
> I agree that this change does not introduce any new security
> considerations.
>
> General comments:
>
> None.
>
> Editorial comments:
>
> Abbreviations should be expanded in the title of the draft and when > first
> used (in this case the Abstract).
> s/...//
>
> Shawn.
> --

Thanks for your review, Shawn.=C2=A0 Just to clarify, your suggestion is th= at
"S-NAPTR" be expanded in the Abstract, e.g., by adding "(Str= aightforward
Name Authority PoinTeR)".

--Randall
--00000000000077794505a06377a6-- From nobody Mon Mar 9 05:35:19 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E620D3A0EC5; Mon, 9 Mar 2020 05:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1y1-k5n8fOe; Mon, 9 Mar 2020 05:35:05 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 0D9033A0EC7; Mon, 9 Mar 2020 05:35:05 -0700 (PDT) Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id BD534138797460B840A9; Mon, 9 Mar 2020 12:35:03 +0000 (GMT) Received: from fraeml715-chm.china.huawei.com (10.206.15.34) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 9 Mar 2020 12:35:03 +0000 Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml715-chm.china.huawei.com (10.206.15.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 9 Mar 2020 13:35:02 +0100 Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.1713.004; Mon, 9 Mar 2020 13:35:02 +0100 From: Giuseppe Fioccola To: Steve Hanna , "secdir@ietf.org" CC: "last-call@ietf.org" , "ippm@ietf.org" , "draft-ietf-ippm-multipoint-alt-mark.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-ippm-multipoint-alt-mark-06 Thread-Index: AQHV9OCgMT8CAHJu50iS6berULmHjKhANE7A Date: Mon, 9 Mar 2020 12:35:02 +0000 Message-ID: References: <158362735547.25505.12722503226926557935@ietfa.amsl.com> In-Reply-To: <158362735547.25505.12722503226926557935@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.1.210] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-ippm-multipoint-alt-mark-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 12:35:17 -0000 RGVhciBTdGV2ZSwNClRoYW5rcyBhIGxvdCBmb3IgeW91ciByZXZpZXcgb2YgdGhlIGRyYWZ0Lg0K DQpSZWdhcmRzLA0KDQpHaXVzZXBwZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogU3RldmUgSGFubmEgdmlhIERhdGF0cmFja2VyIFttYWlsdG86bm9yZXBseUBpZXRmLm9yZ10g DQpTZW50OiBTdW5kYXksIE1hcmNoIDgsIDIwMjAgMToyOSBBTQ0KVG86IHNlY2RpckBpZXRmLm9y Zw0KQ2M6IGxhc3QtY2FsbEBpZXRmLm9yZzsgaXBwbUBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1pcHBt LW11bHRpcG9pbnQtYWx0LW1hcmsuYWxsQGlldGYub3JnDQpTdWJqZWN0OiBTZWNkaXIgbGFzdCBj YWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWlwcG0tbXVsdGlwb2ludC1hbHQtbWFyay0wNg0KDQpS ZXZpZXdlcjogU3RldmUgSGFubmENClJldmlldyByZXN1bHQ6IFJlYWR5DQoNCkFsdGhvdWdoIEkg YW0gbmFpdmUgd2l0aCByZXNwZWN0IHRvIElQIFBlcmZvcm1hbmNlIE1hbmFnZW1lbnQsIEkgYWdy ZWUgd2l0aCB0aGUgc3RhdGVtZW50cyBpbmNsdWRlZCBpbiB0aGUgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMgc2VjdGlvbiBvZiB0aGlzIGRvY3VtZW50Lg0KVGhlIG1lYXN1cmVtZW50IHRlY2huaXF1 ZXMgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQgc2VlbSB0byBoYXZlIGZhaXJseSBtaW5pbWFs IHNlY3VyaXR5IGFuZCBwcml2YWN5IGltcGxpY2F0aW9ucy4gVGhlIHJlZmVyZW5jZSB0byB0aGUg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiBvZiBSRkMgODMyMSAoYWxyZWFkeSBpbmNs dWRlZCBpbiB0aGlzIGRvY3VtZW50KSBpcyBhIGdvb2Qgd2F5IHRvIGV4cGFuZCBvbiB0aGlzIHRv cGljLg0KDQpUaGVyZWZvcmUsIEkgc2VlIG5vIHNlY3VyaXR5IG9yIHByaXZhY3kgY29uY2VybnMg d2l0aCBhcHByb3ZpbmcgdGhpcyBkb2N1bWVudC4NCg0KDQoNCg== From nobody Mon Mar 9 05:44:22 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC763A07F1; Mon, 9 Mar 2020 05:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zjf9FuAnKTKQ; Mon, 9 Mar 2020 05:44:01 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 97F593A0EC1; Mon, 9 Mar 2020 05:44:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B3368660130; Mon, 9 Mar 2020 14:44:00 +0200 (EET) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIYnzccrxzf7; Mon, 9 Mar 2020 14:43:59 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 2201466012C; Mon, 9 Mar 2020 14:43:59 +0200 (EET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: <158015949760.11784.9026094555168247393@ietfa.amsl.com> Date: Mon, 9 Mar 2020 14:43:58 +0200 Cc: secdir@ietf.org, last-call@ietf.org, draft-ietf-emu-rfc5448bis.all@ietf.org, emu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1C8B843F-1F5F-42D7-BCA4-B1B42120AF1F@piuha.net> References: <158015949760.11784.9026094555168247393@ietfa.amsl.com> To: Kyle Rose X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-emu-rfc5448bis-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 12:44:14 -0000 Thanks for your review, Kyle! Inline: >> =46rom the perspective of clarity and completeness, this document is = Ready With > Nits: it is well-written and mostly quite clear, even to someone = without a > great deal of knowledge of 3GPP systems. In addition to digging into = RFCs 4187 > and 5448, I had to follow a few search engine links to (maybe not = public?) 3GPP > documents for some details, but this was not a terribly high burden. The 3GPP specifications are entirely public, but cumbersomely named and = stored :-)=EF=81=8A Who would name specs with numbers?? :-)=20 Google does help. When you google for nn.mmm you will get a = specification page, and there you can click versions and on the version = numbers you can click the actual document. > With regard to IETF document standards, the thing that sticks out is = the use of > normative language in an informational document. (FWIW, RFC 5448 also = has this, > and is also informational.) There=E2=80=99s some history to why this document is not on the = standards track (see the AD review thread for more history). > Minor comments and questions: >=20 > Section 1 has a note starting with "This specification refers only to = the 5G > specifications..." I am not quite sure what this note is intended to = imply. Is > "this specification" the draft itself, and therefore that it should be = used > only for 5G deployments, and that 5448 should continue to be followed = for older > access technologies? This has been clarified. See also our respond to the Gen-ART review from = Dan. The document refers actually to both 4G and 5G specifications that = contain, among other things, specifications for the relevant algorithms = that EAP-AKA=E2=80=99 uses. > Section 3.1 states that "The value of the AT_KDF_INPUT attribute from = the > server MUST be non-empty." I presume this means that the Network Name = must be > non-empty, i.e., that "Actual Network Name Length" must be non-zero. Yes. Clarified. > Following the previous paragraph, the note in Section 3.1 states that >=20 > However, from an EAP-AKA' perspective both occupy > the same field, and need to be distinguishable from each other. >=20 > I am assuming this is to prevent collisions between two different = network names > that would enable some of the attacks that the AT_KDF_INPUT mechanism = was > intended to thwart. Yes, primarily 4G usage needs to be separated from 5G usage, and this = has been specified in the 3GPP specifications as the note also suggests. = But the text has been clarified in -07. > Also in section 3.1, the document talks about network name mismatches. = What is > the threat model here? Since the whole exchange is protected by the = AT_MAC, > it's not clear that there is any security benefit: the primary benefit = appears > to be to detect misconfigurations. Is that correct? The purpose is to detect if the locally indicated network name that the = peer sees matches with the network name received in AT_KDF_INPUT. If = they don=E2=80=99t match, an attacker, which may have got hold of the = authentication vector, may be advertising a wrong network name and = thereby luring the victim peer to connect to it. Basically, channel = binding. > Related to that point, my exploration of the AKA document space = suggests that > the scheme is based on keys shared between the user device (the USIM) = and the > "home environment", which I take to mean some system operated by the = user's > home carrier. I didn't dig deep enough to understand which systems = have access > to this shared secret: could you describe at a high level how the = shared secret > relates to CK, IK, and K_aut? This is described in 3.3. Basically the AKA algorithm uses the =E2=80=9Csh= ared key=E2=80=9D stored in USIM and home environment to produce CK and = IK. CK and IK are used to derive CK=E2=80=99 and IK=E2=80=99, which are = then used to derive k_aut (and other keys indicated in 3.3). =20 But in short, the shared secret is only in the secure USIM and in the = operator=E2=80=99s authentication server. It is not shared to any other = nodes, for instance. There are some attacks on SIM card manufacturers = for instance that may cause a leaks though of course, the remedy is = similar to what we=E2=80=99d do for other protocols (such as PFS). > Section 7.1 cautions implementors not to use null-scheme encryption to = generate > the SUCI, as privacy will then be lost. The obvious question is: why = is it even > mentioned in the draft (in section 5.3.2.1) and in 3GPP technical > specifications? Is it for diagnostic purposes in lab environments and, = if so, > is it called out that way in the specs? Null-scheme encryption is an option in 3GPP specifications to give the = decision power to the home environment 3GPP operator to use encryption = or not. Such decision may be based on regulatory requirements. > Near the end of section 7.2 is a paragraph about the potential for = traffic > analysis, concluding: >=20 > However, phone calls and SMS messages > are just some of the many potential triggers for authentication. = For > instance, various mobility events and the amount of mobile data = sent > or received can also trigger authentication. As a result, while = some > amount of information may be derived about the activity level on a > particular phone in some cases, the linkage to specific activities = is > not direct. >=20 > I would not be so sanguine about the value of such noise to privacy: = amplifying > signal is one of the more straightforward parts of traffic analysis. = This might > best be filed under "if your adversary is the CIA or Mossad, you = lose." I'd > just lose this text entirely and merely state the risk. Yes, perhaps. Text stricken out/shortened in -07. > There are numerous minor grammatical errors throughout the doc that = could > benefit from an editorial pass prior to submitting to the RFC editor = for > publication. >=20 > Future guidance: >=20 > In section 3.3, the fast reauth derivation of MK is specified as: >=20 > MK =3D PRF'(K_re,"EAP-AKA' re-auth"|Identity|counter|NONCE_S) >=20 > I do not think there is any actual problem here, given that K_re = should be > unique, meaning that unique parseability of the second argument to = PRF' is not > required to avoid collisions in the output MK; but unique parseability = is > generally a good idea. We agree with point but don=E2=80=99t think this requires any change in = the document. > Section 4 states: >=20 > there is no need to prevent bidding "down" > attacks in the other direction, i.e., attackers forcing the = endpoints > to use EAP-AKA'. >=20 > and in general throughout this section the draft refers to EAP-AKA' = being "at > least as secure" as EAP-AKA. I don't think this is the right way to = frame > downgrade attacks. Downgrade attacks (what you call "bidding down" = here) are > denoted as such by the value of a successful exploit to the attacker, = not by a > relation between some supposed fixed notions of algorithm strength = that might > change unexpectedly in the future. >=20 > Downgrade prevention should designed to prevent any kind of influence = on the > negotiated protocol by an attacker without access to any relevant > authentication credentials: essentially, it should make no assumption = about the > strength of either the new or old scheme, but simply provide assurance = that the > intended handshake was not tampered with. This is what TLS 1.3 does, = for > instance, through the inclusion of the full handshake transcript in = the key > derivation process. You are correct of course that one could think of downgrade attacks in = the other direction as well. That was not in RFC 5448 however, so it is = difficult to put it into practice years after. In addition, we are = concerned with deviating from 3GPP specifications. We do agree though = that the other direction protection would be useful. Perhaps that=E2=80=99= s something that could be addressed by a separate feature RFC, and = clearly labeled as an extension. This would at least reduce the risk = that someone objects to the entire new RFC based on the new = functionality. =20 In any case, we added text about the lack of other direction protection = in the security considerations text in -07. =20 > Re: section 7: What are the barriers to cryptographic agility, i.e., > ciphersuite negotiation, in general? Stipulating the limitations of = EAP, can > this agility be implemented at a higher layer and used to select = (e.g.) > EAP-AKA'' sometime in the future? While being able to upgrade highly = performant > ciphers in deployed hardware is a challenging task and/or expensive = prospect, > it seems such agility is even more important for ecosystems that move = slowly > relative to software updates that can be deployed in days or weeks. I = don't > have a magic solution for this: I only wanted to bring it up as = something that > may be worth mentioning as an accepted risk. We agree that this is an interesting topic. I=E2=80=99m not sure = there=E2=80=99s much we could say, as the ability to provide additional = agility depends highly on what specific change is contemplated. Some = changes might require a new method, others could be done as part of = EAP-AKA=E2=80=99. We can only point to some examples, such as the PFS = draft that seem to be able to make extensions. Nevertheless, a small note was added to the -07 on this. Thanks again for your review. Jari From nobody Mon Mar 9 08:19:55 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D059B3A11F9; Mon, 9 Mar 2020 08:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.696 X-Spam-Level: * X-Spam-Status: No, score=1.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_RELAY_MUA_TO_MX=3.595, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGIGDzehp6Io; Mon, 9 Mar 2020 08:19:52 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id DEAD93A11FD; Mon, 9 Mar 2020 08:19:51 -0700 (PDT) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 9 Mar 2020 08:19:51 -0700 From: "Randall Gellens" To: "Shawn Emery" Cc: draft-gellens-lost-validation.all@ietf.org, secdir Date: Mon, 09 Mar 2020 08:19:50 -0700 X-Mailer: MailMate (1.13.1r5671) Message-ID: <31885533-65E0-4A47-84E4-EDA9D74E57A0@coretechnologyconsulting.com> In-Reply-To: References: <492424B2-40EF-46FF-B4D1-C8664E01DAC9@coretechnologyconsulting.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_81929450-3393-4996-9DE5-DBF37EA41549_=" Embedded-HTML: [{"HTML":[745, 2141], "plain":[397, 1509], "uuid":"AD5C00A8-97E0-4807-B0D2-0D65794EE829"}] Archived-At: Subject: Re: [secdir] Review of draft-gellens-lost-validation-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 15:19:53 -0000 --=_MailMate_81929450-3393-4996-9DE5-DBF37EA41549_= Content-Type: text/plain; format=flowed Hi Ben, I added the expansion as noted in my original reply. By the gen-art comments you mean Pete's? I sent a separate email to everyone who has reviewed the draft asking if everyone is OK with Pete's last suggestion, which is to delete Sections 3 and 4 and add a reference to NENA i3 as a work in progress that will use the new tag. --Randall On 8 Mar 2020, at 20:18, Shawn Emery wrote: > Yes, it's not listed as a well-known abbreviation in the RFC-editor's > list. Could you also send me an update of the draft stemming from the > Gen-ART comments? > > Thanks, > > Shawn. > -- > > On Sun, Mar 8, 2020 at 5:38 PM Randall Gellens < > rg+ietf@coretechnologyconsulting.com> wrote: > >> On 4 Mar 2020, at 18:41, Shawn Emery wrote: >> >>> Reviewer: Shawn M. Emery >>> Review result: Ready >>> >>> I have reviewed this document as part of the security directorate's >>> ongoing effort to review all IETF documents being processed by the >>> IESG. >>> These comments were written primarily for the benefit of the >>> security >>> area directors. Document editors and WG chairs should treat these >>> comments just like any other last call comments. >>> >>> This draft specifies an IANA registry for the Location-to-Service >>> Translation >>> (LoST) Protocol Validation Service Tag under U-NAPTR. >>> >>> The security considerations section does exist and refers to RFC >>> 3958 >>> and >>> 4848. >>> I agree that this change does not introduce any new security >>> considerations. >>> >>> General comments: >>> >>> None. >>> >>> Editorial comments: >>> >>> Abbreviations should be expanded in the title of the draft and when >>> first >>> used (in this case the Abstract). >>> s/...// >>> >>> Shawn. >>> -- >> >> Thanks for your review, Shawn. Just to clarify, your suggestion is >> that >> "S-NAPTR" be expanded in the Abstract, e.g., by adding >> "(Straightforward >> Name Authority PoinTeR)". >> >> --Randall >> --=_MailMate_81929450-3393-4996-9DE5-DBF37EA41549_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Hi Ben,

I added the expansion as noted in my original reply. By = the gen-art comments you mean Pete's? I sent a separate email to everyon= e who has reviewed the draft asking if everyone is OK with Pete's last su= ggestion, which is to delete Sections 3 and 4 and add a reference to NENA= i3 as a work in progress that will use the new tag.

--Randall

On 8 Mar 2020, at 20:18, Shawn Emery wrote:


Yes, it's not listed as a well-known abbrevia= tion in the RFC-editor's list.=C2=A0 Could you also send me an update= of the draft stemming from the Gen-ART comments?

Thanks,

Shawn.
--

On Sun, Mar= 8, 2020 at 5:38 PM Randall Gellens <rg+ietf@coretechnologyconsulti= ng.com> wrote:
On 4 Mar 2020, at 18:41, Shawn Emery wrote:

> Reviewer: Shawn M. Emery
> Review result: Ready
>
> I have reviewed this document as part of the security directorate= 9;s
> ongoing effort to review all IETF documents being processed by the <= br> > IESG.
> These comments were written primarily for the benefit of the securit= y
> area directors. Document editors and WG chairs should treat these > comments just like any other last call comments.
>
> This draft specifies an IANA registry for the Location-to-Service > Translation
> (LoST) Protocol Validation Service Tag under U-NAPTR.
>
> The security considerations section does exist and refers to RFC 395= 8
> and
> 4848.
> I agree that this change does not introduce any new security
> considerations.
>
> General comments:
>
> None.
>
> Editorial comments:
>
> Abbreviations should be expanded in the title of the draft and when =
> first
> used (in this case the Abstract).
> s/...//
>
> Shawn.
> --

Thanks for your review, Shawn.=C2=A0 Just to clarify, your suggestion is = that
"S-NAPTR" be expanded in the Abstract, e.g., by adding "(S= traightforward
Name Authority PoinTeR)".

--Randall


--=_MailMate_81929450-3393-4996-9DE5-DBF37EA41549_=-- From nobody Mon Mar 9 09:12:33 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AEAC83A0BB9; Mon, 9 Mar 2020 02:45:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1583747124; bh=b9aZRfPz78zNv9Zf4gobccUnHKlxdkvcCUeToNOb+Qc=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=phKkFOlYZmq2qh5DzuqrXKctiqUSsr37ETJvdFcIi09GBU/l5LRLc3JtL2EoMfuC0 T021Fube2j5vzfIxLnu/GIj7Y5Y7gLlKUBb1aKl4eDRxjO4gE3wBbdq4RVWl8VcJ+B sEUPc5CHBeMt3EJS8bJaLQn6xu8xv/mNRCM93AHA= X-Mailbox-Line: From new-work-bounces@ietf.org Mon Mar 9 02:45:24 2020 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E61393A0BA6; Mon, 9 Mar 2020 02:45:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1583747124; bh=b9aZRfPz78zNv9Zf4gobccUnHKlxdkvcCUeToNOb+Qc=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=phKkFOlYZmq2qh5DzuqrXKctiqUSsr37ETJvdFcIi09GBU/l5LRLc3JtL2EoMfuC0 T021Fube2j5vzfIxLnu/GIj7Y5Y7gLlKUBb1aKl4eDRxjO4gE3wBbdq4RVWl8VcJ+B sEUPc5CHBeMt3EJS8bJaLQn6xu8xv/mNRCM93AHA= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1773A0BAA for ; Mon, 9 Mar 2020 02:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.998, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F_hc0_TulLlw for ; Mon, 9 Mar 2020 02:45:19 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (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 AD4813A0BA5 for ; Mon, 9 Mar 2020 02:45:19 -0700 (PDT) Received: from moon.w3.org ([128.30.55.110] helo=jiaxueyuandeMacBook-Pro.local) by raoul.w3.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jBEyK-0007as-F0 for new-work@ietf.org; Mon, 09 Mar 2020 09:45:17 +0000 To: new-work@ietf.org From: xueyuan Message-ID: Date: Mon, 9 Mar 2020 17:45:10 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Mon, 09 Mar 2020 09:12:33 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Immersive Web Working Group (until 2020-04-06) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 09:45:28 -0000 CkhlbGxvLAoKVG9kYXkgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMgcmVj ZWl2ZWQgYSBQcm9wb3NhbAp0byByZXZpZXcgYSBkcmFmdCBjaGFydGVyIGZvciB0aGUgSW1tZXJz aXZlIFdlYiBXb3JraW5nIEdyb3VwOgpodHRwczovL3d3dy53My5vcmcvMjAyMC8wMy9wcm9wb3Nl ZC1pbW1lcnNpdmUtd2ViLXdnLWNoYXJ0ZXIuaHRtbAoKQXMgcGFydCBvZiBlbnN1cmluZyB0aGF0 IHRoZSBjb21tdW5pdHkgaXMgYXdhcmUgb2YgcHJvcG9zZWQgd29yawphdCBXM0MsIHRoaXMgZHJh ZnQgY2hhcnRlciBpcyBwdWJsaWMgZHVyaW5nIHRoZSBBZHZpc29yeQpDb21taXR0ZWUgcmV2aWV3 IHBlcmlvZC4KClczQyBpbnZpdGVzIHB1YmxpYyBjb21tZW50cyB0aHJvdWdoIDIwMjAtMDQtMDYg b24gdGhlCnByb3Bvc2VkIGNoYXJ0ZXIuIFBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvCnB1YmxpYy1u ZXctd29ya0B3My5vcmcsIHdoaWNoIGhhcyBhIHB1YmxpYyBhcmNoaXZlOgogwqAgaHR0cDovL2xp c3RzLnczLm9yZy9BcmNoaXZlcy9QdWJsaWMvcHVibGljLW5ldy13b3JrLwoKT3RoZXIgdGhhbiBj b21tZW50cyBzZW50IGluIGZvcm1hbCByZXNwb25zZXMgYnkgVzNDIEFkdmlzb3J5CkNvbW1pdHRl ZSBSZXByZXNlbnRhdGl2ZXMsIFczQyBjYW5ub3QgZ3VhcmFudGVlIGEgcmVzcG9uc2UgdG8KY29t bWVudHMuIElmIHlvdSB3b3JrIGZvciBhIFczQyBNZW1iZXIgWzFdLCBwbGVhc2UgY29vcmRpbmF0 ZQp5b3VyIGNvbW1lbnRzIHdpdGggeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50YXRp dmUuIEZvcgpleGFtcGxlLCB5b3UgbWF5IHdpc2ggdG8gbWFrZSBwdWJsaWMgY29tbWVudHMgdmlh IHRoaXMgbGlzdCBhbmQKaGF2ZSB5b3VyIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2 ZSByZWZlciB0byBpdCBmcm9tIGhpcwpvciBoZXIgZm9ybWFsIHJldmlldyBjb21tZW50cy4KClRo ZSBJbW1lcnNpdmUgV2ViIFdvcmtpbmcgR3JvdXAncyBjdXJyZW50IGNoYXJ0ZXIgaXMgaGVyZWJ5 IGV4dGVuZGVkCnVudGlsIDMwIEFwcmlsIDIwMjAsIHRvIGFjY29tbW9kYXRlIHRoZSBjaGFydGVy IHJldmlldyBwZXJpb2QuCmh0dHBzOi8vd3d3LnczLm9yZy8yMDE4LzA5L2ltbWVyc2l2ZS13ZWIt d2ctY2hhcnRlcgoKSWYgeW91IGhhdmUgYW55IHF1ZXN0aW9ucyBvciBuZWVkIGZ1cnRoZXIgaW5m b3JtYXRpb24sIHBsZWFzZSBjb250YWN0CkRvbWluaXF1ZSBIYXphw6tsLU1hc3NpZXV4IDxkb21A dzMub3JnPiBhbmQgQXRzdXNoaSBTaGltb25vIDxhdHN1c2hpQHczLm9yZz4sCkltbWVyc2l2ZSBX ZWIgV29ya2luZyBHcm91cCBUZWFtIENvbnRhY3RzLgoKVGhhbmsgeW91LApYdWV5dWFuIEppYSwg VzNDIE1hcmtldGluZyAmIENvbW11bmljYXRpb25zCgpbMV0gaHR0cDovL3d3dy53My5vcmcvQ29u c29ydGl1bS9NZW1iZXIvTGlzdAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KbmV3LXdvcmsgbWFpbGluZyBsaXN0Cm5ldy13b3JrQGlldGYub3JnCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV3LXdvcmsK From nobody Mon Mar 9 09:13:18 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2CC23A0D08; Mon, 9 Mar 2020 09:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2E0ZNhX8RWW; Mon, 9 Mar 2020 09:13:14 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2F13A12C3; Mon, 9 Mar 2020 09:13:13 -0700 (PDT) Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 2085B1B001B7; Mon, 9 Mar 2020 16:13:08 +0000 (GMT) To: tsvwg@ietf.org, secdir@ietf.org References: <158376420248.14208.2438240270562621574@ietfa.amsl.com> From: Gorry Fairhurst Message-ID: Date: Mon, 9 Mar 2020 16:13:07 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <158376420248.14208.2438240270562621574@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [secdir] [tsvwg] Revised ID: draft-ietf-tsvwg-datagram-plpmtud-16.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 16:13:18 -0000 This revision follows the issues raised by the IETF Last Call SECDIR Review (of draft-15). We think this will address all the security-related issues that were noted. (It also addresses one case of repetition that was found.) Gorry, et al (DPLPMTUD editors) On 09/03/2020 14:30, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Area Working Group WG of the IETF. > > Title : Packetization Layer Path MTU Discovery for Datagram Transports > Authors : Godred Fairhurst > Tom Jones > Michael Tuexen > Irene Ruengeler > Timo Voelker > Filename : draft-ietf-tsvwg-datagram-plpmtud-16.txt > Pages : 44 > Date : 2020-03-09 > > Abstract: > This document describes a robust method for Path MTU Discovery > (PMTUD) for datagram Packetization Layers (PLs). It describes an > extension to RFC 1191 and RFC 8201, which specifies ICMP-based Path > MTU Discovery for IPv4 and IPv6. The method allows a PL, or a > datagram application that uses a PL, to discover whether a network > path can support the current size of datagram. This can be used to > detect and reduce the message size when a sender encounters a packet > black hole (where packets are discarded). The method can probe a > network path with progressively larger packets to discover whether > the maximum packet size can be increased. This allows a sender to > determine an appropriate packet size, providing functionality for > datagram transports that is equivalent to the Packetization Layer > PMTUD specification for TCP, specified in RFC 4821. > > The document updates RFC 4821 to specify the method for datagram PLs, > and updates RFC 8085 as the method to use in place of RFC 4821 with > UDP datagrams. Section 7.3 of RFC4960 recommends an endpoint apply > the techniques in RFC 4821 on a per-destination-address basis. RFC > 4960, RFC 6951 and RFC 8261 are updated to recommend that SCTP, SCTP > encapsulated in UDP and SCTP encapsulated in DTLS use the method > specified in this document instead of the method in RFC 4821. > > The document also provides implementation notes for incorporating > Datagram PMTUD into IETF datagram transports or applications that use > datagram transports. > > When published, this specification updates RFC 4960, RFC 4821, RFC > 8085 and RFC 8261. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tsvwg-datagram-plpmtud-16 > https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-datagram-plpmtud-16 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-datagram-plpmtud-16 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > From nobody Mon Mar 9 10:04:38 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7D43A138C; Mon, 9 Mar 2020 10:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 G9904oZ0SJlJ; Mon, 9 Mar 2020 10:04:25 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BA6E3A1322; Mon, 9 Mar 2020 10:04:24 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 029H0160008477; Mon, 9 Mar 2020 17:04:24 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=9CG4I6J1sgFO7c/SDdvIf1dQpCLzm75SLoDFZ/O3oqo=; b=iEZhcGIpfU+nTJmY09m49bF0bK9EdQ6qcdyTISYPDGyByq7CqhUmYYH2L9QW3i51Ieyf BVRoTcax/bvqx480ZMurLXDUGSiaYvDLDhYvsHyoiAADuzomw/cJUop/tGZ6quciCXdn NgCoAYNX0nYG+4UbPrV8+IdzxOUrh/Xw2BhHz3nwYOoArrGbuFBT0zYSh2ttYnUTv7Y5 0asCZH3xUbm3yvDF5hqBltuscpyOPva6dUJuBf6RfvnkrkM0v3L7Kyw+x8WifP59spB0 TU8YJxns+X8efv6bdZStDOaDc+xcggnlXwvzIoRsN/r7rBRb6nlnD1wEvfHF2vmSyeDZ 7Q== Received: from prod-mail-ppoint8 (prod-mail-ppoint8.akamai.com [96.6.114.122] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2ym1c0gs2u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 09 Mar 2020 17:04:23 +0000 Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 029H2l0V005968; Mon, 9 Mar 2020 13:04:23 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.113]) by prod-mail-ppoint8.akamai.com with ESMTP id 2ym7u1njxw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 09 Mar 2020 13:04:23 -0400 Received: from USTX2EX-DAG3MB6.msg.corp.akamai.com (172.27.165.130) by ustx2ex-dag3mb5.msg.corp.akamai.com (172.27.165.129) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 9 Mar 2020 13:04:21 -0400 Received: from USTX2EX-DAG3MB6.msg.corp.akamai.com ([172.27.165.130]) by USTX2EX-DAG3MB6.msg.corp.akamai.com ([172.27.165.130]) with mapi id 15.00.1497.006; Mon, 9 Mar 2020 12:04:22 -0500 From: "Franke, Daniel" To: "kivinen@iki.fi" CC: "ntp@ietf.org" , "secdir@ietf.org" Thread-Topic: Missing secdir assignment for draft-ietf-ntp-using-nts-for-ntp? Thread-Index: AQHV9jSfcC2Y8Bb4V06FmksATtG71Q== Date: Mon, 9 Mar 2020 17:04:22 +0000 Message-ID: <1583773461963.52013@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.28.13.81] Content-Type: multipart/alternative; boundary="_000_158377346196352013akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-03-09_06:2020-03-09, 2020-03-09 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=526 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002050000 definitions=main-2003090109 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-03-09_06:2020-03-09, 2020-03-09 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 adultscore=0 phishscore=0 spamscore=0 priorityscore=1501 mlxlogscore=488 lowpriorityscore=0 clxscore=1011 impostorscore=0 suspectscore=0 bulkscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2003090109 Archived-At: Subject: [secdir] Missing secdir assignment for draft-ietf-ntp-using-nts-for-ntp? X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 17:04:27 -0000 --_000_158377346196352013akamaicom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tero, Did draft-ietf-ntp-using-nts-for-ntp somehow get overlooked for SECDIR revi= ew? I see no review in the datatracker and nobody assigned to do one. --_000_158377346196352013akamaicom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Tero,


Did draft-ietf-ntp-using-nts-for-ntp somehow get overlooked for SEC= DIR review? I see no review in the datatracker and nobody assigned to do on= e.

--_000_158377346196352013akamaicom_-- From nobody Mon Mar 9 12:15:09 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A763A15DC; Mon, 9 Mar 2020 12:14:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Stephen Kent via Datatracker To: Cc: netmod@ietf.org, draft-ietf-netmod-factory-default.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.120.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158378129274.5575.11079304412600243334@ietfa.amsl.com> Reply-To: Stephen Kent Date: Mon, 09 Mar 2020 12:14:52 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-netmod-factory-default-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 19:15:00 -0000 Reviewer: Stephen Kent Review result: Has Issues SECDIR review of draft-ietf-netmod-factory-default-14 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This is a very brief document- only 9 pages (ignoring notes that are to be removed before publication)! It is a proposal for a YANG data model that will allow clients to reset a server to its factory default settings. It also defines a “factory-default” datastore that enables a client to determine the values for the default settings for a server. The datamodel is said to conform to the architecture defined in RFC 8342. RFC 8342, and RFC 7950, define the terms used in this document, and the terminology Section (1.1) cites these RFCs when enumerating these terms. This reader would prefer to have the definitions replicated here for the nine terms in question. Only one additional term is defined in this document, the factory-default datastore. The acronym “RPC” (remote procedure call) is not expanded upon first use. The description of how to effect a factor-reset RPC, in Sections 2 & 3 seems pretty thorough, and includes appropriate comments about security-relevant data, e.g., private keys and certificates. I an not familiar enough with YANG to evaluate the module definition in Section 4. Section 6, Security Considerations, calls for use of SSH (RFC 6242) with NETCONF and HTTPS (RFC 8446) with RESTCONF. The TLS reference is current, citing TLS v1.3. However, RFC 6242 is a document that describes how to use SSH with NETCONF. That document, in turn, cites RFC 4254, and that RFC cites RFC 4253 for a description of SSH. 4253 is a very much out of date document; the integrity and key management algorithms in the original RFC have been updated 3 times (6668, 8268, and 8332). The encryption algorithms cited in 4253 are all outdated. This discussion of SSH security for use with NETCONF, based on the one citation, seems to be inconsistent with current IETF crypto guidelines. This is a problem that the net management area should address before this document is approved. The discussion of how a factory-reset RPC may isolate a device, is good, as is the warning about not relying on this RPC to prevent recovery of security-sensitive data from NV storage. From nobody Mon Mar 9 15:05:08 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3FE3A07A9; Mon, 9 Mar 2020 15:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUVKrhdIjbuy; Mon, 9 Mar 2020 15:04:54 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [IPv6:2a00:1c30:1c1::55]) (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 33B5B3A07B4; Mon, 9 Mar 2020 15:04:53 -0700 (PDT) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id C56F21B0008A; Tue, 10 Mar 2020 00:04:50 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1583791490; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AWjeDvdsZLaRMGEV1jlNKP0uibbvhgXBF8S725XZp/I=; b=KLOfmCykBRRcSsXJY9Ek2eSj9SwWh0WKvGN2igty4kCvVKeKM4tjxN7rt9gMNq5jhJcn3m 4h8oYmi1sKNzoyD9wZbKdaaqcLSipoP/Uykm/sS6nfg1/yLbHzDYi/BvuFvnR5fzx/zFgr xvjrixfmxYdXBlVR4xP/R/RokzcAWvIdAANhKiU6ZHl2BIZjxn7AV+Cq61O75C5YiSJvHv /5+Y07XTOYyQpI7UGrWxW5BYOYCzoqyddb3IQmNNSMKKa/ul72kfz3qAkvn8kq7Fjk3BS0 ++jgTpwaQGgOOQd2zok8hVOO/bgqotYWj/D9sMXU0ePMcl8o8nHxr+vrHcHJHQ== Received: by fireball.acr.fi (Postfix, from userid 15204) id EAFF425C0E59; Tue, 10 Mar 2020 00:04:48 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24166.48512.923994.774704@fireball.acr.fi> Date: Tue, 10 Mar 2020 00:04:48 +0200 From: Tero Kivinen To: "Franke\, Daniel" Cc: "ntp\@ietf.org" , "secdir\@ietf.org" In-Reply-To: <1583773461963.52013@akamai.com> References: <1583773461963.52013@akamai.com> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 7 min X-Total-Time: 8 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1583791490; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AWjeDvdsZLaRMGEV1jlNKP0uibbvhgXBF8S725XZp/I=; b=HZob/yNQwHBIBTy5tK5ei2gMbTrdLi1Ihe/JsenNcHol2CF0wv7IN3N1JdBg6YC0X/G6gH lsjo7vxvTWdv9WqdrvaKI8InWzEhkVIaToqIREp6qXGLTYxxN1SjRPhn0OXqq2PsCYR2es EqkEMvkqweeg0Bw4wjalisE0TxxNsX+1TQiLqSidm/MJZOSdw4yWmssv2Vnt447Nbfw+Bx so2w0iZGjjeSb3hiW1y+AKzlbjOgc5o934wH+ixHejrfg5ZfNFlExDp4y6ymQls5LQUmS4 wOcpUmjftE9QN7qVoymoSuKgbmw/lo2ehGo+iCXy7LvCBoMFAmZiZ3ryiC4T7w== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1583791490; a=rsa-sha256; cv=none; b=iMI+rP0p918oLGYyn/biDPv6eLYUKlbSpOwpjKZBBy1QklkPJoDKTEOsLu6Jlu7zZi3/We MRwFr5dMz2oitbxK6Nbd91V43y/uAWRXOEQKL/ILN05hWrAzRTpiUtaa8Ov3JSgzoI2qEf dyUB25fYWuVgAwgTZMYtwv/XO07M4oY5qSA0bPaW8WjHFchVF/4cwYjebTCONga51Xq76a iTIACtB0oEPiIB9btz2araf36ksefEe7jxIHQlDiLcqX3XQy+/Vg3Wk54PhKSkzOaGrQJH xwH851FnLymALPUyImPVF/Mlo9H+7znnozh1SixBdIuam/JlUmUzsS+4uHvVUA== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: [secdir] Missing secdir assignment for draft-ietf-ntp-using-nts-for-ntp? X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 22:05:06 -0000 Franke, Daniel writes: > Did draft-ietf-ntp-using-nts-for-ntp somehow get overlooked for > SECDIR review? I see no review in the datatracker and nobody > assigned to do one. Seems to be so. I have no idea why the datatracker has not picked that one up. It seems to have entered to last call state 2020-02-14, and I did do assignments 2020-02-20, but for some reason that draft was not automatically picked up by the datatracker. I have no idea why the datatracker is not picking that document up. And as it is for telechat agenda for Thursday this week, there is no time to make secdir review for it on time (unless someone in the secdir has time to do emergency review today or tomorrow... I will make ticket (https://trac.tools.ietf.org/tools/ietfdb/ticket/2904) about this, so someone who can check out the logs and see if they can find out what happened to that draft. -- kivinen@iki.fi From nobody Mon Mar 9 15:10:40 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C4C3A079D; Mon, 9 Mar 2020 15:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 BFcWKwrA71ZC; Mon, 9 Mar 2020 15:10:29 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F1553A0817; Mon, 9 Mar 2020 15:10:28 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 029M4ar8010962; Mon, 9 Mar 2020 22:10:28 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=4OSWoFDFhIdLOOYVhi3H1ix7HVq1sLVY+3QTNLndzHQ=; b=A3utNFftvmlezHb6UFs6r6pmaWi+ZQ2wq2Gomux6MCQqyz91aOIvNAcUsbol0YZWj7wb iIMikGHfZ5rLoNhQf1JOxNyQDM63Be6qxD+GJ4Z3fOIk+lhika/y01TJ9QgYC3mWIVdb lFpfUvrQiTyUTqD4lHjnI1ansDhsV/BsMLMsbfyBxRi4xUXWpj4aGx8+OSS2XdtMKE0N VxXrQQfTAh85tWUIu9aXRCexHzpVx0bO1QdAh9jYWZuTXGzPfci1ye63/LPzHs0CKvu/ CY5I0NY/LzngmJA/9keRlRqIRb/xveRiQjFYZpON0K2jHPeLyTQGEZ/dChFLl1Gy0rI6 EA== Received: from prod-mail-ppoint8 (prod-mail-ppoint8.akamai.com [96.6.114.122] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2ym4wehqsc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 09 Mar 2020 22:10:28 +0000 Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 029M2BVl027363; Mon, 9 Mar 2020 18:10:27 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.117]) by prod-mail-ppoint8.akamai.com with ESMTP id 2ym7u1qdp1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 09 Mar 2020 18:10:27 -0400 Received: from USTX2EX-DAG3MB6.msg.corp.akamai.com (172.27.165.130) by USTX2EX-DAG3MB6.msg.corp.akamai.com (172.27.165.130) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 9 Mar 2020 17:10:26 -0500 Received: from USTX2EX-DAG3MB6.msg.corp.akamai.com ([172.27.165.130]) by USTX2EX-DAG3MB6.msg.corp.akamai.com ([172.27.165.130]) with mapi id 15.00.1497.006; Mon, 9 Mar 2020 17:10:26 -0500 From: "Franke, Daniel" To: Tero Kivinen CC: "ntp@ietf.org" , "secdir@ietf.org" , "sandy@tislabs.com" Thread-Topic: Missing secdir assignment for draft-ietf-ntp-using-nts-for-ntp? Thread-Index: AQHV9jSfcC2Y8Bb4V06FmksATtG71ahBJOcA//+tjWA= Date: Mon, 9 Mar 2020 22:10:26 +0000 Message-ID: <1583791826070.2373@akamai.com> References: <1583773461963.52013@akamai.com>, <24166.48512.923994.774704@fireball.acr.fi> In-Reply-To: <24166.48512.923994.774704@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.28.13.81] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-03-09_11:2020-03-09, 2020-03-09 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002050000 definitions=main-2003090133 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-03-09_11:2020-03-09, 2020-03-09 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 suspectscore=0 malwarescore=0 mlxlogscore=999 priorityscore=1501 phishscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2003090133 Archived-At: Subject: Re: [secdir] Missing secdir assignment for draft-ietf-ntp-using-nts-for-ntp? X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 22:10:38 -0000 How about we call Sandra's review the official secdir review then?=0A= ________________________________________=0A= From: Tero Kivinen =0A= Sent: Monday, March 9, 2020 18:04=0A= To: Franke, Daniel=0A= Cc: ntp@ietf.org; secdir@ietf.org=0A= Subject: Missing secdir assignment for draft-ietf-ntp-using-nts-for-ntp?=0A= =0A= Franke, Daniel writes:=0A= > Did draft-ietf-ntp-using-nts-for-ntp somehow get overlooked for=0A= > SECDIR review? I see no review in the datatracker and nobody=0A= > assigned to do one.=0A= =0A= Seems to be so. I have no idea why the datatracker has not picked that=0A= one up. It seems to have entered to last call state 2020-02-14, and I=0A= did do assignments 2020-02-20, but for some reason that draft was not=0A= automatically picked up by the datatracker. I have no idea why the=0A= datatracker is not picking that document up.=0A= =0A= And as it is for telechat agenda for Thursday this week, there is no=0A= time to make secdir review for it on time (unless someone in the=0A= secdir has time to do emergency review today or tomorrow...=0A= =0A= I will make ticket=0A= (https://trac.tools.ietf.org/tools/ietfdb/ticket/2904) about this, so=0A= someone who can check out the logs and see if they can find out what=0A= happened to that draft.=0A= --=0A= kivinen@iki.fi=0A= From nobody Mon Mar 9 21:28:21 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E383A0D32; Mon, 9 Mar 2020 21:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 N0pbfS_1g7w1; Mon, 9 Mar 2020 21:28:05 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11olkn2056.outbound.protection.outlook.com [40.92.19.56]) (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 4836B3A0F34; Mon, 9 Mar 2020 21:28:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KVyqdYjtRO71OnthCmaVX2YP2mHPMfmtqx7eBsAZYoIaXaFAFLwcPBc6cwQiE3A7O5QpCHxizEFj9ErVZ4BfbjQgvxU6AyasOrFYFBd/bmjHpa08uRLgJTmUnTPyHj+JQMQFOaxeAt8mQDTTe8k2EMLmWf87v9s4V/Ywu3KvXraCX8AOJwmNMKCJNfBrH5qLd0vkbzFarJELIZJkohwH74SX1RWEP1Iuusl6f/O2m3KJTQtSJYhu3R+bwjNZmzK2q9plc18Tz8x7+S0uKolUKX4pr45AAJ8LS5sl+BMZ5tXcshDcXXTAabcH3wIMARqQx6/2u4GJhBb0YoBna3Etxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kFWFjiegfaLIt5qGFh+zzF639y5HBcnif9lS+OxTND4=; b=LgnOW4QbP/0ovhJfi6jXodYxdQ5xqSxaXzVQfQNJRcOsF3OzFtUyCDr8124TpLZ3lyQbv2RNhsRiqXE8jjAjxMduH2EUpfXpMteoiLyX9n8ytR8h9lQuMhLaJc7YU3tHGvQKF0tryqS0QL5btzO5zgsaWMxLPa3uUP8xZkvtmy/LdN93P8z672ShYuCQL9oPdRckJv9SlmtOXao3/tMyDO226bZRTMClX+M6eGG9D45+lQNLnE1A8wHhpDpSb33YRBoo6pQgIXir+lQkojlzHAse4/ltJwDHI2ncX1VVFhq2ih8CHDLt/npO+EpZ7Q74PfFNg0IaRt9pzhg9ySxnaw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kFWFjiegfaLIt5qGFh+zzF639y5HBcnif9lS+OxTND4=; b=iC3QISZ4s2EKMhgufZ+aFJgN8ZxDON4KPruEl1qJBw5yWp5sUXa9P6e9gFtHbh5wOBs10Ul3ZpfUafGbvgAaVzaw+BqOVu4vo7uZK8mQcUTMaJN6bsnaRGlbuclVpc8+bHPpmyN33BpISDEEy7uTU459Dco0pLdEY/xtdZYoaaVzvbMUv/3lxq6fqzGSUn1vSmZojoMkWBBd3QJkP/DvSBN9KOlXMmagWvls0T8Ml+sf4eFyHhBUWYLqU3qLTySgiYXGsK+2Y0MNjf1z9RuMFE36PLybF1O7xpB6KDSGD4ouHTWjoN95KlOULhYbskyFYtJg0Pd5fy3gaxddsoNwXA== Received: from CO1NAM11FT034.eop-nam11.prod.protection.outlook.com (2a01:111:e400:3861::36) by CO1NAM11HT107.eop-nam11.prod.protection.outlook.com (2a01:111:e400:3861::67) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.11; Tue, 10 Mar 2020 04:27:58 +0000 Received: from MWHPR07MB3022.namprd07.prod.outlook.com (2a01:111:e400:3861::38) by CO1NAM11FT034.mail.protection.outlook.com (2a01:111:e400:3861::248) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.11 via Frontend Transport; Tue, 10 Mar 2020 04:27:58 +0000 Received: from MWHPR07MB3022.namprd07.prod.outlook.com ([fe80::b8aa:d51:1c05:e5c2]) by MWHPR07MB3022.namprd07.prod.outlook.com ([fe80::b8aa:d51:1c05:e5c2%10]) with mapi id 15.20.2793.013; Tue, 10 Mar 2020 04:27:58 +0000 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-ecrit-data-only-ea.all@ietf.org" Thread-Topic: Secdir review of draft-ietf-ecrit-data-only-ea-22 Thread-Index: AQHV9pPmrIjEdIT3Qk+swGPwFHA7rQ== Date: Tue, 10 Mar 2020 04:27:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:CC76F32459D47FF11E118C001832DAC2282056CF59A792B753D295692525A0CA; UpperCasedChecksum:758124576CEF65074093FD191F1618DBD234B9C088CA6FA3C68E9330A02BDE56; SizeAsReceived:6842; Count:42 x-tmn: [A8TdHTbd9dwrHbpOozTCKrwsoSP1/NSo] x-ms-publictraffictype: Email x-incomingheadercount: 42 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 0f4aeb4f-f467-4d33-ae97-08d7c4ab69c1 x-ms-traffictypediagnostic: CO1NAM11HT107: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1kwMgRo04J3eySSL7m+Hs+qFJyT14g3sdR+c0bLC09Tma3+HZopHriH7sWo0CZ+6C7r8pOQfZl0wWdwNgFC+dhIhMCbtiyml9Kc/BJ6ftky57STXiMnHalkXWP4JH88br3D3cII2Az4euL1M2iGF9G4d+0S5miMDxMPNzok8Y+UwrV0VkhRX4d6hmUnWnedAEuaP7IM7tTpdNjhsyxlGxhA+d9LZz5BHJKsJEk7UVVc= x-ms-exchange-antispam-messagedata: sMmh5twVYuGvPdn5muh0UCu4rpYmVjvU2VDWn2+Un+dKjbGBAkxAScIhX7JzsdzTTLxGC9T3olOFZ1GHUMUbO/84OxsqIN1GCT5wirqExGEYNSVQs7ZTprR8p3XF3k4a95xqf89XTJNTBca2aaZIrw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MWHPR07MB3022095D6C1139A44443BA66DFFF0MWHPR07MB3022namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 0f4aeb4f-f467-4d33-ae97-08d7c4ab69c1 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2020 04:27:58.7687 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM11HT107 Archived-At: Subject: [secdir] Secdir review of draft-ietf-ecrit-data-only-ea-22 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 04:28:15 -0000 --_000_MWHPR07MB3022095D6C1139A44443BA66DFFF0MWHPR07MB3022namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document defines a new MIME type: 'application/EmergencyCallData.cap+x= ml' for use primarily by sensors to send alert messages to emergency servic= es providers. It also defines a new Emergency Call Data Type: 'cap' in orde= r to embed this data efficiently in a SIP transaction. I saw no new securit= y issues beyond those already noted for the protocols carrying these messag= es. I reviewed version 18 of this document last August, and found no security i= ssues then either. I made several editorial suggestions and they have been = incorporated in subsequent drafts. --Charlie Sent from Outlook --_000_MWHPR07MB3022095D6C1139A44443BA66DFFF0MWHPR07MB3022namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security directorate's on= going effort to review all IETF documents being processed by the IESG. = ; These comments were written primarily for the benefit of the security are= a directors.  Document editors and WG chairs should treat these comments just like any other last call comments.=

This document defines a new MIME type: 'application/EmergencyCallData.= cap+xml' for use primarily by sensors to send alert messages to emergen= cy services providers. It also defines a new Emergency Call Data Type: 'cap= ' in order to embed this data efficiently in a SIP transaction. I saw no new security issues beyond those already no= ted for the protocols carrying these messages.

I reviewed version 18 of this document last August, and found no secur= ity issues then either. I made several editorial suggestions and they have = been incorporated in subsequent drafts.

 --Charlie


Sent from Outlook

--_000_MWHPR07MB3022095D6C1139A44443BA66DFFF0MWHPR07MB3022namp_-- From nobody Tue Mar 10 06:48:14 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5EE3A0F58; Tue, 10 Mar 2020 06:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=a4uabIQp; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=0KCYh1/v Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Acztv2yilbMF; Tue, 10 Mar 2020 06:48:09 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB17C3A0F53; Tue, 10 Mar 2020 06:48:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32289; q=dns/txt; s=iport; t=1583848088; x=1585057688; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=lu7pCkvlTXx5f6IHtEGWGjWf7Yv963yu/ulMDwsmd24=; b=a4uabIQp/EyJeL2Q3ZlZa/Z2CVX53bt0DA9ZNQHaRZX94RKkge2LzY0x itNm1sf3u6rYt/nyH14SHdshOrhof286H6fcMeF1MhpebozDPzEZb6OR1 CDnNv3xVVVsby9CH9lUdT3f/A+zkg3U0pPKnHe9S9mfkvrEOeEBurpx3p I=; IronPort-PHdr: =?us-ascii?q?9a23=3AjDEAlx9FCyYrcP9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+/bR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVdWGE0TpJdbhbjcxG4JJU1o2t3w=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DFAACLmWde/5NdJa1lDgwBAQEBAQE?= =?us-ascii?q?BAQEDAQEBAREBAQECAgEBAQGBe4ElL1AFbFggBAsqCoQLg0UDim+CX4ljjjK?= =?us-ascii?q?CUgNUCQEBAQwBAS0CBAEBhEMCF4FvJDgTAgMBAQsBAQUBAQECAQUEbYVWDIV?= =?us-ascii?q?jAQEBAQMSER0BATcBDwIBCBEDAQIhBwMCAgIfERQJCAIEDgUigwQBgX1NAy4?= =?us-ascii?q?BniUCgTmIYnWBMoJ/AQEFhQwNC4IMCYE4jCwaggCBEScggk0+ghuCUBaCWzK?= =?us-ascii?q?CLJBshXKKD45RLEQKgjySMoQ4HYJKiCSETot+kEeJYIwog3wCBAIEBQIOAQE?= =?us-ascii?q?FgWkigVhwFWUBgkFQGA2BGo0DDQQSg1CEWYU/PXQCgSeMRwGBDwEB?= X-IronPort-AV: E=Sophos;i="5.70,537,1574121600"; d="scan'208,217";a="445125474" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Mar 2020 13:48:07 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 02ADm3Yh005808 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 10 Mar 2020 13:48:06 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 10 Mar 2020 08:48:04 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 10 Mar 2020 09:48:02 -0400 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 10 Mar 2020 08:48:02 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BqzgbkR0Lq0fMu8KWM2S92YxMGAhzdMhEdv+Bz8evR8/HKftIJvVq3yd0OswUtu4AQbsOaZB8rJ8qRAKMGCJ/8DWu4nlldxQkxQNyGHcBdieqOIGxRSIj0NwDZORPPKuE+PU+OXUIHJ5ab2x/mIAFjFVIItnqPSHhbhx82VQ8bsCJbyQdR3/wX4b3lANvXen1V6z9oYwebrzfs2jzxdFtCWmcE40C6/aah3r8yVbEesb0Y8dQy8rJ5rdPAAqtbyWWbZv9x6hSaniy3N+SYhKAhkeZpPA0QjNc2MvOQ8Lq2nuOk0+lxkWKi2afuBOpUi1OU3M57JcVvRwPvjOOJhV/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lu7pCkvlTXx5f6IHtEGWGjWf7Yv963yu/ulMDwsmd24=; b=n1vgGQ7IXivr5tobC+OUkPxx5ksnzgf4eDwQ3X9D2V/tzwYsyssa8kNHMiOgurGhYc0H/jL3oTr1fhvYUX7LKirLFnxJHIVLsUQJCQxNtd2fpW429F8Dwn/5FKcP8c/jUpJ6ud1D8U+BLa4w5yVAN9dF7YzdLxPvGk1cW/FNkdmLK+dV6+mnIvuluG6jipNfSOcAlnzAjadl8+7BEehDNnQdluKTURnZgutq+wPtCL67tEK0D14YMnXHQUhl4BJ8eZGNic5OcjFyurYCiFQe8IOQbrizoOUiwF1LGqjPj85Fd6VfzVr4/Mh75iVZKNsmXE2ZUegtHT+SbIqmPHvPbA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lu7pCkvlTXx5f6IHtEGWGjWf7Yv963yu/ulMDwsmd24=; b=0KCYh1/vwasj4Cnvn9u0pvH7A8mGd6549cVgc0H8rOMokspZ7qyrbRnTftIz0CB9Cbg0+jy/Hr6Zsc8U0uSNWhG3hOGEcOmZEm2kimxDjz5Bs1d0bnhLZtiLxkhpLrG3imDlGzLNFbLykgtd7cJEnkXoGnUo6Jr3XhxQ0nGVm3U= Received: from BL0PR11MB3412.namprd11.prod.outlook.com (2603:10b6:208:7c::32) by BL0PR11MB3410.namprd11.prod.outlook.com (2603:10b6:208:33::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.17; Tue, 10 Mar 2020 13:48:01 +0000 Received: from BL0PR11MB3412.namprd11.prod.outlook.com ([fe80::b955:b5f0:af03:ee30]) by BL0PR11MB3412.namprd11.prod.outlook.com ([fe80::b955:b5f0:af03:ee30%3]) with mapi id 15.20.2793.018; Tue, 10 Mar 2020 13:48:01 +0000 From: "Kamran Raza (skraza)" To: "Shawn M. Emery" CC: secdir , "draft-ietf-mpls-ldp-yang.all@ietf.org" Thread-Topic: Updated rev posted [Re: Review of draft-ietf-mpls-ldp-yang-07] Thread-Index: AQHV7e9JI5sjC6LP2EGHwHk11d+oLqgyyzYAgA7a4wA= Date: Tue, 10 Mar 2020 13:48:01 +0000 Message-ID: <3791FB89-740C-44AA-A7B2-8DF07155E19C@cisco.com> References: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.22.0.200209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=skraza@cisco.com; x-originating-ip: [173.38.117.91] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dfc47c99-614c-45ae-5bc4-08d7c4f9a69a x-ms-traffictypediagnostic: BL0PR11MB3410: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 033857D0BD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(376002)(346002)(39860400002)(136003)(199004)(189003)(6916009)(8936002)(64756008)(316002)(66446008)(296002)(54906003)(186003)(2906002)(2616005)(6486002)(26005)(66476007)(66556008)(76116006)(81166006)(81156014)(8676002)(71200400001)(66946007)(86362001)(478600001)(5660300002)(33656002)(6512007)(53546011)(4326008)(15650500001)(36756003)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:BL0PR11MB3410; H:BL0PR11MB3412.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Fsb0pvQ8X27GGN1eu481XEeNvyOrHShxp+5DPDnTNWUhnCzN4Vi+NfH9gDfTugO5rL1M24wSYUCR7lBHFeROCxK+YVwIkUrBWQZ8ctVgWwAGCBbGQhUu1ZCjVN6PIhTivxT+Sfkvohq+wVhUpUQejBYFtPKD1v9ED60X4ryXgfo8eK2tq/psD4VEzaPIv8z7Wh2VgfpToNrX9Hkv7VKaH1eKwMGy7IpCDRErGKJMB3sxSgjQcYrsaJELPB7fOfvqzYk1tsLflwPnohoWdaip7O8aszdGovW/NMiJlujz/i1h5/Dqv68V4MNqYw3URoLjInk+mgxBjhKMpw3Rg6GMXYpkq2TzKGrtdt+ChDB211xEzLGbSRhdcbjZAfIpgjqak2CXJNsIvNL0A6L92igeT6XTt7BbLQK2KcitMx1QDIPtkwsf1JHfGq5hPFo11MhE x-ms-exchange-antispam-messagedata: 2TOT7o59Q2Ik/SjA6pyg4ed0EpXyLqP0VnBbMYr95KVB7yVtO0LnjLhiAyRbbiXZvvuJumsIaw1Pc7AIwvElRQDe83SsqdZK7A++0n/5g87a9RYos9MZZTJn62zBw5jPPGMGGr4JNrzgBoTZ5mcOow== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_3791FB89740C44AAA7B28DF07155E19Cciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: dfc47c99-614c-45ae-5bc4-08d7c4f9a69a X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2020 13:48:01.5290 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: K1NmYvnz9txkazAz8Mdi/cvF2rQTEfZvewsOtKQfC4Ri8FawidJzpdkfBXRszmw/Fq3pWt56fb157/ZcQLlRyw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3410 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [secdir] Updated rev posted [Re: Review of draft-ietf-mpls-ldp-yang-07] X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 13:48:12 -0000 --_000_3791FB89740C44AAA7B28DF07155E19Cciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 77u/SGkgU2hhd24sDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4gUGxlYXNlIHNlZSBpbmxp bmUgW3NrcmF6YTJdDQoNCkZyb206ICJTaGF3biBNLiBFbWVyeSIgPHNlbWVyeUB1Y2NzLmVkdT4N CkRhdGU6IFNhdHVyZGF5LCBGZWJydWFyeSAyOSwgMjAyMCBhdCA1OjU3IFBNDQpUbzogIkthbXJh biBSYXphIChza3JhemEpIiA8c2tyYXphQGNpc2NvLmNvbT4NCkNjOiBzZWNkaXIgPHNlY2RpckBp ZXRmLm9yZz4sICJkcmFmdC1pZXRmLW1wbHMtbGRwLXlhbmcuYWxsQGlldGYub3JnIiA8ZHJhZnQt aWV0Zi1tcGxzLWxkcC15YW5nLmFsbEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBVcGRhdGVkIHJl diBwb3N0ZWQgW1JlOiBSZXZpZXcgb2YgZHJhZnQtaWV0Zi1tcGxzLWxkcC15YW5nLTA3XQ0KDQpU aGFuayB5b3UgZm9yIHRoZSBtYWpvciB1cGRhdGUsIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9u IHNlY3Rpb24gbG9va3MgbXVjaCBiZXR0ZXIuICBIZXJlIGFyZSBteSBjb21tZW50cyB3aXRoIHJl diAwODoNCg0KMS4gSW4gc2VjdGlvbiAxMC4xLjIsIGl0IHN0YXRlcyB0aGF0IExEUCBwZWVyIGF1 dGhlbnRpY2F0aW9uIGNhbiBiZSBhdWdtZW50ZWQgdmlhIGEga2V5IGdlbmVyYXRlZCB3aXRoIGFu IGFsZ29yaXRobSBzdWNoIGFzIE1ENS4gIEkga25vdyBpdCBtYXkgYmUgb3V0IG9mIHNjb3BlIGZy b20gdGhpcyBkb2N1bWVudCwgYnV0IHdoeSBpcyBNRDUgZ2l2ZW4gYXMgYW4gZXhhbXBsZSByYXRo ZXIgdGhhbiBzY3J5cHQgb3IgaXMgdGhlIGFzc3VtcHRpb24gdGhhdCB0aGUga2V5cyBhcmUgYmFz ZWQgb24gaGlnaCBlbnRyb3B5Pw0KW3NrcmF6YTJdOiBNRDUgaXMgc3BlY2lmaWVkIGFzIHRoZSBh dXRoZW50aWNhdGlvbiBtZWNoYW5pc20gaW4gYmFzZSBMRFAgc3BlYyBSRkMgNTAzNiBhbmQgaGVu Y2Ugc3BlY2lhbCBtZW50aW9uIGhlcmUuIEluZmFjdCwgaW4gcHJldiByZXZpc2lvbiwgd2Ugd2Vy ZSBvbmx5IGNvdmVyaW5nIG1kNSBhbmQgY2hhbmdlZCB0aGUgbW9kZWwgdG8gbWFrZSBpdCBtb3Jl IGdlbmVyaWMgdG8gY292ZXIgb3RoZXIgdHlwZXMsIGluY2x1ZGluZyBNRDUuDQoNCjIuIEluIHNl Y3Rpb24gMTAuMS4zLCBpdCBzdGF0ZXM6DQpUaGVzZSBhcmUgdGhlIG9wZXJhdGlvbnMgYW5kIHRo ZWlyIHNlbnNpdGl2aXR5L3Z1bG5lcmFiaWxpdHk6DQouLi4NCg0KYnV0IHRoZSB2dWxuZXJhYmls aXRpZXMgd2VyZSBsaXN0ZWQgYmVmb3JlIHRoaXMgc3RhdGVtZW50LiAgU2hvdWxkIHJlb3JkZXIu DQoNCltza3JhemEyXTogUmVwaHJhc2VkLiBXaWxsIGJlIHBhcnQgb2YgcmV2IC0wOSB1cGRhdGUu DQoNClJlZ2FyZHMsDQoNClNoYXduLg0KLS0NCg0KT24gVGh1LCBGZWIgMjcsIDIwMjAgYXQgMTE6 MjYgUE0gS2FtcmFuIFJhemEgKHNrcmF6YSkgPHNrcmF6YUBjaXNjby5jb208bWFpbHRvOnNrcmF6 YUBjaXNjby5jb20+PiB3cm90ZToNClRoYW5rcyBmb3IgeW91ciByZXZpZXcgYW5kIGNvbW1lbnRz Lg0KDQpXZSBoYXZlIGp1c3QgcG9zdGVkIGEgbmV3IHJldiAtMDggdGhhdCB0YWtlcyBjYXJlIG9m IHlvdXIgY29tbWVudHMgYW5kIGNvbW1lbnRzIGZyb20gb3RoZXIgSUVTRyByZXZpZXdlcnMuDQpP biBiZWhhbGYgb2YgYXV0aG9ycywgcGxlYXNlIHNlZSBpbmxpbmUgW3NrcmF6YV06DQoNCkZyb206 ICJTaGF3biBNLiBFbWVyeSIgPHNlbWVyeUB1Y2NzLmVkdTxtYWlsdG86c2VtZXJ5QHVjY3MuZWR1 Pj4NCkRhdGU6IE1vbmRheSwgTm92ZW1iZXIgMjUsIDIwMTkgYXQgNTozNCBQTQ0KVG86IHNlY2Rp ciA8c2VjZGlyQGlldGYub3JnPG1haWx0bzpzZWNkaXJAaWV0Zi5vcmc+PiwgImRyYWZ0LWlldGYt bXBscy1sZHAteWFuZy5hbGxAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtbXBscy1sZHAteWFu Zy5hbGxAaWV0Zi5vcmc+IiA8ZHJhZnQtaWV0Zi1tcGxzLWxkcC15YW5nLmFsbEBpZXRmLm9yZzxt YWlsdG86ZHJhZnQtaWV0Zi1tcGxzLWxkcC15YW5nLmFsbEBpZXRmLm9yZz4+DQpDYzogU2hhd24g RW1lcnkgPHNoYXduLmVtZXJ5QGdtYWlsLmNvbTxtYWlsdG86c2hhd24uZW1lcnlAZ21haWwuY29t Pj4NClN1YmplY3Q6IFJldmlldyBvZiBkcmFmdC1pZXRmLW1wbHMtbGRwLXlhbmctMDcNClJlc2Vu dC1Gcm9tOiA8YWxpYXMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86YWxpYXMtYm91bmNlc0BpZXRm Lm9yZz4+DQpSZXNlbnQtVG86IDxza3JhemFAY2lzY28uY29tPG1haWx0bzpza3JhemFAY2lzY28u Y29tPj4sIDxyYWppdmFAY2lzY28uY29tPG1haWx0bzpyYWppdmFAY2lzY28uY29tPj4sIDx4dWZl bmcubGl1LmlldGZAZ21haWwuY29tPG1haWx0bzp4dWZlbmcubGl1LmlldGZAZ21haWwuY29tPj4s IDxzZXNhbGVAanVuaXBlci5uZXQ8bWFpbHRvOnNlc2FsZUBqdW5pcGVyLm5ldD4+LCA8amVzY2lh LmNoZW54aWFAaHVhd2VpLmNvbTxtYWlsdG86amVzY2lhLmNoZW54aWFAaHVhd2VpLmNvbT4+LCA8 aHNoYWhAY2llbmEuY29tPG1haWx0bzpoc2hhaEBjaWVuYS5jb20+PiwgPG1hY2guY2hlbkBodWF3 ZWkuY29tPG1haWx0bzptYWNoLmNoZW5AaHVhd2VpLmNvbT4+LCA8dHNhYWQubmV0QGdtYWlsLmNv bTxtYWlsdG86dHNhYWQubmV0QGdtYWlsLmNvbT4+LCA8bi5sZXltYW5uQHRlbGVrb20uZGU8bWFp bHRvOm4ubGV5bWFubkB0ZWxla29tLmRlPj4sIDxsb2FAcGkubnU8bWFpbHRvOmxvYUBwaS5udT4+ LCA8bWFydGluLnZpZ291cmV1eEBub2tpYS5jb208bWFpbHRvOm1hcnRpbi52aWdvdXJldXhAbm9r aWEuY29tPj4sIDxkYjM1NDZAYXR0LmNvbTxtYWlsdG86ZGIzNTQ2QGF0dC5jb20+PiwgPGFyZXRh bmEuaWV0ZkBnbWFpbC5jb208bWFpbHRvOmFyZXRhbmEuaWV0ZkBnbWFpbC5jb20+PiwgTmljb2xh aSBMZXltYW5uIDxuLmxleW1hbm5AdGVsZWtvbS5kZTxtYWlsdG86bi5sZXltYW5uQHRlbGVrb20u ZGU+PiwgVGFyZWsgU2FhZCA8dHNhYWQubmV0QGdtYWlsLmNvbTxtYWlsdG86dHNhYWQubmV0QGdt YWlsLmNvbT4+DQpSZXNlbnQtRGF0ZTogTW9uZGF5LCBOb3ZlbWJlciAyNSwgMjAxOSBhdCA1OjMz IFBNDQoNClJldmlld2VyOiBTaGF3biBNLiBFbWVyeQ0KUmV2aWV3IHJlc3VsdDogUmVhZHkgd2l0 aCBuaXRzDQoNCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNl Y3VyaXR5IGRpcmVjdG9yYXRlJ3MNCm9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBk b2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLg0KVGhlc2UgY29tbWVudHMgd2Vy ZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5DQphcmVh IGRpcmVjdG9ycy4gRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0 aGVzZQ0KY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQoN ClRoaXMgZHJhZnQgc3BlY2lmaWVzIGEgWUFORyBtb2RlbCBmb3IgdGhlIE11bHRpLVByb3RvY29s IExhYmVsDQpTd2l0Y2hpbmcgKE1QTFMpIExhYmVsIERpc3RyaWJ1dGlvbiBQcm90b2NvbCAoTERQ KS4gIE5ldHdvcmsNCkNvbmZpZ3VyYXRpb24gUHJvdG9jb2wgKE5FVENPTkYpIGFuZCBSRVNUQ09O RiBpcyB1c2VkDQp0byBtYW5nZSBuZXR3b3JrIGRldmljZXMgYmFzZWQgb24gdGhpcyBtb2RlbC4N Cg0KVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gZG9lcyBleGlzdCBhbmQgZm9y IHNlY3VyaXR5DQphbmQgcHJpdmFjeSBjb25jZXJucywgZGlzY3Vzc2VzIHRoYXQgdGhlIE1USSBm b3IgTkVUQ09ORiBpcw0KU1NIIGFuZCBUTFMgZm9yIFJFU1RDT05GLiAgRm9yIGF1dGhvcml6YXRp b24sIE5FVENPTkYNCmFuZCBSRVNUQ09ORiB1c2VzIHRoZSBOZXR3b3JrIENvbmZpZ3VyYXRpb24g QWNjZXNzIENvbnRyb2wNCk1vZGVsIChOQUNNKS4NCg0KVGhlIHNlY3Rpb24gZ29lcyBvbiB0byBz dGF0ZSB0aGF0IHNvbWUgZGF0YSBub2Rlcw0KYW5kIFJQQyBvcGVyYXRpb25zIGluIHRoZSBZQU5H IG1vZHVsZSBhcmUgY29uc2lkZXJlZCBzZW5zaXRpdmUNCnRvIHZhcmlvdXMgb3BlcmF0aW9ucywg YnV0IGRvZXMgbm90IGdpdmUgZ3VpZGFuY2Ugb24gd2hpY2ggbm9kZXMNCm9yIHN1YnRyZWVzIHRo YXQgd291bGQgYmUgYWZmZWN0ZWQuICBJbiB0aGUgcGFzdCwgbW9kdWxlIHNwZWNpZmljYXRpb25z DQp0aGF0IEkndmUgcmV2aWV3ZWQgaGF2ZSBvdXRsaW5lZCBlYWNoIG9mIHRoZXNlIHJlbGV2YW50 IGl0ZW1zLg0KDQpbc2tyYXphXTogRW5oYW5jZWQgdGhpcyBzZWN0aW9uIHNpZ25pZmljYW50bHkg YW5kIGhhdmUgYWRkZWQgdGhlIHJlbGV2YW50IGl0ZW1zIHRvIHRoaXMgc2VjdGlvbi4gU2VlIGRy YWZ0IHJldiAtMDguDQoNClRoZSBzZWN0aW9uIGZpbmlzaGVzIHdpdGggdGhlIHN0YXRlbWVudCB0 aGF0IHRoZSBzZWN1cml0eQ0KcHJvcGVydGllcyBvZiB0aGUgYmFzZSBzcGVjaWZpY2F0aW9ucywg TERQLCBMRFAgSVB2NiwgZXRjLiwgYWxzbyBhcHBsaWVzDQp0byB0aGlzIGRyYWZ0LiAgSSBhZ3Jl ZSB3aXRoIHRoZSBhYm92ZSBhc3NlcnRpb25zLg0KDQpHZW5lcmFsIGNvbW1lbnRzOg0KDQpOb25l Lg0KDQpFZGl0b3JpYWwgY29tbWVudHM6DQpbc2tyYXphXTogRml4ZWQgYWxsIHRoZSBsaXN0ZWQu DQoNCnMvaW50byBmb2xsb3dpbmcvaW50byB0aGUgZm9sbG93aW5nLw0Kcy9tZWFucyBhbmQgYmUg cmVhZC9zaG91bGQgYmUgcmVhZC8NCnMvZmFtaWx5Ii9mYW1pbHkiLi8NCnMvVlBOIEZvcndhcmRp bmcgYW5kIFJvdXRpbmcvVlBOIFJvdXRpbmcgYW5kIEZvcndhcmRpbmcvDQpzL3Byb3ZpZGVzIGEg bWVhbi9wcm92aWRlcyBhIG1lYW5zLw0Kcy9OZWliZ2Jvci9OZWlnaGJvci8NCnMvcGVyZWZlcmVu Y2UvcHJlZmVyZW5jZS8NCnMvY3JlYXRhYmxlXC8gZGVsZXRhYmxlL2NyZWF0YWJsZVwvZGVsZXRh YmxlLw0KDQpSRVNUQ09ORiBzaG91bGQgYmUgZXhwYW5kZWQgb24gZmlyc3Qgb2N1cmVuY2UuDQpb c2tyYXphXTogSSBjb3VsZCBub3QgZmluZCB0aGUgZXhwYW5zaW9uIOKAkyBldmVuIGluIHRoZSBS RVNUQ09ORiBSRkMgODA0MCAuDQoNClNoYXduLg0KLS0NCg== --_000_3791FB89740C44AAA7B28DF07155E19Cciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <35182F7E60B2934DB1DFD63A1D978D96@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw LmdtYWlsLW0tNjU0OTczNDg2ODM5MTI5NDA4Nm1zb3BsYWludGV4dCwgbGkuZ21haWwtbS02NTQ5 NzM0ODY4MzkxMjk0MDg2bXNvcGxhaW50ZXh0LCBkaXYuZ21haWwtbS02NTQ5NzM0ODY4MzkxMjk0 MDg2bXNvcGxhaW50ZXh0DQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLW1fLTY1NDk3MzQ4NjgzOTEy OTQwODZtc29wbGFpbnRleHQ7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJp Z2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQXJpYWwiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUNB IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iRW1haWxTdHlsZTE5Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPu+7vzwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9IkVtYWlsU3R5bGUxOSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkhpIFNoYXduLDwvc3Bhbj48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiBQbGVhc2Ugc2VlIGlubGluZSBbc2tyYXphMl08 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZxdW90O1NoYXduIE0uIEVtZXJ5JnF1b3Q7ICZs dDtzZW1lcnlAdWNjcy5lZHUmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlNhdHVyZGF5LCBGZWJydWFy eSAyOSwgMjAyMCBhdCA1OjU3IFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtLYW1yYW4gUmF6YSAo c2tyYXphKSZxdW90OyAmbHQ7c2tyYXphQGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPnNl Y2RpciAmbHQ7c2VjZGlyQGlldGYub3JnJmd0OywgJnF1b3Q7ZHJhZnQtaWV0Zi1tcGxzLWxkcC15 YW5nLmFsbEBpZXRmLm9yZyZxdW90OyAmbHQ7ZHJhZnQtaWV0Zi1tcGxzLWxkcC15YW5nLmFsbEBp ZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFVwZGF0ZWQgcmV2IHBvc3RlZCBb UmU6IFJldmlldyBvZiBkcmFmdC1pZXRmLW1wbHMtbGRwLXlhbmctMDddPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFuayB5b3Ug Zm9yIHRoZSBtYWpvciB1cGRhdGUsIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9uIHNlY3Rpb24g bG9va3MgbXVjaCBiZXR0ZXIuJm5ic3A7IEhlcmUgYXJlIG15IGNvbW1lbnRzIHdpdGggcmV2IDA4 Og0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xLiBJbiBz ZWN0aW9uIDEwLjEuMiwgaXQgc3RhdGVzIHRoYXQgTERQIHBlZXIgYXV0aGVudGljYXRpb24gY2Fu IGJlIGF1Z21lbnRlZCB2aWEgYSBrZXkgZ2VuZXJhdGVkIHdpdGggYW4gYWxnb3JpdGhtIHN1Y2gg YXMgTUQ1LiZuYnNwOyBJIGtub3cgaXQgbWF5IGJlIG91dCBvZiBzY29wZSBmcm9tIHRoaXMgZG9j dW1lbnQsIGJ1dCB3aHkgaXMgTUQ1IGdpdmVuIGFzIGFuIGV4YW1wbGUgcmF0aGVyIHRoYW4gc2Ny eXB0IG9yDQogaXMgdGhlIGFzc3VtcHRpb24gdGhhdCB0aGUga2V5cyBhcmUgYmFzZWQgb24gaGln aCBlbnRyb3B5PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+W3NrcmF6YTJdOiBNRDUgaXMgc3BlY2lmaWVkIGFzIHRoZSBhdXRoZW50aWNhdGlvbiBt ZWNoYW5pc20gaW4gYmFzZSBMRFAgc3BlYyBSRkMgNTAzNiBhbmQgaGVuY2Ugc3BlY2lhbCBtZW50 aW9uIGhlcmUuIEluZmFjdCwgaW4gcHJldiByZXZpc2lvbiwgd2Ugd2VyZSBvbmx5IGNvdmVyaW5n IG1kNSBhbmQgY2hhbmdlZCB0aGUgbW9kZWwgdG8gbWFrZSBpdCBtb3JlIGdlbmVyaWMgdG8gY292 ZXIgb3RoZXIgdHlwZXMsDQogaW5jbHVkaW5nIE1ENS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+Mi4gSW4gc2VjdGlvbiAxMC4xLjMsIGl0IHN0YXRlczo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXNlIGFyZSB0aGUgb3BlcmF0 aW9ucyBhbmQgdGhlaXIgc2Vuc2l0aXZpdHkvdnVsbmVyYWJpbGl0eTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi4uLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5idXQgdGhlIHZ1bG5lcmFiaWxp dGllcyB3ZXJlIGxpc3RlZCBiZWZvcmUgdGhpcyBzdGF0ZW1lbnQuJm5ic3A7IFNob3VsZCByZW9y ZGVyLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZiI+W3NrcmF6YTJdOiBSZXBocmFzZWQuIFdpbGwgYmUgcGFydCBvZiByZXYg LTA5IHVwZGF0ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaGF3bi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBGZWIgMjcsIDIw MjAgYXQgMTE6MjYgUE0gS2FtcmFuIFJhemEgKHNrcmF6YSkgJmx0OzxhIGhyZWY9Im1haWx0bzpz a3JhemFAY2lzY28uY29tIj5za3JhemFAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyBmb3IgeW91ciByZXZp ZXcgYW5kIGNvbW1lbnRzLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWls LW0tNjU0OTczNDg2ODM5MTI5NDA4Nm1zb3BsYWludGV4dCI+V2UgaGF2ZSBqdXN0IHBvc3RlZCBh IG5ldyByZXYgLTA4IHRoYXQgdGFrZXMgY2FyZSBvZiB5b3VyIGNvbW1lbnRzIGFuZCBjb21tZW50 cyBmcm9tIG90aGVyIElFU0cgcmV2aWV3ZXJzLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5PbiBiZWhhbGYgb2YgYXV0 aG9ycywgcGxlYXNlIHNlZSBpbmxpbmUNCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjaztiYWNrZ3Jv dW5kOnllbGxvdyI+W3NrcmF6YV08L3NwYW4+Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2si PkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj4mcXVvdDtTaGF3biBNLiBFbWVyeSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNlbWVy eUB1Y2NzLmVkdSIgdGFyZ2V0PSJfYmxhbmsiPnNlbWVyeUB1Y2NzLmVkdTwvYT4mZ3Q7PGJyPg0K PGI+RGF0ZTogPC9iPk1vbmRheSwgTm92ZW1iZXIgMjUsIDIwMTkgYXQgNTozNCBQTTxicj4NCjxi PlRvOiA8L2I+c2VjZGlyICZsdDs8YSBocmVmPSJtYWlsdG86c2VjZGlyQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+c2VjZGlyQGlldGYub3JnPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0 bzpkcmFmdC1pZXRmLW1wbHMtbGRwLXlhbmcuYWxsQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ ZHJhZnQtaWV0Zi1tcGxzLWxkcC15YW5nLmFsbEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpkcmFmdC1pZXRmLW1wbHMtbGRwLXlhbmcuYWxsQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+ZHJhZnQtaWV0Zi1tcGxzLWxkcC15YW5nLmFsbEBpZXRmLm9yZzwvYT4mZ3Q7PGJy Pg0KPGI+Q2M6IDwvYj5TaGF3biBFbWVyeSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNoYXduLmVtZXJ5 QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNoYXduLmVtZXJ5QGdtYWlsLmNvbTwvYT4mZ3Q7 PGJyPg0KPGI+U3ViamVjdDogPC9iPlJldmlldyBvZiBkcmFmdC1pZXRmLW1wbHMtbGRwLXlhbmct MDc8YnI+DQo8Yj5SZXNlbnQtRnJvbTogPC9iPiZsdDs8YSBocmVmPSJtYWlsdG86YWxpYXMtYm91 bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmFsaWFzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCjxiPlJlc2VudC1UbzogPC9iPiZsdDs8YSBocmVmPSJtYWlsdG86c2tyYXphQGNp c2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNrcmF6YUBjaXNjby5jb208L2E+Jmd0OywgJmx0Ozxh IGhyZWY9Im1haWx0bzpyYWppdmFAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+cmFqaXZhQGNp c2NvLmNvbTwvYT4mZ3Q7LCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnh1ZmVuZy5saXUuaWV0ZkBnbWFp bC5jb20iIHRhcmdldD0iX2JsYW5rIj54dWZlbmcubGl1LmlldGZAZ21haWwuY29tPC9hPiZndDss DQogJmx0OzxhIGhyZWY9Im1haWx0bzpzZXNhbGVAanVuaXBlci5uZXQiIHRhcmdldD0iX2JsYW5r Ij5zZXNhbGVAanVuaXBlci5uZXQ8L2E+Jmd0OywgJmx0OzxhIGhyZWY9Im1haWx0bzpqZXNjaWEu Y2hlbnhpYUBodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+amVzY2lhLmNoZW54aWFAaHVhd2Vp LmNvbTwvYT4mZ3Q7LCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhzaGFoQGNpZW5hLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmhzaGFoQGNpZW5hLmNvbTwvYT4mZ3Q7LCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1h Y2guY2hlbkBodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFjaC5jaGVuQGh1YXdlaS5jb208 L2E+Jmd0OywNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRzYWFkLm5ldEBnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj50c2FhZC5uZXRAZ21haWwuY29tPC9hPiZndDssICZsdDs8YSBocmVmPSJtYWls dG86bi5sZXltYW5uQHRlbGVrb20uZGUiIHRhcmdldD0iX2JsYW5rIj5uLmxleW1hbm5AdGVsZWtv bS5kZTwvYT4mZ3Q7LCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxvYUBwaS5udSIgdGFyZ2V0PSJfYmxh bmsiPmxvYUBwaS5udTwvYT4mZ3Q7LCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi52aWdvdXJl dXhAbm9raWEuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFydGluLnZpZ291cmV1eEBub2tpYS5jb208 L2E+Jmd0OywNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRiMzU0NkBhdHQuY29tIiB0YXJnZXQ9Il9i bGFuayI+ZGIzNTQ2QGF0dC5jb208L2E+Jmd0OywgJmx0OzxhIGhyZWY9Im1haWx0bzphcmV0YW5h LmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+YXJldGFuYS5pZXRmQGdtYWlsLmNvbTwv YT4mZ3Q7LCBOaWNvbGFpIExleW1hbm4gJmx0OzxhIGhyZWY9Im1haWx0bzpuLmxleW1hbm5AdGVs ZWtvbS5kZSIgdGFyZ2V0PSJfYmxhbmsiPm4ubGV5bWFubkB0ZWxla29tLmRlPC9hPiZndDssIFRh cmVrDQogU2FhZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRzYWFkLm5ldEBnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj50c2FhZC5uZXRAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8Yj5SZXNlbnQtRGF0 ZTogPC9iPk1vbmRheSwgTm92ZW1iZXIgMjUsIDIwMTkgYXQgNTozMyBQTTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPlJldmlld2VyOiBTaGF3biBNLiBFbWVyeTxicj4NClJldmlldyByZXN1 bHQ6Jm5ic3A7UmVhZHkgd2l0aCBuaXRzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij5J IGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJl Y3RvcmF0ZSdzPGJyPg0Kb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCZuYnNwO0lFVEYmbmJz cDtkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLjxicj4NClRoZXNlIGNvbW1l bnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0 eTxicj4NCmFyZWEgZGlyZWN0b3JzLiBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hv dWxkIHRyZWF0IHRoZXNlPGJyPg0KY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNh bGwgY29tbWVudHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+VGhpcyBkcmFmdCBzcGVjaWZpZXMgYSBZQU5H IG1vZGVsIGZvciB0aGUmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi Pk11bHRpLVByb3RvY29sIExhYmVsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+ U3dpdGNoaW5nIChNUExTKSBMYWJlbCBEaXN0cmlidXRpb24gUHJvdG9jb2wgKExEUCkuJm5ic3A7 Jm5ic3A7TmV0d29yazwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkNvbmZpZ3Vy YXRpb24gUHJvdG9jb2wgKE5FVENPTkYpIGFuZCBSRVNUQ09ORiBpcyB1c2VkPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+dG8gbWFuZ2UgbmV0d29yayZuYnNwO2RldmljZXMgYmFz ZWQgb24gdGhpcyBtb2RlbC4mbmJzcDsmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjVwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjVwdCI+VGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gZG9lcyBleGlzdCBhbmQg Zm9yIHNlY3VyaXR5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij5hbmQgcHJpdmFj eSBjb25jZXJucywmbmJzcDtkaXNjdXNzZXMmbmJzcDt0aGF0IHRoZSBNVEkgZm9yIE5FVENPTkYg aXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPlNTSCBhbmQgVExTJm5ic3A7Zm9y IFJFU1RDT05GLiZuYnNwOyBGb3IgYXV0aG9yaXphdGlvbiwgTkVUQ09ORjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjVwdCI+YW5kIFJFU1RDT05GIHVzZXMgdGhlJm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5OZXR3b3JrIENvbmZpZ3VyYXRpb24gQWNjZXNz IENvbnRyb2w8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Nb2RlbCAoTkFDTSku PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij5UaGUgc2VjdGlvbiBnb2VzIG9uIHRvIHN0YXRlIHRoYXQgc29t ZSBkYXRhIG5vZGVzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+YW5kIFJQQyBv cGVyYXRpb25zIGluIHRoZSBZQU5HIG1vZHVsZSBhcmUgY29uc2lkZXJlZCBzZW5zaXRpdmU8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij50byB2YXJpb3VzIG9wZXJhdGlvbnMsJm5i c3A7YnV0IGRvZXMgbm90IGdpdmUgZ3VpZGFuY2Ugb24gd2hpY2ggbm9kZXM8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij5vciBzdWJ0cmVlcyB0aGF0IHdvdWxkJm5ic3A7YmUgYWZm ZWN0ZWQuJm5ic3A7IEluIHRoZSBwYXN0LCBtb2R1bGUgc3BlY2lmaWNhdGlvbnM8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij50aGF0IEkndmUgcmV2aWV3ZWQgaGF2ZSBvdXRsaW5l ZCBlYWNoIG9mIHRoZXNlIHJlbGV2YW50IGl0ZW1zLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjVwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6eWVsbG93Ij5bc2tyYXph XTogRW5oYW5jZWQgdGhpcyBzZWN0aW9uIHNpZ25pZmljYW50bHkgYW5kIGhhdmUgYWRkZWQgdGhl IHJlbGV2YW50IGl0ZW1zIHRvIHRoaXMNCiBzZWN0aW9uLiBTZWUgZHJhZnQgcmV2IC0wOC48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlRoZSBzZWN0aW9uIGZp bmlzaGVzIHdpdGggdGhlIHN0YXRlbWVudCB0aGF0IHRoZSBzZWN1cml0eTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPnByb3BlcnRpZXMgb2YgdGhlIGJhc2Ugc3BlY2lmaWNhdGlv bnMsIExEUCwgTERQIElQdjYsIGV0Yy4sIGFsc28gYXBwbGllczwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPnRvIHRoaXMgZHJhZnQuJm5ic3A7Jm5ic3A7SSBhZ3JlZSB3aXRoIHRo ZSBhYm92ZSBhc3NlcnRpb25zLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij5HZW5lcmFsIGNvbW1lbnRzOjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuNXB0Ij5Ob25lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkVkaXRvcmlhbCBjb21tZW50czo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO2Jh Y2tncm91bmQ6eWVsbG93Ij5bc2tyYXphXTogRml4ZWQgYWxsIHRoZSBsaXN0ZWQuDQo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+cy9pbnRv IGZvbGxvd2luZy9pbnRvIHRoZSBmb2xsb3dpbmcvPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnMvbWVhbnMgYW5kIGJlIHJlYWQvc2hvdWxkIGJl IHJlYWQvPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPnMvZmFtaWx5JnF1b3Q7L2ZhbWlseSZxdW90Oy4vPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5zL1ZQTiBGb3J3YXJkaW5nIGFu ZCBSb3V0aW5nL1ZQTiBSb3V0aW5nIGFuZCBGb3J3YXJkaW5nLzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnMvcHJvdmlkZXMgYSBt ZWFuL3Byb3ZpZGVzIGEgbWVhbnMvPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPnMvPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6 YmxhY2siPk5laWJnYm9yL05laWdoYm9yLzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Y29sb3I6YmxhY2siPnMvPC9zcGFuPnBlcmVmZXJlbmNlL3ByZWZlcmVuY2UvPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnMvY3JlYXRhYmxl XC8gZGVsZXRhYmxlL2NyZWF0YWJsZVwvZGVsZXRhYmxlLzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UkVTVENPTkYgc2hvdWxkIGJlIGV4 cGFuZGVkIG9uIGZpcnN0IG9jdXJlbmNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2s7YmFja2dyb3VuZDp5ZWxs b3ciPltza3JhemFdOiBJIGNvdWxkIG5vdCBmaW5kIHRoZSBleHBhbnNpb24g4oCTIGV2ZW4gaW4g dGhlIFJFU1RDT05GIFJGQyA4MDQwIC4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TaGF3bi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_3791FB89740C44AAA7B28DF07155E19Cciscocom_-- From nobody Tue Mar 10 07:09:41 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408F73A1382 for ; Tue, 10 Mar 2020 07:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.232 X-Spam-Level: X-Spam-Status: No, score=-1.232 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mE1vweorQ7X for ; Tue, 10 Mar 2020 07:09:38 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C48693A137A for ; Tue, 10 Mar 2020 07:09:32 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id B80EF28B003D for ; Tue, 10 Mar 2020 10:09:31 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id A17401F8056; Tue, 10 Mar 2020 10:09:31 -0400 (EDT) From: Sandra Murphy Content-Type: multipart/alternative; boundary="Apple-Mail=_18A53095-ED99-4B60-A0D4-3E8C95B02746" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 10 Mar 2020 10:09:29 -0400 References: <43842926-38F3-4274-904B-AEBE8248E9A2@tislabs.com> To: secdir@ietf.org Message-Id: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [secdir] Fwd: [Ntp] comments on draft-ietf-ntp-using-nts-for-ntp-23 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 14:09:40 -0000 --Apple-Mail=_18A53095-ED99-4B60-A0D4-3E8C95B02746 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I reviewed draft-ietf-ntp-using-nts-for-ntp out of personal interest. Daniel Franke, the principal author, noted yesterday that no secdir = assignment had been made. He and Tero decided that my review should = stand as the secdir review. Here is my message to the ntp wg and the detailed comments. =E2=80=94Sandy > Begin forwarded message: >=20 > From: Sandra Murphy > Subject: Re: [Ntp] comments on draft-ietf-ntp-using-nts-for-ntp-23 > Date: March 5, 2020 at 9:57:10 AM EST > To: ntp@ietf.org > Cc: Sandra Murphy >=20 > I realize that I did not include one concern about the security = considerations. Section 9.7 NTS Stripping talks about the client being = deceived into reverting to plain NTP. There=E2=80=99s no discussion of = the server being deceived into responding with plain NTP. An adversary = who stripped the NTS extensions from the a NTP request would lead the = server to reply without the expected NTS extensions in the response. = What should/would the client do if it receives a non-NTS enhanced = response to a NTS enhanced request? >=20 > [Steve Bellovin would frequently suggest that there should be a way = for a recipient to know to expect security protections to prevent such = downgrade attacks. I don=E2=80=99t think there is a way in this case.] >=20 > =E2=80=94Sandy >=20 >> On Mar 4, 2020, at 7:06 PM, Sandra Murphy wrote: >>=20 >> I am not an NTP participant but curious about vulnerabilities of NTP = so I looked at NTS on last Fri, 28 Feb. >>=20 >> Unfortunately, that was the last day of the IETF last call, so I have = comments and they are arriving after the last call. >>=20 >> So give these comments the consideration they deserve - they come = late from someone who lacks context. >>=20 >> Detailed comments attached. Overall comments here: >>=20 >> Section 1 makes it clear that there is an intentional separation = between the NTS-KE server and the NTP server, although it is allowed = that both services could be resident on the same host. Figure 1 also = makes it appear that the NTS-KE server may be associated with a large = number of NTP servers, with unspecified means of communicating between = them. Reading through, I was struck by how much the NTS-KE server must = know about the NTP server - in Section 4.1.5 what algorithms it would = support, in Section 6 the keying material it would accept. I was = puzzled at how this could work in the post.ntp.org set of volunteer NTP = servers. Then in Section 6, I saw a reference to =E2=80=9Cload-balanced = cluster=E2=80=9D, which would easily account for the NTS-KE server=E2=80=99= s knowledge of the NTP servers=E2=80=99 configurations. More = explanations of the supportable (current and potential) architectures = would be very helpful. =20 >>=20 >> I believe it would be helpful for the implementers to have an = explicit list of what the NTS-KE server must know about the NTP servers = (address, algorithms supported, shared keys in use, cookie construction, = protocol IDs accepted, anything else?) and what the communication = between the NTS-KE server and the NTP server must provide (what Figure 1 = calls =E2=80=9CShared cookie encryption parameters=E2=80=9D). >>=20 >> Some of the text concerns the interactions with the NTS-KE server, = some concerns the interactions with the NTP server. The word = =E2=80=9Cserver=E2=80=9D is used throughout. There are cases where it = is not clear which type of server is meant from context. >>=20 >> I found several cases where I was not sure what the error conditions = should be handled, when requirements are not met, when an exchange = fails, when an error condition is received, etc. In some sections, the = receiver=E2=80=99s action upon receiving one message is explained but = for other messages is not. =20 >>=20 >> Normative language: There are places where the text says =E2=80=9Cshoul= d=E2=80=9D not =E2=80=9CSHOULD=E2=80=9D and it was not clear the RFC2119 = language was intended. In particular, Section 6 uses =E2=80=9Cshould=E2=80= =9D many times. Perhaps that was intentional since this section is not = normative. I=E2=80=99m not sure what should (sic) be the usage in that = case. =E2=80=9CIn general=E2=80=9D appears many times, which begs the = question of when it is or is not the case. On page 21, the text says = =E2=80=9CIn general, however, the server MUST=E2=80=9D. I=E2=80=99m not = sure what that means to an implementer. The following language talks = about exceptions, so perhaps the =E2=80=9CIn general=E2=80=9D means = =E2=80=9Cwhere there is no exception=E2=80=9D. >>=20 >> The document sets up an IANA registry for the Protocol ID. Is it = necessary to stipulate what a specification of a new Protocol ID must = include? Must it include a cookie format, for example? >>=20 >> On page 21, the caption for Figure 5 should be =E2=80=9CNTS-protected = NTP Time Synchronization Messages=E2=80=9D. It is an NTP exchange, not = an NTS exchange. >>=20 >> Section 9.4 page 36 - Is there a reference for =E2=80=9CNTP_PHASE_MAX?=E2= =80=9D A web search found only references to this draft and to a = =E2=80=9Ckernel constant=E2=80=9D in various *nx man pages. >>=20 >> In Section 6, the identifier =E2=80=9CI=E2=80=9D is used as a salt. = RFC5869 says the salt is random. Should the text about choosing the = =E2=80=9Cnon-secret, unique=E2=80=9D identifier mention random / = unpredictable as well? >>=20 >> =E2=80=94Sandy >> >>=20 >>=20 >> _______________________________________________ >> ntp mailing list >> ntp@ietf.org >> https://www.ietf.org/mailman/listinfo/ntp >=20 --Apple-Mail=_18A53095-ED99-4B60-A0D4-3E8C95B02746 Content-Type: multipart/mixed; boundary="Apple-Mail=_F7CE7F70-36A8-4742-9FB4-C1718ADDB2E6" --Apple-Mail=_F7CE7F70-36A8-4742-9FB4-C1718ADDB2E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = reviewed draft-ietf-ntp-using-nts-for-ntp out of personal interest.

Daniel Franke, the = principal author, noted yesterday that no secdir assignment had = been made.  He and Tero decided that my review should stand as the = secdir review.

Here is my message to the ntp wg and the detailed = comments.

=E2=80=94Sandy

= --Apple-Mail=_F7CE7F70-36A8-4742-9FB4-C1718ADDB2E6 Content-Disposition: attachment; filename=draft-ietf-ntp-using-nts-for-ntp.detailedcomments.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-ntp-using-nts-for-ntp.detailedcomments.txt" Content-Transfer-Encoding: quoted-printable Detailed comments on=20 draft-ietf-ntp-using-nts-for-ntp-22 Section 1.2, p 6 supply of cookies along with an IP address to the NTP server for ... Time synchronization proceeds with one of the indicated NTP servers The cookies are for one server, what are "the indicated NTP servers" (plural). Section 4, p 8 in the TLS-protected channel. Then, the server SHALL send a single response=20 and The client's request and the server's response but=20 Requests and non-error responses each SHALL include exactly one NTS Next Protocol Negotiation record. Is there a single request and single response, or plural requests and responses? If there are many, do they have to have the same Next Protocol? Section 4, page 9 unrecognized Record Type MUST ignore the record if the Critical Bit is 0 and MUST treat it as an error if the Critical Bit is 1. If it is an error, what then? The server can reply with an Error record type, if so, what would the code be? What would the client do? significant bit of the first octet. In C, given a network buffer There is a bit called "C" discussed on this page, took me aback a bit. Probably not a problem, but if there's an opportunity to say "In the C=20= language", maybe you should. Section 4.1.2 page 11 Protocol IDs listed in the server's response MUST comprise a subset of those listed in the request and denote those protocols which the server is willing and able to speak using the key material established through this NTS-KE session. It is clear that the server in "server's response" is the NTS-KE server, but I believe that the server in "server is willing and able to speak" = is the NTP server that the client will eventually contact. Right? The request MUST list at least one protocol, but the response MAY be empty. If the request is empty, what is the client to do? retry with a different set of protocols? Close the TLS channel? [There is text saying the the TLS session has minimal impact because only one request and one response are exchanged, but retries change that. And Section 4 intro page 8 says client SHALL send a single request as Application Data encapsulated in the TLS-protected channel. Then, the server SHALL send a single response followed by a TLS "Close notify" alert and then discard the channel state. which makes retries unlikely.] Protocol ID 0 is the only defined protocol now, but is it MTI for the server to support Protocol ID 0 always?=20 Section 4.1.3 page 11 Clients MUST NOT include Error records in their request. What if it does? Does the server drop, respond with an Error, send the TLS "Close notify" alert, what? If responding with Error, what code -=20 Bad Request or Internal Error? (I'm not sure format errors fit in the=20= Bad Request description, tho' they certainly fit the name.) If clients receive a server response which includes an Error record, they MUST discard any negotiated key material and MUST NOT proceed to the Next Protocol. Does "negotiated key material" mean the TLS negotiated material? Does the client retry with a new request? (next paragraph would seem to=20= indicate retries are possible with modification, Section 4 intro pg 8=20 makes retries sound impossible.) If the client is discarding the TLS negotiated materials, does the = client close the TLS channel and start over from the beginning? That = Section 4 intro page 8 makes it sound like the client will be forced start over. The following error codes are defined: In all these cases, what does the server do after it sends the Error code? Section 4.1.5, page 12 It is empty if the server supports none of the algorithms offered. If it is empty, what does the client do? retry with a new request? (yadayada about whether the Section 4 intro page 8 means that can't be) or declare failure and communicate with the NTP server without NTS = protections? should the server send the TLS "Close notify" alert after sending the empty algorithms list? Server implementations of NTS extension fields for NTPv4 (Section 5) MUST support AEAD_AES_SIV_CMAC_256 Does this apply to the client as well? If so, is it advisable for the client to always include that algorithm? Is it mandatory for the client to include that algorithm? Section 4.1.6 page 13 Clients MUST NOT send records of this type. What does the server do if the client does? Send an Error and if so with what code? Servers MUST send at least one record of this type What does the client do if the server does not? Send a new request? Section 4.1.7 page 13 Servers MUST NOT send more than one record of this type. What does the client do if the server does? Choose the first? Drop the response and retry the request? Close the TLS channel? Randomly pick one? When this record is sent by the client, it indicates that the client wishes to associate with the specified NTP server. What if the client wishes to associate with more than one NTP server? (that's recommended practice, so likely.) Does that mean multiple requests to the NTS-KE server under the same TLS channel? [Section 4 intro page 8 makes that sound impossible.] does it mean opening multiple TLS channels to the NTS-KE server? Section 4.2 page 14 Inputs to the exporter function are to be constructed in a manner specific to the negotiated Next Protocol. However, all protocols which utilize NTS-KE MUST conform to the following two rules: So must all protocols with utilize NTS-KE be time protocols? There are requirements here about what a Next Protocol must provide. The cookie construction is another. Should there be a statement about what a Next Protocol spec must include? Section 5.7 page 20 (nit) already sent, it SHOULD initiate a re-run the NTS-KE protocol. The "initiate a re-run of the NTS-KE protocol" or "SHOULD re-run the NTS-KE protocol" Section 5.7 page 21 Figure 5: NTS Time Synchronization Messages The caption should be "NTS-protected NTP Time Synchronization Messages". The exchange in the figure is of NTP messages, not NTS messages. In general, however, the server MUST discard any unauthenticated extension fields=20 I am not sure what "In general, ... the server MUST" could mean,=20 but given that later text says Servers MAY implement exceptions to this requirement for particular extension fields if their specification explicitly provides for such. I figure this means something like: The server MUST discard any unauthenticated extension fields, UNLESS an exception is implemented for specific extension fields whose specification explicitly provides for unauthenticated transmission. Maybe. Section 5.7 page 22 In general, however, the client MUST discard any unauthenticated extension fields and process the packet as though they were not present. Clients MAY implement exceptions to this requirement for particular extension fields if their specification explicitly provides for such. Same complaint as on page 21 about "In general, ... the client MUST discard..... and "MAY implement exceptions" Section 5.7 page 23 If the server is unable to validate the cookie or authenticate the request, it SHOULD respond with a Kiss-o'-Death (KoD) packet ... A client MAY automatically re-run the NTS-KE protocol upon forced disassociation from an NTP server. Is there a suggestion there that the server may force a disassociation from the NTP server after sending the NTS NAK? (I don't know what force that would be, NTP doesn't really have a session-connection- channel-state on the server side.) Section 6 page 24 This section uses "should" a lot, not SHOULD, in cases where it seems to be describing recommended optional behavior and sometimes when it is describing required behavior. =20 Perhaps that is because this is non-normative text, but distinguishing between the required behavior and optional behavior in this text is desirable, so I suggest deciding which uses of "should" are really RFC21119 requirements language and make it SHOULD, MUST, SHALL, etc. This section is non-normative. It gives a suggested way for servers to construct NTS cookies. =20 and manage the server (NTS-KE and NTP) keys Servers should select an AEAD algorithm which they will use to encrypt and authenticate cookies. NTS-KE encrypt cookies with this algorithm, NTP servers authenticate=20 cookies with this algorithm, so in this case "servers" means both of=20 them, right? And both must make the same choice, right? (And this is one of the places where it really sounds like you mean=20 MUST or SHALL.)=20 Servers should additionally choose a non-secret, unique value `I` as key-identifier for `K`. ... of this approach is to use HKDF [RFC5869] to derive new keys, using the key's predecessor as Input Keying Material and its key identifier as a salt. RFC5869 says the salt is random. Should the text about choosing the = =E2=80=9Cnon-secret, unique=E2=80=9D identifier mention random / = unpredictable as well? Servers should periodically (e.g., once daily) generate a new pair ... Immediately following each such key rotation, servers should securely erase any keys generated two or more rotation periods prior. Does this mean that a client's cookies to its chosen NTP server will no longer be usable after two daily rotations? (This presumes it does no polls in those two days, because any new response would provide a new cookie.) Must it go back to forming a TLS channel and an NTS-KE = exchange? If the NTS-KE server gives it a cookie for a different NTP=20 server, won't its time synchronization process revert to unsynchronized? Section 7.6 page 28 Applications for new entries SHALL specify the contents of the Description, Set Critical Bit, and Reference fields as well as which "Set Critical Bit" is not a field in the registry entries' field=20 descriptions above and not included in the table below. Section 9.2 In addition to dropping packets and attacks such as those described in Section 9.5, an on- path attacker can send spoofed kiss-o'-death replies, which are not authenticated, in response to NTP requests. This could result in significantly increased load on the NTS-KE server. Why? I presume this text means that the KoD is a NTS-NAK and client=20 who sees the NTS-NAK would restart the whole process with the=20 NTS-KE server. That is optional behavior in Section 5.7 page 23,=20 and then only "upon forced disassociation" from the server, which=20 the text does not require of the NTP server that sent an NTS-NAK. Section 9.4 page 36 error less than NTP_PHASE_MAX. In this case, the clock SHOULD be Is there a reference for the "NTP_PHASE_MAX"? It is not in RFC5905. A web search finds only hits in this draft and in various *nx man pages as being a "kernel constant" Section 9.4 page 37 take care not to cause an inadvertent denial-of-service attack on the NTS-KE server, for example by picking a random time in the week preceding certificate expiry to perform the new handshake. This order makes it sound like the example is about the attack, not the way to "take care not to cause". Appendix A (I wasn't going to note this nit, but since you have a list...) NTS NAK should be on this list. Actually, NTS NAK is not defined before it is used. In Section 5.7, = page 23 it says "NTS negative-acknowledgment (NAK)" but it does not say "NTS NAK". So a search for the acronym does not find its definition. --Apple-Mail=_F7CE7F70-36A8-4742-9FB4-C1718ADDB2E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


Begin forwarded message:

From: = Sandra Murphy <sandy@tislabs.com>
Subject: = Re: [Ntp] = comments on draft-ietf-ntp-using-nts-for-ntp-23
Date: = March 5, 2020 at 9:57:10 AM = EST
To: = ntp@ietf.org
Cc: Sandra Murphy <sandy@tislabs.com>

I = realize that I did not include one concern about the security = considerations.  Section 9.7 NTS Stripping talks about the client = being deceived into reverting to plain NTP.  There=E2=80=99s no = discussion of the server being deceived into responding with plain NTP. =  An adversary who stripped the NTS extensions from the a NTP = request would lead the server to reply without the expected NTS = extensions in the response.  What should/would the client do if it = receives a non-NTS enhanced response to a NTS enhanced request?

[Steve Bellovin would frequently suggest that = there should be a way for a recipient to know to expect security = protections to prevent such downgrade attacks.  I don=E2=80=99t = think there is a way in this case.]

=E2=80=94Sandy

On Mar 4, 2020, at 7:06 PM, Sandra Murphy = <sandy@tislabs.com> wrote:

I= am not an NTP participant but curious about vulnerabilities of NTP so I = looked at NTS on last Fri, 28 Feb.

Unfortunately, that was the last day of the IETF last call, = so I have comments and they are arriving after the last call.

So give these comments the consideration they = deserve - they come late from someone who lacks context.
Detailed comments attached.  Overall comments here:

Section 1 makes it clear that there is an = intentional separation between the NTS-KE server and the NTP server, = although it is allowed that both services could be resident on the same = host.  Figure 1 also makes it appear that the NTS-KE server may be = associated with a large number of NTP servers, with unspecified means of = communicating between them.  Reading through, I was struck by how = much the NTS-KE server must know about the NTP server - in Section 4.1.5 = what algorithms it would support, in Section 6 the keying material it = would accept.  I was puzzled at how this could work in the post.ntp.org set of = volunteer NTP servers.  Then in Section 6, I saw a reference to = =E2=80=9Cload-balanced cluster=E2=80=9D, which would easily account for = the NTS-KE server=E2=80=99s knowledge of the NTP servers=E2=80=99 = configurations.  More explanations of the supportable (current and = potential) architectures would be very helpful.  

I believe it would be helpful for the implementers to have an = explicit list of what the NTS-KE server must know about the NTP servers = (address, algorithms supported, shared keys in use, cookie construction, = protocol IDs accepted, anything else?) and what the communication = between the NTS-KE server and the NTP server must provide (what Figure 1 = calls =E2=80=9CShared cookie encryption parameters=E2=80=9D).

Some of the text concerns the interactions = with the NTS-KE server, some concerns the interactions with the NTP = server.  The word =E2=80=9Cserver=E2=80=9D is used throughout. =  There are cases where it is not clear which type of server is = meant from context.

I found several cases = where I was not sure what the error conditions should be handled, when = requirements are not met, when an exchange fails, when an error = condition is received, etc.  In some sections, the receiver=E2=80=99s= action upon receiving one message is explained but for other messages = is not.  

Normative language: There = are places where the text says =E2=80=9Cshould=E2=80=9D not =E2=80=9CSHOUL= D=E2=80=9D and it was not clear the RFC2119 language was intended. =  In particular, Section 6 uses =E2=80=9Cshould=E2=80=9D many times. =  Perhaps that was intentional since this section is not normative. =  I=E2=80=99m not sure what should (sic) be the usage in that case. =  =E2=80=9CIn general=E2=80=9D appears many times, which begs the = question of when it is or is not the case.  On page 21, the text = says =E2=80=9CIn general, however, the server MUST=E2=80=9D.  I=E2=80= =99m not sure what that means to an implementer.  The following = language talks about exceptions, so perhaps the =E2=80=9CIn general=E2=80=9D= means =E2=80=9Cwhere there is no exception=E2=80=9D.

The document sets up an IANA registry for the Protocol ID. =  Is it necessary to stipulate what a specification of a new = Protocol ID must include?  Must it include a cookie format, for = example?

On page 21, the caption for Figure = 5 should be =E2=80=9CNTS-protected NTP Time Synchronization Messages=E2=80= =9D.  It is an NTP exchange, not an NTS exchange.

Section 9.4 page 36 - Is there a reference for = =E2=80=9CNTP_PHASE_MAX?=E2=80=9D  A web search found only = references to this draft and to a =E2=80=9Ckernel constant=E2=80=9D in = various *nx man pages.

In Section 6, the = identifier =E2=80=9CI=E2=80=9D is used as a salt.  RFC5869 says the = salt is random.  Should the text about choosing the =E2=80=9Cnon-secr= et, unique=E2=80=9D identifier mention random / unpredictable as = well?

=E2=80=94Sandy
<draft-ietf-ntp-using-nts-for-ntp.detailedcomments.txt>

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


= --Apple-Mail=_F7CE7F70-36A8-4742-9FB4-C1718ADDB2E6-- --Apple-Mail=_18A53095-ED99-4B60-A0D4-3E8C95B02746-- From nobody Tue Mar 10 07:28:54 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43D7F3A13D3; Tue, 10 Mar 2020 07:28:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Phillip Hallam-Baker via Datatracker To: Cc: last-call@ietf.org, calsify@ietf.org, draft-ietf-calext-jscalendar.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.120.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158385051998.15836.4770030164750320016@ietfa.amsl.com> Reply-To: Phillip Hallam-Baker Date: Tue, 10 Mar 2020 07:28:40 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-calext-jscalendar-26 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 14:28:41 -0000 Reviewer: Phillip Hallam-Baker Review result: Has Issues The Security Considerations need to be substantially expanded to address: 1) Spam 2) Duplication 3) Time Zones 4) Authentication The first issue is a major problem with ical attachments, applications assume that these are authentic and create entries. It is stupid but it is ubiquitous. There should be note of this as it is a very common channel exploited by spamers. Duplication is a related problem. Calendar entries should have a unique persistent ID and clients should check these so that updates on multiple devices don't end up resulting in a dozen calendar entries which happens to me repeatedly. Time Zones are a related problem it is important to make sure that the time zone of recurring entries is correctly set. Why is this a security issue? Because I have been in a situation where a meeting secretary deliberately sent out a maliciously crafted meeting announcement to make sure the 'wrong people' didn't attend. Authentication is my main concern though as my entire home automation system runs off a a task database that is based on a JSON calendar format which is not this format _yet_. My plan being to let you folk do the work and then wrap authentication round it. So when I am done, the calendar will drive the selection of what happens in the house. The school calendars will be loaded and these will cause the alarms for myself and the kids to come on when it is a school day and not otherwise. Same for heating etc. If one of us is traveling, there will be adjustments etc. This is obviously a stretch goal but it is clearly something that will be commonplace at some point. Calendaring systems are going to be about more than just work appointments. And that means we need authentication. The draft does not need to say HOW this is done but it does need to say you need to do it. A related concern is that many companies set up accounts for each meeting room and you reserve the room for your meeting by 'inviting' it to the meeting. Now consider doing the same in a serviced office scenario, you want the convenience but there is also going to be a payments interface because you pay for the meeting room by the hour. In the general body of the text, the treatment of recurring events MUST address time zones and daylight savings. This is the stuff iCal didn't get right at first and that lead to pain. From nobody Tue Mar 10 08:19:42 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B3E3A10E8; Tue, 10 Mar 2020 08:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 yalFTD10zq4V; Tue, 10 Mar 2020 08:19:37 -0700 (PDT) Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (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 CA4CE3A1256; Tue, 10 Mar 2020 08:19:33 -0700 (PDT) Received: by mail-qv1-xf30.google.com with SMTP id ca9so3136990qvb.9; Tue, 10 Mar 2020 08:19:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=eNKBxZFJfvs6V/mCK17fmkZ/XgO1fFYYbFQWGk7rngI=; b=qufVNV9BsO+Fh5kaSdZDWFwCz/5efsQVHne5vcyKC/ZD38uQVsJ14b2jb1yvSUoMGw fd9O63MmDpOWjVqQBd8TWx3Yc8kPdQ3oQ124sI/4LQJv4q4j4coRVLXsQfNM0h7/xj2j H0OJD1hk56NFWnOuE55YiepIZ+cOz3U9k0jISNqeAgDLB2hgeObYw0ur9zuppLyJQhKa FmDZH9vIik3Ajv4LqnO+rps+x+jF6w0YkOQysthBzEPCR8GCCn//8pbKtyius85PJX8E Eirzlo/7x+xqnD2YEmsdu2jW//x3sg1mbcT6I8CYzwgyzQs/q6qHTT6m0HFZ0eDR/Jaz J3xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=eNKBxZFJfvs6V/mCK17fmkZ/XgO1fFYYbFQWGk7rngI=; b=ORF+TprxT40To7S85+3K9beDOdjGd5a86Gygr1e3qsBBZnC9w5ZKz6phJxyA3GYqaz hhmoiqGo4qiFJ3zLgRhbdNHEtvvh9KQWu7mUTbCAkcqzAFqV7WLTR/FB/f5cavzTba/R imQUsB9lulc22BdYml2Kxza0IWreRNCPMzi0CvYJOtTgcIDQ4CdqepW92tcY+87j3g67 DIMW6X/FcNSsWCKyBLVLI/xFGHN/k5xAEJ0Ec9i58qaBwN0/GXiuVYIWqpu6YIZoH605 oYxzTBECrXEX4B+JFPcDV1B0P8BGAtoBwQUrC88IJVUPdHys+IEQpyLBW99ws2d4ocdG pMeA== X-Gm-Message-State: ANhLgQ3gcyAsYuygBlMGFQRTFj7Nzxt6ncOxw4PXOAJzZyFqctEeQgHo 9bhnXFWZXnFDk8UPTKLZ/xFGacTP X-Google-Smtp-Source: ADFU+vttQaSQvemyYnds5sbFjSOZx6UAmqb8oHQq8CBVws4CiawlkrdCoQDlxkJQzJr0IZSwMRvqUw== X-Received: by 2002:a0c:f892:: with SMTP id u18mr19715400qvn.159.1583853572396; Tue, 10 Mar 2020 08:19:32 -0700 (PDT) Received: from ?IPv6:2607:fea8:6a0:1a5a:51ec:9c3f:c37:3026? ([2607:fea8:6a0:1a5a:51ec:9c3f:c37:3026]) by smtp.gmail.com with ESMTPSA id o57sm4427150qtf.42.2020.03.10.08.19.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Mar 2020 08:19:31 -0700 (PDT) From: Rene Struik To: Russ Housley Cc: IETF SecDir , lwip@ietf.org, draft-ietf-lwig-curve-representations.all@ietf.org References: <157479110201.13605.6894641490219218764@ietfa.amsl.com> Message-ID: Date: Tue, 10 Mar 2020 11:19:29 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [secdir] Secdir early review of draft-ietf-lwig-curve-representations-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 15:19:39 -0000 Hi Russ: I tried to take into account your comments with draft-ietf-lwig-curve-representations-09. I will send out a separate email to the list highlighting main changes. Below, I will explain how I tried and accommodate your previous comments on the 08-draft, now that the new draft is out. Important note: As you know from offline communications, I did include Curve448-related material with the 09 version. I tried to do this in a way that would create the least editorial upheaval and would not take away from the main objectives of the document: to this end, I only introduced Curve448-related material in Section 4.4 [thereby avoiding having to sprinkle in curve448-related language in each section and blurring the message of the document]. The only other sections where Curve448 plays a role is IANA Section 10 and the appendices that give the parameters and test vectors for the Curve448 family members. {Note: I probably should have added a note on ECDSA448 in the security consideration section, though (I made a note on this and will fix).} Best regards, Rene On 11/26/2019 5:21 PM, Rene Struik wrote: > Hi Russ: > > Thanks. > > On 11/26/2019 4:10 PM, Russ Housley wrote: >> >>> On Nov 26, 2019, at 2:54 PM, Rene Struik wrote: >>> >>> Dear Russ: >>> >>> Thanks for your review (and speedy turn-around). >>> >>> Please find below feedback on how I intend to address all but your >>> last remarks (I will reflect on your suggestion as to introductory >>> text with the appendices when looking over Daniel Migault's earlier >>> "guidance of the reader" remarks). >>> >>> Best regards, Rene >>> >>> On 11/26/2019 12:58 PM, Russ Housley via Datatracker wrote: >>>> Reviewer: Russ Housley >>>> Review result: Has Issues >>>> >>>> I reviewed this document as part of the Security Directorate's ongoing >>>> effort to review all IETF documents being processed by the IESG.  >>>> These >>>> comments were written primarily for the benefit of the Security Area >>>> Directors.  Document authors, document editors, and WG chairs should >>>> treat these comments just like any other IETF Last Call comments. >>>> >>>> Document: draft-ietf-lwig-curve-representations-08 >>>> Reviewer: Russ Housley >>>> Review Date: 2019-11-26 >>>> IETF LC End Date: unknown >>>> IESG Telechat date: unknown >>>> >>>> Summary: Has Issues >>>> >>>> >>>> Major Concerns: >>>> >>>> I am confused by the first paragraph in Section 10.  It says that "An >>>> object identifier is requested ...", but then code points for COSE >>>> and JOSE (not object identifiers) are requested in the subsection. >>>> >>>> I am confused by the second paragraph in Section 10.  It says that >>>> "There is *currently* no further IANA action required ...". Please >>>> delete this paragraph. >>> RS>> If I remember this correctly, I borrowed this from another >>> draft (but perhaps was somewhat ignorant here about proper >>> formulation). I intend to change the first para to "code points are >>> requested for ....". As to the second para, I believe it has some >>> merit to keep this in, in slightly altered form, e.g.,  as "New >>> object identifiers would be required in case one wishes to specify >>> one or more of the "offspring" protocols exemplified in Section 4.4. >>> Specification hereof is, however, outside scope of the current >>> document." >>> >>> <> I do not see how the second paragraph gives any direction regarding >> the IANA registries. > > RS>>  The requested algorithm registrations are for co-factor ECDH > (Example 4.1) and ECDSA (Example 4.3), where the second para is more a > reminder that one would need more registrations if one would like > other spin-offs (so it was more to keep parallelism with Example 4.4). > As example, one could instantiate e.g., Wei25519 plus, say, MQV (which > NIST SP 800-56a + new curve W25519 in draft SP 186 would enable) and, > e.g., Wei25519+MQV, Wei25519 + impl cert (for V2V; see IACR 2019-157), > etc., but I did not wish to go over the top and that could be to be > defined elsewhere. From a Spartan writing perspective, it could indeed > be argued that one could guess this oneself. <> Since I added Curve448-related material, I divided the IANA section into two subsections, where the first one requests for code points for Wei25519 and the second one requests for code points for Wei448. The reason for this organization is that it shows clearly the edits w.r.t. the 08 version. Due to the additional request for code points for Wei448, I changed the language in the preamble of the IANA section as follows: Code points are requested for curve Wei25519 and Wei448 and its use with ECDSA and co-factor ECDH, using the representation conventions of this document. New code points would be required in case one wishes to specify one or more other "offspring" protocols beyond those exemplified in Section 4.4. Specification hereof is, however, outside scope of the current document. < >> >>>> Minor Concerns: >>>> >>>> Requirements Language section is out of date.  It should reference >>>> RFC 8174 in addition to RFC 2119, as follows: >>>> >>>>     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL >>>> NOT", >>>>     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", >>>> "MAY", and >>>>     "OPTIONAL" in this document are to be interpreted as described in >>>>     BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all >>>>     capitals, as shown here. >>> RS>> will do. As minor point (from a non-native speaker's >>> perspective): shouldn't the last part of the above sentence read >>> "if, and only if, these appear...."? <> RFC 8174 calls for this exact text. > RS>> My remark above was more a "Strunk and White" remark. <> Changed, as requested. <> >>>> Section 2 says: "... reuse of existing generic code ...";  I do not >>>> know >>>> what is meant by "generic".  It either needs to be defined, >>>> reworded, or >>>> dropped.  I note that elsewhere in the document "existing code" is >>>> used. >>> RS>> I will add a sentence to that effect, e.g., "(Here, generic >>> code refers to an implementation that does not depend on hardcoded >>> domain parameters (see also Section 6).)" <> Thanks. >> >>>> I expected Section 9 to say something about public keys being unique >>>> identifiers of the private key holder. >>> RS>> I will add an extra paragraph to this effect, e.g., "Use of a >>> public key in any protocol for which successful execution evidences >>> knowledge of the corresponding private key implicitly indicates the >>> entity holding this private key. Reuse of this public key with more >>> than one protocol or more than one protocol instantiation may, >>> therefore, allow traceability of this entity." <> Also, using the same public key with different addresses allows an >> observer to correlate them. > RS>> Indeed, one can correlate more stuff from meta-info that includes > the public key as a common data element (even if the observer would > not be able to check whether those are technically bound to this, this > would often work in practice). <>The added text now reads as follows: Use of a public key in any protocol for which successful execution evidences knowledge of the corresponding private key implicitly indicates the entity holding this private key. Reuse of this public key with more than one protocol or more than one protocol instantiation may, therefore, allow traceability of this entity. It may also allow correlation of meta-data communicated with this common data element (e.g., different addressing information), even if an observer cannot technically verify the binding of this meta-data. <> >>>> Some introduction text at the beginning of each Appendix would be very >>>> helpful.  Please tell the reader what they will learn by delving into >>>> the subsections of the appendix. >>> RS>> I will reflect on this somewhat more (while also considering >>> "guidance to the reader" remarks in Daniel Migault's Early IoTDir >>> review).  Broadly speaking, though, inclusion of all these >>> appendices makes the entire docment self-contained, including >>> arithmetic, representations, how-to-convert details, etc. <> Yes, I understand that.  Some of the appendicies have introductory >> text, but other do not.  I think they all should have introductory text. RS1>> I added some introductory text to each appendix. <> >>>> Nits: >>>> >>>> Section 4.2 says: "... at the end of hereof ...".  This does not tell >>>> me anything useful.  I suggest deleting this phrase. >>> RS>> I will change this to "at the end hereof" (i.e., will remove >>> "of" - a glitch). Here, one can only recover the y-coordinate at the >>> end of the Montgomery ladder, since one needs the x-coordinates of >>> k*G and (k+1)*G to make this work. <> I think it would be better to say: ... at the end of the Montgomery >> ladder ..." RS1>> Changed as suggested. <> >> Russ >> > -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 287-3867 From nobody Tue Mar 10 08:41:22 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A2C3A14BD for ; Tue, 10 Mar 2020 08:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pU4sThYjPunX for ; Tue, 10 Mar 2020 08:41:18 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50C273A11BD for ; Tue, 10 Mar 2020 08:41:18 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 3587B28B003D for ; Tue, 10 Mar 2020 11:41:17 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 1B7241F804E; Tue, 10 Mar 2020 11:41:17 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sandra Murphy In-Reply-To: Date: Tue, 10 Mar 2020 11:41:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <16ACFBEF-C6E8-4E74-AA79-BED7553B07B7@tislabs.com> References: <43842926-38F3-4274-904B-AEBE8248E9A2@tislabs.com> To: secdir@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [secdir] [Ntp] comments on draft-ietf-ntp-using-nts-for-ntp-23 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 15:41:20 -0000 One more thing. Steve Kent noted in his secdir review yesterday that = there are more modern algorithms than those chosen in the draft he = reviewed. draft-ietf-ntp-using-nts-for-ntp has chosen AEAD_AES_SIV_CMAC_256. = That=E2=80=99s from 2008. Someone here is probably better qualified = than I to say whether there is a better AEAD-type choice. (The fact = that this algorithm is a downward ref is already noted.) =E2=80=94Sandy > On Mar 10, 2020, at 10:09 AM, Sandra Murphy wrote: >=20 > I reviewed draft-ietf-ntp-using-nts-for-ntp out of personal interest. >=20 > Daniel Franke, the principal author, noted yesterday that no secdir = assignment had been made. He and Tero decided that my review should = stand as the secdir review. >=20 > Here is my message to the ntp wg and the detailed comments. >=20 > =E2=80=94Sandy >=20 > >=20 >=20 >> Begin forwarded message: >>=20 >> From: Sandra Murphy >> Subject: Re: [Ntp] comments on draft-ietf-ntp-using-nts-for-ntp-23 >> Date: March 5, 2020 at 9:57:10 AM EST >> To: ntp@ietf.org >> Cc: Sandra Murphy >>=20 >> I realize that I did not include one concern about the security = considerations. Section 9.7 NTS Stripping talks about the client being = deceived into reverting to plain NTP. There=E2=80=99s no discussion of = the server being deceived into responding with plain NTP. An adversary = who stripped the NTS extensions from the a NTP request would lead the = server to reply without the expected NTS extensions in the response. = What should/would the client do if it receives a non-NTS enhanced = response to a NTS enhanced request? >>=20 >> [Steve Bellovin would frequently suggest that there should be a way = for a recipient to know to expect security protections to prevent such = downgrade attacks. I don=E2=80=99t think there is a way in this case.] >>=20 >> =E2=80=94Sandy >>=20 >>> On Mar 4, 2020, at 7:06 PM, Sandra Murphy wrote: >>>=20 >>> I am not an NTP participant but curious about vulnerabilities of NTP = so I looked at NTS on last Fri, 28 Feb. >>>=20 >>> Unfortunately, that was the last day of the IETF last call, so I = have comments and they are arriving after the last call. >>>=20 >>> So give these comments the consideration they deserve - they come = late from someone who lacks context. >>>=20 >>> Detailed comments attached. Overall comments here: >>>=20 >>> Section 1 makes it clear that there is an intentional separation = between the NTS-KE server and the NTP server, although it is allowed = that both services could be resident on the same host. Figure 1 also = makes it appear that the NTS-KE server may be associated with a large = number of NTP servers, with unspecified means of communicating between = them. Reading through, I was struck by how much the NTS-KE server must = know about the NTP server - in Section 4.1.5 what algorithms it would = support, in Section 6 the keying material it would accept. I was = puzzled at how this could work in the post.ntp.org set of volunteer NTP = servers. Then in Section 6, I saw a reference to =E2=80=9Cload-balanced = cluster=E2=80=9D, which would easily account for the NTS-KE server=E2=80=99= s knowledge of the NTP servers=E2=80=99 configurations. More = explanations of the supportable (current and potential) architectures = would be very helpful. =20 >>>=20 >>> I believe it would be helpful for the implementers to have an = explicit list of what the NTS-KE server must know about the NTP servers = (address, algorithms supported, shared keys in use, cookie construction, = protocol IDs accepted, anything else?) and what the communication = between the NTS-KE server and the NTP server must provide (what Figure 1 = calls =E2=80=9CShared cookie encryption parameters=E2=80=9D). >>>=20 >>> Some of the text concerns the interactions with the NTS-KE server, = some concerns the interactions with the NTP server. The word = =E2=80=9Cserver=E2=80=9D is used throughout. There are cases where it = is not clear which type of server is meant from context. >>>=20 >>> I found several cases where I was not sure what the error conditions = should be handled, when requirements are not met, when an exchange = fails, when an error condition is received, etc. In some sections, the = receiver=E2=80=99s action upon receiving one message is explained but = for other messages is not. =20 >>>=20 >>> Normative language: There are places where the text says = =E2=80=9Cshould=E2=80=9D not =E2=80=9CSHOULD=E2=80=9D and it was not = clear the RFC2119 language was intended. In particular, Section 6 uses = =E2=80=9Cshould=E2=80=9D many times. Perhaps that was intentional since = this section is not normative. I=E2=80=99m not sure what should (sic) = be the usage in that case. =E2=80=9CIn general=E2=80=9D appears many = times, which begs the question of when it is or is not the case. On = page 21, the text says =E2=80=9CIn general, however, the server MUST=E2=80= =9D. I=E2=80=99m not sure what that means to an implementer. The = following language talks about exceptions, so perhaps the =E2=80=9CIn = general=E2=80=9D means =E2=80=9Cwhere there is no exception=E2=80=9D. >>>=20 >>> The document sets up an IANA registry for the Protocol ID. Is it = necessary to stipulate what a specification of a new Protocol ID must = include? Must it include a cookie format, for example? >>>=20 >>> On page 21, the caption for Figure 5 should be =E2=80=9CNTS-protected = NTP Time Synchronization Messages=E2=80=9D. It is an NTP exchange, not = an NTS exchange. >>>=20 >>> Section 9.4 page 36 - Is there a reference for =E2=80=9CNTP_PHASE_MAX?= =E2=80=9D A web search found only references to this draft and to a = =E2=80=9Ckernel constant=E2=80=9D in various *nx man pages. >>>=20 >>> In Section 6, the identifier =E2=80=9CI=E2=80=9D is used as a salt. = RFC5869 says the salt is random. Should the text about choosing the = =E2=80=9Cnon-secret, unique=E2=80=9D identifier mention random / = unpredictable as well? >>>=20 >>> =E2=80=94Sandy >>> >>>=20 >>>=20 >>> _______________________________________________ >>> ntp mailing list >>> ntp@ietf.org >>> https://www.ietf.org/mailman/listinfo/ntp >>=20 >=20 From nobody Tue Mar 10 12:09:54 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F03A3A08BA; Tue, 10 Mar 2020 12:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4TsMut986AZ; Tue, 10 Mar 2020 12:09:48 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 B93A23A08B9; Tue, 10 Mar 2020 12:09:47 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 02AJ9cX4009510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Mar 2020 15:09:43 -0400 Date: Tue, 10 Mar 2020 12:09:38 -0700 From: Benjamin Kaduk To: Tero Kivinen Cc: "Franke, Daniel" , "ntp@ietf.org" , "secdir@ietf.org" Message-ID: <20200310190938.GH98042@kduck.mit.edu> References: <1583773461963.52013@akamai.com> <24166.48512.923994.774704@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24166.48512.923994.774704@fireball.acr.fi> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [secdir] Missing secdir assignment for draft-ietf-ntp-using-nts-for-ntp? X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 19:09:49 -0000 On Tue, Mar 10, 2020 at 12:04:48AM +0200, Tero Kivinen wrote: > Franke, Daniel writes: > > Did draft-ietf-ntp-using-nts-for-ntp somehow get overlooked for > > SECDIR review? I see no review in the datatracker and nobody > > assigned to do one. > > Seems to be so. I have no idea why the datatracker has not picked that > one up. It seems to have entered to last call state 2020-02-14, and I > did do assignments 2020-02-20, but for some reason that draft was not > automatically picked up by the datatracker. I have no idea why the > datatracker is not picking that document up. Whatever bug happened seems likely to have affected other directorates as well, since this doc only got a genart review and an opsdir review request, but no secdir or other directorate review requests, and I would have expected a couple more reviews to be requested (e.g., intdir). Though I don't think anyone other than secdir and genart actively tries to review *all* drafts, so it's possible we were the only ones affected. -Ben From nobody Tue Mar 10 20:22:21 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D033A103E; Tue, 10 Mar 2020 20:22:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Watson Ladd via Datatracker To: Cc: detnet@ietf.org, draft-ietf-detnet-mpls.all@ietf.org, last-call@ietf.org, watsonbladd@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.120.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158389693039.16158.6977515080330200081@ietfa.amsl.com> Reply-To: Watson Ladd Date: Tue, 10 Mar 2020 20:22:10 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-detnet-mpls-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2020 03:22:11 -0000 Reviewer: Watson Ladd Review result: Not Ready This is the secdir review of draft-ietf-detnet-mpls-05. Authors should treat these as any other Last Call comments. Apologies for the delays in completing this review. I am concerned that this document (and the related work) introduces some substantial differences from existing Internet architecture, and that inadequate attention is paid to the consequent security implications. Pointing to a separate, in progress draft I don't think is an adequate security consideration section. That's particularly true when we're discussing the network providing functions like duplicate packet dropping that are potentially quite expensive and which attackers may exploit to consume large amounts of resources. Saying that one can mitigate DoS on the edge of a DetNet domain isn't enough: how do you mitigate the DoS, or detect it? What if the edge is the problem? Are there resources that can be consumed in the center the edge doesn't know about? With confidentiality this draft mentions the possibility of link to link protection, ignoring the possibility of malicious nodes, and doesn't describe the way one actually uses that integration. It's not clear to me what the security goals are, and saying a mechanism may be used, without indicating how doesn't make it remediation for a security problem. I can think of a few ways to abuse the one-packet only service to rewrite flows with great ease. The Internet is composed of smart nodes at the edge and dumb forwarders in the middle. DetNet is a very different design, with significant complexity and state in the network, and guarantees not maintained by end nodes. This means that a lot that has been learned about Internet security doesn't apply, which raises a whole host of questions: what threat model is applied? Is it realistic? Are the properties such as bounded latency and low jitter maintained even in the face of adversarial behavior? While this may be appropriately handled at greater length in a separated draft, a tighter link to the mechanisms defined in this draft would be useful. It's very likely these have been discussed in the detnet wg at length as evidenced by the security considerations, but I'd like to see the MPLS draft reflect some of that conversation more directly. From nobody Wed Mar 11 08:30:07 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233453A0942; Wed, 11 Mar 2020 08:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 9-UXaBFWW-EK; Wed, 11 Mar 2020 08:30:03 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 027303A09B2; Wed, 11 Mar 2020 08:29:59 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id p2so3189584wrw.7; Wed, 11 Mar 2020 08:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iOj0onZgPXZm47Uu9KnHAkgVUvpE1kEM/6HFzh6/XRQ=; b=NnKv0g2frFKoFanc7PhVBkyr2XSaE5WPoxsHBwdssmqaJlhRkfa5dudkc8YCDrdJEG xoNDbexkTltj6BM9NsX1JJkz6k/disF03sWPp4UqRW4qNuLwDMbWfHj/mI4Zc2vp2wSg cTGfUPL7mHKYyuYwi84I29PQGlPYgRh0yzQi3Bai/VTyyM/umrMUBffpZLdPbFWtlxI6 hKmsG3+kQ4u2AlBolRU6SLwCM5opiCasde8bp6fFA4m6YpGXGX/HOpHm3bjxn/QkotFH XOzvDc4qNwAf9Ac5ifQ8Bp+iXhdZnCtH8Vb9lQZ3U2Qm8BOBMqNsCccZhDOnYzsSiKv9 9Gxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iOj0onZgPXZm47Uu9KnHAkgVUvpE1kEM/6HFzh6/XRQ=; b=kvTh++FTQqUl3KX2BF1H06315U+gEkpliL+iHlkVNb8xINZR+EpufGrLs6L2RfgonI T5ol1GK7Py1SlaAOxsrbHAEmyfsdPMzRq47ndrJxCeJvudz4BDjC4uBw/YGSFxiVRxaI ajWUSD7TiK83/4JLX/9OJ7jpaMEBL0Sm1o7quFk/wd0LNzrf+R5zj4gO/JTV6gpEbs8m rc41gca/7cb4N7NR9MbIugYbcufe6Lt+TXGMFVazLHVNo5noASOZ7KQuCajc5tfS1RST oqrN41NZnMoS3Vrk9Ou5XpSzwuXGXdzi3B2/egxY8cMLaB/DLwQkUVXJhjMKYcu7NoTV UO6A== X-Gm-Message-State: ANhLgQ3KkHDpDo6kWIIZSZy/sGW+xwG0VuQl22TJJ1r81/5ZPAZmdS9x MYmDRkUrKtRs8SGpOYkr7GI= X-Google-Smtp-Source: ADFU+vub8pZtZMD7SrBfSh5NSXYrWpbpyp/RfUZ2hzcHnKjCaYfqHBi+9KILMaIpTL2I1wgZUiZQLQ== X-Received: by 2002:adf:e911:: with SMTP id f17mr4824324wrm.87.1583940598246; Wed, 11 Mar 2020 08:29:58 -0700 (PDT) Received: from broadband.bt.com ([2a00:23a8:4140:0:58e6:6b0b:ad19:fc8b]) by smtp.gmail.com with ESMTPSA id e26sm7034021wmk.9.2020.03.11.08.29.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Mar 2020 08:29:57 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Stewart Bryant In-Reply-To: <158389693039.16158.6977515080330200081@ietfa.amsl.com> Date: Wed, 11 Mar 2020 15:29:55 +0000 Cc: Stewart Bryant , secdir@ietf.org, DetNet WG , draft-ietf-detnet-mpls.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <158389693039.16158.6977515080330200081@ietfa.amsl.com> To: Watson Ladd X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-detnet-mpls-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2020 15:30:05 -0000 > On 11 Mar 2020, at 03:22, Watson Ladd via Datatracker = wrote: >=20 > Reviewer: Watson Ladd > Review result: Not Ready >=20 > This is the secdir review of draft-ietf-detnet-mpls-05. Authors should = treat > these as any other Last Call comments. >=20 > Apologies for the delays in completing this review. >=20 > I am concerned that this document (and the related work) introduces = some > substantial differences from existing Internet architecture, and that > inadequate attention is paid to the consequent security implications. I disagree with the proposition that this is a substantial change to the = existing Internet architecture. This MPLS DetNet design is, if anything, a development of pseudowires, a = widely deployed technology that for many years was the standard method = of carrying IP from the customer premise to the ISP. It is a close = cousin to MPLS VPN which has been a stable of provider network = deployments. MPLS is designed to be run in a tightly controlled environment. This is = something that all competent MPLS operators do as a matter of course, = and I do not see this being much of an additional issue. The special = problem here is the need to police ingress traffic for dynamic issues. = That is quite a significant body of work, and is being tackled in a = separate document. We can add a reference to general MPLS security, and to the security of = pseudowires running over MPLS, but these are well known by anyone = operating an MPLS network, and the clutter will distract the reader from = the unique issues that apply to this design. > Pointing > to a separate, in progress draft I don't think is an adequate security > consideration section. Adding all the text from that draft would imbalance this draft, and = referring to it is normally a better idea, particularly as the same text = applies to a number of the DetNet drafts. > That's particularly true when we're discussing the > network providing functions like duplicate packet dropping that are = potentially > quite expensive and which attackers may exploit to consume large = amounts of > resources. The expensive process of duplicate dropping is a cost of that aspect of = the service. Obviously if your forwarder is incapable of offering that = service you would not offer the service. Now we know that a lot of = forwarder designs cannot do this, and to do so would require a rebalance = of processing between the ingress and the egress interface, but that = should not stop us designing such a system. It is simply a mark of = progress that we upgrade the forwarding system to add new features. Now if you are worried about an attacker injecting such packets, I would = ask you to remember that no competent MPLS operator will allow any MPLS = packets in their network that they have not put there themselves, or = have accepted from a highly trusted peer. There is over 20 years of = experience in securing MPLS networks. As far as I am aware there has = never been an MPLS injection attack brought to the attention of the MPLS = WG or the PALS (ne PWE3) WGs. I am not loosing any sleep over this type = of attack. If the attack was a likely prospect we would be seeing it as = an issue with VPNs and PWs and we see no such issue. > Saying that one can mitigate DoS on the edge of a DetNet domain > isn't enough: how do you mitigate the DoS, or detect it? Again this is standard MPLS. Remember nothing gets into the network = other than through a PE, and it is common for a PE to do rate detection = and ensure that the attached external device does not exceed the agreed = rate. =20 > What if the edge is > the problem? Are there resources that can be consumed in the center = the edge > doesn't know about? This is no different from the MPLS traffic engineered network case with = reserved bandwidth. This is widely understood in MPLS network designs. = If you are concerned about faulty equipment, there are many worse things = that could happen. >=20 > With confidentiality this draft mentions the possibility of link to = link > protection, ignoring the possibility of malicious nodes, and doesn't = describe > the way one actually uses that integration. If you have a malicious node, then all bets are off anyway. There are = many bad things a malicious node can do, of which this is the least = interesting. We have for example known how to protect the routing system = against malicious nodes since Radia wrote her thesis at MIT, but the = industry does not yet have an interest in moving there.=20 Our assumption is that the more likely point of attack is the link = rather than the node (because it is much easier and we have an existence = proof of that attack being common). It is well known to operators how to = encrypt the link traffic and thus we do not add much value to this = document by describing it. > It's not clear to me what the > security goals are, and saying a mechanism may be used, without = indicating how > doesn't make it remediation for a security problem. In this specific case it is the prevention of snooping of traffic not = secured by the application (many applications are legacy) such as the = snooping that the NSA became famous for.=20 > I can think of a few ways > to abuse the one-packet only service to rewrite flows with great ease. Please describe them in the contest of operation of this service and we = will assess the eligibility and vulnerability.=20 >=20 > The Internet is composed of smart nodes at the edge and dumb = forwarders in the > middle. This is **NOT** running over the general Internet. It is of necessity a = well controlled network. This is an MPLS design and MPLS only operates = in well controlled provider networks. > DetNet is a very different design, with significant complexity and > state in the network, and guarantees not maintained by end nodes. Are you familiar with multi-segment pseudowires? This design is = basically an MS-PW with the addition of the a very special type of = multicast. In both cases there is a controlled amount of additional = state. The state that we add here is well controlled. As to guarantees, I would point you to the fundamental design philosophy = of PWs, which was that we would operate as best we could, and if that = was not good enough buy a (much more expensive) real wire. We designed = some types of PW that were quite sensitive to loss and no one = complained. It is the same here. If you need a greater guarantee than = you get with this approach, spend more money and use a private physical = network. However that discussion belongs is in the scope of DetNet per = se and this design inherits that scope. It should not be part of this = text. > This means > that a lot that has been learned about Internet security doesn't = apply, which > raises a whole host of questions: what threat model is applied? We are documenting that in other work, hence the references. However of = all of the network types, MPLS is intrinsically one of the most secure. > Is it > realistic? Are the properties such as bounded latency and low jitter = maintained > even in the face of adversarial behavior? That is why we have to police the behaviour at the edge, something that = the MPLS community has a lot of existing experience with. > While this may be appropriately > handled at greater length in a separated draft, a tighter link to the > mechanisms defined in this draft would be useful. If you look at the work you will see that this would imbalance the draft = and then we would have to duplicate it in the other data-plane drafts. = Much better to discuss that in a single place and just call out the = data-plane specific security issues in the data-plane drafts. That way = the critical issues are documented in a way that the reader is less = likely to lose in a sea of familiar text. >=20 > It's very likely these have been discussed in the detnet wg at length = as > evidenced by the security considerations, but I'd like to see the MPLS = draft > reflect some of that conversation more directly. I would ask you to reflect on the discussion above. If you need any help = understanding MPLS and Pseudowires (which are fundamentally assumed = knowledge that anyone deploying this technology would have) I can = provide you with some pointers to background reading.=20 Best regards Stewart >=20 >=20 From nobody Wed Mar 11 10:19:18 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F133A0EA0; Wed, 11 Mar 2020 10:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 gdIduPjNOCZ2; Wed, 11 Mar 2020 10:19:13 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D461B3A0E99; Wed, 11 Mar 2020 10:19:12 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id d23so3186197ljg.13; Wed, 11 Mar 2020 10:19:12 -0700 (PDT) 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:content-transfer-encoding; bh=ONL1RiEakPNW1hgnQb3grreH0oJDu1BFL9tosGXtvkc=; b=n+ypNzoJxJrUyGmb+R1SVNkNsyHUY30X9X/H4sn3HJsm3snFm6zwNzsrkdR8KLCjC6 erH8R6RMfLTT5XWn07ho1DdkxhFteYM4PcdkzAxVfwutEp+503XC4TM58/6F+x2Y29Dt DjA7Q58Yk8fkl4mLMr4frquxuHnlU2uYoXhrcmbnVWaA9SX+94RRtdYOpVGFDJ4z6uVp IuibX/zaHXzoXQc5vgBZWMRBJiCM9TGOmt1BxCbMxGsn5jGPIGfQHwbFWF7XOApNKAqW QyzV75ocOI0riSwoYKnRxoOfdOWhDSQSyEQ57d86WHC9WxhUCePYQeWZtsKmK/3Rhunj HVtQ== 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:content-transfer-encoding; bh=ONL1RiEakPNW1hgnQb3grreH0oJDu1BFL9tosGXtvkc=; b=X74c774AMVq1qM+3c38ugEzq2mVXYO67d8kzCXEQ10cEKypmkRN+D82iQILosATHma 9QKsWv5vE1IhlsQolEUJZuYKSFlREpxeXMdoIIvKlZta9JdQPxWppWPwBxkTaMs9euVR dNYj601bISb7TvEqtCVsZOGfJp5hF4SGtAmuBPcWyyVI+Kj1+hjHtie4ytqjXeEURDms BWr0R5yEVHycLfyjE8xBG+CEZdkYqztudKOnXJ7SrUAvxSc/WBBwtddwkfFj5pWyuycG nHUFhqtdmBJIhwd8sM5yrvB0T28GppkacsaPoqHogmqGfvAFpBgOuHgg8Hqf14FGgQnG BRwA== X-Gm-Message-State: ANhLgQ3jxTnQ7fTMKO7CBEMuoaHtO7vqi86a1GFEiMXtZQphCAebPRC9 wLb0e8Tht48B4ACGJjpgGV+igOqrJut1j92dVJw= X-Google-Smtp-Source: ADFU+vvNdFnYpb9S7W84XlbgAutEuEr9PFzuEgA6Cir9DIB48iIAcwO5X56rA+xvIc4yzZkIm+G4q/H4JImw3rN9VjI= X-Received: by 2002:a2e:b5ca:: with SMTP id g10mr2768310ljn.123.1583947150769; Wed, 11 Mar 2020 10:19:10 -0700 (PDT) MIME-Version: 1.0 References: <158389693039.16158.6977515080330200081@ietfa.amsl.com> In-Reply-To: From: Watson Ladd Date: Wed, 11 Mar 2020 10:18:59 -0700 Message-ID: To: Stewart Bryant Cc: secdir , DetNet WG , draft-ietf-detnet-mpls.all@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-detnet-mpls-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2020 17:19:16 -0000 On Wed, Mar 11, 2020 at 8:29 AM Stewart Bryant w= rote: > > > > > On 11 Mar 2020, at 03:22, Watson Ladd via Datatracker wrote: > > > > Reviewer: Watson Ladd > > Review result: Not Ready > > > > This is the secdir review of draft-ietf-detnet-mpls-05. Authors should = treat > > these as any other Last Call comments. > > > > Apologies for the delays in completing this review. > > > > I am concerned that this document (and the related work) introduces som= e > > substantial differences from existing Internet architecture, and that > > inadequate attention is paid to the consequent security implications. > > I disagree with the proposition that this is a substantial change to the = existing Internet architecture. > > This MPLS DetNet design is, if anything, a development of pseudowires, a = widely deployed technology that for many years was the standard method of c= arrying IP from the customer premise to the ISP. It is a close cousin to MP= LS VPN which has been a stable of provider network deployments. > > MPLS is designed to be run in a tightly controlled environment. This is s= omething that all competent MPLS operators do as a matter of course, and I = do not see this being much of an additional issue. The special problem her= e is the need to police ingress traffic for dynamic issues. That is quite a= significant body of work, and is being tackled in a separate document. > > We can add a reference to general MPLS security, and to the security of p= seudowires running over MPLS, but these are well known by anyone operating = an MPLS network, and the clutter will distract the reader from the unique i= ssues that apply to this design. Then this assumption that all the nodes are trusted needs to be explicitly stated in the securities consideration section. > > > Pointing > > to a separate, in progress draft I don't think is an adequate security > > consideration section. > > Adding all the text from that draft would imbalance this draft, and refer= ring to it is normally a better idea, particularly as the same text applies= to a number of the DetNet drafts. I don't think you need to add all the text: i think you need to connect the specific mechanisms in this draft to those considerations. As it is much of the security considerations section here talks about DetNet and not MPLS or MPLS-DetNet: it makes it very hard to figure out what the issues are, especially for someone unfamiliar with it. It's not much text to add, but it's important text. > > > That's particularly true when we're discussing the > > network providing functions like duplicate packet dropping that are pot= entially > > quite expensive and which attackers may exploit to consume large amount= s of > > resources. > > The expensive process of duplicate dropping is a cost of that aspect of t= he service. Obviously if your forwarder is incapable of offering that servi= ce you would not offer the service. Now we know that a lot of forwarder des= igns cannot do this, and to do so would require a rebalance of processing b= etween the ingress and the egress interface, but that should not stop us de= signing such a system. It is simply a mark of progress that we upgrade the = forwarding system to add new features. There is an old prank where one introduces 3 pigs numbered 1, 2, and 4 into a place where pigs are not normally found. The deduplication capacity isn't unlimited, and care should be taken that the state can't grow unboundedly. > > Now if you are worried about an attacker injecting such packets, I would = ask you to remember that no competent MPLS operator will allow any MPLS pac= kets in their network that they have not put there themselves, or have acce= pted from a highly trusted peer. There is over 20 years of experience in se= curing MPLS networks. As far as I am aware there has never been an MPLS inj= ection attack brought to the attention of the MPLS WG or the PALS (ne PWE3)= WGs. I am not loosing any sleep over this type of attack. If the attack wa= s a likely prospect we would be seeing it as an issue with VPNs and PWs and= we see no such issue. > > > > Saying that one can mitigate DoS on the edge of a DetNet domain > > isn't enough: how do you mitigate the DoS, or detect it? > > Again this is standard MPLS. Remember nothing gets into the network other= than through a PE, and it is common for a PE to do rate detection and ensu= re that the attached external device does not exceed the agreed rate. > > > What if the edge is > > the problem? Are there resources that can be consumed in the center the= edge > > doesn't know about? > > This is no different from the MPLS traffic engineered network case with r= eserved bandwidth. This is widely understood in MPLS network designs. If yo= u are concerned about faulty equipment, there are many worse things that co= uld happen. It's very different: bandwidth is frequently exceeded over very short periods due to microbursts, with no real harmful effects, and it's a resource one can pretty nicely model as a flow problem. Latency or deduplication memory is a bit trickier: I suppose if everything is reserved it's ok, but whatever sets up the reservations and the routing should know about all of the resources involved. I don't think these are the same problem as bandwidth reservations. > > > > > With confidentiality this draft mentions the possibility of link to lin= k > > protection, ignoring the possibility of malicious nodes, and doesn't de= scribe > > the way one actually uses that integration. > > If you have a malicious node, then all bets are off anyway. There are man= y bad things a malicious node can do, of which this is the least interestin= g. We have for example known how to protect the routing system against mali= cious nodes since Radia wrote her thesis at MIT, but the industry does not = yet have an interest in moving there. > > Our assumption is that the more likely point of attack is the link rather= than the node (because it is much easier and we have an existence proof of= that attack being common). It is well known to operators how to encrypt th= e link traffic and thus we do not add much value to this document by descri= bing it. > > > > It's not clear to me what the > > security goals are, and saying a mechanism may be used, without indicat= ing how > > doesn't make it remediation for a security problem. > > In this specific case it is the prevention of snooping of traffic not sec= ured by the application (many applications are legacy) such as the snooping= that the NSA became famous for. RFC 3552 says that this sort of statement is insufficient, and recommends instead describing what the lower layer should do and the properties of the combined system. > > > I can think of a few ways > > to abuse the one-packet only service to rewrite flows with great ease. > > Please describe them in the contest of operation of this service and we w= ill assess the eligibility and vulnerability. Insert the packet with the same number, win the race. > > > > > The Internet is composed of smart nodes at the edge and dumb forwarders= in the > > middle. > > This is **NOT** running over the general Internet. It is of necessity a w= ell controlled network. This is an MPLS design and MPLS only operates in we= ll controlled provider networks. > > > DetNet is a very different design, with significant complexity and > > state in the network, and guarantees not maintained by end nodes. > > Are you familiar with multi-segment pseudowires? This design is basically= an MS-PW with the addition of the a very special type of multicast. In bot= h cases there is a controlled amount of additional state. The state that we= add here is well controlled. > > As to guarantees, I would point you to the fundamental design philosophy = of PWs, which was that we would operate as best we could, and if that was n= ot good enough buy a (much more expensive) real wire. We designed some type= s of PW that were quite sensitive to loss and no one complained. It is the = same here. If you need a greater guarantee than you get with this approach,= spend more money and use a private physical network. However that discussi= on belongs is in the scope of DetNet per se and this design inherits that = scope. It should not be part of this text. I think that's a considerable change from current MPLS! Operators should be aware that all of a sudden they have to worry about latency. Does current MPLS hardware offer the guarantees required? I feel this needs to be a bit louder: you can't just throw on DetNet on top of MPLS without problems. > > > This means > > that a lot that has been learned about Internet security doesn't apply,= which > > raises a whole host of questions: what threat model is applied? > > We are documenting that in other work, hence the references. However of a= ll of the network types, MPLS is intrinsically one of the most secure. I looked and found it quite hard to understand exactly what I should be looking for in this draft. That's in no small part due to my own unfamiliarity, and writing for nonexperts is hard. > > > > Is it > > realistic? Are the properties such as bounded latency and low jitter ma= intained > > even in the face of adversarial behavior? > > That is why we have to police the behaviour at the edge, something that t= he MPLS community has a lot of existing experience with. Would you necessarily notice if a low bandwidth flow was causing a priority inversion at some node and thus violating latency promises on another low bandwidth flow? > > > While this may be appropriately > > handled at greater length in a separated draft, a tighter link to the > > mechanisms defined in this draft would be useful. > > If you look at the work you will see that this would imbalance the draft = and then we would have to duplicate it in the other data-plane drafts. Much= better to discuss that in a single place and just call out the data-plane = specific security issues in the data-plane drafts. That way the critical is= sues are documented in a way that the reader is less likely to lose in a se= a of familiar text. Right, but then this draft should focus on the specific MPLS-DetNet security issues and explicitly link particular mechanisms to the problems. As it is the securities considerations section of this draft feels pretty generic, which is not good. Deviation from RFC3552 should be very explicitly noted. > > > > > It's very likely these have been discussed in the detnet wg at length a= s > > evidenced by the security considerations, but I'd like to see the MPLS = draft > > reflect some of that conversation more directly. > > I would ask you to reflect on the discussion above. If you need any help = understanding MPLS and Pseudowires (which are fundamentally assumed knowled= ge that anyone deploying this technology would have) I can provide you with= some pointers to background reading. > > Best regards > > Stewart > > > > > > --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Wed Mar 11 11:59:28 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 711FD3A1161; Wed, 11 Mar 2020 11:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 bdMPQL4-tGpo; Wed, 11 Mar 2020 11:59:18 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 E27EB3A1163; Wed, 11 Mar 2020 11:59:17 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id l18so4030221wru.11; Wed, 11 Mar 2020 11:59:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=/uJredsOWy+0U4GVv8bmrgbbu/hh9ZxiVe4CILwH5JE=; b=NnDQagO+de5Ez3imiGqjgnYlCu+JwA/sjXT2JuMRUvcpHOYlv+cj2EisoRsFGPfVPV mRvywXD8eNYK4PJTc69RBnpmhLhCIiCccwP8YWlgsnLkdVu9evETIdrX5UOP6wtgPNTC lykeDDephtS59aCADMqw6LJCJ4paKjCgfIXQbe1HdPlp+IFqRGIdETZtVDqJHEXhhulz nyOE4R0a3yarpWO1F/E3XpP9PjIq+hoVYmH8FLSrCfBnWsSyvZp8PIDufurTC5V3DiUq ZUtzN5Ff3DEW88dH58M7omRyuVQ2+UC2K/6QNxNiTNfdUKnhOP26l2QccqIvLReTJ35c rimA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=/uJredsOWy+0U4GVv8bmrgbbu/hh9ZxiVe4CILwH5JE=; b=ZryAW2tvdsdqsiUSahv6p2JgqL5BMSXAjjbg/AO1LM3fEpxUJo9LHw5kMM74kYP2MG esschzhS2zXNt36J0tUEceTdaVROurRdCHGnswM5SheKPGCsQF0ktSWAVAaY3trmdaA+ Bija1l7ryxa8x/nIX/wqzv2VqjkdSMCM3SguP1ng6qMc61tilBT4M2zIx2odiUgBgWC3 qzJtkEdpF6D6Oxsnd+j1qqrsG8nJLd5wUM/hJjdcdYfTBzXF8J1/Wkc5pkzyY046HUos w3F/a70RfhWBSB8y5DYqWoGRvxHdBaj+Zww5ipK8EsVO7fnwbJfMwDAx9r1QoYQNp6N/ ZecQ== X-Gm-Message-State: ANhLgQ3Gyv2BhWwB+cnOOjisB+dSN7o6ehfSsjmNyzLVnGHuP5PhgsR3 b/raDTkNfMqGAbbMtmTLAF0eCcqV X-Google-Smtp-Source: ADFU+vtE1PDC8y9wyfpQfli/ximpSsgPs4+r3N/IRtHRJ4dXgEsvdQihnh2WCtedQBqDLFUpNzFWKw== X-Received: by 2002:a5d:55c7:: with SMTP id i7mr6069225wrw.252.1583953155981; Wed, 11 Mar 2020 11:59:15 -0700 (PDT) Received: from broadband.bt.com ([2a00:23a8:4140:0:c8eb:cfef:a8bf:b0ef]) by smtp.gmail.com with ESMTPSA id k4sm13978697wrx.27.2020.03.11.11.59.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Mar 2020 11:59:15 -0700 (PDT) From: Stewart Bryant Message-Id: <137FCA36-3B7C-46EB-B951-3FDC01560069@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7CCE0078-0C2F-4820-BE5D-208964F2047E" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Wed, 11 Mar 2020 18:59:03 +0000 In-Reply-To: Cc: Stewart Bryant , secdir , DetNet WG , draft-ietf-detnet-mpls.all@ietf.org To: Watson Ladd References: <158389693039.16158.6977515080330200081@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-detnet-mpls-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2020 18:59:22 -0000 --Apple-Mail=_7CCE0078-0C2F-4820-BE5D-208964F2047E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii As requested I just sent you a reading list and short tutorial on PWs = and MPLS. It is our assumption that before anyone gets to DetNet over MPLS that = already became an expert on MPLS, because if they had not they would be = dealing with a huge set of problems. It is therefore unreasonable to = clutter the document with basis MPLS material since this would only = distract from the crucial issues that are associated with DetNet. > On 11 Mar 2020, at 17:18, Watson Ladd wrote: >=20 > On Wed, Mar 11, 2020 at 8:29 AM Stewart Bryant = > wrote: >>=20 >>=20 >>=20 >>> On 11 Mar 2020, at 03:22, Watson Ladd via Datatracker = wrote: >>>=20 >>> Reviewer: Watson Ladd >>> Review result: Not Ready >>>=20 >>> This is the secdir review of draft-ietf-detnet-mpls-05. Authors = should treat >>> these as any other Last Call comments. >>>=20 >>> Apologies for the delays in completing this review. >>>=20 >>> I am concerned that this document (and the related work) introduces = some >>> substantial differences from existing Internet architecture, and = that >>> inadequate attention is paid to the consequent security = implications. >>=20 >> I disagree with the proposition that this is a substantial change to = the existing Internet architecture. >>=20 >> This MPLS DetNet design is, if anything, a development of = pseudowires, a widely deployed technology that for many years was the = standard method of carrying IP from the customer premise to the ISP. It = is a close cousin to MPLS VPN which has been a stable of provider = network deployments. >>=20 >> MPLS is designed to be run in a tightly controlled environment. This = is something that all competent MPLS operators do as a matter of course, = and I do not see this being much of an additional issue. The special = problem here is the need to police ingress traffic for dynamic issues. = That is quite a significant body of work, and is being tackled in a = separate document. >>=20 >> We can add a reference to general MPLS security, and to the security = of pseudowires running over MPLS, but these are well known by anyone = operating an MPLS network, and the clutter will distract the reader from = the unique issues that apply to this design. >=20 > Then this assumption that all the nodes are trusted needs to be > explicitly stated in the securities consideration section. That is an MPLS given. I am not sure that it needs to be stated since it = is only in IETF security reviews that we meet the case of someone = wanting to do a detailed review of DetNet over MPLS without first = understanding MPLS and the shared assumptions. >=20 >>=20 >>> Pointing >>> to a separate, in progress draft I don't think is an adequate = security >>> consideration section. >>=20 >> Adding all the text from that draft would imbalance this draft, and = referring to it is normally a better idea, particularly as the same text = applies to a number of the DetNet drafts. >=20 > I don't think you need to add all the text: i think you need to > connect the specific mechanisms in this draft to those considerations. > As it is much of the security considerations section here talks about > DetNet and not MPLS or MPLS-DetNet: it makes it very hard to figure > out what the issues are, especially for someone unfamiliar with it. > It's not much text to add, but it's important text. Yes, but normally the text would not be read by someone that was not an = MPLS expert. We could add at the beginning something of the form: "This technology must only be deployed in a well managed MPLS network = operated by those familiar with MPLS." However that seems a bit obvious. >=20 >>=20 >>> That's particularly true when we're discussing the >>> network providing functions like duplicate packet dropping that are = potentially >>> quite expensive and which attackers may exploit to consume large = amounts of >>> resources. >>=20 >> The expensive process of duplicate dropping is a cost of that aspect = of the service. Obviously if your forwarder is incapable of offering = that service you would not offer the service. Now we know that a lot of = forwarder designs cannot do this, and to do so would require a rebalance = of processing between the ingress and the egress interface, but that = should not stop us designing such a system. It is simply a mark of = progress that we upgrade the forwarding system to add new features. >=20 > There is an old prank where one introduces 3 pigs numbered 1, 2, and 4 > into a place where pigs are not normally found. The deduplication > capacity isn't unlimited, and care should be taken that the state > can't grow unboundedly. But how do the pigs get inside the pen when ALL the outer gates are = guarded by a robot that kills all pigs regardless of their number? >=20 >>=20 >> Now if you are worried about an attacker injecting such packets, I = would ask you to remember that no competent MPLS operator will allow any = MPLS packets in their network that they have not put there themselves, = or have accepted from a highly trusted peer. There is over 20 years of = experience in securing MPLS networks. As far as I am aware there has = never been an MPLS injection attack brought to the attention of the MPLS = WG or the PALS (ne PWE3) WGs. I am not loosing any sleep over this type = of attack. If the attack was a likely prospect we would be seeing it as = an issue with VPNs and PWs and we see no such issue. >>=20 >>=20 >>> Saying that one can mitigate DoS on the edge of a DetNet domain >>> isn't enough: how do you mitigate the DoS, or detect it? >>=20 >> Again this is standard MPLS. Remember nothing gets into the network = other than through a PE, and it is common for a PE to do rate detection = and ensure that the attached external device does not exceed the agreed = rate. >>=20 >>> What if the edge is >>> the problem? Are there resources that can be consumed in the center = the edge >>> doesn't know about? >>=20 >> This is no different from the MPLS traffic engineered network case = with reserved bandwidth. This is widely understood in MPLS network = designs. If you are concerned about faulty equipment, there are many = worse things that could happen. >=20 > It's very different: bandwidth is frequently exceeded over very short > periods due to microbursts, with no real harmful effects, and it's a > resource one can pretty nicely model as a flow problem. Latency or > deduplication memory is a bit trickier: I suppose if everything is > reserved it's ok, but whatever sets up the reservations and the > routing should know about all of the resources involved. I don't think > these are the same problem as bandwidth reservations. We know its harder, but that is an operational problem not a security = problem. The input policer would need to understand the constraints it was = policing which would not be simple bandwidth over the long term but = would include shorter term bandwidth constraints. Indeed the input to = the network would need to smooth the flow over time. However that is = really a study in advanced QoS rather than a security issue. >=20 >>=20 >>>=20 >>> With confidentiality this draft mentions the possibility of link to = link >>> protection, ignoring the possibility of malicious nodes, and doesn't = describe >>> the way one actually uses that integration. >>=20 >> If you have a malicious node, then all bets are off anyway. There are = many bad things a malicious node can do, of which this is the least = interesting. We have for example known how to protect the routing system = against malicious nodes since Radia wrote her thesis at MIT, but the = industry does not yet have an interest in moving there. >>=20 >> Our assumption is that the more likely point of attack is the link = rather than the node (because it is much easier and we have an existence = proof of that attack being common). It is well known to operators how to = encrypt the link traffic and thus we do not add much value to this = document by describing it. >>=20 >>=20 >>> It's not clear to me what the >>> security goals are, and saying a mechanism may be used, without = indicating how >>> doesn't make it remediation for a security problem. >>=20 >> In this specific case it is the prevention of snooping of traffic not = secured by the application (many applications are legacy) such as the = snooping that the NSA became famous for. >=20 > RFC 3552 says that this sort of statement is insufficient, and > recommends instead describing what the lower layer should do and the > properties of the combined system. Please provide some recommended text or a pointed to the text in an RFC = that addresses this problem. >=20 >>=20 >>> I can think of a few ways >>> to abuse the one-packet only service to rewrite flows with great = ease. >>=20 >> Please describe them in the contest of operation of this service and = we will assess the eligibility and vulnerability. >=20 > Insert the packet with the same number, win the race. See earlier. The packet was killed on sight by the ingress PE. Remember = this is MPLS not IP. >=20 >>=20 >>>=20 >>> The Internet is composed of smart nodes at the edge and dumb = forwarders in the >>> middle. >>=20 >> This is **NOT** running over the general Internet. It is of necessity = a well controlled network. This is an MPLS design and MPLS only operates = in well controlled provider networks. >>=20 >>> DetNet is a very different design, with significant complexity and >>> state in the network, and guarantees not maintained by end nodes. >>=20 >> Are you familiar with multi-segment pseudowires? This design is = basically an MS-PW with the addition of the a very special type of = multicast. In both cases there is a controlled amount of additional = state. The state that we add here is well controlled. >>=20 >> As to guarantees, I would point you to the fundamental design = philosophy of PWs, which was that we would operate as best we could, and = if that was not good enough buy a (much more expensive) real wire. We = designed some types of PW that were quite sensitive to loss and no one = complained. It is the same here. If you need a greater guarantee than = you get with this approach, spend more money and use a private physical = network. However that discussion belongs is in the scope of DetNet per = se and this design inherits that scope. It should not be part of this = text. >=20 > I think that's a considerable change from current MPLS! Operators > should be aware that all of a sudden they have to worry about latency. Surely if they are deploying DetNet they know that. They are deploying a = deterministic service. > Does current MPLS hardware offer the guarantees required? I feel this > needs to be a bit louder: you can't just throw on DetNet on top of > MPLS without problems. Yes, as I said if you are being asked to deploy a deterministic service, = and presumably underhand what that means from the DetNet architecture = you would know that and not need to read it in the security section. >=20 >>=20 >>> This means >>> that a lot that has been learned about Internet security doesn't = apply, which >>> raises a whole host of questions: what threat model is applied? >>=20 >> We are documenting that in other work, hence the references. However = of all of the network types, MPLS is intrinsically one of the most = secure. >=20 > I looked and found it quite hard to understand exactly what I should > be looking for in this draft. That's in no small part due to my own > unfamiliarity, and writing for nonexperts is hard. But it was not written for non-experts! There is so much MPLS you need to know to stand up the network I find it = hard to see why we need to provide a tutorial in this document. Maybe SecDir needs some MPLS expertise on staff to review MPLS texts? >=20 >>=20 >>=20 >>> Is it >>> realistic? Are the properties such as bounded latency and low jitter = maintained >>> even in the face of adversarial behavior? >>=20 >> That is why we have to police the behaviour at the edge, something = that the MPLS community has a lot of existing experience with. >=20 > Would you necessarily notice if a low bandwidth flow was causing a > priority inversion at some node and thus violating latency promises on > another low bandwidth flow? What do you mean by a priority inversion in the context of MPLS? Remember that DetNet (see the architecture) only promises a latency = ceiling, not the minimum transit latency. You therefore have to assume = in working out the SLA that a low bandwidth packet just get to the = output pipeline stage before the deterministic packet. The most you will = be delayed is by the number of bytes in the pipeline, but that is a = feature of the approach. It is not a security issue. >>=20 >>> While this may be appropriately >>> handled at greater length in a separated draft, a tighter link to = the >>> mechanisms defined in this draft would be useful. >>=20 >> If you look at the work you will see that this would imbalance the = draft and then we would have to duplicate it in the other data-plane = drafts. Much better to discuss that in a single place and just call out = the data-plane specific security issues in the data-plane drafts. That = way the critical issues are documented in a way that the reader is less = likely to lose in a sea of familiar text. >=20 > Right, but then this draft should focus on the specific MPLS-DetNet > security issues and explicitly link particular mechanisms to the > problems. As it is the securities considerations section of this draft > feels pretty generic, which is not good. Deviation from RFC3552 should > be very explicitly noted. We do point to other drafts. I am sure that RFC3552 says nothing about a = draft being freestanding. In any case RFC3552 just deals with classic attacks on best effort = networks and so is not a good model for a security analysis of a dynamic = system overlayed on a well established technology well known for its = intrinsic security properties. We have references to other specialist material we are in the process of = publishing, so I think that all that is required is a sentence saying = that this technology must be deployed over a well managed MPLS network. Best regards Stewart. >=20 >>=20 >>>=20 >>> It's very likely these have been discussed in the detnet wg at = length as >>> evidenced by the security considerations, but I'd like to see the = MPLS draft >>> reflect some of that conversation more directly. >>=20 >> I would ask you to reflect on the discussion above. If you need any = help understanding MPLS and Pseudowires (which are fundamentally assumed = knowledge that anyone deploying this technology would have) I can = provide you with some pointers to background reading. >>=20 >> Best regards >>=20 >> Stewart >>=20 >>>=20 >>>=20 >>=20 >=20 >=20 > --=20 > "Man is born free, but everywhere he is in chains". > --Rousseau. --Apple-Mail=_7CCE0078-0C2F-4820-BE5D-208964F2047E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii As = requested I just sent you a reading list and short tutorial on PWs and = MPLS.

It is our = assumption that before anyone gets to DetNet over MPLS that already = became an expert on MPLS, because if they had not they would be dealing = with a huge set of problems. It is therefore unreasonable to clutter the = document with basis MPLS material since this would only distract from = the crucial issues that are associated with DetNet.

On 11 Mar 2020, at 17:18, Watson Ladd <watsonbladd@gmail.com> wrote:

On Wed, Mar = 11, 2020 at 8:29 AM Stewart Bryant <stewart.bryant@gmail.com> wrote:



On 11 Mar 2020, at = 03:22, Watson Ladd via Datatracker <noreply@ietf.org> wrote:

Reviewer: Watson Ladd
Review result: Not = Ready

This is the secdir review of = draft-ietf-detnet-mpls-05. Authors should treat
these as = any other Last Call comments.

Apologies for = the delays in completing this review.

I am = concerned that this document (and the related work) introduces some
substantial differences from existing Internet architecture, = and that
inadequate attention is paid to the consequent = security implications.

I = disagree with the proposition that this is a substantial change to the = existing Internet architecture.

This MPLS = DetNet design is, if anything, a development of pseudowires, a widely = deployed technology that for many years was the standard method of = carrying IP from the customer premise to the ISP. It is a close cousin = to MPLS VPN which has been a stable of provider network deployments.

MPLS is designed to be run in a tightly = controlled environment. This is something that all competent MPLS = operators do as a matter of course, and I do not see this being much of = an additional issue. The special  problem here is the need to = police ingress traffic for dynamic issues. That is quite a significant = body of work, and is being tackled in a separate document.

We can add a reference to general MPLS = security, and to the security of pseudowires running over MPLS, but = these are well known by anyone operating an MPLS network, and the = clutter will distract the reader from the unique issues that apply to = this design.

Then this assumption that all the nodes are trusted needs to = be
explicitly = stated in the securities consideration section.

That = is an MPLS given. I am not sure that it needs to be stated since it is = only in IETF security reviews that we meet the case of someone wanting = to do a detailed review of DetNet over MPLS without first understanding = MPLS and the shared assumptions.



Pointing
to a separate, in = progress draft I don't think is an adequate security
consideration section.

Adding all the text from that draft would imbalance this = draft, and referring to it is normally a better idea, particularly as = the same text applies to a number of the DetNet drafts.

I don't think you need to add all the text: i think you need = to
connect the = specific mechanisms in this draft to those considerations.
As it is much = of the security considerations section here talks about
DetNet and = not MPLS or MPLS-DetNet: it makes it very hard to figure
out what the = issues are, especially for someone unfamiliar with it.
It's not much = text to add, but it's important text.

Yes, but normally the text would not be read by = someone that was not an MPLS expert.

We could add at the beginning something of the = form:

"This technology must only =  be deployed in a well managed MPLS network operated by those = familiar with MPLS."

However that = seems a bit obvious.



That's particularly true when we're discussing = the
network providing functions like duplicate packet = dropping that are potentially
quite expensive and which = attackers may exploit to consume large amounts of
resources.

The = expensive process of duplicate dropping is a cost of that aspect of the = service. Obviously if your forwarder is incapable of offering that = service you would not offer the service. Now we know that a lot of = forwarder designs cannot do this, and to do so would require a rebalance = of processing between the ingress and the egress interface, but that = should not stop us designing such a system. It is simply a mark of = progress that we upgrade the forwarding system to add new features.

There is an old prank where one introduces 3 pigs numbered 1, = 2, and 4
into a place = where pigs are not normally found. The deduplication
capacity = isn't unlimited, and care should be taken that the state
can't grow = unboundedly.

But = how do the pigs get inside the pen when ALL the outer gates are guarded = by a robot that kills all pigs regardless of their number?



Now if you are worried about an attacker injecting such = packets, I would ask you to remember that no competent MPLS operator = will allow any MPLS packets in their network that they have not put = there themselves, or have accepted from a highly trusted peer. There is = over 20 years of experience in securing MPLS networks. As far as I am = aware there has never been an MPLS injection attack brought to the = attention of the MPLS WG or the PALS (ne PWE3) WGs. I am not loosing any = sleep over this type of attack. If the attack was a likely prospect we = would be seeing it as an issue with VPNs and PWs and we see no such = issue.


Saying that one can mitigate DoS on the edge of = a DetNet domain
isn't enough: how do you mitigate the DoS, = or detect it?

Again this is = standard MPLS. Remember nothing gets into the network other than through = a PE, and it is common for a PE to do rate detection and ensure that the = attached external device does not exceed the agreed rate.

What if = the edge is
the problem? Are there resources that can be = consumed in the center the edge
doesn't know about?

This is no different from the = MPLS traffic engineered network case with reserved bandwidth. This is = widely understood in MPLS network designs. If you are concerned about = faulty equipment, there are many worse things that could happen.

It's very different: bandwidth is frequently exceeded over = very short
periods due = to microbursts, with no real harmful effects, and it's a
resource one = can pretty nicely model as a flow problem. Latency or
deduplication = memory is a bit trickier: I suppose if everything is
reserved it's = ok, but whatever sets up the reservations and the
routing = should know about all of the resources involved. I don't think
these are the = same problem as bandwidth reservations.

We know its harder, but that is an operational = problem not a security problem.

The = input policer would need to understand the constraints it was policing = which would not be simple bandwidth over the long term but would include = shorter term bandwidth constraints. Indeed the input to the network = would need to smooth the flow over time. However that is really a study = in advanced QoS rather than a security issue.




With = confidentiality this draft mentions the possibility of link to link
protection, ignoring the possibility of malicious nodes, and = doesn't describe
the way one actually uses that = integration.

If you have a = malicious node, then all bets are off anyway. There are many bad things = a malicious node can do, of which this is the least interesting. We have = for example known how to protect the routing system against malicious = nodes since Radia wrote her thesis at MIT, but the industry does not yet = have an interest in moving there.

Our = assumption is that the more likely point of attack is the link rather = than the node (because it is much easier and we have an existence proof = of that attack being common). It is well known to operators how to = encrypt the link traffic and thus we do not add much value to this = document by describing it.


It's not clear to me = what the
security goals are, and saying a mechanism may be = used, without indicating how
doesn't make it remediation = for a security problem.

In = this specific case it is the prevention of snooping of traffic not = secured by the application (many applications are legacy) such as the = snooping that the NSA became famous for.

RFC 3552 says = that this sort of statement is insufficient, and
recommends = instead describing what the lower layer should do and the
properties of = the combined system.

Please provide some recommended text or a pointed = to the text in an RFC that addresses this problem.



I can think of a few = ways
to abuse the one-packet only service to rewrite flows = with great ease.

Please = describe them in the contest of operation of this service and we will = assess the eligibility and vulnerability.

Insert the = packet with the same number, win the race.

See earlier. The packet was killed on sight by the = ingress PE. Remember this is MPLS not IP.




The = Internet is composed of smart nodes at the edge and dumb forwarders in = the
middle.

This = is **NOT** running over the general Internet. It is of necessity a well = controlled network. This is an MPLS design and MPLS only operates in = well controlled provider networks.

DetNet is a very = different design, with significant complexity and
state in = the network, and guarantees not maintained by end nodes.

Are you familiar with = multi-segment pseudowires? This design is basically an MS-PW with the = addition of the a very special type of multicast. In both cases there is = a controlled amount of additional state. The state that we add here is = well controlled.

As to guarantees, I would = point you to the fundamental design philosophy of PWs, which was that we = would operate as best we could, and if that was not good enough buy a = (much more expensive) real wire. We designed some types of PW that were = quite sensitive to loss and no one complained. It is the same here. If = you need a greater guarantee than you get with this approach, spend more = money and use a private physical network. However that discussion = belongs  is in the scope of DetNet per se and this design inherits = that scope. It should not be part of this text.

I think that's a considerable change from current MPLS! =  Operators
should be aware that all of a sudden they have to worry about = latency.

Surely= if they are deploying DetNet they know that. They are deploying a = deterministic service.

Does current MPLS hardware offer the guarantees required? I = feel this
needs to be a = bit louder: you can't just throw on DetNet on top of
MPLS without = problems.

Yes, = as I said if you are being asked to deploy a deterministic service, and = presumably underhand what that means from the DetNet architecture you = would know that and not need to read it in the security = section.




This means
that a lot that has = been learned about Internet security doesn't apply, which
raises a whole host of questions: what threat model is = applied?

We are documenting = that in other work, hence the references. However of all of the network = types, MPLS is intrinsically one of the most secure.

I looked and found it quite hard to understand exactly what I = should
be looking = for in this draft. That's in no small part due to my own
unfamiliarity, = and writing for nonexperts is hard.

But it was not written for = non-experts!

There is so much MPLS = you need to know to stand up the network I find it hard to see why we = need to provide a tutorial in this document.

Maybe SecDir needs some MPLS expertise on staff to = review MPLS texts?




Is it
realistic? Are the properties such as bounded latency and low = jitter maintained
even in the face of adversarial = behavior?

That is why we have = to police the behaviour at the edge, something that the MPLS community = has a lot of existing experience with.

Would you = necessarily notice if a low bandwidth flow was causing a
priority = inversion at some node and thus violating latency promises on
another low = bandwidth flow?

What do you mean by a priority inversion in the = context of MPLS?

Remember that = DetNet (see the architecture) only promises a latency ceiling, not the = minimum transit latency. You therefore have to assume in working out the = SLA that a low bandwidth packet just get to the output pipeline stage = before the deterministic packet. The most you will be delayed is by the = number of bytes in the pipeline, but that is a feature of the approach. = It is not a security issue.



While this may be = appropriately
handled at greater length in a separated = draft, a tighter link to the
mechanisms defined in this = draft would be useful.

If you = look at the work you will see that this would imbalance the draft and = then we would have to duplicate it in the other data-plane drafts. Much = better to discuss that in a single place and just call out the = data-plane specific security issues in the data-plane drafts. That way = the critical issues are documented in a way that the reader is less = likely to lose in a sea of familiar text.

Right, but = then this draft should focus on the specific MPLS-DetNet
security = issues and explicitly link particular mechanisms to the
problems. As = it is the securities considerations section of this draft
feels pretty = generic, which is not good. Deviation from RFC3552 should
be very = explicitly noted.

We do point to other drafts. I am sure that = RFC3552 says nothing about a draft being freestanding.

In any case RFC3552 just deals with classic = attacks on best effort networks and so is not a good model for a = security analysis of a dynamic system overlayed on a well established = technology well known for its intrinsic security = properties.

We have references to = other specialist material we are in the process of publishing, so I = think that all that is required is a sentence saying that this = technology must be deployed over a well managed MPLS = network.

Best regards

Stewart.




It's very likely these have been = discussed in the detnet wg at length as
evidenced by the = security considerations, but I'd like to see the MPLS draft
reflect some of that conversation more directly.

I would ask you to reflect on the = discussion above. If you need any help understanding MPLS and = Pseudowires (which are fundamentally assumed knowledge that anyone = deploying this technology would have) I can provide you with some = pointers to background reading.

Best = regards

Stewart






-- 
"Man is born = free, but everywhere he is in chains".
--Rousseau.

= --Apple-Mail=_7CCE0078-0C2F-4820-BE5D-208964F2047E-- From nobody Wed Mar 11 19:29:48 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548E23A0766; Wed, 11 Mar 2020 19:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 XzeIrxAiI0EM; Wed, 11 Mar 2020 19:29:45 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 02EFB3A0755; Wed, 11 Mar 2020 19:29:44 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id q10so3447543lfo.8; Wed, 11 Mar 2020 19:29:44 -0700 (PDT) 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=2jOReqRALxHXkPED2FxK1wwo0TvGecfrDFmwsp4F0Mg=; b=LcNRz/sPgu/eIFkIJ1DjzPmgrBX6wiq8yCF6xomo6ujqEo5l84MLT6Y4fRUoAcN6+i 7GpSVCgiBZBptHTgvwVkiSeRM5X9ndJ2fvgzJp+jnLEyTeGKxHpg2FeMO7x5jutnccDw A9rGlxTMBGVGUBARO9lRCqQ+Ab0ZkIY/wdqS6pqhJXPcG2a/Pf8c3t/xuQFafCZ2EQ/a 1jCHBgW/v8Z69O29ZGEC80z99hl2FZuirFG7lNEr49vkheXiwwty453+nt2nmIXpuTt7 pTYU9A1JjJEzGe/zCEbM8TBUbN9a6pOaI6QALAd5gDwQvKbFB8wFPo+C2LKZegcUd3yb b+UA== 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=2jOReqRALxHXkPED2FxK1wwo0TvGecfrDFmwsp4F0Mg=; b=Qzii54Ii0IbhblbiJyeCr1sED2nB3QNOcSqsNRFdQws7Ixs8zcvhVAMHYftcYK+NO9 8GMBgbUPFG+2pWqiP03A//xiwfA+L0XljPlzljgkX3DRDH8WFrsfiMudRlPaoxhEgA7u oqcXhyAvqnZGJAqvCyHFIKyAT/XloxGzTV5UbU65DLfdXANB0omXdD0U+5maM6bgND38 u/1CDEnDPCv5eBMOkV5feQ2mUtfAvY4rSsQKVMKgu3jYV6f4ShGNF16+Btubo4rJ4l/t RI4VkA9+Btw6TbC2YcEcQOwXrDMRUGCNJWhB/kxrQ+bKZ3eMhDwoLLgND0ZdDc7WaRtM Xc1Q== X-Gm-Message-State: ANhLgQ1FRJWei0fnyrSz1TkJT/fJUtl8GEU7iTWFaPKfjXEPxkr+KQtY gI+NLUDd0Ozew0Ja+YpDmiGsfP+U+jCfhgR82nk= X-Google-Smtp-Source: ADFU+vsTo6e0DQ7TC/AU8O72+/uF3faJK1HWjpuFWp6Gw2gTqAS4fRD1yXehL+BoqN1HB5iFpONpj/S7Ud4TgvM/HT4= X-Received: by 2002:ac2:4906:: with SMTP id n6mr3824501lfi.163.1583980183014; Wed, 11 Mar 2020 19:29:43 -0700 (PDT) MIME-Version: 1.0 References: <158389693039.16158.6977515080330200081@ietfa.amsl.com> <137FCA36-3B7C-46EB-B951-3FDC01560069@gmail.com> In-Reply-To: <137FCA36-3B7C-46EB-B951-3FDC01560069@gmail.com> From: Watson Ladd Date: Wed, 11 Mar 2020 19:29:31 -0700 Message-ID: To: Stewart Bryant Cc: secdir , DetNet WG , draft-ietf-detnet-mpls.all@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-detnet-mpls-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 02:29:46 -0000 I don't see any reason why RFC 3552's guidelines shoudn't apply to this draft. If there is a MPLS exception I'd like to see the rules that should be applied. As is I don't see any reason why the assumptions can't be explicitly spelled out, either in the Security Considerations or elsewhere. From nobody Thu Mar 12 04:05:09 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64DDC3A0D32; Thu, 12 Mar 2020 04:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 RyGE0twYwiy4; Thu, 12 Mar 2020 04:04:57 -0700 (PDT) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 9CBA43A0D3D; Thu, 12 Mar 2020 04:04:56 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id n8so5594082wmc.4; Thu, 12 Mar 2020 04:04:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jixXKzmXBUy+qeJEImdDesq2ql0Ka4VGHz3NMx1XLic=; b=MJOGtKywly2NxaTxNV9WdeRpF4Hiw04fpJFesZhrBiZYf/rQ1RbSI7IDXXhWBUYHwg v6Ln3mQwBMf95JFsnEzX3pb3O8/+QpuDtSe9vjhyWWSITqnGzaRGOJ4iYcM9FK/YPYsO +8ar4ewROTwpnQ39EGinN0ZwIlCrRyIPpLbSDWbuun7NOLsLoub6OwDwZYeeEc4BwuWM E2DQZqyRho2+tEP2fbbFGx0+p/PMQBs92HBZEZYTGgzVMHzGWxj8+V9GB5SmFRLF+3Xy tl+iskwRT1JFk/AHNAGQXHgln80ttHoCbijupHE0p+T5KEzP3Q+QTzZj1m8ncXgOsYYm QagA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jixXKzmXBUy+qeJEImdDesq2ql0Ka4VGHz3NMx1XLic=; b=lkj8PHq2pfHya852hdc1tfXJbcYrWMscUP93ZzSWUKdcbBP7lROLcyaRJ7myvTcwQp ryR34VqfNpfcmJHw2/o8t4Z2tdQRMoPx0hkEcI97gDgzOAt63lFgCO66wr651DRF2OBf N2EvdKg83286J0VwJ+gYGSa0I0hZwOztEIkxDlxzesayqmuWfem8YVagUrRfVGf8ZpGC ivwi82FU5osAQqJ6Po/KCVg4+CmtdoPuFkufpCk+49xdcvdm7ju70Vnj7A1Rk0BF8BKj VoSDX50V1fUYJenU7JEfCdm2XAX5O47TBt+6zPChCHXLmQipn6LPaIbzhqjFTbsvhMMb DQ4g== X-Gm-Message-State: ANhLgQ3p5dNuXcVwfA7j8lIoBfjrf8b4cb4x6tJTYjIkl7tXxX1KUZj2 gKo90hha7bU8FB1MI+nvPmOACHz7 X-Google-Smtp-Source: ADFU+vstwzX/07zZRx0yowLctF4QKuOZ3C1zCJL9IjgyOuiBfW62qloaVSxsNgjex37dARX975flCw== X-Received: by 2002:a1c:6a16:: with SMTP id f22mr4206479wmc.53.1584011094872; Thu, 12 Mar 2020 04:04:54 -0700 (PDT) Received: from broadband.bt.com ([2a00:23a8:4140:0:a0a7:a4c5:a18b:5118]) by smtp.gmail.com with ESMTPSA id t187sm12467632wmt.25.2020.03.12.04.04.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Mar 2020 04:04:54 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Stewart Bryant In-Reply-To: Date: Thu, 12 Mar 2020 11:04:52 +0000 Cc: Stewart Bryant , secdir , DetNet WG , draft-ietf-detnet-mpls.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <158389693039.16158.6977515080330200081@ietfa.amsl.com> <137FCA36-3B7C-46EB-B951-3FDC01560069@gmail.com> To: Watson Ladd X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-detnet-mpls-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 11:05:07 -0000 > On 12 Mar 2020, at 02:29, Watson Ladd wrote: >=20 > I don't see any reason why RFC 3552's guidelines shoudn't apply to = this draft. No you mis the point. The underlay (MPLS) is resilient to the level required by RFC3552 so = that really is out of scope because we are not describing MPLS itself = but what in MPLS terminology is an application running over MPLS. As far as I can see the RFC3552 view of security was the necessary = security to be applied to a best effort service. The types of attack that very few people have experience of is dynamic = attacks. The only people that have experience of them, and I am sure you = know, are people doing time transfer. Now I think that this is largely = an unsolved problem, particularly with fine grained timing. I have = worked on systems where this has accidentally occurred (two 1588 streams = with different clocks beating), but this sets a floor on the lower = deterministic delay bound and as I noted earlier DN is not looking for = min delay, just a delay floor. However that is not really a security problem, it is an operational = performance problem. >=20 > If there is a MPLS exception I'd like to see the rules that should be = applied. >=20 > As is I don't see any reason why the assumptions can't be explicitly > spelled out, either in the Security Considerations or elsewhere. We can certainly note that we assume that DN over MPLS will be run over = a well managed MPLS network if that helps. If you have explicit suggestions for text we will look at them. - Stewart From nobody Thu Mar 12 04:08:08 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3CF3A0C68 for ; Thu, 12 Mar 2020 04:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.362 X-Spam-Level: X-Spam-Status: No, score=-3.362 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tt9522tsfJHf for ; Thu, 12 Mar 2020 04:08:05 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 414AD3A09BB for ; Thu, 12 Mar 2020 04:08:01 -0700 (PDT) Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 33A501E1E7D for ; Thu, 12 Mar 2020 05:07:59 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id CLh0jHTj4ZuymCLh0jllWD; Thu, 12 Mar 2020 05:07:59 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.3 cv=Bcv2LIl2 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10:nop_charset_1 a=SS2py6AdgQ4A:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=8Thv01DKMWluz4qxGx8A:9 a=CjuIK1q_8ugA:10:nop_charset_2 a=rKrVYePj7rwA:10:demote_shortener_domain_2 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=GUx3nu854t6PGLD2PVg9uJGj3vmFZVYAxU+wNOoRg90=; b=AYlERUhXb8Ix6fbsJiftRwzxdA OUePJhGTAOKJg1iNbxZBAmEIpgtIDRmMC2OdvRVXnOI74cOEc0E2/OFAb/2vXFdlu1MUbc1DRhNJi xgX7HYemqxkZU9Yk2A6oJPieH; Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:41370 helo=[11.5.0.140]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1jCLh0-002UM0-3e; Thu, 12 Mar 2020 05:07:58 -0600 From: Lou Berger To: Watson Ladd , Stewart Bryant CC: , DetNet WG , secdir Date: Thu, 12 Mar 2020 07:07:55 -0400 Message-ID: <170ce6deaf8.277b.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: References: <158389693039.16158.6977515080330200081@ietfa.amsl.com> <137FCA36-3B7C-46EB-B951-3FDC01560069@gmail.com> User-Agent: AquaMail/1.22.0-1511 (build: 102200004) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 72.66.11.201 X-Source-L: No X-Exim-ID: 1jCLh0-002UM0-3e X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net ([11.5.0.140]) [72.66.11.201]:41370 X-Source-Auth: lberger@labn.net X-Email-Count: 1 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 11:08:06 -0000 Watson, Can you provide context here? Can you be explicit on what you see needs to be addressed (beyond what is in this document as well as related rfcs)? Thank you, Lou ---------- On March 11, 2020 10:30:27 PM Watson Ladd wrote: > I don't see any reason why RFC 3552's guidelines shoudn't apply to this draft. > > If there is a MPLS exception I'd like to see the rules that should be applied. > > As is I don't see any reason why the assumptions can't be explicitly > spelled out, either in the Security Considerations or elsewhere. > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > From nobody Thu Mar 12 18:15:38 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D44B63A0C7D; Thu, 12 Mar 2020 18:15:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: Cc: draft-ietf-detnet-ip.all@ietf.org, last-call@ietf.org, detnet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.120.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158406212471.18347.14473548719649982992@ietfa.amsl.com> Reply-To: Tero Kivinen Date: Thu, 12 Mar 2020 18:15:24 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-detnet-ip-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2020 01:15:25 -0000 Reviewer: Tero Kivinen Review result: Has Nits In section 1 there is text saying: The DetNet Architecture models the DetNet related data plane functions as two sub-layers: functions into two sub-layers: a service sub-layer and a forwarding sub-layer. I think the second one of the "functions as/into two sub-layers" instance should be removed. In section 5.1.2.2 it says that SPI field of the ESP and AH is used, but in case the IPsec is configured to use UDP encapsulation (rfc3948, i.e., UDP destination port is 4500) there is different location for the SPI. Should this document also dig SPI out from the UDP encapsulated ESP/AH? There is also wrapped ESP (rfc5840) with bit different format, i.e., having wrapped ESP header before the normal ESP header. Should this be included also? In section 6, I would think it would be useful to have wildcard SPI matching too, i.e., match all ESP/AH traffic between two hosts regardless of SPI. Note, that standard procedure to support QoS in IPsec is to create multiple SAs between hosts with identical addresses, but different SPI, and where each flow has traffic related to one QoS level inside, but there might not be any way for external user to know which SPI match to which QoS level). So there is definitely need to have exact match SPI, but problem is that DetNet might not have any visibility which SPI match witch QoS level. From nobody Thu Mar 12 18:36:11 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B34E3A0CF1; Thu, 12 Mar 2020 18:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 PLYNI8nmehVj; Thu, 12 Mar 2020 18:36:07 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4158D3A0CF0; Thu, 12 Mar 2020 18:36:07 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id f13so8741276ljp.0; Thu, 12 Mar 2020 18:36:07 -0700 (PDT) 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=7l7IZ5kkXUgooqAg7Wnl9Ty+5/xT9/XiD8Knc0Bi4pE=; b=NGPujv7OIR0D/W5zU9u8Hr5jzj/EL7iJR/Fkyx6L7hp2LXrOby9QADv+mh31kwX4Lx f97bBkY6IQAXrAW9zvfA2N6S4QAkMSHpkUrLuPAbE95z7pekvxegYIrxdMa+Wur3v2P7 z3Unp/+WiJro8JBy+6qQrPawX0wH8SAWm8KPr/KG1ukUAO0jAfwID2jEfEu05cjxMEZa t2wzwWgf4q05X9tAK7PooNT99dKLBzFtl+HC3oLSftUpncmrhjsk75sOunezAnv8dIzv NBPDId19Ll/hT0b9qCJqw3bDMFSSvpxSswidWyCJS8JZ4Oi7NBPHE97QpqPv95hXUTWf zKow== 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=7l7IZ5kkXUgooqAg7Wnl9Ty+5/xT9/XiD8Knc0Bi4pE=; b=gG0BvFEAxOQyVnV/B9PSFba1qk/c9o5u4kZvZ0cZciFzryW/ps1VJAMW8qg2mxSnIO ZLa4xGpHwoVe1EnoM+vomf1gYzx2DmK5Qoklz4TiuCCfQletI/X6Hnggx9lJm27xMtd8 FkGBpBr68xj1N0cNHyVASLUXm5XX/jGuoH8Or1+HYkigSDu9gpl0fokf9q8U5xLpCXcE fEnVV2uYtk/tUyc5NJ+sVuxCYqFG76BDgUWgaTGvBGhbBASrgW5X6DAWjUfC5zXxz/5P EwlJMFbRKPBU8io4dcoGzFCa8ge4RMnGneElwjTCg10bhC4O+fQAoaTSfasG0Cb5O1cy 1kbg== X-Gm-Message-State: ANhLgQ2OCsSpwKAXBT9+82T+B6AoTKa5NSCU75karaOawbqF1QUUz7lK DLu+YuuRNKfJttPD5O8JjgHwYPANl/3jIaE5y+zogXYv X-Google-Smtp-Source: ADFU+vt0q0P1Leo41lBYNhie290JJyyqhVNJiT71GtUTjyNFUbC4nV1+W0syFZ4/QaboWM/enJWlaCpZ9Q/seTtqv4M= X-Received: by 2002:a2e:a312:: with SMTP id l18mr6834786lje.229.1584063365151; Thu, 12 Mar 2020 18:36:05 -0700 (PDT) MIME-Version: 1.0 References: <158389693039.16158.6977515080330200081@ietfa.amsl.com> <137FCA36-3B7C-46EB-B951-3FDC01560069@gmail.com> <170ce6deaf8.277b.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <170ce6deaf8.277b.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> From: Watson Ladd Date: Thu, 12 Mar 2020 18:35:53 -0700 Message-ID: To: Lou Berger Cc: Stewart Bryant , draft-ietf-detnet-mpls.all@ietf.org, DetNet WG , secdir Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2020 01:36:10 -0000 On Thu, Mar 12, 2020 at 4:07 AM Lou Berger wrote: > > Watson, > > Can you provide context here? Can you be explicit on what you see needs to > be addressed (beyond what is in this document as well as related rfcs)? You have to talk about how the layers interact, and can't just say the lower level handles anything without any guide as to what needs to be provided by that lower layer. I think my concerns about the assumptions this could be fixed by saying. "All nodes are trusted and any of them can misbehave in ways that affect the network. If the MPLS layer cannot provide sufficient determinism, then the DetNet mechanisms won't work". I agree we shoudn't require an entire massive security framework to be quoted again here, but there must be some details of this embedding that are worth noting, and yet I don't see them called out in the security considerations section. Are there really no specific concerns about the interaction between DetNet and MPLS? > > Thank you, > Lou > > > ---------- > On March 11, 2020 10:30:27 PM Watson Ladd wrote: > > > I don't see any reason why RFC 3552's guidelines shoudn't apply to this draft. > > > > If there is a MPLS exception I'd like to see the rules that should be applied. > > > > As is I don't see any reason why the assumptions can't be explicitly > > spelled out, either in the Security Considerations or elsewhere. > > > > _______________________________________________ > > detnet mailing list > > detnet@ietf.org > > https://www.ietf.org/mailman/listinfo/detnet > > > > -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Thu Mar 12 19:03:04 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F493A0D68 for ; Thu, 12 Mar 2020 19:03:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.120.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <158406498253.18304.14195153060899450474@ietfa.amsl.com> Date: Thu, 12 Mar 2020 19:03:02 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2020 02:03:03 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2020-03-12 Reviewer LC end Draft Dan Harkins 2020-03-06 draft-ietf-alto-incr-update-sse-20 For telechat 2020-03-19 Reviewer LC end Draft Donald Eastlake 2020-02-27 draft-ietf-6tisch-msf-12 Charlie Kaufman 2020-02-20 draft-ietf-lpwan-coap-static-context-hc-13 David Waltermire 2020-02-25 draft-ietf-6man-icmp-limits-07 For telechat 2020-04-09 Reviewer LC end Draft John Bradley 2020-02-28 draft-ietf-regext-data-escrow-05 Donald Eastlake R2019-11-14 draft-ietf-hip-dex-14 Last calls: Reviewer LC end Draft John Bradley 2020-02-28 draft-ietf-regext-data-escrow-05 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-09 Donald Eastlake R2019-11-14 draft-ietf-hip-dex-14 Donald Eastlake 2020-02-27 draft-ietf-6tisch-msf-12 Daniel Franke 2020-03-09 draft-ietf-regext-dnrd-objects-mapping-06 Dan Harkins 2020-03-06 draft-ietf-alto-incr-update-sse-20 Leif Johansson 2020-02-28 draft-ietf-tcpm-converters-18 Charlie Kaufman R2019-09-02 draft-ietf-ecrit-data-only-ea-22 Charlie Kaufman 2020-02-20 draft-ietf-lpwan-coap-static-context-hc-13 Scott Kelly 2020-03-18 draft-ietf-sidrops-ov-egress-01 Chris Lonvick 2020-03-13 draft-ietf-detnet-data-plane-framework-04 Aanchal Malhotra 2020-03-12 draft-ietf-bess-vpls-multihoming-05 David Mandelberg 2020-04-02 draft-ietf-core-stateless-05 Catherine Meadows 2020-04-02 draft-ietf-dnsop-extended-error-14 Daniel Migault 2020-03-31 draft-ietf-dnsop-multi-provider-dnssec-04 Adam Montville 2020-03-31 draft-ietf-core-resource-directory-24 Kathleen Moriarty 2020-03-20 draft-ietf-sidrops-rp-06 Russ Mundy 2020-01-02 draft-ietf-dprive-bcp-op-08 Sandra Murphy 2019-10-04 draft-ietf-mpls-ldp-yang-06 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-11 Vincent Roca 2020-01-30 draft-ietf-pim-msdp-yang-16 Takeshi Takahashi 2020-02-06 draft-ietf-mmusic-t140-usage-data-channel-11 Tina Tsou 2020-02-06 draft-ietf-6lo-backbone-router-19 Sean Turner None draft-ietf-opsawg-sdi-02 Carl Wallace R2018-02-26 draft-ietf-hip-native-nat-traversal-30 David Waltermire 2020-02-25 draft-ietf-6man-icmp-limits-07 Dacheng Zhang 2020-03-12 draft-nottingham-how-did-that-get-into-the-repo-01 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Next in the reviewer rotation: Russ Mundy Sandra Murphy Yoav Nir Magnus Nystrom Hilarie Orman Francesca Palombini Radia Perlman Derrell Piper Tirumaleswar Reddy.K Vincent Roca From nobody Thu Mar 12 23:10:37 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349893A1171; Thu, 12 Mar 2020 23:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 AWBDOKelQcSC; Thu, 12 Mar 2020 23:10:32 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-oln040092004072.outbound.protection.outlook.com [40.92.4.72]) (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 448E53A116E; Thu, 12 Mar 2020 23:10:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RJRJDUju9Vg8k16xc3cyyXC1z2brO+zntrPD/JUyM5U3yZwalzEa2+0FrF3GVp39JOgnZy+y8vlX/MXgkR31Ljt1Q2wAI2ceGf2Kfm+G9D5f2OGu6yTzrHa/epD5r4Egz7HWHqeZgYgA7hHjGNlxq00zUrgiqsyqlURaKABCGrEGYBBv3uFAqHuY4SiZLhwI0qf1XsMKIsuu8i0jAexq+VhSEpxpnjiNcgVgp1u6zytFfs9HrlOMS9+KH5Kdsd/QFsZ++Th3oyHqJXzRvyusYquvmebW252KBYs/P9JA/dK+bGswCoa3FtO7watDnsVEHA3T4URwoB7859iPBuyCdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=v80Sb5utK6cdiDHAGrWccBu9TCZAs75L4/lm3it+mng=; b=oCzoien8qPFk42OEXLznEcaNdtQCiu7dw0cstQVVRqP3qCXNmeqxOSEmWzK+lKd3l5vjMUqonhPBUF5CoG08EFiojt93nUvyxIgwEc6Gzwuq8RKSXGSLzaIG47RcvozxNNMblMe69lDIYRHUhWCb7jf88i9HIpk+7vUuypAPhXIJdpqka58CiAWMEYhZ4DHfrTeoMi8J+Pdtn5ZvEOfCEMGWCOPhOpcc480d/G8G2hrzfy9Ieo+W9H1fR6q37jfSoGJuwPCqJJpKOvU20aBl/1h9eVuLyuDGgWZkx1B7+4NI0nQ++uDJvpAJH2J9EvvOF8stEKG6J6FXukC+hLIsAw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=v80Sb5utK6cdiDHAGrWccBu9TCZAs75L4/lm3it+mng=; b=k+VmI90Xm3U6xS3g9L9Ka8DycDMu1KQfbO9cTWVj2ySDvyHvgsdMDe7uHv7orHWqpr4O9hRm6HJv0SinLhaIBnwl44D3df05a37XXfvJKbN7AWAAs59trukBjwGFy8AXjz0QnLUuqHLiN6AllxE/Fo04lGuhdSurUOExmd7B7xhMFE85ilY+8B5x3hK8r/leNWKrycOk3GIyr2F45rbOAsAXNEhHIpQ8yucN+FeJOHVOFmgB+d12jXVWNh6Kiq3P6qb196ktCCywLoM1lShdTOq+XL+NhQopizYAlnz8k8r1fQz0OFMviiC7J4zhQCyCewx5oEi05YRnKrrXZAJy2w== Received: from BL2NAM02FT005.eop-nam02.prod.protection.outlook.com (10.152.76.51) by BL2NAM02HT020.eop-nam02.prod.protection.outlook.com (10.152.77.54) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.13; Fri, 13 Mar 2020 06:10:31 +0000 Received: from MWHPR07MB3022.namprd07.prod.outlook.com (10.152.76.56) by BL2NAM02FT005.mail.protection.outlook.com (10.152.76.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.13 via Frontend Transport; Fri, 13 Mar 2020 06:10:31 +0000 Received: from MWHPR07MB3022.namprd07.prod.outlook.com ([fe80::b8aa:d51:1c05:e5c2]) by MWHPR07MB3022.namprd07.prod.outlook.com ([fe80::b8aa:d51:1c05:e5c2%10]) with mapi id 15.20.2793.018; Fri, 13 Mar 2020 06:10:31 +0000 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-lpwan-coap-static-content-hc.all@ietf.org" Thread-Topic: Secdir review of draft-ietf-lpwan-coap-static-content-hc-13 Thread-Index: AQHV+P3rKcTCZ1P5vEmbTfI320LRuA== Date: Fri, 13 Mar 2020 06:10:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:88410AB0D7EF56E90FBC6BCE823130E2B5792CBEEBBE88EB8EFC4CFA35F800AF; UpperCasedChecksum:535724E2F0CED84D01F733E92319B97AFB94EE5DFAFBA708004AEFF1484C2C48; SizeAsReceived:7031; Count:42 x-tmn: [AhQQU/UO2kUbRL2qvMfqASCQodPkmfXr9psnW2JN3fqOUyot5aLvQClCYb5aWapT] x-ms-publictraffictype: Email x-incomingheadercount: 42 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 9ef06c18-0f0a-4ea6-eeb6-08d7c7153c17 x-ms-traffictypediagnostic: BL2NAM02HT020: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: VeUkWrnWACG2QixhADaMoegj23HneU0D8qGqvxczGsGpp6MW92Qqr5LXHJ3aMyhAXTUgyYSXGZ7pwqpgFM/WMzDhUYn/Sx+0481whp0XaQ67yLixtDtoI1IUR9Gz8ofzSmfieWk1kbkOeyryzjnoPu1DWWwMhGFES+PznPruKSW64YDfKwBU/MR+w0VeHC7l9k16tZC540FX1rU5v9lnsLV9tHYz/RtT5BTAOLHG6es= x-ms-exchange-antispam-messagedata: +xqATIx/smoxHgbVaaO5aMWYU5ga5JNRIYo1d5df/wX1QkfIQ62YoM9pPeUnRMMlKdLWr0doaYyriifhxw+Xfi5HiwnLzJDMXfG8VH/1rAmfvBnTq9qxv2u6vWtr9SwnPTGwZyw9wovluDMxtinu5R9cI0iCPDEMi/l+suEege1MYiV9pKq4BgHrUTCvT8WwMPS5EeBeitNnqOkhtblRyw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MWHPR07MB30229CA068BE628C515653DFDFFA0MWHPR07MB3022namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 9ef06c18-0f0a-4ea6-eeb6-08d7c7153c17 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2020 06:10:31.2196 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2NAM02HT020 Archived-At: Subject: [secdir] Secdir review of draft-ietf-lpwan-coap-static-content-hc-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2020 06:10:34 -0000 --_000_MWHPR07MB30229CA068BE628C515653DFDFFA0MWHPR07MB3022namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This draft defines how SCHC (Static Context Header Compression) should be a= pplied to the CoAP (Constrained Application Protocol). It appears that this= is designed for low end devices speaking standard protocols with a lot of = static content they would like to suppress to avoid wasting processing time= and communications overhead. That means that these devices are likely to b= e generating and parsing the compressed content directly rather than genera= ting the full content and then compressing it. The only security considerat= ions worth noting is that whenever compression is used with a protocol inte= nded to be encrypted (which this one is), the question should be raised as = to whether the compression can be leveraged by an attacker to make traffic = analysis more effective. In this case, I don't believe it can, but there sh= ould probably be an explanation of why in the security considerations. With a compression scheme like Lempel Ziv, the value of some field potentia= lly supplied by an attacker can affect the compression of some other field = potentially containing a secret. This allows traffic analysis looking at th= e lengths of messages containing content supplied by an adversary to reveal= secrets. On the other hand, with a compression scheme like Huffman coding,= fields are compressed independently. This scheme appears to be more like H= uffman; the compression rules are not dynamically adjusted based on variabl= e content. If anything, the compression here seems likely to make traffic a= nalysis more difficult by making messages shorter such that the lengths are= masked by padding. Nits: The acronym CoAP appears 181 times in this document but is never defined/ex= panded except in the references. It probably should be either on first use = or in terminology. The capitalization of certain keywords (e.g., Rule, Residue, Plaintext, Out= er, Header) seems inconsistent. If whether the word is capitalized is inten= ded to convey some meaning to the reader, that should probably be mentioned= somewhere, and in any case the usage should be consistent. "to performs the" -> "to perform the" "might be use" -> "might be used" "knwoledge" -> "knowledge" "to appears" -> "to appear" "length send" -> "length sent" "bits on the SCHC packet" -> "bits in the SCHC packet" "This document does not have any more Security consideration than the ones = already raised on..." ->"This document does not have any security considerations beyond those rai= sed in..." ...except that the security considerations goes on to raise some issues. So= unless those are duplicating ones mentioned in the referenced document, th= e introductory phrase should probably be "These security considerations are= in addition to those raised in ...". --Charlie Sent from Outlook --_000_MWHPR07MB30229CA068BE628C515653DFDFFA0MWHPR07MB3022namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security directorate's on= going effort to review all IETF documents being processed by the IESG. = ; These comments were written primarily for the benefit of the security are= a directors.  Document editors and WG chairs should treat these comments just like any other last call comments.=

This draft defines how SCHC (Static Context Header Compression) should= be applied to the CoAP (Constrained Application Protocol). It appears that= this is designed for low end devices speaking standard protocols with a lo= t of static content they would like to suppress to avoid wasting processing time and communications overhead. = That means that these devices are likely to be generating and parsing the c= ompressed content directly rather than generating the full content and then= compressing it. The only security considerations worth noting is that whenever compression is used with a pr= otocol intended to be encrypted (which this one is), the question should be= raised as to whether the compression can be leveraged by an attacker to ma= ke traffic analysis more effective. In this case, I don't believe it can, but there should probably be an expl= anation of why in the security considerations.

With a compression scheme like Lempel Ziv, the value of some field pot= entially supplied by an attacker can affect the compression of some other f= ield potentially containing a secret. This allows traffic analysis looking = at the lengths of messages containing content supplied by an adversary to reveal secrets. On the other hand, wit= h a compression scheme like Huffman coding, fields are compressed independe= ntly. This scheme appears to be more like Huffman; the compression rules ar= e not dynamically adjusted based on variable content. If anything, the compression here seems likely to mak= e traffic analysis more difficult by making messages shorter such that the = lengths are masked by padding.

Nits:

The acronym CoAP appears 181 times in this document but is never defin= ed/expanded except in the references. It probably should be either on first= use or in terminology.

The capitalization of certain keywords (e.g., Rule, Residue, Plaintext= , Outer, Header) seems inconsistent. If whether the word is capitalized is = intended to convey some meaning to the reader, that should probably be ment= ioned somewhere, and in any case the usage should be consistent.

"to performs the" -> "to perform the"
"might be use" -> "might be used"
"knwoledge" -> "knowledge"
"to appears" -> "to appear"
"length send" -> "length sent"
"bits on the SCHC packet" -> "bits in the SCHC packet&quo= t;

"This document does not have any more Security consideration than= the ones already raised on..."
->"This document does not have any security considerations beyond t= hose raised in..."

...except that the security considerations goes on to raise some issue= s. So unless those are duplicating ones mentioned in the referenced documen= t, the introductory phrase should probably be "These security consider= ations are in addition to those raised in ...".

 --Charlie


Sent from Outlook

--_000_MWHPR07MB30229CA068BE628C515653DFDFFA0MWHPR07MB3022namp_-- From nobody Thu Mar 12 23:16:20 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC163A1183; Thu, 12 Mar 2020 23:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 Rl7wUUzQttim; Thu, 12 Mar 2020 23:16:16 -0700 (PDT) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11olkn2095.outbound.protection.outlook.com [40.92.18.95]) (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 3C4A53A1180; Thu, 12 Mar 2020 23:16:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NpCFxw4Dvc8BqwLP3cTO40Fb2D8Agokz+z1mWEk9Gij/3f6RZbinom56k99dkZMYL1ZUTsVcMIZ7YCa4RqW4FOsCIKhs4XZve0P5/L23ITJr5p/Dut35wx3aAou0hRWuZJHdhQHDyNvssqA6PmZix/hbn1NQQ6rDOoIPx/E2ccSub2jE5FkFTZOf+6ckm5TcwOhKQjqtY3AS2kG5GqmiWK8y1uUt0vv2CNSpirLYQj7lHJumHj7hEHVpLBlaLOEpW7ls30Uksbh7hU7tWJgGUx/m4cS5e/aDFLMwPlCXLPKn6IBwcukzoLkZLJSVD4BKiCdZI/rICSezTwrMFkoC+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3efqxVor3bS1YFHBnfBIDdJfV7ss2kNC1WVxB/r2q7c=; b=IkbiwoAR+eKTnW3XvMV4q9CusgPiSyVl+P4zst5clqqAuvk2iAa2REaIcfSAdKHo+08czkWpgQb+ac59IdAb+OnPXTyTQlzqmQ9n6ULKMUmf4VJlmQ2M6+j0nTiWMv06jTpdeHxELkh3wdiDeFhZ3afFQlH+ZlHCEWNPcgRLL0r9YtbdJ9GsEX+RHVE2aEHnl+ETIQwtw8ASrW0SwUamb0Zjgv3vMuynxvKmYfUH52thpcf7+s4IN2Hc7sizA/7zdO2oYu0uAISOX1+3RSLdgnlDRxRHrUqZZlc6ko1khNpE125+xT5cG/uc49t8KjTzMknJHAo5g8c1ZrtkhdBZ8w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3efqxVor3bS1YFHBnfBIDdJfV7ss2kNC1WVxB/r2q7c=; b=l7quXkHVD+lY/FwqVkNMC5/EGGIZjdTnFSrWOq9+7LOnbKlJfnDimcqWAKJt2pAUfHHmh2G5j1vKbRURed3Dr52raERBCKqaqzvctjXxgt+mxYL/kC3RDwzmdQnJMfaMGXGSBskTRVWUC3Y5Q01tfUuAM5N9HKsF6jXR9PcPx7kk3guxmwhOz7lN0l1jCiKr1+tQ8D0hJENTvuSLHEW2vx/4HU6FwEy6p2Szy3akGzNRclmV3ekjt66x602XaDbWYpccgV0FuVO1yCRGCQHBH1VD4Zg7f64CyfMlEOUI/LBLvbC9MZZ7SRncKAy+ovK1UKPt40Nw0EzrBfrD/Gz7gQ== Received: from DM6NAM11FT015.eop-nam11.prod.protection.outlook.com (2a01:111:e400:fc4d::3c) by DM6NAM11HT253.eop-nam11.prod.protection.outlook.com (2a01:111:e400:fc4d::257) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.13; Fri, 13 Mar 2020 06:16:15 +0000 Received: from MWHPR07MB3022.namprd07.prod.outlook.com (10.13.172.60) by DM6NAM11FT015.mail.protection.outlook.com (10.13.172.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.13 via Frontend Transport; Fri, 13 Mar 2020 06:16:15 +0000 Received: from MWHPR07MB3022.namprd07.prod.outlook.com ([fe80::b8aa:d51:1c05:e5c2]) by MWHPR07MB3022.namprd07.prod.outlook.com ([fe80::b8aa:d51:1c05:e5c2%10]) with mapi id 15.20.2793.018; Fri, 13 Mar 2020 06:16:15 +0000 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-lpwan-coap-static-context-hc.all@ietf.org" Thread-Topic: Secdir review of draft-ietf-lpwan-coap-static-context-hc-13 Thread-Index: AQHV+P7AITANL01nLUOrR6njwCQ0eg== Date: Fri, 13 Mar 2020 06:16:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:638C72B2D6573327C65CED32AD4E42FB9BFF227744A180CD1F5E1F6D20814B23; UpperCasedChecksum:6EC0095C8E9AAA9E668EF0ECF1F03969C2AA0AE32825DA480262D03691928E16; SizeAsReceived:7040; Count:42 x-tmn: [gRgjHYA0gc3oAvMz21XOIIaRHHlZspG5Fv9i+iEv4UgByqdLW2iCtCH2+u7R3v8i] x-ms-publictraffictype: Email x-incomingheadercount: 42 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: c0079185-3536-4dd0-1b07-08d7c7160928 x-ms-traffictypediagnostic: DM6NAM11HT253: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: YVBRaBfuztY+pFboDOSW9nkGDxpVgXpOH7t3yvye5UfJA21FeTwr5G2cyxso2iKiJg/7M8v6fEcCJVlpoLjbhTkJ+FE20V6To27XavPU3n/jhHqbmGPEj6K42fUD1k47IADvUV8CS/WENDsUy/O4HV8r3vzVo9S6v19e82YYlolHiIAfAOa65goTUeJog1zAzAUYu00CtMuFewngSGM/uk3sJ/aSIAHD7HI6uQCI4MM= x-ms-exchange-antispam-messagedata: nBZ8nLioemwTSIB8l+fOERghsYqtHgVzz4EtvH4w6zfgQaEYOzDEqvquZ0kniCD66D0C7A+rR9NVPY2FtJYDiArqApSF1B4ObNoujJYrPTRRvjUYIhCe5cwL//8oxZAo0GoLZvD5IepAkzzQFvM4e+S/uwAsjZQ0XeKZ7X6T+V+Iq0EeMY+DzAemB69Ixi4hgTz7OihZoEBZdNnvei7AfA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MWHPR07MB302285D21D766D07C4358AAEDFFA0MWHPR07MB3022namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: c0079185-3536-4dd0-1b07-08d7c7160928 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2020 06:16:15.2286 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6NAM11HT253 Archived-At: Subject: [secdir] Secdir review of draft-ietf-lpwan-coap-static-context-hc-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2020 06:16:18 -0000 --_000_MWHPR07MB302285D21D766D07C4358AAEDFFA0MWHPR07MB3022namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable **Resend fixing typo in addresses and subject line...*** I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This draft defines how SCHC (Static Context Header Compression) should be a= pplied to the CoAP (Constrained Application Protocol). It appears that this= is designed for low end devices speaking standard protocols with a lot of = static content they would like to suppress to avoid wasting processing time= and communications overhead. That means that these devices are likely to b= e generating and parsing the compressed content directly rather than genera= ting the full content and then compressing it. The only security considerat= ions worth noting is that whenever compression is used with a protocol inte= nded to be encrypted (which this one is), the question should be raised as = to whether the compression can be leveraged by an attacker to make traffic = analysis more effective. In this case, I don't believe it can, but there sh= ould probably be an explanation of why in the security considerations. With a compression scheme like Lempel Ziv, the value of some field potentia= lly supplied by an attacker can affect the compression of some other field = potentially containing a secret. This allows traffic analysis looking at th= e lengths of messages containing content supplied by an adversary to reveal= secrets. On the other hand, with a compression scheme like Huffman coding,= fields are compressed independently. This scheme appears to be more like H= uffman; the compression rules are not dynamically adjusted based on variabl= e content. If anything, the compression here seems likely to make traffic a= nalysis more difficult by making messages shorter such that the lengths are= masked by padding. Nits: The acronym CoAP appears 181 times in this document but is never defined/ex= panded except in the references. It probably should be either on first use = or in terminology. The capitalization of certain keywords (e.g., Rule, Residue, Plaintext, Out= er, Header) seems inconsistent. If whether the word is capitalized is inten= ded to convey some meaning to the reader, that should probably be mentioned= somewhere, and in any case the usage should be consistent. "to performs the" -> "to perform the" "might be use" -> "might be used" "knwoledge" -> "knowledge" "to appears" -> "to appear" "length send" -> "length sent" "bits on the SCHC packet" -> "bits in the SCHC packet" "This document does not have any more Security consideration than the ones = already raised on..." ->"This document does not have any security considerations beyond those rai= sed in..." ...except that the security considerations goes on to raise some issues. So= unless those are duplicating ones mentioned in the referenced document, th= e introductory phrase should probably be "These security considerations are= in addition to those raised in ...". --Charlie Sent from Outlook --_000_MWHPR07MB302285D21D766D07C4358AAEDFFA0MWHPR07MB3022namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
**Resend fixing typo in addresses and subject line...***

I have reviewed this document as part of the security directorate's on= going effort to review all IETF documents being processed by the IESG. = ; These comments were written primarily for the benefit of the security are= a directors.  Document editors and WG chairs should treat these comments just like any other last call comments.=

This draft defines how SCHC (Static Context Header Compression) should= be applied to the CoAP (Constrained Application Protocol). It appears that= this is designed for low end devices speaking standard protocols with a lo= t of static content they would like to suppress to avoid wasting processing time and communications overhead. = That means that these devices are likely to be generating and parsing the c= ompressed content directly rather than generating the full content and then= compressing it. The only security considerations worth noting is that whenever compression is used with a pr= otocol intended to be encrypted (which this one is), the question should be= raised as to whether the compression can be leveraged by an attacker to ma= ke traffic analysis more effective. In this case, I don't believe it can, but there should probably be an expl= anation of why in the security considerations.

With a compression scheme like Lempel Ziv, the value of some field pot= entially supplied by an attacker can affect the compression of some other f= ield potentially containing a secret. This allows traffic analysis looking = at the lengths of messages containing content supplied by an adversary to reveal secrets. On the other hand, wit= h a compression scheme like Huffman coding, fields are compressed independe= ntly. This scheme appears to be more like Huffman; the compression rules ar= e not dynamically adjusted based on variable content. If anything, the compression here seems likely to mak= e traffic analysis more difficult by making messages shorter such that the = lengths are masked by padding.

Nits:

The acronym CoAP appears 181 times in this document but is never defin= ed/expanded except in the references. It probably should be either on first= use or in terminology.

The capitalization of certain keywords (e.g., Rule, Residue, Plaintext= , Outer, Header) seems inconsistent. If whether the word is capitalized is = intended to convey some meaning to the reader, that should probably be ment= ioned somewhere, and in any case the usage should be consistent.

"to performs the" -> "to perform the"
"might be use" -> "might be used"
"knwoledge" -> "knowledge"
"to appears" -> "to appear"
"length send" -> "length sent"
"bits on the SCHC packet" -> "bits in the SCHC packet&quo= t;

"This document does not have any more Security consideration than= the ones already raised on..."
->"This document does not have any security considerations beyond t= hose raised in..."

...except that the security considerations goes on to raise some issue= s. So unless those are duplicating ones mentioned in the referenced documen= t, the introductory phrase should probably be "These security consider= ations are in addition to those raised in ...".

--Charlie


Sent from Outlook

--_000_MWHPR07MB302285D21D766D07C4358AAEDFFA0MWHPR07MB3022namp_-- From nobody Fri Mar 13 05:41:37 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53AD53A1739; Fri, 13 Mar 2020 05:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 9ZoYtzimtLpz; Fri, 13 Mar 2020 05:41:28 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 6D1133A1738; Fri, 13 Mar 2020 05:41:22 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id 6so9761406wmi.5; Fri, 13 Mar 2020 05:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uaW3zio8OnAbYpY38vKuXoqUF+Orl6fkl80B5tbhoSg=; b=popldn4E/SexRagI2AzPBiyRlCL3gVCJ1wR186nErW2P/IAZh577RMGvhphmn7Yo+v 6o27eztGT6sJHpNN00aokjZpWePMCMZW7CKvibDUV+mqWMosw8CaiKGwMHURbXjdHhwh nI3ThLRgyFcfOBdr7u1Zzblsc2vGsqQdc8FsowG/191TUqQKGtOK0oMLiHaZy4WfdZh1 S+dnqhmkIOtpNHvdiACrDZG4d+KWTtUwhy8mR3G3stU8KKkTLVwjMZt/6ihvbVEojkGf 1RqvdHnIREjIoLDsOnQvUMgMIIOZAeSfAQyM+HiRNeDgj0+x9v+tSpca8cYrNnmX7Jzq BVFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uaW3zio8OnAbYpY38vKuXoqUF+Orl6fkl80B5tbhoSg=; b=QsF8pLN9kF8G+FY+I9gEL80m2WCyzx/XC8KDKar0qOHvCfTr9wCAQxKvdQl8zGnlyU 8Yc30vSsmSsCGGORvK/DIMKe43IKu/Cmkz6GuVbvg3MAnx291mYINtJIF12lRxp/urpH Hq0rSPBdI6uqZ7+0BmzcvjpO+Epp7In+KJSTgpJ2Y3RVTW3Rb4/uJuIqglHuoB6qy3QC FUJIdVLze6SGjXnyIIZp1MVWXotrKmsmM219yCqRTpmsNhuLJDJLY/IdgcuSyNnLdoi+ n+yQkKHtv37P2dIeMcBhDIKi1IN1rpmsdDCV9LL2VeQzzMObwlR7/KUy3Fg6RiRpRKa+ Bdzw== X-Gm-Message-State: ANhLgQ2pAFGdAefhcE+yXd45C6YYPJb0MBaXamXuB77OI51QrSm8GWfJ wVGsApEfjFVDFO9Lc5Mq7R4= X-Google-Smtp-Source: ADFU+vvFdFYyPYgZ2Lw4OzjKHcWQWRCClhjBlwfQnjTsoTriu59b8k2H1ZtsTGqV9hfZsDlzpJnmkw== X-Received: by 2002:a05:600c:2306:: with SMTP id 6mr10619931wmo.86.1584103280685; Fri, 13 Mar 2020 05:41:20 -0700 (PDT) Received: from appleton.fritz.box ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id r9sm9752654wma.47.2020.03.13.05.41.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Mar 2020 05:41:16 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Stewart Bryant In-Reply-To: Date: Fri, 13 Mar 2020 12:41:15 +0000 Cc: Stewart Bryant , Lou Berger , draft-ietf-detnet-mpls.all@ietf.org, DetNet WG , secdir Content-Transfer-Encoding: quoted-printable Message-Id: <7E8B0875-79F6-4FDB-AD59-29A192C723BC@gmail.com> References: <158389693039.16158.6977515080330200081@ietfa.amsl.com> <137FCA36-3B7C-46EB-B951-3FDC01560069@gmail.com> <170ce6deaf8.277b.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> To: Watson Ladd X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2020 12:41:32 -0000 > On 13 Mar 2020, at 01:35, Watson Ladd wrote: >=20 > On Thu, Mar 12, 2020 at 4:07 AM Lou Berger wrote: >>=20 >> Watson, >>=20 >> Can you provide context here? Can you be explicit on what you see = needs to >> be addressed (beyond what is in this document as well as related = rfcs)? >=20 > You have to talk about how the layers interact, and can't just say the > lower level handles anything without any guide as to what needs to be > provided by that lower layer. >=20 > I think my concerns about the assumptions this could be fixed by > saying. "All nodes are trusted and any of them can misbehave in ways > that affect the network. =20 That is a fundamental assumption of all routers, so there really is no = need to state it. As I said earlier, a practical solution to the byzantine routing problem = was proposed by Radia about 30 years ago and there is zero interest in = it because the trust assumption is fundamentally ingrained in the = routing architecture, and so far it has been well founded. > If the MPLS layer cannot provide sufficient > determinism, then the DetNet mechanisms won't work". =20 That is kind of fundamental to the point where I am also not sure it = needs to be stated, and if it does need to be stated then it needs to go = up the tree in one of the fundamental documents, not each of the = data-plane documents (there are quite a few such documents). > I agree we > shoudn't require an entire massive security framework to be quoted > again here, but there must be some details of this embedding that are > worth noting, and yet I don't see them called out in the security > considerations section. Is this about showing that we have done something to prove that we take = security seriously, or is it about giving practical advice to someone = deploying the technology. Hopefully the later, in which case I think = this is well covered by the DetNet context and the MPLS documents, all = of which the reader can be assumed to be familiar with. >=20 > Are there really no specific concerns about the interaction between > DetNet and MPLS? There are MPLS service requirements and expectations. However I don=E2=80=99= t think there is an interaction per se. It is as I already said about pseudowires. If the performance of this = approach is not good enough, then spend the money and buy a dedicated = physical network. - Stewart >=20 >>=20 >> Thank you, >> Lou >>=20 >>=20 >> ---------- >> On March 11, 2020 10:30:27 PM Watson Ladd = wrote: >>=20 >>> I don't see any reason why RFC 3552's guidelines shoudn't apply to = this draft. >>>=20 >>> If there is a MPLS exception I'd like to see the rules that should = be applied. >>>=20 >>> As is I don't see any reason why the assumptions can't be explicitly >>> spelled out, either in the Security Considerations or elsewhere. >>>=20 >>> _______________________________________________ >>> detnet mailing list >>> detnet@ietf.org >>> https://www.ietf.org/mailman/listinfo/detnet >>>=20 >>=20 >>=20 >=20 >=20 > --=20 > "Man is born free, but everywhere he is in chains". > --Rousseau. From nobody Fri Mar 13 06:26:11 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218BC3A03F1; Fri, 13 Mar 2020 06:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 LfgAyMKj2Mun; Fri, 13 Mar 2020 06:26:04 -0700 (PDT) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 02E3F3A0363; Fri, 13 Mar 2020 06:26:03 -0700 (PDT) Received: by mail-ot1-x335.google.com with SMTP id j16so10044557otl.1; Fri, 13 Mar 2020 06:26:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=sxvP/GH2j11AVsDNePpq5DZsMQYebde03Bl3Zq40lms=; b=QlQBaF9oMsFkevoFlNk+48m+BdOZPr0GmR7M7Z0hThKeUOSmxNUnVyoc0GeR161RCR x62f7pKGkFpvAKjCuJnRQkkRDybiziTeA122Zz96y0g3j/kguJP+ar5dXqWXYqCIIfpJ Ff3MzIeIIeTHdSIzLCHjuZavlpDR7rFZGyo05paXASTL5hFokHsFWRAMJTt928LDi4mM 2tRftjGlLM8xYQoeOuW7kvk8QTc3qfXqiO/A1bimIUnYHZiq56zeFb/BPzROcayhzOj0 ocaZ0kNlno1mpooLlkip/LMRWwCXS7HbYE6HVVQUmcWXt4Y/HL43lKeifWHUaq5IoHJc OLig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=sxvP/GH2j11AVsDNePpq5DZsMQYebde03Bl3Zq40lms=; b=nnR/rzUg64jQmD9EFDzACTwKqcy/Dx4fsJ13lsyXuIAKrjSkAUNTU/LC2e9d6Wu62f rvJBuDfjlEV9/VjYnvzRb0z70nCuVCvcYydlmSawqjVJE6e5Nj4x+brxyvBUn9STkWrh ydkSb+Uvpwu3mQaUP9Lk5fGxgxjUygASObJ6l/cxo8YNmPCWYZVkz5B5bSge1dw0YLxv zji9sm80pOSnoDKuldqWwlkX3lzVpZPEkVIjj6kvXfZL3E64GjuzQQwEDq7SEqsRTKVC +s6JZ5/9I/MOJZlWTF977x/a4iOuM5hpoSorQDFag2WG2pFS3jopc3Y1bhxy7fVo947Q jfyQ== X-Gm-Message-State: ANhLgQ12pftF+mzuUeG2qrRiVXagA8VrTjllaJr/e4f77D6+ZbuG0bL7 GV//+nkSk5PBXVkrJh2Xu4GTWS25 X-Google-Smtp-Source: ADFU+vtqkw3wXCp59V5uiflwIYT8/4CaLIdma0JkrFTSFEsQn4OZCNnikA1bYhhw2rOFJz9q/tLv4w== X-Received: by 2002:a9d:3f4b:: with SMTP id m69mr10216674otc.146.1584105962960; Fri, 13 Mar 2020 06:26:02 -0700 (PDT) Received: from Chriss-Air.lan (69-4-52-8.dsl.frcn.hctcnetworks.net. [69.4.52.8]) by smtp.googlemail.com with ESMTPSA id r8sm6490564otp.7.2020.03.13.06.26.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Mar 2020 06:26:02 -0700 (PDT) To: raft-ietf-detnet-data-plane-framework.all@ietf.org, "iesg@ietf.org" , "secdir@ietf.org" From: Chris Lonvick Message-ID: <800b9d7a-f510-85a9-b1a0-63ff114c8723@gmail.com> Date: Fri, 13 Mar 2020 08:26:01 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [secdir] SECDIR review of draft-ietf-detnet-data-plane-framework-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2020 13:26:05 -0000 Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready with Issues. The only reason I add the "with Issues" caveat is that the Security Considerations section broadly defers to I-D.ietf-detnet-security. The Security Considerations section of draft-ietf-detnet-data-plane-framework additionally provides some comments that are specific to the draft. I found those to be well thought out and appropriate. I skimmed I-D.ietf-detnet-security and found it to also be well thought out. The threat model was clear and understandable and the document appeared to appropriately address the threat analysis. I would give draft-ietf-detnet-data-plane-framework an unqualified Ready, as soon as I-D.ietf-detnet-security is reviewed and becomes an RFC. Regards, Chris From nobody Fri Mar 13 08:31:31 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4CE3A0B3E; Fri, 13 Mar 2020 08:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 3AV1U5pfVkU6; Fri, 13 Mar 2020 08:31:27 -0700 (PDT) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FDCB3A0B68; Fri, 13 Mar 2020 08:31:23 -0700 (PDT) Received: by mail-oi1-x22a.google.com with SMTP id p125so9759040oif.10; Fri, 13 Mar 2020 08:31:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=rzKVYiAyZRd/tDw1mfAL0LKdpGQWUcTzYlC0sCNMWms=; b=SHpPwkQjNpMCu1REmSnuI3eCa+BxAEeIA7jO+o6rtpb4jxdWH9+mAgH3yPOqiRg49a HeNYAfDyTZybr8YuVK1xBTgyu7o1IouLpkZlHyzd3+ztqslNA0BChSd4X5syCaI3aoKn kcIdd/Jb6ozUQjPFa+73qoSmQXdngPxwVEDdDuzVObCsC1PF2HdF5c7ptidKq2gvCftj RKcVx6tpQ9dixO2OghJr3FSgD/xuxruF2NhF2mbn2uhIa8CO16S4y+GPKwfisGl/gFqB aqeJqVeS6BsXAcq51DEDCHDO1wGFAeljjZbNScGHw+uHdNZUdzVw74zdzJ23kP+mLn95 Sn9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=rzKVYiAyZRd/tDw1mfAL0LKdpGQWUcTzYlC0sCNMWms=; b=ArHlraQmclN/mAhy0OXcTmj1JDHyvm9e6P9HYkAiVZZIizPhu00VQ0SHr3GPUPyA9x WUjKZJf6h+gFyK/4fWysNsOeGhRyYqJ6LwYO9XS7a0GxT4VNj53SFQEycpa0AsfV43Zl 1oUVAdcxPeG2M1Zk8giYfI2uR/h4kQyc8NqTFoMNCb/bGt323md16Tf3bckxqd0nr7jB RRVkstCP3NGmWrniY2+Xs59n2A15+KwPUN/d/XP5XAQ16dHRjiLkQhVPI+NtantJx3st D5smIqMtHsHSVL1zKc6gWP9dw1bo9Eu6WiIfWtZ3zxOlOnLb2BcomTK5rOuGaHKY2xJk olkw== X-Gm-Message-State: ANhLgQ1Vczm3uJGTXV2o/ppOQUkMb2Yj2vrnkhmQ6nsfxkteC9Cv4C7C umaqcHxMI0M9Qup5N5HB2fxHulc/ X-Google-Smtp-Source: ADFU+vuMVkN80OQNAUuE87cu9SPy//AUtUNIFmTX9ppHtdWJQ052sIFyX/4B1DY4xKDeMoigmPgEcw== X-Received: by 2002:aca:c390:: with SMTP id t138mr2167951oif.117.1584113482889; Fri, 13 Mar 2020 08:31:22 -0700 (PDT) Received: from Chriss-Air.lan (69-4-52-8.dsl.frcn.hctcnetworks.net. [69.4.52.8]) by smtp.googlemail.com with ESMTPSA id m6sm2179276oic.7.2020.03.13.08.31.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Mar 2020 08:31:22 -0700 (PDT) From: Chris Lonvick To: draft-ietf-detnet-data-plane-framework.all@ietf.org, "iesg@ietf.org" , "secdir@ietf.org" References: <800b9d7a-f510-85a9-b1a0-63ff114c8723@gmail.com> Message-ID: <1d756ed5-1c58-17f4-ffcc-f0033e912648@gmail.com> Date: Fri, 13 Mar 2020 10:31:16 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <800b9d7a-f510-85a9-b1a0-63ff114c8723@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-detnet-data-plane-framework-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2020 15:31:29 -0000 Oops - sorry. Resending to the correct alias. Thanks, Chris On 3/13/20 8:26 AM, Chris Lonvick wrote: > Hello, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The summary of the review is Ready with Issues. The only reason I add > the "with Issues" caveat is that the Security Considerations section > broadly defers to I-D.ietf-detnet-security. > > The Security Considerations section of > draft-ietf-detnet-data-plane-framework additionally provides some > comments that are specific to the draft. I found those to be well > thought out and appropriate. I skimmed I-D.ietf-detnet-security and > found it to also be well thought out. The threat model was clear and > understandable and the document appeared to appropriately address the > threat analysis. > > I would give draft-ietf-detnet-data-plane-framework an unqualified > Ready, as soon as I-D.ietf-detnet-security is reviewed and becomes an > RFC. > > Regards, > > Chris > From nobody Fri Mar 13 10:01:35 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71A3B3A0F87; Fri, 13 Mar 2020 10:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a65ofD7tfCZq; Fri, 13 Mar 2020 10:01:19 -0700 (PDT) Received: from outgoing-exchange-7.mit.edu (outgoing-exchange-7.mit.edu [18.9.28.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 9AA933A0F2A; Fri, 13 Mar 2020 10:01:18 -0700 (PDT) Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-7.mit.edu (8.14.7/8.12.4) with ESMTP id 02DH17jK016575; Fri, 13 Mar 2020 13:01:13 -0400 Received: from w92expo31.exchange.mit.edu (18.7.74.43) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Fri, 13 Mar 2020 12:58:49 -0400 Received: from oc11expo31.exchange.mit.edu (18.9.4.104) by w92expo31.exchange.mit.edu (18.7.74.43) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Fri, 13 Mar 2020 13:00:53 -0400 Received: from oc11expo31.exchange.mit.edu ([18.9.4.104]) by oc11expo31.exchange.mit.edu ([18.9.4.104]) with mapi id 15.00.1365.000; Fri, 13 Mar 2020 13:00:53 -0400 From: Uri Blumenthal To: Stewart Bryant CC: Watson Ladd , DetNet WG , "draft-ietf-detnet-mpls.all@ietf.org" , Lou Berger , secdir Thread-Topic: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-05 Thread-Index: AQHV+F6FNSfnEeGpGUm730Plf9JWd6hGAciAgAC554CAAEiKgA== Date: Fri, 13 Mar 2020 17:00:53 +0000 Message-ID: <675222A1-2CFD-4B09-99DE-4D17C52E55D4@mit.edu> References: <7E8B0875-79F6-4FDB-AD59-29A192C723BC@gmail.com> In-Reply-To: <7E8B0875-79F6-4FDB-AD59-29A192C723BC@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/signed; boundary="Apple-Mail-F5238617-7028-4E4B-8469-0B6847B71AD4"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2020 17:01:28 -0000 --Apple-Mail-F5238617-7028-4E4B-8469-0B6847B71AD4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SSBjb25jdXIgd2l0aCBXYXRzb24uIFBsZWFzZSBzdGF0ZSAqZXhwbGljaXRseSogdGhlIHRoaW5n cyB0aGF0IGhlIHN1Z2dlc3RlZC4NCg0KDQoNCj4gT24gTWFyIDEzLCAyMDIwLCBhdCAwODo0MSwg U3Rld2FydCBCcnlhbnQgPHN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiDv u78NCj4gDQo+PiBPbiAxMyBNYXIgMjAyMCwgYXQgMDE6MzUsIFdhdHNvbiBMYWRkIDx3YXRzb25i bGFkZEBnbWFpbC5jb20+IHdyb3RlOg0KPj4gDQo+Pj4gT24gVGh1LCBNYXIgMTIsIDIwMjAgYXQg NDowNyBBTSBMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0PiB3cm90ZToNCj4+PiANCj4+PiBX YXRzb24sDQo+Pj4gDQo+Pj4gQ2FuIHlvdSBwcm92aWRlIGNvbnRleHQgaGVyZT8gQ2FuIHlvdSBi ZSBleHBsaWNpdCBvbiB3aGF0IHlvdSBzZWUgbmVlZHMgdG8NCj4+PiBiZSBhZGRyZXNzZWQgKGJl eW9uZCB3aGF0IGlzIGluIHRoaXMgZG9jdW1lbnQgYXMgd2VsbCBhcyByZWxhdGVkIHJmY3MpPw0K Pj4gDQo+PiBZb3UgaGF2ZSB0byB0YWxrIGFib3V0IGhvdyB0aGUgbGF5ZXJzIGludGVyYWN0LCBh bmQgY2FuJ3QganVzdCBzYXkgdGhlDQo+PiBsb3dlciBsZXZlbCBoYW5kbGVzIGFueXRoaW5nIHdp dGhvdXQgYW55IGd1aWRlIGFzIHRvIHdoYXQgbmVlZHMgdG8gYmUNCj4+IHByb3ZpZGVkIGJ5IHRo YXQgbG93ZXIgbGF5ZXIuDQo+PiANCj4+IEkgdGhpbmsgbXkgY29uY2VybnMgYWJvdXQgdGhlIGFz c3VtcHRpb25zIHRoaXMgY291bGQgYmUgZml4ZWQgYnkNCj4+IHNheWluZy4gIkFsbCBub2RlcyBh cmUgdHJ1c3RlZCBhbmQgYW55IG9mIHRoZW0gY2FuIG1pc2JlaGF2ZSBpbiB3YXlzDQo+PiB0aGF0 IGFmZmVjdCB0aGUgbmV0d29yay4gIA0KPiANCj4gVGhhdCBpcyBhIGZ1bmRhbWVudGFsIGFzc3Vt cHRpb24gb2YgYWxsIHJvdXRlcnMsIHNvIHRoZXJlIHJlYWxseSBpcyBubyBuZWVkIHRvIHN0YXRl IGl0Lg0KPiANCj4gQXMgSSBzYWlkIGVhcmxpZXIsIGEgcHJhY3RpY2FsIHNvbHV0aW9uIHRvIHRo ZSBieXphbnRpbmUgcm91dGluZyBwcm9ibGVtIHdhcyBwcm9wb3NlZCBieSBSYWRpYSBhYm91dCAz MCB5ZWFycyBhZ28gYW5kIHRoZXJlIGlzIHplcm8gaW50ZXJlc3QgaW4gaXQgYmVjYXVzZSB0aGUg dHJ1c3QgYXNzdW1wdGlvbiBpcyBmdW5kYW1lbnRhbGx5IGluZ3JhaW5lZCBpbiB0aGUgcm91dGlu ZyBhcmNoaXRlY3R1cmUsIGFuZCBzbyBmYXIgaXQgaGFzIGJlZW4gd2VsbCBmb3VuZGVkLg0KPiAN Cj4gDQo+PiBJZiB0aGUgTVBMUyBsYXllciBjYW5ub3QgcHJvdmlkZSBzdWZmaWNpZW50DQo+PiBk ZXRlcm1pbmlzbSwgdGhlbiB0aGUgRGV0TmV0IG1lY2hhbmlzbXMgd29uJ3Qgd29yayIuICANCj4g DQo+IFRoYXQgaXMga2luZCBvZiBmdW5kYW1lbnRhbCB0byB0aGUgcG9pbnQgd2hlcmUgSSBhbSBh bHNvIG5vdCBzdXJlIGl0IG5lZWRzIHRvIGJlIHN0YXRlZCwgYW5kIGlmIGl0IGRvZXMgbmVlZCB0 byBiZSBzdGF0ZWQgdGhlbiBpdCBuZWVkcyB0byBnbyB1cCB0aGUgdHJlZSBpbiBvbmUgb2YgdGhl IGZ1bmRhbWVudGFsIGRvY3VtZW50cywgbm90IGVhY2ggb2YgdGhlIGRhdGEtcGxhbmUgZG9jdW1l bnRzICh0aGVyZSBhcmUgcXVpdGUgYSBmZXcgc3VjaCBkb2N1bWVudHMpLg0KPiANCj4+IEkgYWdy ZWUgd2UNCj4+IHNob3Vkbid0IHJlcXVpcmUgYW4gZW50aXJlIG1hc3NpdmUgc2VjdXJpdHkgZnJh bWV3b3JrIHRvIGJlIHF1b3RlZA0KPj4gYWdhaW4gaGVyZSwgYnV0IHRoZXJlIG11c3QgYmUgc29t ZSBkZXRhaWxzIG9mIHRoaXMgZW1iZWRkaW5nIHRoYXQgYXJlDQo+PiB3b3J0aCBub3RpbmcsIGFu ZCB5ZXQgSSBkb24ndCBzZWUgdGhlbSBjYWxsZWQgb3V0IGluIHRoZSBzZWN1cml0eQ0KPj4gY29u c2lkZXJhdGlvbnMgc2VjdGlvbi4NCj4gDQo+IElzIHRoaXMgYWJvdXQgc2hvd2luZyB0aGF0IHdl IGhhdmUgZG9uZSBzb21ldGhpbmcgdG8gcHJvdmUgdGhhdCB3ZSB0YWtlIHNlY3VyaXR5IHNlcmlv dXNseSwgb3IgaXMgaXQgYWJvdXQgZ2l2aW5nIHByYWN0aWNhbCBhZHZpY2UgdG8gc29tZW9uZSBk ZXBsb3lpbmcgdGhlIHRlY2hub2xvZ3kuIEhvcGVmdWxseSB0aGUgbGF0ZXIsIGluIHdoaWNoIGNh c2UgSSB0aGluayB0aGlzIGlzIHdlbGwgY292ZXJlZCBieSB0aGUgRGV0TmV0IGNvbnRleHQgYW5k IHRoZSBNUExTIGRvY3VtZW50cywgYWxsIG9mIHdoaWNoIHRoZSByZWFkZXIgY2FuIGJlIGFzc3Vt ZWQgdG8gYmUgZmFtaWxpYXIgd2l0aC4NCj4gDQo+PiANCj4+IEFyZSB0aGVyZSByZWFsbHkgbm8g c3BlY2lmaWMgY29uY2VybnMgYWJvdXQgdGhlIGludGVyYWN0aW9uIGJldHdlZW4NCj4+IERldE5l dCBhbmQgTVBMUz8NCj4gDQo+IFRoZXJlIGFyZSBNUExTIHNlcnZpY2UgcmVxdWlyZW1lbnRzIGFu ZCBleHBlY3RhdGlvbnMuIEhvd2V2ZXIgSSBkb27igJl0IHRoaW5rIHRoZXJlIGlzIGFuIGludGVy YWN0aW9uIHBlciBzZS4NCj4gDQo+IEl0IGlzIGFzIEkgYWxyZWFkeSBzYWlkIGFib3V0IHBzZXVk b3dpcmVzLiBJZiB0aGUgcGVyZm9ybWFuY2Ugb2YgdGhpcyBhcHByb2FjaCBpcyBub3QgZ29vZCBl bm91Z2gsIHRoZW4gc3BlbmQgdGhlIG1vbmV5IGFuZCBidXkgYSBkZWRpY2F0ZWQgcGh5c2ljYWwg bmV0d29yay4NCj4gDQo+IC0gU3Rld2FydA0KPiANCj4gDQo+PiANCj4+PiANCj4+PiBUaGFuayB5 b3UsDQo+Pj4gTG91DQo+Pj4gDQo+Pj4gDQo+Pj4gLS0tLS0tLS0tLQ0KPj4+PiBPbiBNYXJjaCAx MSwgMjAyMCAxMDozMDoyNyBQTSBXYXRzb24gTGFkZCA8d2F0c29uYmxhZGRAZ21haWwuY29tPiB3 cm90ZToNCj4+PiANCj4+Pj4gSSBkb24ndCBzZWUgYW55IHJlYXNvbiB3aHkgUkZDIDM1NTIncyBn dWlkZWxpbmVzIHNob3Vkbid0IGFwcGx5IHRvIHRoaXMgZHJhZnQuDQo+Pj4+IA0KPj4+PiBJZiB0 aGVyZSBpcyBhIE1QTFMgZXhjZXB0aW9uIEknZCBsaWtlIHRvIHNlZSB0aGUgcnVsZXMgdGhhdCBz aG91bGQgYmUgYXBwbGllZC4NCj4+Pj4gDQo+Pj4+IEFzIGlzIEkgZG9uJ3Qgc2VlIGFueSByZWFz b24gd2h5IHRoZSBhc3N1bXB0aW9ucyBjYW4ndCBiZSBleHBsaWNpdGx5DQo+Pj4+IHNwZWxsZWQg b3V0LCBlaXRoZXIgaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIG9yIGVsc2V3aGVyZS4N Cj4+Pj4gDQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4+IGRldG5ldCBtYWlsaW5nIGxpc3QNCj4+Pj4gZGV0bmV0QGlldGYub3JnDQo+Pj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGV0bmV0DQo+Pj4+IA0KPj4+ IA0KPj4+IA0KPj4gDQo+PiANCj4+IC0tIA0KPj4gIk1hbiBpcyBib3JuIGZyZWUsIGJ1dCBldmVy eXdoZXJlIGhlIGlzIGluIGNoYWlucyIuDQo+PiAtLVJvdXNzZWF1Lg0KPiANCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2VjZGlyIG1haWxpbmcg bGlzdA0KPiBzZWNkaXJAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZWNkaXINCj4gd2lraTogaHR0cDovL3Rvb2xzLmlldGYub3JnL2FyZWEvc2VjL3Ry YWMvd2lraS9TZWNEaXJSZXZpZXcNCg== --Apple-Mail-F5238617-7028-4E4B-8469-0B6847B71AD4 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCGsw ggQkMIICjKADAgECAgRbkXGgMA0GCSqGSIb3DQEBDAUAMBoxGDAWBgNVBAMMD0ZvcmVzdCBDQSBS U0EgNDAeFw0xODA5MDYxODI3NDRaFw0yMTA5MDYxODI3NDRaMA4xDDAKBgNVBAMMA1VyaTCCAaIw DQYJKoZIhvcNAQEBBQADggGPADCCAYoCggGBANJi8+lfrSCcWThbn0vQzXsW7AYTyTZSo/pv/274 xD/t1rpn/X/vegP2lSfr+SRJ4oJ+51MFJvRl/sAveroDN8gGrFyYaCg5ZsOMqksCmLha4Ttgk04L I/aqrPGuzF1OVgjhi6WrnFr80KS6sy3MWzYIYV6G1FycKEup5snMr1B1WWzFKOwSslnJwvCuHu2W Tc5OzJKPtxMcDIS9y6VOZTzsJUFe0bRiw0LICDBcB3fgKCvYMcDfke0pw13I4O7wEG40s9E6rTIj Q0H1LVk69pSo1ikzpikl5W8pXUQQrSmjHqhFn/Q+PwSzHSOralN0p1UMziUv57lgvvZbTaH1ooqq MZBuTed0xLye3w+h9+/iqDY4B7lFqbegzseBh7/Q6KdtfpkwwI7xSpZEME/V77KAMw+ipb+Itbij Bi3r/t81fDW8eitIAbVtalpFROlYIaZnIIohOZRyVjn2unZ+lj3jDKsDq53g+oleo+Ruszlt8nju 6uKhzE7bdX1xJuvCtwIDAQABo34wfDAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFIDAWBgNV HREEDzANgQt1cmlAbWl0LmVkdTAdBgNVHQ4EFgQU2p+nwSyQFM6byFBhc7oIZephJbcwJQYDVR0l BB4wHAYIKwYBBQUHAwQGCisGAQQBgjcKAwQGBFUdJQAwDQYJKoZIhvcNAQEMBQADggGBAH/zzG9P gU+ogFbc75JpUK0amUUtmtSsGDe4599GolCDiuPHrnbCGcaNc9aQjRaP3Q3aU7BB3aOjwssjQSN0 tsfZD8p+XPny/odhDSwS/25jCg0dVasd8q+Jd1S1g34RGUqPQ+5ofTrBSEkHBdLdJOnxBGo9GRzA yiDg34r6zK6BXNYv2GdqRk+GGGvL/w3CDR+ih36ZDBxw/EO19oH/aV4+mVlcRI6aoj4KMb+h4zMY S8jLDArIZSce4EWzJqxKVcX6Q7CE/0Br/7R8Ixs+vt5YKPUVpEbFM6koH624GDQYKM2kzXBnwYgS /jvl02KUx6uNmIgo+ufK2l7sc83vRLxBTJKhT0/USVkwu9uzg2zHJeGBZ4pmDhkIVkGcamW7KPYZ dgOz8zAOy8Ntk7GebPn85XuPcQS9UntdO61X1EyEXg4Ixl/qapidfJQfdCqEeZZXpaV3WKWE8u1l fNB00mC0/xhG3bikQxl3O20nyPjXvl6VZFzglsPRy1Xh5L//rzCCBD8wggKnoAMCAQICBFuRckIw DQYJKoZIhvcNAQEMBQAwGjEYMBYGA1UEAwwPRm9yZXN0IENBIFJTQSA0MB4XDTE4MDkwNjE4MzAy NloXDTIxMDkwNjE4MzAyNlowDjEMMAoGA1UEAwwDVXJpMIIBojANBgkqhkiG9w0BAQEFAAOCAY8A MIIBigKCAYEAtZvms8stf9xj5w7pjYzgmHe7TH0eX/q3buMBqdLufhFuqCizZPhXJmSbue8WHm8H HO7SHQPUqIqbPOMIQfAL8nwWhuTfsN5nrtFW77eiNsEexRNkbhw/U6RzamCGl6xQmUxOD0nabEmd Xdces+rjtzlvjpNHI7xrR32ee4JuGTjwAWlAHPtBC8TqiOR/ysR2K2umk5BkjCEWV9kDfGklfKmu IhuCzzpTvN3AnLMX9kP9IY6E9B8OsLOhkOFBbAMzyqkXibtPWluqOnYW3V3MVc9H1ir6sGLF5onW lHLEorI51WuHlfVO8WJRYwhrzQIIAWAYheZaH2wdb87Kw6o4JbHDLTDJHHrBDwfqa5OtFTeQNWCD JPdHa4xfFpjnMTzP18POa5C6QN5XBpTFsfccWyEdt+ykGB2FMzhB3GgMVRfWPgo8TgxVwU9MHt8s vmxj8KMUd7afSJBOjMIRPZ6gi8Vja9SR9+Hj/YWgpKZMHhI7irJVpWF++7hhfxxDbgDBAgMBAAGj gZgwgZUwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBsAwFgYDVR0RBA8wDYELdXJpQG1pdC5l ZHUwHQYDVR0OBBYEFK3WLENy4CH330dGZEWchN+L1r28MD4GA1UdJQQ3MDUGCCsGAQUFBwMCBggr BgEFBQcDAwYKKwYBBAGCNwoDDAYJKoZIhvcvAQEFBggrBgEFBQcDBDANBgkqhkiG9w0BAQwFAAOC AYEACYbThcFo+JTQNP5UacMtYogWU/yOx5GBLSNNa5cpvoRrOJc9CUDfzfnrd7IhDLXvnFUYNt3i oyU13LKRoPsp/YYuZ2CBI1om9g27SSqqEcOom0eojIKkPNw+sJzYVl7Dz2I7f9DHN6nEC9BeT8Do rjuq67UOlZZw0YvlvCmtMI4xJ7CUM8NrphoeRN18OnbwmkHWIYnYwdxipTJ8oLWi5EbKaUEYyLlC JWd6o9vH8cFNzsViPUl9POxBtX++o5KxtW7/JQwrQt3uFubF6rHQag6HDeXcXSyI0DmL8MrfVtHi Ma2bN+7z8N9Wnuvx8v0qlqfwd+uhmP7OvD32PuzjQxuGyPd43DZazlMhY9IRpSSCPhdbxzS3YwKr jnTZlKGwPiYCmiQ0XSEW3K64Exe4t+jrkBReocr9ccslB4d4XhxQPdAvUdI43xGMbnFea7pyTDyP b0z1vMrYt6dAguU0QTgRZsPFoIldK70ILvncq9amhxuQ4Uw+u2WUXiYba2R1MYICoTCCAp0CAQEw IjAaMRgwFgYDVQQDDA9Gb3Jlc3QgQ0EgUlNBIDQCBFuRckIwDQYJYIZIAWUDBAIBBQCggdEwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwMzEzMTcwMDUzWjAvBgkq hkiG9w0BCQQxIgQg9LfEnzOqHSHHf6HD9R+JAxWHO+G35DZpRqTQ/9YYKR0wMQYJKwYBBAGCNxAE MSQwIjAaMRgwFgYDVQQDDA9Gb3Jlc3QgQ0EgUlNBIDQCBFuRcaAwMwYLKoZIhvcNAQkQAgsxJKAi MBoxGDAWBgNVBAMMD0ZvcmVzdCBDQSBSU0EgNAIEW5FxoDANBgkqhkiG9w0BAQEFAASCAYBRJ5Ts gLTXt+g4cU6W8B13v7RNdTrBoRZfkbVzvgUozzIGTnHQAJjEqynWNy88JyVaOMs20Zl10TIVL0Cl ZRvnXerUdjv/9GQgNu+E85wS0W8fmU4Lt0Cn3tf7BroovbQv2K7Hwu576JusUhgoCzQhEXrckqOR 8cquwfdhb+lEBkrTTlQJkbW2QhOPkpYtQLpSrtlJ/BrMiX731rqrPDWa2rN/DhrsWXq/uansjY8/ fAAVuURU7R77KXFZYqG2fifQH9H8iWQ+lnZOPH6qzrIBkTQ+wOrDg6UGVv4tJ7N8/IMHaZTmpSgV IQc0vmTLDF4oZZuPibaDtLobx5FnG1tukEXmLQtvkbFuDPBDsYUs3TrLyR8RmxNoui0YhuvLe0eN 4s8t0FWde+vLr29sbqZpTymk1R8WasIULKw99Ssgm1guzjQyWHkT8aH73k5wwNa/2AGgK9P9xbAU RbLh664fC7BqkD1JEj1fqecXCzaa2Q8YETbin/M/rAx67j42kjIAAAAAAAA= --Apple-Mail-F5238617-7028-4E4B-8469-0B6847B71AD4-- From nobody Sun Mar 15 08:11:55 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2440E3A0D8D for ; Sun, 15 Mar 2020 08:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.243 X-Spam-Level: *** X-Spam-Status: No, score=3.243 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CK_HELO_GENERIC=0.249, HTML_MESSAGE=0.001, MIXED_ES=1, RCVD_IN_RP_RNBL=1.31, RCVD_IN_SORBS_DUL=0.001, RDNS_DYNAMIC=0.982, SPF_FAIL=0.001, SPF_HELO_NONE=0.001, TO_EQ_FM_DOM_SPF_FAIL=0.001, TO_EQ_FM_SPF_FAIL=1.596, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frv9Z-Xlx-yu for ; Sun, 15 Mar 2020 08:11:50 -0700 (PDT) Received: from 5f44cf48.dynamic.mv.ru (5f44cf48.dynamic.mv.ru [95.68.207.72]) (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 ACC293A17CD for ; Sun, 15 Mar 2020 08:11:49 -0700 (PDT) Message-ID: <20f2bb37c15d77499590268a53476ddaed044f@ietf.org> From: Albina To: secdir@ietf.org Date: Sun, 15 Mar 2020 17:11:39 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="8b7118b60adec635e9eca52410c4557e1a35" Archived-At: Subject: [secdir] =?cp1251?b?VE9QMTAg7/Du4/Dg7OwgMjAyMCDj7uTgIOTr/yDn4PDg?= =?cp1251?b?4e7y6uAg4iDI7fLl8O3l8uUu?= X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2020 15:11:52 -0000 --8b7118b60adec635e9eca52410c4557e1a35 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable =CF=F0=E5=E2=F0=E0=F2=E8 =F1=E2=EE=E9 =EA=EE=EC=EF=FC=FE=F2=E5=F0 =E2 =C3= =E5=ED=E5=F0=E0=F2=EE=F0 =C4=E5=ED=E5=E3! 100% =C1=E5=F1=EF=EB=E0=F2=ED=EE. 100% =C0=E2=F2=EE=EF=E8=EB=EE=F2. =D0=E0=E1=EE=F2=E0=E5=F2 =F3 =E2=F1=E5=F5! =CE=E7=ED=E0=EA=EE=EC=E8=F2=FC=F1=FF =F1 =EF=F0=EE=E3=F0=E0=EC=EC=EE=E9 >= >> http://bit.ly/3cCY5Mz If you do not wish to receive further emails, then please click here to L= ist-Unsubscribe | 97756 Santa Monica Blvd, Suite 97756 Los Angeles, CA 97756-97756, USA | --8b7118b60adec635e9eca52410c4557e1a35 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
=CF=F0=E5=E2=F0=E0=F2=E8 =F1=E2=EE=E9 =EA= =EE=EC=EF=FC=FE=F2=E5=F0 =E2 =C3=E5=ED=E5=F0=E0=F2=EE=F0=20 =C4=E5=ED=E5=E3!
  
100% =C1=E5=F1=EF=EB=E0=F2=ED=EE. 100= %=20 =C0=E2=F2=EE=EF=E8=EB=EE=F2.
  
=D0=E0=E1=EE=F2=E0=E5=F2 = =F3=20 =E2=F1=E5=F5!
  
=CE=E7=ED=E0=EA=EE=EC=E8=F2=FC=F1=FF =F1 =EF=F0=EE=E3=F0= =E0=EC=EC=EE=E9 >>>=20 http://bit.ly/3cCY5Mz
  
  
If you do = not wish to=20 receive further emails, then please click here to List-Unsubscribe
|=20 97756 Santa Monica Blvd, Suite=20 97756 Los Angeles, CA=20 97756-97756, USA=20 |
 
--8b7118b60adec635e9eca52410c4557e1a35-- From nobody Sun Mar 15 10:03:58 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43AF93A1923 for ; Sun, 15 Mar 2020 10:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mandelberg.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aymx8Zz-sRoP for ; Sun, 15 Mar 2020 10:03:48 -0700 (PDT) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (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 8B4FF3A191D for ; Sun, 15 Mar 2020 10:03:44 -0700 (PDT) X_CMAE_Category: , , X-CNFS-Analysis: v=2.3 cv=ddH+Ikfe c=1 sm=1 tr=0 a=OXtaa+9CFT7WVSERtyqzJw==:117 a=OXtaa+9CFT7WVSERtyqzJw==:17 a=KGjhK52YXX0A:10 a=IkcTkHD0fZMA:10 a=NTnny0joGdQA:10 a=SS2py6AdgQ4A:10 a=bmmO2AaSJ7QA:10 a=NHPww3FDJbjRN2bx45sA:9 a=QEXdDO2ut3YA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: ZHNlb21uQHJjbi5jb20= Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=david@mandelberg.org; spf=softfail; sender-id=softfail Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=david@mandelberg.org; sender-id=softfail Authentication-Results: smtp02.rcn.cmh.synacor.com header.DKIM-Signature=@mandelberg.org; dkim=pass Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.user=dseomn@rcn.com; auth=pass (LOGIN) Received: from [209.6.43.168] ([209.6.43.168:46264] helo=uriel.mandelberg.org) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.25.56547 r(Core:3.6.25.0)) with ESMTPSA (cipher=DHE-RSA-AES256-GCM-SHA384) id 42/80-41843-9EF5E6E5; Sun, 15 Mar 2020 13:03:37 -0400 Received: from [192.168.1.152] (DD-WRT [192.168.1.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id DE7251C602C; Sun, 15 Mar 2020 13:03:35 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mandelberg.org; s=202003; t=1584291815; bh=y9D+DHMv6AoYReHUuDBE8O/xUZX7ILLiLvcKLjpOTB4=; h=To:From:Subject:Date:From; b=cfNl/4R4yQ9+LY74Wiv7T8pD5ce2Pqzv994WPZKddd3+Tl3qLhSed0LCM72fRgEeN OcRPvirGAnQ3psQfMOnbE58rDgIGmHzaXGToTwL6ZQyCtpB6LhsSh6q0ziOWx4btVw dNMVDWEgOVQeC5kAlrnm+JYOmrCZmoyoJEj3lQaWpSjIDa3sCoidPGPHYJhGcShayY To8/ElfEpOU2DXnJnNg6C3W9H8S1EzLNQAMwGiREy8WKj4wdwd+tm1ELwW324KZmAv jhx85nnxNTpzpJ29LZF+8syUillaxXeEkorlFva+fEgb2ixB8Pdy8P5n8Ts07Uhr9E gE5aRH57dKtZw== To: iesg@ietf.org, secdir@ietf.org, draft-ietf-core-stateless.all@ietf.org From: David Mandelberg Message-ID: <9ea24cd9-e194-9820-a903-9cc09ef19504@mandelberg.org> Date: Sun, 15 Mar 2020 13:03:33 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [secdir] secdir review of draft-ietf-core-stateless-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2020 17:03:50 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is ready with issues. I think this protocol change increases the amount of data that a CoAP server would reflect in a DoS attack using spoofed source IP addresses with UDP. I don't see any opportunity for amplification though, just reflection of more data sent by a malicious client. I'm very much not a DoS expert though, so I have no idea if this is an issue at all. What happens when a client changes the (implementation-private) format of the state it puts in the tokens? E.g., what if a client sends a request, applies a software update, then receives the response? (I'm guessing that's a more likely situation with UDP, since the software update would probably interrupt a TCP session.) If an attacker can predict when the software update will happen and how the new version will interpret the old version's tokens, can they replay anything maliciously? (Assuming the replay window includes some messages from just before the software update.) From nobody Sun Mar 15 14:14:04 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E85B3A1C68 for ; Sun, 15 Mar 2020 14:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.362 X-Spam-Level: X-Spam-Status: No, score=-3.362 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYdbHkpvx7Ul for ; Sun, 15 Mar 2020 14:14:00 -0700 (PDT) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) (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 25A053A1C66 for ; Sun, 15 Mar 2020 14:14:00 -0700 (PDT) Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id C491E3E0F231A for ; Sun, 15 Mar 2020 15:13:59 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id Daa7jkjpdVKjoDaa7jJF85; Sun, 15 Mar 2020 15:13:59 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.3 cv=dJyIZtRb c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=xqWC_Br6kY4A:10:nop_ipv6 a=IkcTkHD0fZMA:10:nop_charset_1 a=SS2py6AdgQ4A:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=wU2YTnxGAAAA:8 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=giGUBfhqyIHcbX5fTZUA:9 a=QEXdDO2ut3YA:10:nop_charset_2 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=C7x7eFCcOafwhEQpiZAKfu31JVJhRFOiq3fjpT5sWDM=; b=jza5ijtz6QQjkDWupcHVn6GWhb 36ELwcyBaZoI82NhzKeQSiUhWVDh2C5GfXxPA9YxhhdNOs+q6EAZnq2jF0dmxqa/rhgdWRHq0fll9 6pBlylAlKMxZro3ABIcCNC43w; Received: from [127.0.0.1] (port=55373 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1jDaa7-001fBu-I1; Sun, 15 Mar 2020 15:13:59 -0600 To: Watson Ladd Cc: Stewart Bryant , draft-ietf-detnet-mpls.all@ietf.org, DetNet WG , secdir References: <158389693039.16158.6977515080330200081@ietfa.amsl.com> <137FCA36-3B7C-46EB-B951-3FDC01560069@gmail.com> <170ce6deaf8.277b.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> From: Lou Berger Message-ID: <4db5034d-4c48-031b-8604-b9d1ad4d9c68@labn.net> Date: Sun, 15 Mar 2020 17:13:58 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 127.0.0.1 X-Source-L: Yes X-Exim-ID: 1jDaa7-001fBu-I1 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPv6:::1]) [127.0.0.1]:55373 X-Source-Auth: lberger@labn.net X-Email-Count: 14 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2020 21:14:02 -0000 Hi Watson,     I think Stewart's response really covers the main points. DetNet is really just MPLS (and IP) with some specific forwarding behaviors and queuing.  The only thing I'd add, is I see DetNet in general as a specific form of policy based routing. (The general form of which is pretty much as old as IP). Lou On 3/12/2020 9:35 PM, Watson Ladd wrote: > On Thu, Mar 12, 2020 at 4:07 AM Lou Berger wrote: >> Watson, >> >> Can you provide context here? Can you be explicit on what you see needs to >> be addressed (beyond what is in this document as well as related rfcs)? > You have to talk about how the layers interact, and can't just say the > lower level handles anything without any guide as to what needs to be > provided by that lower layer. > > I think my concerns about the assumptions this could be fixed by > saying. "All nodes are trusted and any of them can misbehave in ways > that affect the network. If the MPLS layer cannot provide sufficient > determinism, then the DetNet mechanisms won't work". I agree we > shoudn't require an entire massive security framework to be quoted > again here, but there must be some details of this embedding that are > worth noting, and yet I don't see them called out in the security > considerations section. > > Are there really no specific concerns about the interaction between > DetNet and MPLS? > >> Thank you, >> Lou >> >> >> ---------- >> On March 11, 2020 10:30:27 PM Watson Ladd wrote: >> >>> I don't see any reason why RFC 3552's guidelines shoudn't apply to this draft. >>> >>> If there is a MPLS exception I'd like to see the rules that should be applied. >>> >>> As is I don't see any reason why the assumptions can't be explicitly >>> spelled out, either in the Security Considerations or elsewhere. >>> >>> _______________________________________________ >>> detnet mailing list >>> detnet@ietf.org >>> https://www.ietf.org/mailman/listinfo/detnet >>> >> > From nobody Sun Mar 15 14:22:39 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E123A1C83; Sun, 15 Mar 2020 14:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 MnfBvcuYFEIt; Sun, 15 Mar 2020 14:22:29 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 361C03A1C81; Sun, 15 Mar 2020 14:22:29 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id n20so8945845lfl.10; Sun, 15 Mar 2020 14:22:29 -0700 (PDT) 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=1dTtakFspGmv8FE0wQo5cyiHBT7/5bWKhd2WedPHTnc=; b=JrFTzx6hBs8+oM0wJYoFgYYSVuXMcCpEXcOqAd22HcOKhhvU0qCsarzLbMYWnN5KDo 0/h72DfqJjSf6CDZFA+xz8ITfwYZikg/0FmoZZ3J9wTHkRAjNgp2PZXzfG5JyaqAlrFI B8B6bROyK8Ezx6xpIJ3k0rYvNBKOl0G7eMN4Rh6qdbvieulJbskpdbdWDyI3uG/R2o5E LIYrq7querTyKLO9YW+I8RMMuwGLwVdaYUNDzN1Npiyh8cIVtqppPn67PQwzyip52Aay LG1pbE18igsBOnuX96qinCBgfk5mUMUYpRNsllF91R6iCu+P7f1FK5/IUeC3bbREgksA TCkQ== 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=1dTtakFspGmv8FE0wQo5cyiHBT7/5bWKhd2WedPHTnc=; b=Rkvx6p+J+ViyDAD+aC2BDeFLqcGxAqPD2i2n5zZ0bK1AKULnZgRrIS1gnVnenh7FoX 6HQsm2aeWSEtu+otUwtrRbOukAljYv3n8/Mhdbpwdh14heKI904P4MAXLMpVKiKaCyfM uRRwqM8gqCbmtwwya3/5lhaXFUZ2fAErAqQBmzSZ2f2x8xTwH3BjErY/Zr4/jHcAm/Fn oHSJeE1tcMfa/mrHyjbyQA2Qg5beuHZ4MfP3TXT9coJV0QUKCKBYD8+6+ISjtWq6BuyD bUa2noXW3Z6K6+GHxH1jnq3xoNyJKf5RZb97GOhKc1uDDlFsXRZSuj3TWzeB9Qg3kjOS mhHg== X-Gm-Message-State: ANhLgQ2gvXKn1MsifpiLtYhvb/TFQbsjyOSyv9MiEhX2zJkEcIIgK3ol 9LG1rH5CLNHd5UOxo5Hov88lqUSEmnqDi59g7ec= X-Google-Smtp-Source: ADFU+vvqK1Kzyp9BNf4j9EN7sNPCsmEd5oc4xvE1OljzbNz3HHyCU81LxAonvNQp5m07r+GFqt9lnjl7xKQ7Dx62Uf4= X-Received: by 2002:a05:6512:4cf:: with SMTP id w15mr8499483lfq.147.1584307347365; Sun, 15 Mar 2020 14:22:27 -0700 (PDT) MIME-Version: 1.0 References: <158389693039.16158.6977515080330200081@ietfa.amsl.com> <137FCA36-3B7C-46EB-B951-3FDC01560069@gmail.com> <170ce6deaf8.277b.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4db5034d-4c48-031b-8604-b9d1ad4d9c68@labn.net> In-Reply-To: <4db5034d-4c48-031b-8604-b9d1ad4d9c68@labn.net> From: Watson Ladd Date: Sun, 15 Mar 2020 14:22:16 -0700 Message-ID: To: Lou Berger Cc: Stewart Bryant , draft-ietf-detnet-mpls.all@ietf.org, DetNet WG , secdir Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2020 21:22:32 -0000 On Sun, Mar 15, 2020 at 2:14 PM Lou Berger wrote: > > Hi Watson, > > I think Stewart's response really covers the main points. DetNet is > really just MPLS (and IP) with some specific forwarding behaviors and > queuing. The only thing I'd add, is I see DetNet in general as a > specific form of policy based routing. (The general form of which is > pretty much as old as IP). Then Stewart can put those points in the security considerations section. What's the disadvantage of doing so? > > Lou > > On 3/12/2020 9:35 PM, Watson Ladd wrote: > > On Thu, Mar 12, 2020 at 4:07 AM Lou Berger wrote: > >> Watson, > >> > >> Can you provide context here? Can you be explicit on what you see needs to > >> be addressed (beyond what is in this document as well as related rfcs)? > > You have to talk about how the layers interact, and can't just say the > > lower level handles anything without any guide as to what needs to be > > provided by that lower layer. > > > > I think my concerns about the assumptions this could be fixed by > > saying. "All nodes are trusted and any of them can misbehave in ways > > that affect the network. If the MPLS layer cannot provide sufficient > > determinism, then the DetNet mechanisms won't work". I agree we > > shoudn't require an entire massive security framework to be quoted > > again here, but there must be some details of this embedding that are > > worth noting, and yet I don't see them called out in the security > > considerations section. > > > > Are there really no specific concerns about the interaction between > > DetNet and MPLS? > > > >> Thank you, > >> Lou > >> > >> > >> ---------- > >> On March 11, 2020 10:30:27 PM Watson Ladd wrote: > >> > >>> I don't see any reason why RFC 3552's guidelines shoudn't apply to this draft. > >>> > >>> If there is a MPLS exception I'd like to see the rules that should be applied. > >>> > >>> As is I don't see any reason why the assumptions can't be explicitly > >>> spelled out, either in the Security Considerations or elsewhere. > >>> > >>> _______________________________________________ > >>> detnet mailing list > >>> detnet@ietf.org > >>> https://www.ietf.org/mailman/listinfo/detnet > >>> > >> > > -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Sun Mar 15 14:39:27 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FDA3A1CC1 for ; Sun, 15 Mar 2020 14:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.362 X-Spam-Level: X-Spam-Status: No, score=-3.362 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWF3FhbMrzkd for ; Sun, 15 Mar 2020 14:39:24 -0700 (PDT) Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) (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 86B6E3A1CC0 for ; Sun, 15 Mar 2020 14:39:19 -0700 (PDT) Received: from cmgw12.unifiedlayer.com (unknown [10.9.0.12]) by gproxy3.mail.unifiedlayer.com (Postfix) with ESMTP id 9CFCF407C5 for ; Sun, 15 Mar 2020 15:39:17 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id DaybjC2ElN8ArDaybjHlWF; Sun, 15 Mar 2020 15:39:17 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.3 cv=c7SFvy1l c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=xqWC_Br6kY4A:10:nop_ipv6 a=IkcTkHD0fZMA:10:nop_charset_1 a=SS2py6AdgQ4A:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=IqDcSmB9LMul6CyqU_MA:9 a=_WAdI_3R3KZdalHv:21 a=Rw5vpp9MT5_B5BcD:21 a=QEXdDO2ut3YA:10:nop_charset_2 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=NBXmgj5Fpcu4vYPR9WjdUgXkcgjxA0g+2PYECgkMOc4=; b=mptzAaeqeAlyDkTNmjBFv/SW9y CdhfhtLV0vbtTz66V+tjRIWO8rpSseaUSXyWtgwPpdUNfh1sYFGLIXyZuXR7/LRQy8MJruszzULna nRhE1hRlT2aZR52VWKO/HByWv; Received: from [127.0.0.1] (port=45607 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1jDayb-001olt-DC; Sun, 15 Mar 2020 15:39:17 -0600 To: Watson Ladd Cc: Stewart Bryant , draft-ietf-detnet-mpls.all@ietf.org, DetNet WG , secdir References: <158389693039.16158.6977515080330200081@ietfa.amsl.com> <137FCA36-3B7C-46EB-B951-3FDC01560069@gmail.com> <170ce6deaf8.277b.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4db5034d-4c48-031b-8604-b9d1ad4d9c68@labn.net> From: Lou Berger Message-ID: <4834047a-838c-9f4c-96cb-c9486c16826a@labn.net> Date: Sun, 15 Mar 2020 17:39:08 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 127.0.0.1 X-Source-L: Yes X-Exim-ID: 1jDayb-001olt-DC X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPv6:::1]) [127.0.0.1]:45607 X-Source-Auth: lberger@labn.net X-Email-Count: 28 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Org: HG=bhcustomer;ORG=bluehost; X-Local-Domain: yes Archived-At: Subject: Re: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2020 21:39:26 -0000 On 3/15/2020 5:22 PM, Watson Ladd wrote: > On Sun, Mar 15, 2020 at 2:14 PM Lou Berger wrote: >> Hi Watson, >> >> I think Stewart's response really covers the main points. DetNet is >> really just MPLS (and IP) with some specific forwarding behaviors and >> queuing. The only thing I'd add, is I see DetNet in general as a >> specific form of policy based routing. (The general form of which is >> pretty much as old as IP). > Then Stewart can put those points in the security considerations > section. What's the disadvantage of doing so? At one level, it would be easiest for the authors to just put these in.  On the other hand, this would mean that every RFC produced in the routing area will acquire similar notes, e.g., routing protocols are currently built with a chain of trust model.  Is this what the sec-dir really is asking the routing area to do? ADs,     any opinion on this?     (for context, Stewart's response can be found at: https://mailarchive.ietf.org/arch/msg/detnet/-epL5Fb6bFIUltMrjH53C2316ZA/) Thanks, Lou >> Lou >> >> On 3/12/2020 9:35 PM, Watson Ladd wrote: >>> On Thu, Mar 12, 2020 at 4:07 AM Lou Berger wrote: >>>> Watson, >>>> >>>> Can you provide context here? Can you be explicit on what you see needs to >>>> be addressed (beyond what is in this document as well as related rfcs)? >>> You have to talk about how the layers interact, and can't just say the >>> lower level handles anything without any guide as to what needs to be >>> provided by that lower layer. >>> >>> I think my concerns about the assumptions this could be fixed by >>> saying. "All nodes are trusted and any of them can misbehave in ways >>> that affect the network. If the MPLS layer cannot provide sufficient >>> determinism, then the DetNet mechanisms won't work". I agree we >>> shoudn't require an entire massive security framework to be quoted >>> again here, but there must be some details of this embedding that are >>> worth noting, and yet I don't see them called out in the security >>> considerations section. >>> >>> Are there really no specific concerns about the interaction between >>> DetNet and MPLS? >>> >>>> Thank you, >>>> Lou >>>> >>>> >>>> ---------- >>>> On March 11, 2020 10:30:27 PM Watson Ladd wrote: >>>> >>>>> I don't see any reason why RFC 3552's guidelines shoudn't apply to this draft. >>>>> >>>>> If there is a MPLS exception I'd like to see the rules that should be applied. >>>>> >>>>> As is I don't see any reason why the assumptions can't be explicitly >>>>> spelled out, either in the Security Considerations or elsewhere. >>>>> >>>>> _______________________________________________ >>>>> detnet mailing list >>>>> detnet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/detnet >>>>> > > From nobody Sun Mar 15 15:06:49 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 232EC3A1D28 for ; Sun, 15 Mar 2020 15:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.362 X-Spam-Level: X-Spam-Status: No, score=-3.362 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLLP45S1FCQi for ; Sun, 15 Mar 2020 15:06:41 -0700 (PDT) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) (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 BCFA53A0A01 for ; Sun, 15 Mar 2020 15:06:35 -0700 (PDT) Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id 691903E15AB8D for ; Sun, 15 Mar 2020 16:06:35 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id DbP1jl6zBVKjoDbP1jJbws; Sun, 15 Mar 2020 16:06:35 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.3 cv=dJyIZtRb c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=xqWC_Br6kY4A:10:nop_ipv6 a=IkcTkHD0fZMA:10:nop_charset_1 a=SS2py6AdgQ4A:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=48vgC7mUAAAA:8 a=-GYIVPKYuqpPrMMxd9MA:9 a=m9t80olVZxsxLucD:21 a=IwtjSeqQznlvVA3x:21 a=QEXdDO2ut3YA:10:nop_charset_2 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=clmn0WxaP5lp0+T1Lxf1vZ49d322SjWUeUMGdl8Vsxg=; b=T4f1Jbkz8mfqUUQ5M5B8kDsscp qS4RFaSMOu9DP0LiGibOyayXcy4QxFlpwxSFMyz4fGtIdhD+OE9S6zgu9q73gNieLRrFGfuUDj90R yi9n6uqJArhqR5tlf1QB3CMXu; Received: from [127.0.0.1] (port=42103 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1jDbP1-00203I-4s; Sun, 15 Mar 2020 16:06:35 -0600 To: Tero Kivinen , secdir@ietf.org Cc: draft-ietf-detnet-ip.all@ietf.org, detnet@ietf.org, last-call@ietf.org References: <158406212471.18347.14473548719649982992@ietfa.amsl.com> From: Lou Berger Message-ID: <57456b4d-79a4-191a-8e25-7a2d2157f5d8@labn.net> Date: Sun, 15 Mar 2020 18:06:25 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <158406212471.18347.14473548719649982992@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 127.0.0.1 X-Source-L: Yes X-Exim-ID: 1jDbP1-00203I-4s X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPv6:::1]) [127.0.0.1]:42103 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-ip-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2020 22:06:43 -0000 Tero,     Thank you for the comments, please see below. On 3/12/2020 9:15 PM, Tero Kivinen via Datatracker wrote: > Reviewer: Tero Kivinen > Review result: Has Nits > > In section 1 there is text saying: > > The DetNet Architecture models the DetNet related data plane > functions as two sub-layers: functions into two sub-layers: a service > sub-layer and a forwarding sub-layer. > > I think the second one of the "functions as/into two sub-layers" instance > should be removed. agreed. This looks like a cut-and-past bug to me. > > In section 5.1.2.2 it says that SPI field of the ESP and AH is used, but in > case the IPsec is configured to use UDP encapsulation (rfc3948, i.e., UDP > destination port is 4500) there is different location for the SPI. Should this > document also dig SPI out from the UDP encapsulated ESP/AH? no.  I'll add qualifications that this applies when the "IPv4 Protocol and IPv6 Next Header Fields" are set to AH and ESP. specifically:              The rules defined in this section only apply when the               IPv4 Protocol or IPv6 Next Header Field contains the IANA               defined value for AH or ESP. > There is also > wrapped ESP (rfc5840) with bit different format, i.e., having wrapped ESP > header before the normal ESP header. Should this be included also? This was not discussed in the working group -- so a really great point to raise in this review.  Thank you! As it has it's own protocol number, it would be not too hard to add.  That said, there's no reason it couldn't be added later and no one in the working group raised it.  What do you think, is it important to add it now. > In section 6, I would think it would be useful to have wildcard SPI matching > too, i.e., match all ESP/AH traffic between two hosts regardless of SPI. Agreed.  I think this is what is intended by the existing earlier text:               Implementation SHOULD               also allow for the field to be ignored for a specific               DetNet flow. So another good catch! > Note, that standard procedure to support QoS in IPsec is to create multiple SAs > between hosts with identical addresses, but different SPI, and where each flow > has traffic related to one QoS level inside, but there might not be any way for > external user to know which SPI match to which QoS level). So there is > definitely need to have exact match SPI, but problem is that DetNet might not > have any visibility which SPI match witch QoS level. understood.  The thinking is that such information will need to be mapped into the controller (control/management) plane provisioning of the QoS parameters subject to whatever restrictions are appropriate to not expose any security information. Thanks again for the review! Lou > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > From nobody Sun Mar 15 15:45:35 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955B63A1D8D; Sun, 15 Mar 2020 15:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyGjFchSTs1d; Sun, 15 Mar 2020 15:45:04 -0700 (PDT) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) (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 2D8BC3A1D8C; Sun, 15 Mar 2020 15:45:03 -0700 (PDT) Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-1.mit.edu (8.14.7/8.12.4) with ESMTP id 02FMj0bv008261; Sun, 15 Mar 2020 18:45:04 -0400 Received: from w92expo31.exchange.mit.edu (18.7.74.43) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Sun, 15 Mar 2020 18:42:49 -0400 Received: from oc11expo31.exchange.mit.edu (18.9.4.104) by w92expo31.exchange.mit.edu (18.7.74.43) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Sun, 15 Mar 2020 18:44:58 -0400 Received: from oc11expo31.exchange.mit.edu ([18.9.4.104]) by oc11expo31.exchange.mit.edu ([18.9.4.104]) with mapi id 15.00.1365.000; Sun, 15 Mar 2020 18:44:58 -0400 From: Uri Blumenthal To: Lou Berger CC: Watson Ladd , Stewart Bryant , "draft-ietf-detnet-mpls.all@ietf.org" , DetNet WG , secdir Thread-Topic: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-05 Thread-Index: AQHV+F6FNSfnEeGpGUm730Plf9JWd6hGAciAgARt0QCAAAJSAIAABLYAgAASZQA= Date: Sun, 15 Mar 2020 22:44:58 +0000 Message-ID: <1EAC1CA8-82B2-4D2E-89D5-3562DA1CCC4B@mit.edu> References: <4834047a-838c-9f4c-96cb-c9486c16826a@labn.net> In-Reply-To: <4834047a-838c-9f4c-96cb-c9486c16826a@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/signed; boundary="Apple-Mail-C34D3E98-DDB9-4034-BE6F-AC87946EE2D7"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2020 22:45:07 -0000 --Apple-Mail-C34D3E98-DDB9-4034-BE6F-AC87946EE2D7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SSBzYXkgeWVzIC0gdW5sZXNzIHlvdSBleHBlY3QgYSBwZXJzb24gd2hvIHdhbnRzIGp1c3Qgb25l IFJGQyB0byBoYXZlIHRvIHJlYWQgZXZlcnkgY3JeaF5oIHN0dWZmIHRoYXQgY2FtZSBvdXQgb2Yg dGhlIHJvdXRpbmcgYXJlYS4NCg0KIkp1c3QgZG8gaXQiDQoNCg0KPiBPbiBNYXIgMTUsIDIwMjAs IGF0IDE3OjM5LCBMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0PiB3cm90ZToNCj4gDQo+IO+7 vw0KPj4gT24gMy8xNS8yMDIwIDU6MjIgUE0sIFdhdHNvbiBMYWRkIHdyb3RlOg0KPj4+IE9uIFN1 biwgTWFyIDE1LCAyMDIwIGF0IDI6MTQgUE0gTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4g d3JvdGU6DQo+Pj4gSGkgV2F0c29uLA0KPj4+IA0KPj4+ICAgICAgSSB0aGluayBTdGV3YXJ0J3Mg cmVzcG9uc2UgcmVhbGx5IGNvdmVycyB0aGUgbWFpbiBwb2ludHMuIERldE5ldCBpcw0KPj4+IHJl YWxseSBqdXN0IE1QTFMgKGFuZCBJUCkgd2l0aCBzb21lIHNwZWNpZmljIGZvcndhcmRpbmcgYmVo YXZpb3JzIGFuZA0KPj4+IHF1ZXVpbmcuICBUaGUgb25seSB0aGluZyBJJ2QgYWRkLCBpcyBJIHNl ZSBEZXROZXQgaW4gZ2VuZXJhbCBhcyBhDQo+Pj4gc3BlY2lmaWMgZm9ybSBvZiBwb2xpY3kgYmFz ZWQgcm91dGluZy4gKFRoZSBnZW5lcmFsIGZvcm0gb2Ygd2hpY2ggaXMNCj4+PiBwcmV0dHkgbXVj aCBhcyBvbGQgYXMgSVApLg0KPj4gVGhlbiBTdGV3YXJ0IGNhbiBwdXQgdGhvc2UgcG9pbnRzIGlu IHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucw0KPj4gc2VjdGlvbi4gV2hhdCdzIHRoZSBkaXNh ZHZhbnRhZ2Ugb2YgZG9pbmcgc28/DQo+IA0KPiBBdCBvbmUgbGV2ZWwsIGl0IHdvdWxkIGJlIGVh c2llc3QgZm9yIHRoZSBhdXRob3JzIHRvIGp1c3QgcHV0IHRoZXNlIGluLiAgT24gdGhlIG90aGVy IGhhbmQsIHRoaXMgd291bGQgbWVhbiB0aGF0IGV2ZXJ5IFJGQyBwcm9kdWNlZCBpbiB0aGUgcm91 dGluZyBhcmVhIHdpbGwgYWNxdWlyZSBzaW1pbGFyIG5vdGVzLCBlLmcuLCByb3V0aW5nIHByb3Rv Y29scyBhcmUgY3VycmVudGx5IGJ1aWx0IHdpdGggYSBjaGFpbiBvZiB0cnVzdCBtb2RlbC4gIElz IHRoaXMgd2hhdCB0aGUgc2VjLWRpciByZWFsbHkgaXMgYXNraW5nIHRoZSByb3V0aW5nIGFyZWEg dG8gZG8/DQo+IA0KPiBBRHMsDQo+IA0KPiAgICAgYW55IG9waW5pb24gb24gdGhpcz8gICAgIChm b3IgY29udGV4dCwgU3Rld2FydCdzIHJlc3BvbnNlIGNhbiBiZSBmb3VuZCBhdDogaHR0cHM6Ly9t YWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9kZXRuZXQvLWVwTDVGYjZiRklVbHRNcmpINTND MjMxNlpBLykNCj4gDQo+IFRoYW5rcywNCj4gDQo+IExvdQ0KPiANCj4+PiBMb3UNCj4+PiANCj4+ PiBPbiAzLzEyLzIwMjAgOTozNSBQTSwgV2F0c29uIExhZGQgd3JvdGU6DQo+Pj4+IE9uIFRodSwg TWFyIDEyLCAyMDIwIGF0IDQ6MDcgQU0gTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4gd3Jv dGU6DQo+Pj4+PiBXYXRzb24sDQo+Pj4+PiANCj4+Pj4+IENhbiB5b3UgcHJvdmlkZSBjb250ZXh0 IGhlcmU/IENhbiB5b3UgYmUgZXhwbGljaXQgb24gd2hhdCB5b3Ugc2VlIG5lZWRzIHRvDQo+Pj4+ PiBiZSBhZGRyZXNzZWQgKGJleW9uZCB3aGF0IGlzIGluIHRoaXMgZG9jdW1lbnQgYXMgd2VsbCBh cyByZWxhdGVkIHJmY3MpPw0KPj4+PiBZb3UgaGF2ZSB0byB0YWxrIGFib3V0IGhvdyB0aGUgbGF5 ZXJzIGludGVyYWN0LCBhbmQgY2FuJ3QganVzdCBzYXkgdGhlDQo+Pj4+IGxvd2VyIGxldmVsIGhh bmRsZXMgYW55dGhpbmcgd2l0aG91dCBhbnkgZ3VpZGUgYXMgdG8gd2hhdCBuZWVkcyB0byBiZQ0K Pj4+PiBwcm92aWRlZCBieSB0aGF0IGxvd2VyIGxheWVyLg0KPj4+PiANCj4+Pj4gSSB0aGluayBt eSBjb25jZXJucyBhYm91dCB0aGUgYXNzdW1wdGlvbnMgdGhpcyBjb3VsZCBiZSBmaXhlZCBieQ0K Pj4+PiBzYXlpbmcuICJBbGwgbm9kZXMgYXJlIHRydXN0ZWQgYW5kIGFueSBvZiB0aGVtIGNhbiBt aXNiZWhhdmUgaW4gd2F5cw0KPj4+PiB0aGF0IGFmZmVjdCB0aGUgbmV0d29yay4gIElmIHRoZSBN UExTIGxheWVyIGNhbm5vdCBwcm92aWRlIHN1ZmZpY2llbnQNCj4+Pj4gZGV0ZXJtaW5pc20sIHRo ZW4gdGhlIERldE5ldCBtZWNoYW5pc21zIHdvbid0IHdvcmsiLiAgSSBhZ3JlZSB3ZQ0KPj4+PiBz aG91ZG4ndCByZXF1aXJlIGFuIGVudGlyZSBtYXNzaXZlIHNlY3VyaXR5IGZyYW1ld29yayB0byBi ZSBxdW90ZWQNCj4+Pj4gYWdhaW4gaGVyZSwgYnV0IHRoZXJlIG11c3QgYmUgc29tZSBkZXRhaWxz IG9mIHRoaXMgZW1iZWRkaW5nIHRoYXQgYXJlDQo+Pj4+IHdvcnRoIG5vdGluZywgYW5kIHlldCBJ IGRvbid0IHNlZSB0aGVtIGNhbGxlZCBvdXQgaW4gdGhlIHNlY3VyaXR5DQo+Pj4+IGNvbnNpZGVy YXRpb25zIHNlY3Rpb24uDQo+Pj4+IA0KPj4+PiBBcmUgdGhlcmUgcmVhbGx5IG5vIHNwZWNpZmlj IGNvbmNlcm5zIGFib3V0IHRoZSBpbnRlcmFjdGlvbiBiZXR3ZWVuDQo+Pj4+IERldE5ldCBhbmQg TVBMUz8NCj4+Pj4gDQo+Pj4+PiBUaGFuayB5b3UsDQo+Pj4+PiBMb3UNCj4+Pj4+IA0KPj4+Pj4g DQo+Pj4+PiAtLS0tLS0tLS0tDQo+Pj4+PiBPbiBNYXJjaCAxMSwgMjAyMCAxMDozMDoyNyBQTSBX YXRzb24gTGFkZCA8d2F0c29uYmxhZGRAZ21haWwuY29tPiB3cm90ZToNCj4+Pj4+IA0KPj4+Pj4+ IEkgZG9uJ3Qgc2VlIGFueSByZWFzb24gd2h5IFJGQyAzNTUyJ3MgZ3VpZGVsaW5lcyBzaG91ZG4n dCBhcHBseSB0byB0aGlzIGRyYWZ0Lg0KPj4+Pj4+IA0KPj4+Pj4+IElmIHRoZXJlIGlzIGEgTVBM UyBleGNlcHRpb24gSSdkIGxpa2UgdG8gc2VlIHRoZSBydWxlcyB0aGF0IHNob3VsZCBiZSBhcHBs aWVkLg0KPj4+Pj4+IA0KPj4+Pj4+IEFzIGlzIEkgZG9uJ3Qgc2VlIGFueSByZWFzb24gd2h5IHRo ZSBhc3N1bXB0aW9ucyBjYW4ndCBiZSBleHBsaWNpdGx5DQo+Pj4+Pj4gc3BlbGxlZCBvdXQsIGVp dGhlciBpbiB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgb3IgZWxzZXdoZXJlLg0KPj4+Pj4+ IA0KPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj4+Pj4gZGV0bmV0IG1haWxpbmcgbGlzdA0KPj4+Pj4+IGRldG5ldEBpZXRmLm9yZw0KPj4+ Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGV0bmV0DQo+Pj4+Pj4g DQo+PiANCj4+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gc2VjZGlyIG1haWxpbmcgbGlzdA0KPiBzZWNkaXJAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZWNkaXINCj4gd2lraTogaHR0cDov L3Rvb2xzLmlldGYub3JnL2FyZWEvc2VjL3RyYWMvd2lraS9TZWNEaXJSZXZpZXcNCg== --Apple-Mail-C34D3E98-DDB9-4034-BE6F-AC87946EE2D7 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCGsw ggQkMIICjKADAgECAgRbkXGgMA0GCSqGSIb3DQEBDAUAMBoxGDAWBgNVBAMMD0ZvcmVzdCBDQSBS U0EgNDAeFw0xODA5MDYxODI3NDRaFw0yMTA5MDYxODI3NDRaMA4xDDAKBgNVBAMMA1VyaTCCAaIw DQYJKoZIhvcNAQEBBQADggGPADCCAYoCggGBANJi8+lfrSCcWThbn0vQzXsW7AYTyTZSo/pv/274 xD/t1rpn/X/vegP2lSfr+SRJ4oJ+51MFJvRl/sAveroDN8gGrFyYaCg5ZsOMqksCmLha4Ttgk04L I/aqrPGuzF1OVgjhi6WrnFr80KS6sy3MWzYIYV6G1FycKEup5snMr1B1WWzFKOwSslnJwvCuHu2W Tc5OzJKPtxMcDIS9y6VOZTzsJUFe0bRiw0LICDBcB3fgKCvYMcDfke0pw13I4O7wEG40s9E6rTIj Q0H1LVk69pSo1ikzpikl5W8pXUQQrSmjHqhFn/Q+PwSzHSOralN0p1UMziUv57lgvvZbTaH1ooqq MZBuTed0xLye3w+h9+/iqDY4B7lFqbegzseBh7/Q6KdtfpkwwI7xSpZEME/V77KAMw+ipb+Itbij Bi3r/t81fDW8eitIAbVtalpFROlYIaZnIIohOZRyVjn2unZ+lj3jDKsDq53g+oleo+Ruszlt8nju 6uKhzE7bdX1xJuvCtwIDAQABo34wfDAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFIDAWBgNV HREEDzANgQt1cmlAbWl0LmVkdTAdBgNVHQ4EFgQU2p+nwSyQFM6byFBhc7oIZephJbcwJQYDVR0l BB4wHAYIKwYBBQUHAwQGCisGAQQBgjcKAwQGBFUdJQAwDQYJKoZIhvcNAQEMBQADggGBAH/zzG9P gU+ogFbc75JpUK0amUUtmtSsGDe4599GolCDiuPHrnbCGcaNc9aQjRaP3Q3aU7BB3aOjwssjQSN0 tsfZD8p+XPny/odhDSwS/25jCg0dVasd8q+Jd1S1g34RGUqPQ+5ofTrBSEkHBdLdJOnxBGo9GRzA yiDg34r6zK6BXNYv2GdqRk+GGGvL/w3CDR+ih36ZDBxw/EO19oH/aV4+mVlcRI6aoj4KMb+h4zMY S8jLDArIZSce4EWzJqxKVcX6Q7CE/0Br/7R8Ixs+vt5YKPUVpEbFM6koH624GDQYKM2kzXBnwYgS /jvl02KUx6uNmIgo+ufK2l7sc83vRLxBTJKhT0/USVkwu9uzg2zHJeGBZ4pmDhkIVkGcamW7KPYZ dgOz8zAOy8Ntk7GebPn85XuPcQS9UntdO61X1EyEXg4Ixl/qapidfJQfdCqEeZZXpaV3WKWE8u1l fNB00mC0/xhG3bikQxl3O20nyPjXvl6VZFzglsPRy1Xh5L//rzCCBD8wggKnoAMCAQICBFuRckIw DQYJKoZIhvcNAQEMBQAwGjEYMBYGA1UEAwwPRm9yZXN0IENBIFJTQSA0MB4XDTE4MDkwNjE4MzAy NloXDTIxMDkwNjE4MzAyNlowDjEMMAoGA1UEAwwDVXJpMIIBojANBgkqhkiG9w0BAQEFAAOCAY8A MIIBigKCAYEAtZvms8stf9xj5w7pjYzgmHe7TH0eX/q3buMBqdLufhFuqCizZPhXJmSbue8WHm8H HO7SHQPUqIqbPOMIQfAL8nwWhuTfsN5nrtFW77eiNsEexRNkbhw/U6RzamCGl6xQmUxOD0nabEmd Xdces+rjtzlvjpNHI7xrR32ee4JuGTjwAWlAHPtBC8TqiOR/ysR2K2umk5BkjCEWV9kDfGklfKmu IhuCzzpTvN3AnLMX9kP9IY6E9B8OsLOhkOFBbAMzyqkXibtPWluqOnYW3V3MVc9H1ir6sGLF5onW lHLEorI51WuHlfVO8WJRYwhrzQIIAWAYheZaH2wdb87Kw6o4JbHDLTDJHHrBDwfqa5OtFTeQNWCD JPdHa4xfFpjnMTzP18POa5C6QN5XBpTFsfccWyEdt+ykGB2FMzhB3GgMVRfWPgo8TgxVwU9MHt8s vmxj8KMUd7afSJBOjMIRPZ6gi8Vja9SR9+Hj/YWgpKZMHhI7irJVpWF++7hhfxxDbgDBAgMBAAGj gZgwgZUwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBsAwFgYDVR0RBA8wDYELdXJpQG1pdC5l ZHUwHQYDVR0OBBYEFK3WLENy4CH330dGZEWchN+L1r28MD4GA1UdJQQ3MDUGCCsGAQUFBwMCBggr BgEFBQcDAwYKKwYBBAGCNwoDDAYJKoZIhvcvAQEFBggrBgEFBQcDBDANBgkqhkiG9w0BAQwFAAOC AYEACYbThcFo+JTQNP5UacMtYogWU/yOx5GBLSNNa5cpvoRrOJc9CUDfzfnrd7IhDLXvnFUYNt3i oyU13LKRoPsp/YYuZ2CBI1om9g27SSqqEcOom0eojIKkPNw+sJzYVl7Dz2I7f9DHN6nEC9BeT8Do rjuq67UOlZZw0YvlvCmtMI4xJ7CUM8NrphoeRN18OnbwmkHWIYnYwdxipTJ8oLWi5EbKaUEYyLlC JWd6o9vH8cFNzsViPUl9POxBtX++o5KxtW7/JQwrQt3uFubF6rHQag6HDeXcXSyI0DmL8MrfVtHi Ma2bN+7z8N9Wnuvx8v0qlqfwd+uhmP7OvD32PuzjQxuGyPd43DZazlMhY9IRpSSCPhdbxzS3YwKr jnTZlKGwPiYCmiQ0XSEW3K64Exe4t+jrkBReocr9ccslB4d4XhxQPdAvUdI43xGMbnFea7pyTDyP b0z1vMrYt6dAguU0QTgRZsPFoIldK70ILvncq9amhxuQ4Uw+u2WUXiYba2R1MYICoTCCAp0CAQEw IjAaMRgwFgYDVQQDDA9Gb3Jlc3QgQ0EgUlNBIDQCBFuRckIwDQYJYIZIAWUDBAIBBQCggdEwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwMzE1MjI0NDU4WjAvBgkq hkiG9w0BCQQxIgQg1MgnGErQa6f87n2SFH7MJresPBaaJUC8IK8c2n5sZLwwMQYJKwYBBAGCNxAE MSQwIjAaMRgwFgYDVQQDDA9Gb3Jlc3QgQ0EgUlNBIDQCBFuRcaAwMwYLKoZIhvcNAQkQAgsxJKAi MBoxGDAWBgNVBAMMD0ZvcmVzdCBDQSBSU0EgNAIEW5FxoDANBgkqhkiG9w0BAQEFAASCAYAYlgK6 byBJjKEK+rB5pYZT0Su+DNETD8dEKn71FV4/bvvxuI6CqvPKVljzew49zq8QtNGn5pppkmW+w5TF zQ5yf3EnRO99zxricWQGFg/yDEQlJBaJHrW7EvhgsnO/81HZ2US+Z6I1NtPo/J1Zo9NgXnptOI3e raoMF0PDVwEb/xEhWMiOiwKi9NhzTJcpEgThBKtNTd7Ro2szmVMe6wiSPMsboJYEjbRZ7FoZyNCA XYjr244G33vkdkhhsYddVo8L0PzxozIVtQprMRnev6RWXbIf4M/riMj8BVANZdEsoHGPuGdEQoqf 7SPR4tau5cZunMhfc8S17YqiaIR3C/9+24rrPEmK59U7A1lU1yfzUcWI7y6kGgmadmYe5Qk35IP6 XsGtFR9GDQbLrje9DhX3hBPQQ9gRFWHMenkJdheG1T3IYCOC/p06tblU0b0V6b4SBaoe3aBBTWi4 bog+/q+rdMqo8B4tLfC6kpSqotlTfuNv72g7RIKsXCtsyIwLf/QAAAAAAAA= --Apple-Mail-C34D3E98-DDB9-4034-BE6F-AC87946EE2D7-- From nobody Mon Mar 16 03:08:10 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F9A3A2226; Mon, 16 Mar 2020 03:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=Tfs4cJIT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=3ehIi5QN Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHZYJZ9kmh4q; Mon, 16 Mar 2020 03:07:56 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AB563A2210; Mon, 16 Mar 2020 03:07:56 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id DAD6E79E; Mon, 16 Mar 2020 06:07:54 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Mon, 16 Mar 2020 06:07:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm2; bh=j4n8 GfMgWen2loVFeNGeqfmOdHo3ESxYXNCJHmxYw1o=; b=Tfs4cJIT48tBXNU83JKV 37prICyyDrKl+a9TTYJ+1vzEMtvyooOzIkknt4PXPn8CQ5FVIxZnLk/K9mN9t1hn 2FMID7Jr1wjaYPMpYZ+j4trOXECozuD7Ja0w095ytNGLsEudC3ozPQtMjQguGsGW MvOC+eqlneBi2pVBPbbGRU1gvv4Z+H4Rl6omgK/lRWphgZdX4QXXxCt2J1Lr6kP/ UFDgwvu96YHHs7M1TgUuMWov6zEXbAUYuzA2LnDh+ZmkJCmAruHNIOGoe3DDNR9H sj6AQXLKk4+4kYAkZO/Ixu571FWST3Zp0u5QvOvuAJRWl0usx30b1+8Z7S2gyl0D RQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=j4n8Gf MgWen2loVFeNGeqfmOdHo3ESxYXNCJHmxYw1o=; b=3ehIi5QNIS6xWQ8zGZrlMR iiLWm+0uteafk6SHIrxRxIlgfJUN70R+tkQ07rRrArX5dOd4rqi9pZNqyN8mv2ce EbjR8GSMf3q+df9+EntvuOHcnehfZbsA6+pKmKo/GuRhJdIJN70/Xch7Y39CiDk8 p674YCKMNZevDbMCnYK3077g/3shXw7cFXuTPFOsEj97cDhov70Tb1xBQhroXr1b 5zljPYUtSpuXNQ/ql3/W0gQRXHq3sQDcYQhgknPwugq747dEc9fh1VSDkdiguCA/ CSge6S4aa7AvXMd2bLMs0pzxdFcpucVakSs1CRRmIdqLkVopx0i2RNcIrpIp9lGQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudeffedguddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdfpvghi lhculfgvnhhkihhnshdfuceonhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghi lhhjsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 18394180090; Mon, 16 Mar 2020 06:07:54 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-991-g5a577d3-fmstable-20200305v3 Mime-Version: 1.0 Message-Id: <857a3426-bda6-47cb-9b73-b9db8e596a2d@beta.fastmail.com> In-Reply-To: <158385051998.15836.4770030164750320016@ietfa.amsl.com> References: <158385051998.15836.4770030164750320016@ietfa.amsl.com> Date: Mon, 16 Mar 2020 21:07:32 +1100 From: "Neil Jenkins" To: "Phillip Hallam-Baker" , secdir@ietf.org Cc: last-call@ietf.org, draft-ietf-calext-jscalendar.all@ietf.org, calsify@ietf.org Content-Type: multipart/alternative; boundary=c9116e7e33f04a42b5c5d8c86be3520b Archived-At: Subject: Re: [secdir] =?utf-8?q?=5Bcalsify=5D_Secdir_last_call_review_of_draf?= =?utf-8?q?t-ietf-calext-jscalendar-26?= X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 10:07:59 -0000 --c9116e7e33f04a42b5c5d8c86be3520b Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Phillip, Thank you for the review and apologies for the late reply; I have been o= n leave. > 1) Spam > 2) Duplication > 3) Time Zones > 4) Authentication I have expanded the introduction to the security considerations to menti= on (4) and added sections for (1)-(3); I include the additions and alter= ations below. Please let me know if you believe this is insufficient: *7. Security Considerations* Calendaring and scheduling information is very privacy-sensitive. Its transmission must be done carefully to protect it from possible threats, such as eavesdropping, replay, message insertion, deletion, modification, and man-in-the-middle attacks. The data being stored and transmitted may be used in systems with real world consequences. For example, a home automation system may turn an alarm on and off. Or a coworking space may charge money to the organiser of an event that books one of their meeting rooms. Such systems must be careful to authenticate all data they receive to prevent them from being subverted. This document just defines the data format; such considerations are primarily the concern of the API or method of storage and transmission of such files. =E2=80=A6 7.1-7.3 as before =E2=80=A6 *7.4. Spam* Calendar systems may receive JSCalendar files from untrusted sources, in particular as attachments to emails. This can be a vector for an attacker to inject spam into a user's calendar. This may confuse, annoy, and mislead users, or overwhelm their calendar with bogus events, preventing them from seeing legitimate ones. Heuristic, statistical or machine-learning-based filters can be effective in filtering out spam. Authentication mechanisms such as DKIM [RFC6376] can help establish the source of messages and associate the data with existing relationships (such as an address book contact). Misclassifications are always possible however, and providing a feedback mechanism for users to quickly correct this is advised. *7.5. Duplication* It is important for calendar systems to maintain the UID of an event when updating it to avoid unexpected duplication of events. When the UID changes, consumers of the data may not remove the previous version of the event if it has a different UID. This can lead to a confusing situation for the user, with many variations of the event and no indication of which one is correct. Care must be taken by consumers of the data to remove old events where possible to avoid an accidental denial-of-service attack due to the volume of data. *7.6. Time Zones* Events recur in a particular time zone. When this differs from the user's current time zone, it may unexpectedly cause an occurrence to shift in time for that user due to a daylight savings change in the event's time zone. A maliciously crafted event could attempt to confuse users with such an event to ensure a meeting is missed. > In the general body of the text, the treatment of recurring events MUS= T address > time zones and daylight savings. This is the stuff iCal didn't get rig= ht at > first and that lead to pain. Can you clarify a bit what change you are looking for here, if any? Do y= ou believe the current text in JSCalendar is ambiguous? A recurrence app= lies to the "start" property of the event, which is a local date-time. A= ll other properties (including "timeZone") are inherited unless overridd= en for a specific instance. So an event will essentially recur in its ti= me zone; if you need to translate this into UTC you'll of course need ti= me zone information and to account for daylight savings etc. Cheers, Neil. --c9116e7e33f04a42b5c5d8c86be3520b Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Phillip,
=

Thank you for the review and apologies for the= late reply; I have been on leave.

1) Spam
2) Duplication
3) Time Zones
4) Authentication

I have expanded the introduction to the security = considerations to mention (4) and added sections for (1)-(3); I include = the additions and alterations below. Please let me know if you believe t= his is insufficient:

7.  Security C= onsiderations

   Calendaring = and scheduling information is very privacy-sensitive.
&nbs= p;  Its transmission must be done carefully to protect it from poss= ible
   threats, such as eavesdropping, replay, = message insertion, deletion,
   modification, an= d man-in-the-middle attacks.

   T= he data being stored and transmitted may be used in systems with
   real world consequences.  For example, a home a= utomation system may
   turn an alarm on and off= .  Or a coworking space may charge money to
 &nb= sp; the organiser of an event that books one of their meeting rooms.
=
   Such systems must be careful to authenticate all= data they receive to
   prevent them from being= subverted.

   This document just= defines the data format; such considerations are
 &n= bsp; primarily the concern of the API or method of storage and
=
   transmission of such files.

=E2=80=A6 7.1-7.3 as before =E2=80=A6

7.4.  Spam

   Calendar = systems may receive JSCalendar files from untrusted sources,
   in particular as attachments to emails.  This can b= e a vector for an
   attacker to inject spam int= o a user's calendar.  This may confuse,
   = annoy, and mislead users, or overwhelm their calendar with bogus
   events, preventing them from seeing legitimate ones.=

   Heuristic, statistical or mac= hine-learning-based filters can be
   effective = in filtering out spam.  Authentication mechanisms such as
=
   DKIM [RFC6376] can help establish the source of messag= es and
   associate the data with existing relat= ionships (such as an address
   book contact).&n= bsp; Misclassifications are always possible however, and
&= nbsp;  providing a feedback mechanism for users to quickly correct = this is
   advised.

7.5.  Duplication

  = It is important for calendar systems to maintain the UID of an event
   when updating it to avoid unexpected duplicatio= n of events.  When the
   UID changes, cons= umers of the data may not remove the previous
  = version of the event if it has a different UID.  This can lead to = a
   confusing situation for the user, with many= variations of the event
   and no indication of= which one is correct.  Care must be taken by
 &= nbsp; consumers of the data to remove old events where possible to avoid= an
   accidental denial-of-service attack due t= o the volume of data.

7.6.  Time Zo= nes

   Events recur in a part= icular time zone.  When this differs from the
 &= nbsp; user's current time zone, it may unexpectedly cause an occurrence = to
   shift in time for that user due to a dayli= ght savings change in the
   event's time zone.&= nbsp; A maliciously crafted event could attempt to
 &= nbsp; confuse users with such an event to ensure a meeting is missed.

In the ge= neral body of the text, the treatment of recurring events MUST address
time zones and daylight savings. This is the stuff iCal did= n't get right at
first and that lead to pain.

Can you clarify a bit what change you are = looking for here, if any? Do you believe the current text in JSCalendar = is ambiguous? A recurrence applies to the "start" property of the event,= which is a local date-time. All other properties (including "timeZone")= are inherited unless overridden for a specific instance. So an event wi= ll essentially recur in its time zone; if you need to translate this int= o UTC you'll of course need time zone information and to account for day= light savings etc.

Cheers,
Ne= il.
--c9116e7e33f04a42b5c5d8c86be3520b-- From nobody Mon Mar 16 03:34:01 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530A23A227E; Mon, 16 Mar 2020 03:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 d-Zg0hh0hzDN; Mon, 16 Mar 2020 03:33:56 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 4E7773A227C; Mon, 16 Mar 2020 03:33:40 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id x11so15748331wrv.5; Mon, 16 Mar 2020 03:33:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xNlNpiu4Fr6lTgUkWHozYI+7EMFES/4dsx1GziakuTE=; b=fYoBOgD118K/zsopz1z/+nhcz2DeGSIFxyVzmZQPRgYjcLSlD5SSg+ooY04fO8Tby+ XJI/D745UnUPQt/20GhfOYEp+YHWxkcXKrja0ngu50ZnShNlIj1a8G7K9J96B8eFHxx7 yhN2B76h4A2HqpXJakakuMklg2hVE4+EAPogQzeoeDw4+hGnQKgXRzGfN8ZIOS9YAg9B QvNeqfp9EQ/dP30QTvBCZOsgolK0F2psUFBKoK+0nQqRaPwcbCeXaDMiYhyD2wIRbA5Y WWZm58xzOcDbYzU5N7rGNJoUmF7qHYPxrYN91sLmL5dpbuywoijZjjJ3mrkKtfAQ+h/c lUPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xNlNpiu4Fr6lTgUkWHozYI+7EMFES/4dsx1GziakuTE=; b=RZhcB1Aofp+oHJxkcMLP2Tf6JyvJVPblHX1l6Yhi68VMj4/vzDYOaz2eQoyV4uO8Hv z9sXig3pgBjju88TDGCJMjm+JEGMM8/QclOCgQDhmNrPRYwbZrynEoupLIaukgIjHCCT IAL65K2TTSttt+WC5GdHuptyQQV3HjtdFE9/uB6rJD9KAkF1iIr4x7VoIAW/y8GDuMZZ QoSrDCJzWUT1PpJQRQdGeDnX0R5ByQLr1sJFT5ZaT4G2VISo8eEv5ONOfXZOdUXRVqZW poU7dHr2xF1KDR7XW+df0sUmJoB4332IDfGGCVHTqEx46GpFWfIpWunYnVL3F7TgOdCP p/VQ== X-Gm-Message-State: ANhLgQ1RLj4N+QaG73eCmDnsglWIacJ4z6VMr1dFXR1idF7k+hhXDUQw Ox8wyqBn1r5sThGZyZTT/Oo= X-Google-Smtp-Source: ADFU+vsXihKuGg2gDd0tSf086W+KUfVOh2FEKQVRG5QXTH8O3TPsRH8tHg9Ef0+WJnCmvfsZ2BLV0g== X-Received: by 2002:a5d:55c7:: with SMTP id i7mr36230539wrw.252.1584354818340; Mon, 16 Mar 2020 03:33:38 -0700 (PDT) Received: from appleton.fritz.box ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id w9sm56706109wrn.35.2020.03.16.03.33.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Mar 2020 03:33:37 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Stewart Bryant In-Reply-To: <1EAC1CA8-82B2-4D2E-89D5-3562DA1CCC4B@mit.edu> Date: Mon, 16 Mar 2020 10:33:36 +0000 Cc: Stewart Bryant , Lou Berger , Watson Ladd , "draft-ietf-detnet-mpls.all@ietf.org" , DetNet WG , secdir , rtg-ads@ietf.org, sec-ads@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7A5A9066-7877-402A-9704-AD83AF4FD3D0@gmail.com> References: <4834047a-838c-9f4c-96cb-c9486c16826a@labn.net> <1EAC1CA8-82B2-4D2E-89D5-3562DA1CCC4B@mit.edu> To: Uri Blumenthal X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 10:33:59 -0000 Uri, That is a ridiculous position, and you flippancy demonstrates that. This technology fundamentally rests on MPLS and it is reasonable that = the reader of this RFC will understand MPLS and the security model it = uses before they implement or deploy it. Indeed I cannot think of any = implementor or operator that would not already have that knowledge = before taking on the task of building or running DN over MPLS. If SecDir reviews are to retain any credibility as expert reviews as = opposed to Genart random reader reviews they have to be carried out with = shared knowledge of both the security area and the draft=E2=80=99s host = area. I have been thinking for some time that there needs to be a fundamental = review of the security review process. Stewart > On 15 Mar 2020, at 22:44, Uri Blumenthal wrote: >=20 > I say yes - unless you expect a person who wants just one RFC to have = to read every cr^h^h stuff that came out of the routing area. >=20 > "Just do it" >=20 >=20 >> On Mar 15, 2020, at 17:39, Lou Berger wrote: >>=20 >> =EF=BB=BF >>> On 3/15/2020 5:22 PM, Watson Ladd wrote: >>>> On Sun, Mar 15, 2020 at 2:14 PM Lou Berger = wrote: >>>> Hi Watson, >>>>=20 >>>> I think Stewart's response really covers the main points. = DetNet is >>>> really just MPLS (and IP) with some specific forwarding behaviors = and >>>> queuing. The only thing I'd add, is I see DetNet in general as a >>>> specific form of policy based routing. (The general form of which = is >>>> pretty much as old as IP). >>> Then Stewart can put those points in the security considerations >>> section. What's the disadvantage of doing so? >>=20 >> At one level, it would be easiest for the authors to just put these = in. On the other hand, this would mean that every RFC produced in the = routing area will acquire similar notes, e.g., routing protocols are = currently built with a chain of trust model. Is this what the sec-dir = really is asking the routing area to do? >>=20 >> ADs, >>=20 >> any opinion on this? (for context, Stewart's response can be = found at: = https://mailarchive.ietf.org/arch/msg/detnet/-epL5Fb6bFIUltMrjH53C2316ZA/)= >>=20 >> Thanks, >>=20 >> Lou >>=20 >>>> Lou >>>>=20 >>>> On 3/12/2020 9:35 PM, Watson Ladd wrote: >>>>> On Thu, Mar 12, 2020 at 4:07 AM Lou Berger = wrote: >>>>>> Watson, >>>>>>=20 >>>>>> Can you provide context here? Can you be explicit on what you see = needs to >>>>>> be addressed (beyond what is in this document as well as related = rfcs)? >>>>> You have to talk about how the layers interact, and can't just say = the >>>>> lower level handles anything without any guide as to what needs to = be >>>>> provided by that lower layer. >>>>>=20 >>>>> I think my concerns about the assumptions this could be fixed by >>>>> saying. "All nodes are trusted and any of them can misbehave in = ways >>>>> that affect the network. If the MPLS layer cannot provide = sufficient >>>>> determinism, then the DetNet mechanisms won't work". I agree we >>>>> shoudn't require an entire massive security framework to be quoted >>>>> again here, but there must be some details of this embedding that = are >>>>> worth noting, and yet I don't see them called out in the security >>>>> considerations section. >>>>>=20 >>>>> Are there really no specific concerns about the interaction = between >>>>> DetNet and MPLS? >>>>>=20 >>>>>> Thank you, >>>>>> Lou >>>>>>=20 >>>>>>=20 >>>>>> ---------- >>>>>> On March 11, 2020 10:30:27 PM Watson Ladd = wrote: >>>>>>=20 >>>>>>> I don't see any reason why RFC 3552's guidelines shoudn't apply = to this draft. >>>>>>>=20 >>>>>>> If there is a MPLS exception I'd like to see the rules that = should be applied. >>>>>>>=20 >>>>>>> As is I don't see any reason why the assumptions can't be = explicitly >>>>>>> spelled out, either in the Security Considerations or elsewhere. >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> detnet mailing list >>>>>>> detnet@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/detnet >>>>>>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Mon Mar 16 04:29:59 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1683A2312 for ; Mon, 16 Mar 2020 04:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.362 X-Spam-Level: X-Spam-Status: No, score=-3.362 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofHCX6kNX9B5 for ; Mon, 16 Mar 2020 04:29:49 -0700 (PDT) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) (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 CB9843A2315 for ; Mon, 16 Mar 2020 04:29:48 -0700 (PDT) Received: from CMGW (unknown [10.9.0.13]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id 938E1215EDE for ; Mon, 16 Mar 2020 05:29:46 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id DnwIjc40gtoKZDnwIjK67e; Mon, 16 Mar 2020 05:29:46 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.2 cv=Qrsu5R6d c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10 a=SS2py6AdgQ4A:10 a=Vy_oeq2dmq0A:10 a=pGLkceISAAAA:8 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=Cqp5pYgmsLkxk-JPjJQA:9 a=PoGEmgZM-z0fy8Kv:21 a=uxxTjkePg4vJ2kl6:21 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=OIl2O9lwocrQeUdoZ9JNGm/oahCwRHwgpBUzGrQxx7c=; b=vwTlzRIo7CJNI6Ewjyu7KQd89r tIb4FuO5/3doHRrkPhgqybFyAY+fMH79UimB6rgUzlWBgY/YDivLPG9vRvuV+fVjhYMRq7DntwS4Z ftUVoYd9ja+8LPXc2bKkGanCW; Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:48460 helo=[11.5.0.140]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1jDnwI-002goz-51; Mon, 16 Mar 2020 05:29:46 -0600 From: Lou Berger To: Stewart Bryant CC: secdir , , , , DetNet WG Date: Mon, 16 Mar 2020 07:29:46 -0400 Message-ID: <170e31b5c10.277b.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <7A5A9066-7877-402A-9704-AD83AF4FD3D0@gmail.com> References: <4834047a-838c-9f4c-96cb-c9486c16826a@labn.net> <1EAC1CA8-82B2-4D2E-89D5-3562DA1CCC4B@mit.edu> <7A5A9066-7877-402A-9704-AD83AF4FD3D0@gmail.com> User-Agent: AquaMail/1.22.0-1511 (build: 102200004) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 72.66.11.201 X-Source-L: No X-Exim-ID: 1jDnwI-002goz-51 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net ([11.5.0.140]) [72.66.11.201]:48460 X-Source-Auth: lberger@labn.net X-Email-Count: 6 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 11:29:52 -0000 Stewart, I think a number of your responses are actually more general than mpls and have to do with how routers and routing protocols are built. these concepts that are now generally taught in classes, not rfcs... Lou ---------- On March 16, 2020 6:34:54 AM Stewart Bryant wrote: > Uri, > > That is a ridiculous position, and you flippancy demonstrates that. > > This technology fundamentally rests on MPLS and it is reasonable that the > reader of this RFC will understand MPLS and the security model it uses > before they implement or deploy it. Indeed I cannot think of any > implementor or operator that would not already have that knowledge before > taking on the task of building or running DN over MPLS. > > If SecDir reviews are to retain any credibility as expert reviews as > opposed to Genart random reader reviews they have to be carried out with > shared knowledge of both the security area and the draft’s host area. > > I have been thinking for some time that there needs to be a fundamental > review of the security review process. > > Stewart > >> On 15 Mar 2020, at 22:44, Uri Blumenthal wrote: >> >> I say yes - unless you expect a person who wants just one RFC to have to >> read every cr^h^h stuff that came out of the routing area. >> >> "Just do it" >> >> >>> On Mar 15, 2020, at 17:39, Lou Berger wrote: >>> >>>  >>>> On 3/15/2020 5:22 PM, Watson Ladd wrote: >>>>> On Sun, Mar 15, 2020 at 2:14 PM Lou Berger wrote: >>>>> Hi Watson, >>>>> >>>>> I think Stewart's response really covers the main points. DetNet is >>>>> really just MPLS (and IP) with some specific forwarding behaviors and >>>>> queuing. The only thing I'd add, is I see DetNet in general as a >>>>> specific form of policy based routing. (The general form of which is >>>>> pretty much as old as IP). >>>> Then Stewart can put those points in the security considerations >>>> section. What's the disadvantage of doing so? >>> >>> At one level, it would be easiest for the authors to just put these in. On >>> the other hand, this would mean that every RFC produced in the routing area >>> will acquire similar notes, e.g., routing protocols are currently built >>> with a chain of trust model. Is this what the sec-dir really is asking the >>> routing area to do? >>> >>> ADs, >>> >>> any opinion on this? (for context, Stewart's response can be found at: >>> https://mailarchive.ietf.org/arch/msg/detnet/-epL5Fb6bFIUltMrjH53C2316ZA/) >>> >>> Thanks, >>> >>> Lou >>> >>>>> Lou >>>>> >>>>> On 3/12/2020 9:35 PM, Watson Ladd wrote: >>>>>> On Thu, Mar 12, 2020 at 4:07 AM Lou Berger wrote: >>>>>>> Watson, >>>>>>> >>>>>>> Can you provide context here? Can you be explicit on what you see needs to >>>>>>> be addressed (beyond what is in this document as well as related rfcs)? >>>>>> You have to talk about how the layers interact, and can't just say the >>>>>> lower level handles anything without any guide as to what needs to be >>>>>> provided by that lower layer. >>>>>> >>>>>> I think my concerns about the assumptions this could be fixed by >>>>>> saying. "All nodes are trusted and any of them can misbehave in ways >>>>>> that affect the network. If the MPLS layer cannot provide sufficient >>>>>> determinism, then the DetNet mechanisms won't work". I agree we >>>>>> shoudn't require an entire massive security framework to be quoted >>>>>> again here, but there must be some details of this embedding that are >>>>>> worth noting, and yet I don't see them called out in the security >>>>>> considerations section. >>>>>> >>>>>> Are there really no specific concerns about the interaction between >>>>>> DetNet and MPLS? >>>>>> >>>>>>> Thank you, >>>>>>> Lou >>>>>>> >>>>>>> >>>>>>> ---------- >>>>>>> On March 11, 2020 10:30:27 PM Watson Ladd wrote: >>>>>>> >>>>>>>> I don't see any reason why RFC 3552's guidelines shoudn't apply to this draft. >>>>>>>> >>>>>>>> If there is a MPLS exception I'd like to see the rules that should be applied. >>>>>>>> >>>>>>>> As is I don't see any reason why the assumptions can't be explicitly >>>>>>>> spelled out, either in the Security Considerations or elsewhere. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> detnet mailing list >>>>>>>> detnet@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/detnet >>>>>>>> >>>> >>>> >>> >>> _______________________________________________ >>> secdir mailing list >>> secdir@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdir >>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet From nobody Mon Mar 16 05:23:02 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0A33A0041; Mon, 16 Mar 2020 05:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXs2-SRUW8bC; Mon, 16 Mar 2020 05:22:58 -0700 (PDT) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) (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 82D8D3A0040; Mon, 16 Mar 2020 05:22:52 -0700 (PDT) Received: from w92exedge3.exchange.mit.edu (W92EXEDGE3.EXCHANGE.MIT.EDU [18.7.73.15]) by outgoing-exchange-1.mit.edu (8.14.7/8.12.4) with ESMTP id 02GCMR1t015957; Mon, 16 Mar 2020 08:22:52 -0400 Received: from w92expo31.exchange.mit.edu (18.7.74.43) by w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 16 Mar 2020 08:22:27 -0400 Received: from oc11expo31.exchange.mit.edu (18.9.4.104) by w92expo31.exchange.mit.edu (18.7.74.43) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 16 Mar 2020 08:22:35 -0400 Received: from oc11expo31.exchange.mit.edu ([18.9.4.104]) by oc11expo31.exchange.mit.edu ([18.9.4.104]) with mapi id 15.00.1365.000; Mon, 16 Mar 2020 08:22:35 -0400 From: Uri Blumenthal To: Stewart Bryant CC: Lou Berger , Watson Ladd , "draft-ietf-detnet-mpls.all@ietf.org" , DetNet WG , secdir , "rtg-ads@ietf.org" , "sec-ads@ietf.org" Thread-Topic: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-05 Thread-Index: AQHV+F6FNSfnEeGpGUm730Plf9JWd6hGAciAgARt0QCAAAJSAIAABLYAgAASZQCAAMX9AIAAHnIA Date: Mon, 16 Mar 2020 12:22:35 +0000 Message-ID: References: <7A5A9066-7877-402A-9704-AD83AF4FD3D0@gmail.com> In-Reply-To: <7A5A9066-7877-402A-9704-AD83AF4FD3D0@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/signed; boundary="Apple-Mail-970F7E30-B15D-4C08-8DC6-6128BBACCEF1"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 12:23:01 -0000 --Apple-Mail-970F7E30-B15D-4C08-8DC6-6128BBACCEF1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SUVURiBwb3NpdGlvbiAoYWRkIGZhdCBhcyBJIHJlbWVtYmVyKSByZWdhcmRpbmcgUkZDcyBoYXMg YmVlbiB0aGF0IFJGQ3Mgc2hvdWxkIHByb3ZpZGUgd2l0aCBldmVyeXRoaW5nIGluZm9ybWF0aW9u IGZvciBhIHJlYXNvbmFibGUgZGV2ZWxvcGVyIHRvIGltcGxlbWVudCBjb3JyZWN0bHkgYW5kIHNl Y3VyZWx5IHRoZSBzdGFuZGFyZCB0aGV5IGRlZmluZSwgYW5kIHByb3ZpZGUgZW5vdWdoIGluZm9y bWF0aW9uIGZvciB0aGUgcGVyc29uIHdobyB3aWxsIGRlcGxveSBhIGNvbXBsaWFudCBpbXBsZW1l bnRhdGlvbiB0byBkbyB0aGF0IGNvcnJlY3RseSBhbmQgc2VjdXJlbHkuDQoNCk9uZSBwdXJwb3Nl IG9mIFNlY3VyaXR5IFJldmlldyBpcyB0byBlbnN1cmUgdGhhdCBhIHBlcnNvbiBkb2Vzbid0IGhh dmUgdG8gYmUgYW4gZXhwZXJ0IGluIHRoZSBmaWVsZCB0byBkZWFsIHdpdGggdGhlIHByb3Bvc2Vk IGRvY3VtZW50Lg0KDQpJbiBhIGZsaXBwYW50IHdheSwgaWYgdXNpbmcgeW91ciBzdHVmZiBpcyBy ZXF1aXJlcyBzcGVjaWFsIGNsYXNzZXMgLSBwZXJoYXBzIGl0IGJlbG9uZ3MgdG8gYSBib29rIHJh dGhlciB0aGFuIGFuIFJGQy4NCg0KSW4gYSBub24tZmxpcHBhbnQgd2F5IC0gd2hhdCdzIHRoZSBw cm9ibGVtIGluIG1lbnRpb25pbmcgdGhlIGlzc3VlcyBhbmQgcHJvdmlkaW5nIHRoZSBhcHByb3By aWF0ZSByZWZlcmVuY2VzPyBBICJub3JtYWwiIFJGQyBjYW5ub3QgYmUgc2VsZi1jb250YWluZWQs IGJ1dCBpdCdzIHVucmVhc29uYWJsZSB0byBlcGVjdCBhIHJlYWRlciB0byBqdXN0ICJrbm93IiB3 aGVyZSBhbGwgdGhlIG9taXR0ZWQgdGhpbmdzIGFyZSBkZXNjcmliZWQuIA0KDQo+IE9uIE1hciAx NiwgMjAyMCwgYXQgMDY6MzMsIFN0ZXdhcnQgQnJ5YW50IDxzdGV3YXJ0LmJyeWFudEBnbWFpbC5j b20+IHdyb3RlOg0KPiANCj4g77u/VXJpLA0KPiANCj4gVGhhdCBpcyBhIHJpZGljdWxvdXMgcG9z aXRpb24sIGFuZCB5b3UgZmxpcHBhbmN5IGRlbW9uc3RyYXRlcyB0aGF0Lg0KPiANCj4gVGhpcyB0 ZWNobm9sb2d5IGZ1bmRhbWVudGFsbHkgcmVzdHMgb24gTVBMUyBhbmQgaXQgaXMgcmVhc29uYWJs ZSB0aGF0IHRoZSByZWFkZXIgb2YgdGhpcyBSRkMgd2lsbCB1bmRlcnN0YW5kIE1QTFMgYW5kIHRo ZSBzZWN1cml0eSBtb2RlbCBpdCB1c2VzIGJlZm9yZSB0aGV5IGltcGxlbWVudCBvciBkZXBsb3kg aXQuIEluZGVlZCBJIGNhbm5vdCB0aGluayBvZiBhbnkgaW1wbGVtZW50b3Igb3Igb3BlcmF0b3Ig dGhhdCB3b3VsZCBub3QgYWxyZWFkeSBoYXZlIHRoYXQga25vd2xlZGdlIGJlZm9yZSB0YWtpbmcg b24gdGhlIHRhc2sgb2YgYnVpbGRpbmcgb3IgcnVubmluZyBETiBvdmVyIE1QTFMuDQo+IA0KPiBJ ZiBTZWNEaXIgcmV2aWV3cyBhcmUgdG8gcmV0YWluIGFueSBjcmVkaWJpbGl0eSBhcyBleHBlcnQg cmV2aWV3cyBhcyBvcHBvc2VkIHRvIEdlbmFydCByYW5kb20gcmVhZGVyIHJldmlld3MgdGhleSBo YXZlIHRvIGJlIGNhcnJpZWQgb3V0IHdpdGggc2hhcmVkIGtub3dsZWRnZSBvZiBib3RoIHRoZSBz ZWN1cml0eSBhcmVhIGFuZCB0aGUgZHJhZnTigJlzIGhvc3QgYXJlYS4NCj4gDQo+IEkgaGF2ZSBi ZWVuIHRoaW5raW5nIGZvciBzb21lIHRpbWUgdGhhdCB0aGVyZSBuZWVkcyB0byBiZSBhIGZ1bmRh bWVudGFsIHJldmlldyBvZiB0aGUgc2VjdXJpdHkgcmV2aWV3IHByb2Nlc3MuDQo+IA0KPiBTdGV3 YXJ0DQo+IA0KPj4gT24gMTUgTWFyIDIwMjAsIGF0IDIyOjQ0LCBVcmkgQmx1bWVudGhhbCA8dXJp QG1pdC5lZHU+IHdyb3RlOg0KPj4gDQo+PiBJIHNheSB5ZXMgLSB1bmxlc3MgeW91IGV4cGVjdCBh IHBlcnNvbiB3aG8gd2FudHMganVzdCBvbmUgUkZDIHRvIGhhdmUgdG8gcmVhZCBldmVyeSBjcl5o Xmggc3R1ZmYgdGhhdCBjYW1lIG91dCBvZiB0aGUgcm91dGluZyBhcmVhLg0KPj4gDQo+PiAiSnVz dCBkbyBpdCINCj4+IA0KPj4gDQo+Pj4+IE9uIE1hciAxNSwgMjAyMCwgYXQgMTc6MzksIExvdSBC ZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+IHdyb3RlOg0KPj4+IA0KPj4+IO+7vw0KPj4+PiBPbiAz LzE1LzIwMjAgNToyMiBQTSwgV2F0c29uIExhZGQgd3JvdGU6DQo+Pj4+PiBPbiBTdW4sIE1hciAx NSwgMjAyMCBhdCAyOjE0IFBNIExvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+IHdyb3RlOg0K Pj4+Pj4gSGkgV2F0c29uLA0KPj4+Pj4gDQo+Pj4+PiAgICBJIHRoaW5rIFN0ZXdhcnQncyByZXNw b25zZSByZWFsbHkgY292ZXJzIHRoZSBtYWluIHBvaW50cy4gRGV0TmV0IGlzDQo+Pj4+PiByZWFs bHkganVzdCBNUExTIChhbmQgSVApIHdpdGggc29tZSBzcGVjaWZpYyBmb3J3YXJkaW5nIGJlaGF2 aW9ycyBhbmQNCj4+Pj4+IHF1ZXVpbmcuICBUaGUgb25seSB0aGluZyBJJ2QgYWRkLCBpcyBJIHNl ZSBEZXROZXQgaW4gZ2VuZXJhbCBhcyBhDQo+Pj4+PiBzcGVjaWZpYyBmb3JtIG9mIHBvbGljeSBi YXNlZCByb3V0aW5nLiAoVGhlIGdlbmVyYWwgZm9ybSBvZiB3aGljaCBpcw0KPj4+Pj4gcHJldHR5 IG11Y2ggYXMgb2xkIGFzIElQKS4NCj4+Pj4gVGhlbiBTdGV3YXJ0IGNhbiBwdXQgdGhvc2UgcG9p bnRzIGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucw0KPj4+PiBzZWN0aW9uLiBXaGF0J3Mg dGhlIGRpc2FkdmFudGFnZSBvZiBkb2luZyBzbz8NCj4+PiANCj4+PiBBdCBvbmUgbGV2ZWwsIGl0 IHdvdWxkIGJlIGVhc2llc3QgZm9yIHRoZSBhdXRob3JzIHRvIGp1c3QgcHV0IHRoZXNlIGluLiAg T24gdGhlIG90aGVyIGhhbmQsIHRoaXMgd291bGQgbWVhbiB0aGF0IGV2ZXJ5IFJGQyBwcm9kdWNl ZCBpbiB0aGUgcm91dGluZyBhcmVhIHdpbGwgYWNxdWlyZSBzaW1pbGFyIG5vdGVzLCBlLmcuLCBy b3V0aW5nIHByb3RvY29scyBhcmUgY3VycmVudGx5IGJ1aWx0IHdpdGggYSBjaGFpbiBvZiB0cnVz dCBtb2RlbC4gIElzIHRoaXMgd2hhdCB0aGUgc2VjLWRpciByZWFsbHkgaXMgYXNraW5nIHRoZSBy b3V0aW5nIGFyZWEgdG8gZG8/DQo+Pj4gDQo+Pj4gQURzLA0KPj4+IA0KPj4+ICAgYW55IG9waW5p b24gb24gdGhpcz8gICAgIChmb3IgY29udGV4dCwgU3Rld2FydCdzIHJlc3BvbnNlIGNhbiBiZSBm b3VuZCBhdDogaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9kZXRuZXQvLWVw TDVGYjZiRklVbHRNcmpINTNDMjMxNlpBLykNCj4+PiANCj4+PiBUaGFua3MsDQo+Pj4gDQo+Pj4g TG91DQo+Pj4gDQo+Pj4+PiBMb3UNCj4+Pj4+IA0KPj4+Pj4gT24gMy8xMi8yMDIwIDk6MzUgUE0s IFdhdHNvbiBMYWRkIHdyb3RlOg0KPj4+Pj4+IE9uIFRodSwgTWFyIDEyLCAyMDIwIGF0IDQ6MDcg QU0gTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4gd3JvdGU6DQo+Pj4+Pj4+IFdhdHNvbiwN Cj4+Pj4+Pj4gDQo+Pj4+Pj4+IENhbiB5b3UgcHJvdmlkZSBjb250ZXh0IGhlcmU/IENhbiB5b3Ug YmUgZXhwbGljaXQgb24gd2hhdCB5b3Ugc2VlIG5lZWRzIHRvDQo+Pj4+Pj4+IGJlIGFkZHJlc3Nl ZCAoYmV5b25kIHdoYXQgaXMgaW4gdGhpcyBkb2N1bWVudCBhcyB3ZWxsIGFzIHJlbGF0ZWQgcmZj cyk/DQo+Pj4+Pj4gWW91IGhhdmUgdG8gdGFsayBhYm91dCBob3cgdGhlIGxheWVycyBpbnRlcmFj dCwgYW5kIGNhbid0IGp1c3Qgc2F5IHRoZQ0KPj4+Pj4+IGxvd2VyIGxldmVsIGhhbmRsZXMgYW55 dGhpbmcgd2l0aG91dCBhbnkgZ3VpZGUgYXMgdG8gd2hhdCBuZWVkcyB0byBiZQ0KPj4+Pj4+IHBy b3ZpZGVkIGJ5IHRoYXQgbG93ZXIgbGF5ZXIuDQo+Pj4+Pj4gDQo+Pj4+Pj4gSSB0aGluayBteSBj b25jZXJucyBhYm91dCB0aGUgYXNzdW1wdGlvbnMgdGhpcyBjb3VsZCBiZSBmaXhlZCBieQ0KPj4+ Pj4+IHNheWluZy4gIkFsbCBub2RlcyBhcmUgdHJ1c3RlZCBhbmQgYW55IG9mIHRoZW0gY2FuIG1p c2JlaGF2ZSBpbiB3YXlzDQo+Pj4+Pj4gdGhhdCBhZmZlY3QgdGhlIG5ldHdvcmsuICBJZiB0aGUg TVBMUyBsYXllciBjYW5ub3QgcHJvdmlkZSBzdWZmaWNpZW50DQo+Pj4+Pj4gZGV0ZXJtaW5pc20s IHRoZW4gdGhlIERldE5ldCBtZWNoYW5pc21zIHdvbid0IHdvcmsiLiAgSSBhZ3JlZSB3ZQ0KPj4+ Pj4+IHNob3Vkbid0IHJlcXVpcmUgYW4gZW50aXJlIG1hc3NpdmUgc2VjdXJpdHkgZnJhbWV3b3Jr IHRvIGJlIHF1b3RlZA0KPj4+Pj4+IGFnYWluIGhlcmUsIGJ1dCB0aGVyZSBtdXN0IGJlIHNvbWUg ZGV0YWlscyBvZiB0aGlzIGVtYmVkZGluZyB0aGF0IGFyZQ0KPj4+Pj4+IHdvcnRoIG5vdGluZywg YW5kIHlldCBJIGRvbid0IHNlZSB0aGVtIGNhbGxlZCBvdXQgaW4gdGhlIHNlY3VyaXR5DQo+Pj4+ Pj4gY29uc2lkZXJhdGlvbnMgc2VjdGlvbi4NCj4+Pj4+PiANCj4+Pj4+PiBBcmUgdGhlcmUgcmVh bGx5IG5vIHNwZWNpZmljIGNvbmNlcm5zIGFib3V0IHRoZSBpbnRlcmFjdGlvbiBiZXR3ZWVuDQo+ Pj4+Pj4gRGV0TmV0IGFuZCBNUExTPw0KPj4+Pj4+IA0KPj4+Pj4+PiBUaGFuayB5b3UsDQo+Pj4+ Pj4+IExvdQ0KPj4+Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+IC0tLS0tLS0tLS0NCj4+Pj4+Pj4g T24gTWFyY2ggMTEsIDIwMjAgMTA6MzA6MjcgUE0gV2F0c29uIExhZGQgPHdhdHNvbmJsYWRkQGdt YWlsLmNvbT4gd3JvdGU6DQo+Pj4+Pj4+IA0KPj4+Pj4+Pj4gSSBkb24ndCBzZWUgYW55IHJlYXNv biB3aHkgUkZDIDM1NTIncyBndWlkZWxpbmVzIHNob3Vkbid0IGFwcGx5IHRvIHRoaXMgZHJhZnQu DQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IElmIHRoZXJlIGlzIGEgTVBMUyBleGNlcHRpb24gSSdkIGxp a2UgdG8gc2VlIHRoZSBydWxlcyB0aGF0IHNob3VsZCBiZSBhcHBsaWVkLg0KPj4+Pj4+Pj4gDQo+ Pj4+Pj4+PiBBcyBpcyBJIGRvbid0IHNlZSBhbnkgcmVhc29uIHdoeSB0aGUgYXNzdW1wdGlvbnMg Y2FuJ3QgYmUgZXhwbGljaXRseQ0KPj4+Pj4+Pj4gc3BlbGxlZCBvdXQsIGVpdGhlciBpbiB0aGUg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgb3IgZWxzZXdoZXJlLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+ Pj4gZGV0bmV0IG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4gZGV0bmV0QGlldGYub3JnDQo+Pj4+Pj4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RldG5ldA0KPj4+Pj4+Pj4g DQo+Pj4+IA0KPj4+PiANCj4+PiANCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4+IHNlY2RpciBtYWlsaW5nIGxpc3QNCj4+PiBzZWNkaXJAaWV0 Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NlY2Rpcg0K Pj4+IHdpa2k6IGh0dHA6Ly90b29scy5pZXRmLm9yZy9hcmVhL3NlYy90cmFjL3dpa2kvU2VjRGly UmV2aWV3DQo+IA0K --Apple-Mail-970F7E30-B15D-4C08-8DC6-6128BBACCEF1 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCGsw ggQkMIICjKADAgECAgRbkXGgMA0GCSqGSIb3DQEBDAUAMBoxGDAWBgNVBAMMD0ZvcmVzdCBDQSBS U0EgNDAeFw0xODA5MDYxODI3NDRaFw0yMTA5MDYxODI3NDRaMA4xDDAKBgNVBAMMA1VyaTCCAaIw DQYJKoZIhvcNAQEBBQADggGPADCCAYoCggGBANJi8+lfrSCcWThbn0vQzXsW7AYTyTZSo/pv/274 xD/t1rpn/X/vegP2lSfr+SRJ4oJ+51MFJvRl/sAveroDN8gGrFyYaCg5ZsOMqksCmLha4Ttgk04L I/aqrPGuzF1OVgjhi6WrnFr80KS6sy3MWzYIYV6G1FycKEup5snMr1B1WWzFKOwSslnJwvCuHu2W Tc5OzJKPtxMcDIS9y6VOZTzsJUFe0bRiw0LICDBcB3fgKCvYMcDfke0pw13I4O7wEG40s9E6rTIj Q0H1LVk69pSo1ikzpikl5W8pXUQQrSmjHqhFn/Q+PwSzHSOralN0p1UMziUv57lgvvZbTaH1ooqq MZBuTed0xLye3w+h9+/iqDY4B7lFqbegzseBh7/Q6KdtfpkwwI7xSpZEME/V77KAMw+ipb+Itbij Bi3r/t81fDW8eitIAbVtalpFROlYIaZnIIohOZRyVjn2unZ+lj3jDKsDq53g+oleo+Ruszlt8nju 6uKhzE7bdX1xJuvCtwIDAQABo34wfDAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFIDAWBgNV HREEDzANgQt1cmlAbWl0LmVkdTAdBgNVHQ4EFgQU2p+nwSyQFM6byFBhc7oIZephJbcwJQYDVR0l BB4wHAYIKwYBBQUHAwQGCisGAQQBgjcKAwQGBFUdJQAwDQYJKoZIhvcNAQEMBQADggGBAH/zzG9P gU+ogFbc75JpUK0amUUtmtSsGDe4599GolCDiuPHrnbCGcaNc9aQjRaP3Q3aU7BB3aOjwssjQSN0 tsfZD8p+XPny/odhDSwS/25jCg0dVasd8q+Jd1S1g34RGUqPQ+5ofTrBSEkHBdLdJOnxBGo9GRzA yiDg34r6zK6BXNYv2GdqRk+GGGvL/w3CDR+ih36ZDBxw/EO19oH/aV4+mVlcRI6aoj4KMb+h4zMY S8jLDArIZSce4EWzJqxKVcX6Q7CE/0Br/7R8Ixs+vt5YKPUVpEbFM6koH624GDQYKM2kzXBnwYgS /jvl02KUx6uNmIgo+ufK2l7sc83vRLxBTJKhT0/USVkwu9uzg2zHJeGBZ4pmDhkIVkGcamW7KPYZ dgOz8zAOy8Ntk7GebPn85XuPcQS9UntdO61X1EyEXg4Ixl/qapidfJQfdCqEeZZXpaV3WKWE8u1l fNB00mC0/xhG3bikQxl3O20nyPjXvl6VZFzglsPRy1Xh5L//rzCCBD8wggKnoAMCAQICBFuRckIw DQYJKoZIhvcNAQEMBQAwGjEYMBYGA1UEAwwPRm9yZXN0IENBIFJTQSA0MB4XDTE4MDkwNjE4MzAy NloXDTIxMDkwNjE4MzAyNlowDjEMMAoGA1UEAwwDVXJpMIIBojANBgkqhkiG9w0BAQEFAAOCAY8A MIIBigKCAYEAtZvms8stf9xj5w7pjYzgmHe7TH0eX/q3buMBqdLufhFuqCizZPhXJmSbue8WHm8H HO7SHQPUqIqbPOMIQfAL8nwWhuTfsN5nrtFW77eiNsEexRNkbhw/U6RzamCGl6xQmUxOD0nabEmd Xdces+rjtzlvjpNHI7xrR32ee4JuGTjwAWlAHPtBC8TqiOR/ysR2K2umk5BkjCEWV9kDfGklfKmu IhuCzzpTvN3AnLMX9kP9IY6E9B8OsLOhkOFBbAMzyqkXibtPWluqOnYW3V3MVc9H1ir6sGLF5onW lHLEorI51WuHlfVO8WJRYwhrzQIIAWAYheZaH2wdb87Kw6o4JbHDLTDJHHrBDwfqa5OtFTeQNWCD JPdHa4xfFpjnMTzP18POa5C6QN5XBpTFsfccWyEdt+ykGB2FMzhB3GgMVRfWPgo8TgxVwU9MHt8s vmxj8KMUd7afSJBOjMIRPZ6gi8Vja9SR9+Hj/YWgpKZMHhI7irJVpWF++7hhfxxDbgDBAgMBAAGj gZgwgZUwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBsAwFgYDVR0RBA8wDYELdXJpQG1pdC5l ZHUwHQYDVR0OBBYEFK3WLENy4CH330dGZEWchN+L1r28MD4GA1UdJQQ3MDUGCCsGAQUFBwMCBggr BgEFBQcDAwYKKwYBBAGCNwoDDAYJKoZIhvcvAQEFBggrBgEFBQcDBDANBgkqhkiG9w0BAQwFAAOC AYEACYbThcFo+JTQNP5UacMtYogWU/yOx5GBLSNNa5cpvoRrOJc9CUDfzfnrd7IhDLXvnFUYNt3i oyU13LKRoPsp/YYuZ2CBI1om9g27SSqqEcOom0eojIKkPNw+sJzYVl7Dz2I7f9DHN6nEC9BeT8Do rjuq67UOlZZw0YvlvCmtMI4xJ7CUM8NrphoeRN18OnbwmkHWIYnYwdxipTJ8oLWi5EbKaUEYyLlC JWd6o9vH8cFNzsViPUl9POxBtX++o5KxtW7/JQwrQt3uFubF6rHQag6HDeXcXSyI0DmL8MrfVtHi Ma2bN+7z8N9Wnuvx8v0qlqfwd+uhmP7OvD32PuzjQxuGyPd43DZazlMhY9IRpSSCPhdbxzS3YwKr jnTZlKGwPiYCmiQ0XSEW3K64Exe4t+jrkBReocr9ccslB4d4XhxQPdAvUdI43xGMbnFea7pyTDyP b0z1vMrYt6dAguU0QTgRZsPFoIldK70ILvncq9amhxuQ4Uw+u2WUXiYba2R1MYICoTCCAp0CAQEw IjAaMRgwFgYDVQQDDA9Gb3Jlc3QgQ0EgUlNBIDQCBFuRckIwDQYJYIZIAWUDBAIBBQCggdEwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwMzE2MTIyMjM0WjAvBgkq hkiG9w0BCQQxIgQgoD/Asl3/PhbriFmQFdWTySjX7UrcEgI6UCi+Y53axwkwMQYJKwYBBAGCNxAE MSQwIjAaMRgwFgYDVQQDDA9Gb3Jlc3QgQ0EgUlNBIDQCBFuRcaAwMwYLKoZIhvcNAQkQAgsxJKAi MBoxGDAWBgNVBAMMD0ZvcmVzdCBDQSBSU0EgNAIEW5FxoDANBgkqhkiG9w0BAQEFAASCAYAmjb5R Knv59b9sJSk+DA0D1TchcSI0Y2Eh/UgIliDGMbe0SrT9bPt4hPaw9+/7qiLstwTzls68RPbwFj9z YH8CSCwUCvmXYBWDCYfR0sNF7/eaTRl40+Z7GvVfRRAJVbj7x5lu5rvEkMY1ay7x+To4wFrpXgm0 Ic56CUTh1a8Oeki3ZZuIhJ52gcQCj5b4QykNmT68XTRPNtGUhlt9EZPC9OfkgNuDUOH69GjK9ilv LLlK4PVzRop9KHffnfkX3FSMKp1ek6HopHxHex0i5N+/A808EoRS5eMtRkxf0DJVYVyd81EPvoKI tO38mScT2pB005xIm0zrlwFHdEtqJguzDm86yXGhuE4MzlGhjrIP2xlppxZs3npgSea6n4NFj9wD wiVbJRFgsfR/gVybVdvbo+qM24tOcetFCElY8QVdVP+nsa+1Y1DyOKF6CHnF41D7AK23lhg3KSqH zsCLSpeu3C5rvcK59iLUwzp9/vQHJxsWaxJYAehE834GbOaCoesAAAAAAAA= --Apple-Mail-970F7E30-B15D-4C08-8DC6-6128BBACCEF1-- From nobody Mon Mar 16 07:01:18 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25703A08B9; Mon, 16 Mar 2020 07:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 HtDGKPuxBWzQ; Mon, 16 Mar 2020 07:01:14 -0700 (PDT) Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) (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 9D49D3A08B6; Mon, 16 Mar 2020 07:01:14 -0700 (PDT) Received: by mail-wr1-x444.google.com with SMTP id s5so21423103wrg.3; Mon, 16 Mar 2020 07:01:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ijVwz8xkjXm3uu/e2ozPJTuwLwWzt462QQPPTXacikI=; b=F03xxybDxlB4f0fY3TnYPIOJrRiigAmsjfmzPxLDZfM8kA6dliuoAdRZg2OirYi55O 9klmw4P6XVncMc5n74rn3ZH1Fzgn4XHIZnNuvMnHbWuakwsy5q/avZnD8zQwhlCtGB6O kC2clFtIxxE6fmHDGL+2S7Uwdjt9oGizzxQfC22eR6mO8va54gEawO1MVglpf5gO+JuE dyQ7Ezq5SzKzKKLdLrf44Qn70vTDbJCk80g5SbbQNy8UWnjlOMJSJWm1+loxsEQpgcOB tdSiR8vWydqV/1xdAi2UdnyBSD7fRGchunbDkCgzsdBwGszSIwLZ+WIPCIvJNNSb/6C8 +s4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ijVwz8xkjXm3uu/e2ozPJTuwLwWzt462QQPPTXacikI=; b=fs3iCHGnjgxBtWGSx+bk1c+DC5RqIK/KumMvT41wwcWUvP6XEO74mPxyNrUV4bNJr/ 6eDjBoW3yqfyb8/qG05EVYtrZcrStmyz10HfrlKvZgPrn1hjS8+qAsRa1FBhBpws5+Lf /fj/moIb7+5nnvqQQJl/DPNU3jWaafLyxxHKm+O3TkiCL0J/O4dPmlHtzIsYDerW+36Y +71LzbI6mZoDUJMXES/BaRUkB1OFMN7aUdbeX5BiJ1DSbKbOBPOy6tnctooTdunTENN1 539kd6eeNHCOf20dYNm+JnuksBQJTzyr1O6Y7xBDcxIG/otszuaeEcSrLhF5SPchHrG5 D5Jg== X-Gm-Message-State: ANhLgQ1DSO+uo4kEfFN4bxoaNail/O4V0lPVHRa8A8tN0rb0/5TpzhF2 in8Vyw4dpZQ86nGjjg9FDAY= X-Google-Smtp-Source: ADFU+vt1zTCu6ZgJ6MKOC4/QtZKIYEpx8UNtdLKpUWmvNcK3jxSXf/RZsbeeKTeZTw6pZkxeQF17Fw== X-Received: by 2002:adf:f081:: with SMTP id n1mr3956961wro.161.1584367272919; Mon, 16 Mar 2020 07:01:12 -0700 (PDT) Received: from [192.168.178.42] ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id o23sm64295wro.23.2020.03.16.07.01.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Mar 2020 07:01:11 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Stewart Bryant In-Reply-To: Date: Mon, 16 Mar 2020 14:00:40 +0000 Cc: Stewart Bryant , Lou Berger , Watson Ladd , "draft-ietf-detnet-mpls.all@ietf.org" , DetNet WG , secdir , "rtg-ads@ietf.org" , "sec-ads@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <96BB26AA-3314-4E0A-98F3-4F2E93F1D9FF@gmail.com> References: <7A5A9066-7877-402A-9704-AD83AF4FD3D0@gmail.com> To: Uri Blumenthal X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 14:01:17 -0000 The requirement is NOT for a draft to provide the security analysis of = all of all of the technologies that it calls up. It is, I believe, to = describe the deltas that apply to the new idea. Anything else and the = text would be a security analysis with a short technology preamble. We are describing a technology that is overlaid on MPLS. We should not = need to describe the security model of MPLS, but instead confine our = remarks to issues that specifically apply to the additional technology = we are describing. Early in the document we call up RFC3031 and RFC3032, the fundamental = MPLS RFCs. They are in section 3.1 the first part of the serious = technical discussion. In my view these establish a baseline of = understand that the reader is expected to have. It is important to realise, as I have said before, that without = understanding that baseline the rest of the document is meaningless. Regards Stewart BTW It might be as well if you refrained from illustrating the lack of = professionalism that the security area applies to its reviews by = continuing with the flippancy. There is a serious point that needs to be = debated here about what assumptions are a given and what assumptions = need to be spelled out when modifying or layering a technology. =20 > On 16 Mar 2020, at 12:22, Uri Blumenthal wrote: >=20 > IETF position (add fat as I remember) regarding RFCs has been that = RFCs should provide with everything information for a reasonable = developer to implement correctly and securely the standard they define, = and provide enough information for the person who will deploy a = compliant implementation to do that correctly and securely. >=20 > One purpose of Security Review is to ensure that a person doesn't have = to be an expert in the field to deal with the proposed document. >=20 > In a flippant way, if using your stuff is requires special classes - = perhaps it belongs to a book rather than an RFC. >=20 > In a non-flippant way - what's the problem in mentioning the issues = and providing the appropriate references? A "normal" RFC cannot be = self-contained, but it's unreasonable to epect a reader to just "know" = where all the omitted things are described.=20 >=20 >> On Mar 16, 2020, at 06:33, Stewart Bryant = wrote: >>=20 >> =EF=BB=BFUri, >>=20 >> That is a ridiculous position, and you flippancy demonstrates that. >>=20 >> This technology fundamentally rests on MPLS and it is reasonable that = the reader of this RFC will understand MPLS and the security model it = uses before they implement or deploy it. Indeed I cannot think of any = implementor or operator that would not already have that knowledge = before taking on the task of building or running DN over MPLS. >>=20 >> If SecDir reviews are to retain any credibility as expert reviews as = opposed to Genart random reader reviews they have to be carried out with = shared knowledge of both the security area and the draft=E2=80=99s host = area. >>=20 >> I have been thinking for some time that there needs to be a = fundamental review of the security review process. >>=20 >> Stewart >>=20 >>> On 15 Mar 2020, at 22:44, Uri Blumenthal wrote: >>>=20 >>> I say yes - unless you expect a person who wants just one RFC to = have to read every cr^h^h stuff that came out of the routing area. >>>=20 >>> "Just do it" >>>=20 >>>=20 >>>>> On Mar 15, 2020, at 17:39, Lou Berger wrote: >>>>=20 >>>> =EF=BB=BF >>>>> On 3/15/2020 5:22 PM, Watson Ladd wrote: >>>>>> On Sun, Mar 15, 2020 at 2:14 PM Lou Berger = wrote: >>>>>> Hi Watson, >>>>>>=20 >>>>>> I think Stewart's response really covers the main points. = DetNet is >>>>>> really just MPLS (and IP) with some specific forwarding behaviors = and >>>>>> queuing. The only thing I'd add, is I see DetNet in general as a >>>>>> specific form of policy based routing. (The general form of which = is >>>>>> pretty much as old as IP). >>>>> Then Stewart can put those points in the security considerations >>>>> section. What's the disadvantage of doing so? >>>>=20 >>>> At one level, it would be easiest for the authors to just put these = in. On the other hand, this would mean that every RFC produced in the = routing area will acquire similar notes, e.g., routing protocols are = currently built with a chain of trust model. Is this what the sec-dir = really is asking the routing area to do? >>>>=20 >>>> ADs, >>>>=20 >>>> any opinion on this? (for context, Stewart's response can be = found at: = https://mailarchive.ietf.org/arch/msg/detnet/-epL5Fb6bFIUltMrjH53C2316ZA/)= >>>>=20 >>>> Thanks, >>>>=20 >>>> Lou >>>>=20 >>>>>> Lou >>>>>>=20 >>>>>> On 3/12/2020 9:35 PM, Watson Ladd wrote: >>>>>>> On Thu, Mar 12, 2020 at 4:07 AM Lou Berger = wrote: >>>>>>>> Watson, >>>>>>>>=20 >>>>>>>> Can you provide context here? Can you be explicit on what you = see needs to >>>>>>>> be addressed (beyond what is in this document as well as = related rfcs)? >>>>>>> You have to talk about how the layers interact, and can't just = say the >>>>>>> lower level handles anything without any guide as to what needs = to be >>>>>>> provided by that lower layer. >>>>>>>=20 >>>>>>> I think my concerns about the assumptions this could be fixed by >>>>>>> saying. "All nodes are trusted and any of them can misbehave in = ways >>>>>>> that affect the network. If the MPLS layer cannot provide = sufficient >>>>>>> determinism, then the DetNet mechanisms won't work". I agree we >>>>>>> shoudn't require an entire massive security framework to be = quoted >>>>>>> again here, but there must be some details of this embedding = that are >>>>>>> worth noting, and yet I don't see them called out in the = security >>>>>>> considerations section. >>>>>>>=20 >>>>>>> Are there really no specific concerns about the interaction = between >>>>>>> DetNet and MPLS? >>>>>>>=20 >>>>>>>> Thank you, >>>>>>>> Lou >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> ---------- >>>>>>>> On March 11, 2020 10:30:27 PM Watson Ladd = wrote: >>>>>>>>=20 >>>>>>>>> I don't see any reason why RFC 3552's guidelines shoudn't = apply to this draft. >>>>>>>>>=20 >>>>>>>>> If there is a MPLS exception I'd like to see the rules that = should be applied. >>>>>>>>>=20 >>>>>>>>> As is I don't see any reason why the assumptions can't be = explicitly >>>>>>>>> spelled out, either in the Security Considerations or = elsewhere. >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> detnet mailing list >>>>>>>>> detnet@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/detnet >>>>>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> secdir mailing list >>>> secdir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/secdir >>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >>=20 From nobody Mon Mar 16 07:19:10 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833563A08FD; Mon, 16 Mar 2020 07:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 gpzoOyoKK8fq; Mon, 16 Mar 2020 07:19:03 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 774E93A0901; Mon, 16 Mar 2020 07:18:57 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id c20so14240381lfb.0; Mon, 16 Mar 2020 07:18:57 -0700 (PDT) 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=QljCFe26iYMylvT19icyZdOtgo0dYP6xdQ+NPT2VIIM=; b=kBdpFKjKcVClOCYcUYCjY6dWKqNr5b3f9txfG0CQfLfk7PQa3ACreI86Lj3w5K246L qxkfqtVSCj/w6Sem03rsieiXSxLu5ZrGE3IMmCGlZINJpKr9QLynjnimvTXHli+dzHLx mxCibV0AQdIQRy3OSHjXStUXy+qCGsgLHMf+S6tiyOVgIXptbGfNvg6s9Q/tWLVE8qDY xYE/PH2DTCmRER+1sUmt89TLXqLHg1mCTXLlcLTwgVXwACnUlIYuOvHJdfgRMFDI+Z+5 Nusq5ZdgJzyFc+WOSyIP8eP10SepdbMN3Cs5GiCMHP//d0ytD8ZbZ5WqlHAcH1NrvHAS dA2g== 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=QljCFe26iYMylvT19icyZdOtgo0dYP6xdQ+NPT2VIIM=; b=gpv2zNZDvDO42qKYWf8Lw9clOIaf51ozcx2o0LGizTPQpRJvuN3utAMa3mSbp8TcdL IF81AXZ8NN8lnxB5UDr09HpFH+s8knnEVDX1y9omNjA4kVPum4KDT82NQfc6I2GitVVv DzvxLoN46P8eCcNpyT16480nJOnLR2dsKagrFY4Lm/1z/+BaHybi94k4u7dWnb0HsQqY szlJO7pUuYvakUponzYwz0NQddb0sqdSr0hmUqo5yNgy94/S9kZ+0K8KZrr8q6whvEax 2RJrPon/1xdVaJ1qgISZ3PDIT9agqE9ZCWFfh77zTAZK6NXdUhlvHU3Y91CCLtqYpwU/ Tnvw== X-Gm-Message-State: ANhLgQ1yWmhfDdL2Svac9L2UBOlojDybPDbxYao18q2bGqsDBB1dNiwE vVvdxEqEpSGCsd21Y4F4GpFLEI8x2YBHXqVpad0= X-Google-Smtp-Source: ADFU+vv8yyee/2hDSDzxnLxJK1XrW4xuiVVzaIxYxpJV1rPEivSe8QP+6tDQh1vm0Dxn8ytTAnkf6OCSTqYXnIr8w4s= X-Received: by 2002:a05:6512:4cf:: with SMTP id w15mr10726016lfq.147.1584368335411; Mon, 16 Mar 2020 07:18:55 -0700 (PDT) MIME-Version: 1.0 References: <7A5A9066-7877-402A-9704-AD83AF4FD3D0@gmail.com> <96BB26AA-3314-4E0A-98F3-4F2E93F1D9FF@gmail.com> In-Reply-To: <96BB26AA-3314-4E0A-98F3-4F2E93F1D9FF@gmail.com> From: Watson Ladd Date: Mon, 16 Mar 2020 07:18:44 -0700 Message-ID: To: Stewart Bryant Cc: Uri Blumenthal , Lou Berger , draft-ietf-detnet-mpls.all@ietf.org, DetNet WG , secdir , rtg-ads@ietf.org, "" Content-Type: multipart/alternative; boundary="000000000000d35d7005a0f97fd9" Archived-At: Subject: Re: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 14:19:06 -0000 --000000000000d35d7005a0f97fd9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 16, 2020, 7:01 AM Stewart Bryant wrote: > The requirement is NOT for a draft to provide the security analysis of al= l > of all of the technologies that it calls up. It is, I believe, to describ= e > the deltas that apply to the new idea. Anything else and the text would b= e > a security analysis with a short technology preamble. > > We are describing a technology that is overlaid on MPLS. We should not > need to describe the security model of MPLS, but instead confine our > remarks to issues that specifically apply to the additional technology we > are describing. > RFC 3552 requires that in a case such as this you explicitly describe what the lower layer is providing to the top layer. RFC 3552 section 5 also demands that attacks be enumerated and those out of scope be called out. E.g "use TLS" isn't good enough and imho neither is "use MPLS". Again, the sentences in the security considerations as it stands are about MPLS and Detnet, and they don't seem to come together. Are there really no security considerations when putting the two together? Every MPLS network will just work with Detnet on top, no matter how rushed the deploy is? > Early in the document we call up RFC3031 and RFC3032, the fundamental MPL= S > RFCs. They are in section 3.1 the first part of the serious technical > discussion. In my view these establish a baseline of understand that the > reader is expected to have. > > It is important to realise, as I have said before, that without > understanding that baseline the rest of the document is meaningless. > > Regards > > Stewart > > BTW > > It might be as well if you refrained from illustrating the lack of > professionalism that the security area applies to its reviews by continui= ng > with the flippancy. There is a serious point that needs to be debated her= e > about what assumptions are a given and what assumptions need to be spelle= d > out when modifying or layering a technology. > > > > On 16 Mar 2020, at 12:22, Uri Blumenthal wrote: > > > > IETF position (add fat as I remember) regarding RFCs has been that RFCs > should provide with everything information for a reasonable developer to > implement correctly and securely the standard they define, and provide > enough information for the person who will deploy a compliant > implementation to do that correctly and securely. > > > > One purpose of Security Review is to ensure that a person doesn't have > to be an expert in the field to deal with the proposed document. > > > > In a flippant way, if using your stuff is requires special classes - > perhaps it belongs to a book rather than an RFC. > > > > In a non-flippant way - what's the problem in mentioning the issues and > providing the appropriate references? A "normal" RFC cannot be > self-contained, but it's unreasonable to epect a reader to just "know" > where all the omitted things are described. > > > >> On Mar 16, 2020, at 06:33, Stewart Bryant > wrote: > >> > >> =EF=BB=BFUri, > >> > >> That is a ridiculous position, and you flippancy demonstrates that. > >> > >> This technology fundamentally rests on MPLS and it is reasonable that > the reader of this RFC will understand MPLS and the security model it use= s > before they implement or deploy it. Indeed I cannot think of any > implementor or operator that would not already have that knowledge before > taking on the task of building or running DN over MPLS. > >> > >> If SecDir reviews are to retain any credibility as expert reviews as > opposed to Genart random reader reviews they have to be carried out with > shared knowledge of both the security area and the draft=E2=80=99s host a= rea. > >> > >> I have been thinking for some time that there needs to be a fundamenta= l > review of the security review process. > >> > >> Stewart > >> > >>> On 15 Mar 2020, at 22:44, Uri Blumenthal wrote: > >>> > >>> I say yes - unless you expect a person who wants just one RFC to have > to read every cr^h^h stuff that came out of the routing area. > >>> > >>> "Just do it" > >>> > >>> > >>>>> On Mar 15, 2020, at 17:39, Lou Berger wrote: > >>>> > >>>> =EF=BB=BF > >>>>> On 3/15/2020 5:22 PM, Watson Ladd wrote: > >>>>>> On Sun, Mar 15, 2020 at 2:14 PM Lou Berger > wrote: > >>>>>> Hi Watson, > >>>>>> > >>>>>> I think Stewart's response really covers the main points. DetNet > is > >>>>>> really just MPLS (and IP) with some specific forwarding behaviors > and > >>>>>> queuing. The only thing I'd add, is I see DetNet in general as a > >>>>>> specific form of policy based routing. (The general form of which = is > >>>>>> pretty much as old as IP). > >>>>> Then Stewart can put those points in the security considerations > >>>>> section. What's the disadvantage of doing so? > >>>> > >>>> At one level, it would be easiest for the authors to just put these > in. On the other hand, this would mean that every RFC produced in the > routing area will acquire similar notes, e.g., routing protocols are > currently built with a chain of trust model. Is this what the sec-dir > really is asking the routing area to do? > >>>> > >>>> ADs, > >>>> > >>>> any opinion on this? (for context, Stewart's response can be > found at: > https://mailarchive.ietf.org/arch/msg/detnet/-epL5Fb6bFIUltMrjH53C2316ZA/= ) > >>>> > >>>> Thanks, > >>>> > >>>> Lou > >>>> > >>>>>> Lou > >>>>>> > >>>>>> On 3/12/2020 9:35 PM, Watson Ladd wrote: > >>>>>>> On Thu, Mar 12, 2020 at 4:07 AM Lou Berger > wrote: > >>>>>>>> Watson, > >>>>>>>> > >>>>>>>> Can you provide context here? Can you be explicit on what you se= e > needs to > >>>>>>>> be addressed (beyond what is in this document as well as related > rfcs)? > >>>>>>> You have to talk about how the layers interact, and can't just sa= y > the > >>>>>>> lower level handles anything without any guide as to what needs t= o > be > >>>>>>> provided by that lower layer. > >>>>>>> > >>>>>>> I think my concerns about the assumptions this could be fixed by > >>>>>>> saying. "All nodes are trusted and any of them can misbehave in > ways > >>>>>>> that affect the network. If the MPLS layer cannot provide > sufficient > >>>>>>> determinism, then the DetNet mechanisms won't work". I agree we > >>>>>>> shoudn't require an entire massive security framework to be quote= d > >>>>>>> again here, but there must be some details of this embedding that > are > >>>>>>> worth noting, and yet I don't see them called out in the security > >>>>>>> considerations section. > >>>>>>> > >>>>>>> Are there really no specific concerns about the interaction betwe= en > >>>>>>> DetNet and MPLS? > >>>>>>> > >>>>>>>> Thank you, > >>>>>>>> Lou > >>>>>>>> > >>>>>>>> > >>>>>>>> ---------- > >>>>>>>> On March 11, 2020 10:30:27 PM Watson Ladd > wrote: > >>>>>>>> > >>>>>>>>> I don't see any reason why RFC 3552's guidelines shoudn't apply > to this draft. > >>>>>>>>> > >>>>>>>>> If there is a MPLS exception I'd like to see the rules that > should be applied. > >>>>>>>>> > >>>>>>>>> As is I don't see any reason why the assumptions can't be > explicitly > >>>>>>>>> spelled out, either in the Security Considerations or elsewhere= . > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> detnet mailing list > >>>>>>>>> detnet@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/detnet > >>>>>>>>> > >>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> secdir mailing list > >>>> secdir@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/secdir > >>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > >> > > --000000000000d35d7005a0f97fd9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Mar 16, 2020, 7:01 AM Stewart Bryant <stewart.bryant@gmail.com> wrote:
The requirement is NOT for a draft to provide the security analysis o= f all of all of the technologies that it calls up. It is, I believe, to des= cribe the deltas that apply to the new idea. Anything else and the text wou= ld be a security analysis with a short technology preamble.

We are describing a technology that is overlaid on MPLS. We should not need= to describe the security model of MPLS,=C2=A0 but instead confine our rema= rks to issues that specifically apply to the additional technology we are d= escribing.

RFC 3552 requires that in a case such as this you explicitly desc= ribe what the lower layer is providing to the top layer. RFC 3552 section 5= also demands that attacks be enumerated and those out of scope be called o= ut.

E.g "use TLS&qu= ot; isn't good enough and imho neither is "use MPLS".

Again, the sentences in the sec= urity considerations as it stands are about MPLS and Detnet, and they don&#= 39;t seem to come together. Are there really no security considerations whe= n putting the two together? Every MPLS network will just work with Detnet o= n top, no matter how rushed the deploy is?

uri@mit.edu> w= rote:
>
> IETF position (add fat as I remember) regarding RFCs has been that RFC= s should provide with everything information for a reasonable developer to = implement correctly and securely the standard they define, and provide enou= gh information for the person who will deploy a compliant implementation to= do that correctly and securely.
>
> One purpose of Security Review is to ensure that a person doesn't = have to be an expert in the field to deal with the proposed document.
>
> In a flippant way, if using your stuff is requires special classes - p= erhaps it belongs to a book rather than an RFC.
>
> In a non-flippant way - what's the problem in mentioning the issue= s and providing the appropriate references? A "normal" RFC cannot= be self-contained, but it's unreasonable to epect a reader to just &qu= ot;know" where all the omitted things are described.
>
>> On Mar 16, 2020, at 06:33, Stewart Bryant <ste= wart.bryant@gmail.com> wrote:
>>
>> =EF=BB=BFUri,
>>
>> That is a ridiculous position, and you flippancy demonstrates that= .
>>
>> This technology fundamentally rests on MPLS and it is reasonable t= hat the reader of this RFC will understand MPLS and the security model it u= ses before they implement or deploy it. Indeed I cannot think of any implem= entor or operator that would not already have that knowledge before taking = on the task of building or running DN over MPLS.
>>
>> If SecDir reviews are to retain any credibility as expert reviews = as opposed to Genart random reader reviews they have to be carried out with= shared knowledge of both the security area and the draft=E2=80=99s host ar= ea.
>>
>> I have been thinking for some time that there needs to be a fundam= ental review of the security review process.
>>
>> Stewart
>>
>>> On 15 Mar 2020, at 22:44, Uri Blumenthal <uri@mit.edu> wrote:
>>>
>>> I say yes - unless you expect a person who wants just one RFC = to have to read every cr^h^h stuff that came out of the routing area.
>>>
>>> "Just do it"
>>>
>>>
>>>>> On Mar 15, 2020, at 17:39, Lou Berger <lbe= rger@labn.net> wrote:
>>>>
>>>> =EF=BB=BF
>>>>> On 3/15/2020 5:22 PM, Watson Ladd wrote:
>>>>>> On Sun, Mar 15, 2020 at 2:14 PM Lou Berger <lberger@labn.net> wrote:
>>>>>> Hi Watson,
>>>>>>
>>>>>>=C2=A0 =C2=A0I think Stewart's response really = covers the main points. DetNet is
>>>>>> really just MPLS (and IP) with some specific forwa= rding behaviors and
>>>>>> queuing.=C2=A0 The only thing I'd add, is I se= e DetNet in general as a
>>>>>> specific form of policy based routing. (The genera= l form of which is
>>>>>> pretty much as old as IP).
>>>>> Then Stewart can put those points in the security cons= iderations
>>>>> section. What's the disadvantage of doing so?
>>>>
>>>> At one level, it would be easiest for the authors to just = put these in.=C2=A0 On the other hand, this would mean that every RFC produ= ced in the routing area will acquire similar notes, e.g., routing protocols= are currently built with a chain of trust model.=C2=A0 Is this what the se= c-dir really is asking the routing area to do?
>>>>
>>>> ADs,
>>>>
>>>>=C2=A0 any opinion on this?=C2=A0 =C2=A0 =C2=A0(for context= , Stewart's response can be found at: https://mailarchive.ietf.org/arch/msg/= detnet/-epL5Fb6bFIUltMrjH53C2316ZA/)
>>>>
>>>> Thanks,
>>>>
>>>> Lou
>>>>
>>>>>> Lou
>>>>>>
>>>>>> On 3/12/2020 9:35 PM, Watson Ladd wrote:
>>>>>>> On Thu, Mar 12, 2020 at 4:07 AM Lou Berger <= ;lberger@labn.net> wrote:
>>>>>>>> Watson,
>>>>>>>>
>>>>>>>> Can you provide context here? Can you be e= xplicit on what you see needs to
>>>>>>>> be addressed (beyond what is in this docum= ent as well as related rfcs)?
>>>>>>> You have to talk about how the layers interact= , and can't just say the
>>>>>>> lower level handles anything without any guide= as to what needs to be
>>>>>>> provided by that lower layer.
>>>>>>>
>>>>>>> I think my concerns about the assumptions this= could be fixed by
>>>>>>> saying. "All nodes are trusted and any of= them can misbehave in ways
>>>>>>> that affect the network.=C2=A0 If the MPLS lay= er cannot provide sufficient
>>>>>>> determinism, then the DetNet mechanisms won= 9;t work".=C2=A0 I agree we
>>>>>>> shoudn't require an entire massive securit= y framework to be quoted
>>>>>>> again here, but there must be some details of = this embedding that are
>>>>>>> worth noting, and yet I don't see them cal= led out in the security
>>>>>>> considerations section.
>>>>>>>
>>>>>>> Are there really no specific concerns about th= e interaction between
>>>>>>> DetNet and MPLS?
>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> Lou
>>>>>>>>
>>>>>>>>
>>>>>>>> ----------
>>>>>>>> On March 11, 2020 10:30:27 PM Watson Ladd = <watsonbladd@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> I don't see any reason why RFC 355= 2's guidelines shoudn't apply to this draft.
>>>>>>>>>
>>>>>>>>> If there is a MPLS exception I'd l= ike to see the rules that should be applied.
>>>>>>>>>
>>>>>>>>> As is I don't see any reason why t= he assumptions can't be explicitly
>>>>>>>>> spelled out, either in the Security Co= nsiderations or elsewhere.
>>>>>>>>>
>>>>>>>>> ______________________________________= _________
>>>>>>>>> detnet mailing list
>>>>>>>>> detnet@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/detnet
>>>>>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> secdir mailing list
>>>> secdir@ietf.org
>>>> https://www.ietf.= org/mailman/listinfo/secdir
>>>> wiki: ht= tp://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>>

--000000000000d35d7005a0f97fd9-- From nobody Mon Mar 16 07:23:03 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D0C3A090A for ; Mon, 16 Mar 2020 07:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.361 X-Spam-Level: X-Spam-Status: No, score=-3.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnQ2PLheCmuk for ; Mon, 16 Mar 2020 07:22:54 -0700 (PDT) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) (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 C54E63A092D for ; Mon, 16 Mar 2020 07:22:54 -0700 (PDT) Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id DF43E215DC0 for ; Mon, 16 Mar 2020 08:22:49 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id DqdljsSfOVKjoDqdljQrGR; Mon, 16 Mar 2020 08:22:49 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.3 cv=dJyIZtRb c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=xqWC_Br6kY4A:10:nop_ipv6 a=SS2py6AdgQ4A:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=wU2YTnxGAAAA:8 a=2oqSnHMV4Z3bUipraykA:9 a=J3Vv16-NA7Rc4M9S:21 a=HPhST2ZdynFQX3NX:21 a=QEXdDO2ut3YA:10:nop_charset_2 a=HOegm7vpLclc9V2hf2IA:9 a=YLQGlklLBOgM2PVj:21 a=FivuYDexwT57tvfO:21 a=NAb3cl6HliiaYlxJ:21 a=_W_S_7VecoQA:10:nop_html a=w1C3t2QeGrPiZgrLijVG:22 a=Yz9wTY_ffGCQnEDHKrcv:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Sender:Reply-To:Content-Transfer-Encoding:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=Sdi75d79EOVhit0V5q5ueIh1g7FIsqtlx3yAqUlVfVE=; b=2IlGwVzy++vTE/QrouUsUapy1Z y8yJQOM1HcYa9hLRGvTxf07w3GV6TBqqBMw7yDrSSfL3zB3sEznCZSmqCYZumf4dhz9k0/9pfFOch +qyREAbHncNF1JvN7ziuMT4oW; Received: from [127.0.0.1] (port=35461 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1jDqdl-003oLI-DK; Mon, 16 Mar 2020 08:22:49 -0600 To: Watson Ladd , Stewart Bryant Cc: Uri Blumenthal , draft-ietf-detnet-mpls.all@ietf.org, DetNet WG , secdir , rtg-ads@ietf.org, "" References: <7A5A9066-7877-402A-9704-AD83AF4FD3D0@gmail.com> <96BB26AA-3314-4E0A-98F3-4F2E93F1D9FF@gmail.com> From: Lou Berger Message-ID: Date: Mon, 16 Mar 2020 10:22:48 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E8BAD5B8E6EDDB0992398FA9" Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 127.0.0.1 X-Source-L: Yes X-Exim-ID: 1jDqdl-003oLI-DK X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPv6:::1]) [127.0.0.1]:35461 X-Source-Auth: lberger@labn.net X-Email-Count: 10 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 14:22:58 -0000 This is a multi-part message in MIME format. --------------E8BAD5B8E6EDDB0992398FA9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Watson, Uri, would a reference to https://tools.ietf.org/html/draft-ietf-detnet-security-08#section-7 help? note that Detnet operates/extends the IP and MPLS layers. It is not a service that rides on general IP or separate from the MPLS layers. Lou On 3/16/2020 10:18 AM, Watson Ladd wrote: > > > On Mon, Mar 16, 2020, 7:01 AM Stewart Bryant > wrote: > > The requirement is NOT for a draft to provide the security > analysis of all of all of the technologies that it calls up. It > is, I believe, to describe the deltas that apply to the new idea. > Anything else and the text would be a security analysis with a > short technology preamble. > > We are describing a technology that is overlaid on MPLS. We should > not need to describe the security model of MPLS,  but instead > confine our remarks to issues that specifically apply to the > additional technology we are describing. > > > RFC 3552 requires that in a case such as this you explicitly describe > what the lower layer is providing to the top layer. RFC 3552 section 5 > also demands that attacks be enumerated and those out of scope be > called out. > > E.g "use TLS" isn't good enough and imho neither is "use MPLS". > > Again, the sentences in the security considerations as it stands are > about MPLS and Detnet, and they don't seem to come together. Are there > really no security considerations when putting the two together? Every > MPLS network will just work with Detnet on top, no matter how rushed > the deploy is? > > > Early in the document we call up RFC3031 and RFC3032, the > fundamental MPLS RFCs. They are in section 3.1 the first part of > the serious technical discussion. In my view these establish a > baseline of understand that the reader is expected to have. > > It is important to realise, as I have said before, that without > understanding that baseline the rest of the document is meaningless. > > Regards > > Stewart > > BTW > > It might be as well if you refrained from illustrating the lack of > professionalism that the security area applies to its reviews by > continuing with the flippancy. There is a serious point that needs > to be debated here about what assumptions are a given and what > assumptions need to be spelled out when modifying or layering a > technology. > > > > On 16 Mar 2020, at 12:22, Uri Blumenthal > wrote: > > > > IETF position (add fat as I remember) regarding RFCs has been > that RFCs should provide with everything information for a > reasonable developer to implement correctly and securely the > standard they define, and provide enough information for the > person who will deploy a compliant implementation to do that > correctly and securely. > > > > One purpose of Security Review is to ensure that a person > doesn't have to be an expert in the field to deal with the > proposed document. > > > > In a flippant way, if using your stuff is requires special > classes - perhaps it belongs to a book rather than an RFC. > > > > In a non-flippant way - what's the problem in mentioning the > issues and providing the appropriate references? A "normal" RFC > cannot be self-contained, but it's unreasonable to epect a reader > to just "know" where all the omitted things are described. > > > >> On Mar 16, 2020, at 06:33, Stewart Bryant > > wrote: > >> > >> Uri, > >> > >> That is a ridiculous position, and you flippancy demonstrates that. > >> > >> This technology fundamentally rests on MPLS and it is > reasonable that the reader of this RFC will understand MPLS and > the security model it uses before they implement or deploy it. > Indeed I cannot think of any implementor or operator that would > not already have that knowledge before taking on the task of > building or running DN over MPLS. > >> > >> If SecDir reviews are to retain any credibility as expert > reviews as opposed to Genart random reader reviews they have to be > carried out with shared knowledge of both the security area and > the draft’s host area. > >> > >> I have been thinking for some time that there needs to be a > fundamental review of the security review process. > >> > >> Stewart > >> > >>> On 15 Mar 2020, at 22:44, Uri Blumenthal > wrote: > >>> > >>> I say yes - unless you expect a person who wants just one RFC > to have to read every cr^h^h stuff that came out of the routing area. > >>> > >>> "Just do it" > >>> > >>> > >>>>> On Mar 15, 2020, at 17:39, Lou Berger > wrote: > >>>> > >>>>  > >>>>> On 3/15/2020 5:22 PM, Watson Ladd wrote: > >>>>>> On Sun, Mar 15, 2020 at 2:14 PM Lou Berger > > wrote: > >>>>>> Hi Watson, > >>>>>> > >>>>>>   I think Stewart's response really covers the main points. > DetNet is > >>>>>> really just MPLS (and IP) with some specific forwarding > behaviors and > >>>>>> queuing.  The only thing I'd add, is I see DetNet in > general as a > >>>>>> specific form of policy based routing. (The general form of > which is > >>>>>> pretty much as old as IP). > >>>>> Then Stewart can put those points in the security considerations > >>>>> section. What's the disadvantage of doing so? > >>>> > >>>> At one level, it would be easiest for the authors to just put > these in.  On the other hand, this would mean that every RFC > produced in the routing area will acquire similar notes, e.g., > routing protocols are currently built with a chain of trust > model.  Is this what the sec-dir really is asking the routing area > to do? > >>>> > >>>> ADs, > >>>> > >>>>  any opinion on this?     (for context, Stewart's response > can be found at: > https://mailarchive.ietf.org/arch/msg/detnet/-epL5Fb6bFIUltMrjH53C2316ZA/) > >>>> > >>>> Thanks, > >>>> > >>>> Lou > >>>> > >>>>>> Lou > >>>>>> > >>>>>> On 3/12/2020 9:35 PM, Watson Ladd wrote: > >>>>>>> On Thu, Mar 12, 2020 at 4:07 AM Lou Berger > > wrote: > >>>>>>>> Watson, > >>>>>>>> > >>>>>>>> Can you provide context here? Can you be explicit on what > you see needs to > >>>>>>>> be addressed (beyond what is in this document as well as > related rfcs)? > >>>>>>> You have to talk about how the layers interact, and can't > just say the > >>>>>>> lower level handles anything without any guide as to what > needs to be > >>>>>>> provided by that lower layer. > >>>>>>> > >>>>>>> I think my concerns about the assumptions this could be > fixed by > >>>>>>> saying. "All nodes are trusted and any of them can > misbehave in ways > >>>>>>> that affect the network.  If the MPLS layer cannot provide > sufficient > >>>>>>> determinism, then the DetNet mechanisms won't work".  I > agree we > >>>>>>> shoudn't require an entire massive security framework to > be quoted > >>>>>>> again here, but there must be some details of this > embedding that are > >>>>>>> worth noting, and yet I don't see them called out in the > security > >>>>>>> considerations section. > >>>>>>> > >>>>>>> Are there really no specific concerns about the > interaction between > >>>>>>> DetNet and MPLS? > >>>>>>> > >>>>>>>> Thank you, > >>>>>>>> Lou > >>>>>>>> > >>>>>>>> > >>>>>>>> ---------- > >>>>>>>> On March 11, 2020 10:30:27 PM Watson Ladd > > wrote: > >>>>>>>> > >>>>>>>>> I don't see any reason why RFC 3552's guidelines > shoudn't apply to this draft. > >>>>>>>>> > >>>>>>>>> If there is a MPLS exception I'd like to see the rules > that should be applied. > >>>>>>>>> > >>>>>>>>> As is I don't see any reason why the assumptions can't > be explicitly > >>>>>>>>> spelled out, either in the Security Considerations or > elsewhere. > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> detnet mailing list > >>>>>>>>> detnet@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/detnet > >>>>>>>>> > >>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> secdir mailing list > >>>> secdir@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/secdir > >>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > >> > --------------E8BAD5B8E6EDDB0992398FA9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Watson, Uri,

would a reference to https://tools.ietf.org/html/draft-ietf-detnet-security-08#section-7 help? note that Detnet operates/extends the IP and MPLS layers.  It is not a service that rides on general IP or separate from the MPLS layers.

Lou

On 3/16/2020 10:18 AM, Watson Ladd wrote:


On Mon, Mar 16, 2020, 7:01 AM Stewart Bryant <stewart.bryant@gmail.com> wrote:
The requirement is NOT for a draft to provide the security analysis of all of all of the technologies that it calls up. It is, I believe, to describe the deltas that apply to the new idea. Anything else and the text would be a security analysis with a short technology preamble.

We are describing a technology that is overlaid on MPLS. We should not need to describe the security model of MPLS,  but instead confine our remarks to issues that specifically apply to the additional technology we are describing.

RFC 3552 requires that in a case such as this you explicitly describe what the lower layer is providing to the top layer. RFC 3552 section 5 also demands that attacks be enumerated and those out of scope be called out.

E.g "use TLS" isn't good enough and imho neither is "use MPLS".

Again, the sentences in the security considerations as it stands are about MPLS and Detnet, and they don't seem to come together. Are there really no security considerations when putting the two together? Every MPLS network will just work with Detnet on top, no matter how rushed the deploy is?


Early in the document we call up RFC3031 and RFC3032, the fundamental MPLS RFCs. They are in section 3.1 the first part of the serious technical discussion. In my view these establish a baseline of understand that the reader is expected to have.

It is important to realise, as I have said before, that without understanding that baseline the rest of the document is meaningless.

Regards

Stewart

BTW

It might be as well if you refrained from illustrating the lack of professionalism that the security area applies to its reviews by continuing with the flippancy. There is a serious point that needs to be debated here about what assumptions are a given and what assumptions need to be spelled out when modifying or layering a technology.


> On 16 Mar 2020, at 12:22, Uri Blumenthal <uri@mit.edu> wrote:
>
> IETF position (add fat as I remember) regarding RFCs has been that RFCs should provide with everything information for a reasonable developer to implement correctly and securely the standard they define, and provide enough information for the person who will deploy a compliant implementation to do that correctly and securely.
>
> One purpose of Security Review is to ensure that a person doesn't have to be an expert in the field to deal with the proposed document.
>
> In a flippant way, if using your stuff is requires special classes - perhaps it belongs to a book rather than an RFC.
>
> In a non-flippant way - what's the problem in mentioning the issues and providing the appropriate references? A "normal" RFC cannot be self-contained, but it's unreasonable to epect a reader to just "know" where all the omitted things are described.
>
>> On Mar 16, 2020, at 06:33, Stewart Bryant <stewart.bryant@gmail.com> wrote:
>>
>> Uri,
>>
>> That is a ridiculous position, and you flippancy demonstrates that.
>>
>> This technology fundamentally rests on MPLS and it is reasonable that the reader of this RFC will understand MPLS and the security model it uses before they implement or deploy it. Indeed I cannot think of any implementor or operator that would not already have that knowledge before taking on the task of building or running DN over MPLS.
>>
>> If SecDir reviews are to retain any credibility as expert reviews as opposed to Genart random reader reviews they have to be carried out with shared knowledge of both the security area and the draft’s host area.
>>
>> I have been thinking for some time that there needs to be a fundamental review of the security review process.
>>
>> Stewart
>>
>>> On 15 Mar 2020, at 22:44, Uri Blumenthal <uri@mit.edu> wrote:
>>>
>>> I say yes - unless you expect a person who wants just one RFC to have to read every cr^h^h stuff that came out of the routing area.
>>>
>>> "Just do it"
>>>
>>>
>>>>> On Mar 15, 2020, at 17:39, Lou Berger <lberger@labn.net> wrote:
>>>>
>>>> 
>>>>> On 3/15/2020 5:22 PM, Watson Ladd wrote:
>>>>>> On Sun, Mar 15, 2020 at 2:14 PM Lou Berger <lberger@labn.net> wrote:
>>>>>> Hi Watson,
>>>>>>
>>>>>>   I think Stewart's response really covers the main points. DetNet is
>>>>>> really just MPLS (and IP) with some specific forwarding behaviors and
>>>>>> queuing.  The only thing I'd add, is I see DetNet in general as a
>>>>>> specific form of policy based routing. (The general form of which is
>>>>>> pretty much as old as IP).
>>>>> Then Stewart can put those points in the security considerations
>>>>> section. What's the disadvantage of doing so?
>>>>
>>>> At one level, it would be easiest for the authors to just put these in.  On the other hand, this would mean that every RFC produced in the routing area will acquire similar notes, e.g., routing protocols are currently built with a chain of trust model.  Is this what the sec-dir really is asking the routing area to do?
>>>>
>>>> ADs,
>>>>
>>>>  any opinion on this?     (for context, Stewart's response can be found at: https://mailarchive.ietf.org/arch/msg/detnet/-epL5Fb6bFIUltMrjH53C2316ZA/)
>>>>
>>>> Thanks,
>>>>
>>>> Lou
>>>>
>>>>>> Lou
>>>>>>
>>>>>> On 3/12/2020 9:35 PM, Watson Ladd wrote:
>>>>>>> On Thu, Mar 12, 2020 at 4:07 AM Lou Berger <lberger@labn.net> wrote:
>>>>>>>> Watson,
>>>>>>>>
>>>>>>>> Can you provide context here? Can you be explicit on what you see needs to
>>>>>>>> be addressed (beyond what is in this document as well as related rfcs)?
>>>>>>> You have to talk about how the layers interact, and can't just say the
>>>>>>> lower level handles anything without any guide as to what needs to be
>>>>>>> provided by that lower layer.
>>>>>>>
>>>>>>> I think my concerns about the assumptions this could be fixed by
>>>>>>> saying. "All nodes are trusted and any of them can misbehave in ways
>>>>>>> that affect the network.  If the MPLS layer cannot provide sufficient
>>>>>>> determinism, then the DetNet mechanisms won't work".  I agree we
>>>>>>> shoudn't require an entire massive security framework to be quoted
>>>>>>> again here, but there must be some details of this embedding that are
>>>>>>> worth noting, and yet I don't see them called out in the security
>>>>>>> considerations section.
>>>>>>>
>>>>>>> Are there really no specific concerns about the interaction between
>>>>>>> DetNet and MPLS?
>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> Lou
>>>>>>>>
>>>>>>>>
>>>>>>>> ----------
>>>>>>>> On March 11, 2020 10:30:27 PM Watson Ladd <watsonbladd@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> I don't see any reason why RFC 3552's guidelines shoudn't apply to this draft.
>>>>>>>>>
>>>>>>>>> If there is a MPLS exception I'd like to see the rules that should be applied.
>>>>>>>>>
>>>>>>>>> As is I don't see any reason why the assumptions can't be explicitly
>>>>>>>>> spelled out, either in the Security Considerations or elsewhere.
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> detnet mailing list
>>>>>>>>> detnet@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/detnet
>>>>>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> secdir mailing list
>>>> secdir@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/secdir
>>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>>

--------------E8BAD5B8E6EDDB0992398FA9-- From nobody Mon Mar 16 07:37:52 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C693A0946; Mon, 16 Mar 2020 07:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 w8a8JmyZLoiu; Mon, 16 Mar 2020 07:37:48 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 685693A0945; Mon, 16 Mar 2020 07:37:42 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id z13so1882142wml.0; Mon, 16 Mar 2020 07:37:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=LvvfYBcOK97N2RTj6fKFDPoiviGs4AcshYnpD3KtYdI=; b=MoPR5D5VvP4Rz5z0rbCSUe1gpQkypWBgzAGTajJiivEND66Rj+3Iug0UDdlQNkYM3V 6qbc7lD9KzHURHnuZ24RMWQPDmNiuyRUaDU7xllMqP36MuVcET7oBVoCbSxVAVSuL6cs bKI0m2EBTvgAlgK6pd1T13Ul61Jh6ZhXnANNDLv2530jtoVNAZ1/sJC4Y6gedAhcpSVK TEBSCDo8kOSk5yYowIAWbZ+27v7v0qvXCN8Sr7G819Hj6Cd5ZkFgv+LELhs2hYoSXR3v sI5YCrA5U1ig8aOzEJafRqZwWsDRwm6pcabqxuPMeKE8PlBwIJ5PidBWRhupv0++NAXY oFZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=LvvfYBcOK97N2RTj6fKFDPoiviGs4AcshYnpD3KtYdI=; b=A91xa+sAwA/aN3K4C4qzYT4nuYmmNeDoSJlMf9B0oZ7X7LdBAYw1frQsMZlu6rvItm C70tUZ9bSzVHseYd61cctzwqjhlDNq5kRpdvc4KoEGQNJ6p2rQdXJUgfQnpd78d4BvKJ 7DQG12jpqdmyc7UDaKMvPaB89UtGdF8IgKkAkKse/FPNLmn4MyeE+rGzh5XJXKR//htI YW9yVQWpqrBeo+HuHZyEcyKfZzTocZmpbM+Ubu9O8k7GPcfXAAEi1uSOVESExkdXtqnZ dm/q3qqaxCLlnWtqBSQgkvTOE7zGrfNOc49+L/Hudo5j/ggmdWF9/GYccm59VTmCK7xY ReUA== X-Gm-Message-State: ANhLgQ3vtMiekbHLeH6S8I/Z3+7Z4YzaPKF+byBnfI3chHSEyXiqkHGV LyT3xgXER7IBDlxWiJs+lQU= X-Google-Smtp-Source: ADFU+vvkJIyYv1/tt8VdaYB7IAKNWbPvdVQ3ZCk+P95iUGuLcgAUtHL9b71g6zGZsLZTsJu+D6wKPA== X-Received: by 2002:a1c:1b51:: with SMTP id b78mr28207479wmb.8.1584369460555; Mon, 16 Mar 2020 07:37:40 -0700 (PDT) Received: from [192.168.178.42] ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id b203sm31383117wmc.45.2020.03.16.07.37.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Mar 2020 07:37:39 -0700 (PDT) From: Stewart Bryant Message-Id: <06D31ABA-F8AE-49FF-A2C0-D2F7BBB56E55@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C5B3148D-6617-41CF-B3F4-8172B5BFE4D1" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Mon, 16 Mar 2020 14:37:08 +0000 In-Reply-To: Cc: Stewart Bryant , Watson Ladd , Uri Blumenthal , draft-ietf-detnet-mpls.all@ietf.org, DetNet WG , secdir , rtg-ads@ietf.org, "" To: Lou Berger References: <7A5A9066-7877-402A-9704-AD83AF4FD3D0@gmail.com> <96BB26AA-3314-4E0A-98F3-4F2E93F1D9FF@gmail.com> X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 14:37:51 -0000 --Apple-Mail=_C5B3148D-6617-41CF-B3F4-8172B5BFE4D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 16 Mar 2020, at 14:22, Lou Berger wrote: >=20 >> Are there really no security considerations when putting the two = together? Obviously I cannot think of anything that is not already in the text, or = I would have included it. So if you can be more specific about what this = interactions might be, I am more than happy to discuss them with you and = if needed to address them either directly or by reference. >> Every MPLS network will just work with Detnet on top, no matter how = rushed the deploy is? DN will certainly not damage MPLS no. A poor MPLS deployment will break many things besides DN. However whist = I can see potential for a performance impact, I cannot see how a = security impact would occur. Stewart --Apple-Mail=_C5B3148D-6617-41CF-B3F4-8172B5BFE4D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 16 Mar 2020, at 14:22, Lou Berger <lberger@labn.net> = wrote:

Are = there really no security considerations when putting the two together? =

Obviously I cannot think of anything that is not = already in the text, or I would have included it. So if you can be more = specific about what this interactions might be, I am more than happy to = discuss them with you and if needed  to address them either = directly or by reference.

Every= MPLS network will just work with Detnet on top, no matter how rushed = the deploy is?

DN will certainly not damage MPLS = no.

A poor MPLS deployment will = break many things besides DN. However whist I can see potential for a = performance impact, I cannot see how a security impact would = occur.

Stewart



= --Apple-Mail=_C5B3148D-6617-41CF-B3F4-8172B5BFE4D1-- From nobody Mon Mar 16 09:17:42 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F7D3A0C93; Mon, 16 Mar 2020 09:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIdzrbOe54Yt; Mon, 16 Mar 2020 09:17:31 -0700 (PDT) Received: from outgoing-exchange-3.mit.edu (outgoing-exchange-3.mit.edu [18.9.28.13]) (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 644B03A0C8B; Mon, 16 Mar 2020 09:17:30 -0700 (PDT) Received: from w92exedge3.exchange.mit.edu (W92EXEDGE3.EXCHANGE.MIT.EDU [18.7.73.15]) by outgoing-exchange-3.mit.edu (8.14.7/8.12.4) with ESMTP id 02GGHKfZ030096; Mon, 16 Mar 2020 12:17:27 -0400 Received: from oc11expo31.exchange.mit.edu (18.9.4.104) by w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 16 Mar 2020 12:16:59 -0400 Received: from oc11expo31.exchange.mit.edu (18.9.4.104) by oc11expo31.exchange.mit.edu (18.9.4.104) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 16 Mar 2020 12:17:06 -0400 Received: from oc11expo31.exchange.mit.edu ([18.9.4.104]) by oc11expo31.exchange.mit.edu ([18.9.4.104]) with mapi id 15.00.1365.000; Mon, 16 Mar 2020 12:17:06 -0400 From: Uri Blumenthal To: Lou Berger CC: Watson Ladd , Stewart Bryant , "draft-ietf-detnet-mpls.all@ietf.org" , DetNet WG , secdir , "rtg-ads@ietf.org" , "" Thread-Topic: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-05 Thread-Index: AQHV+F6FNSfnEeGpGUm730Plf9JWd6hGAciAgARt0QCAAAJSAIAABLYAgAASZQCAAMX9AIAAHnIAgAAbaQCAAAUMAIAAASMAgAAf7wA= Date: Mon, 16 Mar 2020 16:17:06 +0000 Message-ID: <73942657-B55A-431F-AB55-444C3C587AE1@mit.edu> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/signed; boundary="Apple-Mail-7EF9E05F-3137-4065-9FD1-9DD5C2A23CC4"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 16:17:34 -0000 --Apple-Mail-7EF9E05F-3137-4065-9FD1-9DD5C2A23CC4 Content-Type: multipart/alternative; boundary=Apple-Mail-E332C98A-9D45-4540-B7F4-8CFBD022EB9B Content-Transfer-Encoding: 7bit --Apple-Mail-E332C98A-9D45-4540-B7F4-8CFBD022EB9B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 TG91LA0KDQpZZXMsIGFkZGluZyB0aGF0IHJlZmVyZW5jZSB3b3VsZCBoZWxwIChJTUhPKS4NCg0K SWYgaW5kZWVkLCBhcyBTdGV3YXJ0IHNheXMsIGRldG5ldCBkb2VzIG5vdCBhZGQgYW55IHNlY3Vy aXR5IGNvbnNpZGVyYXRpb25zIHRvIHRob3NlIGFscmVhZHkgZGVzY3JpYmVkIGluIHRoZSBNUExT IGRvY3VtZW50cyAtIHRoZSBkcmFmdCBzaG91bGQgc3RhdGUgc28gZXhwbGljaXRseS4gVGhvdWdo IEkgcGVyc29uYWxseSBmaW5kIGl0IGhhcmQgdG8gYmVsaWV2ZS4NCg0KV2hhdCBpcyBhbiAib2J2 aW91cyBjb21tb24gc2Vuc2UiIGZvciB5b3UgYW5kIFN0ZXdhcnQsIG1heSBub3QgYmUgc28gb2J2 aW91cyB0byBvdGhlciByZWFkZXJzLg0KDQpBcyBhIG5vdGUgdG8gb3RoZXJzLCBpdCBpcyBleHBl Y3RlZCB0aGF0IFJGQyBhdXRob3JzIGRvIHBlcmZvcm0gYSBjb21wcmVoZW5zaXZlIHNlY3VyaXR5 IGFuYWx5c2lzLCBhbmQgZG9jdW1lbnQgdGhlaXIgZmluZGluZ3MgaW4gdGhlIFNlY3VyaXR5IENv bnNpZGVyYXRpb25zIHNlY3Rpb24uIEkgdGhvdWdodCB0aGF0IHdhcyBvYnZpb3VzLg0KDQoNCj4g T24gTWFyIDE2LCAyMDIwLCBhdCAxMDoyMiwgTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4g d3JvdGU6DQo+IA0KPiDvu78NCj4gV2F0c29uLCBVcmksDQo+IA0KPiB3b3VsZCBhIHJlZmVyZW5j ZSB0byBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kZXRuZXQtc2VjdXJp dHktMDgjc2VjdGlvbi03IGhlbHA/IG5vdGUgdGhhdCBEZXRuZXQgb3BlcmF0ZXMvZXh0ZW5kcyB0 aGUgSVAgYW5kIE1QTFMgbGF5ZXJzLiAgSXQgaXMgbm90IGEgc2VydmljZSB0aGF0IHJpZGVzIG9u IGdlbmVyYWwgSVAgb3Igc2VwYXJhdGUgZnJvbSB0aGUgTVBMUyBsYXllcnMuDQo+IA0KPiBMb3UN Cj4gDQo+IE9uIDMvMTYvMjAyMCAxMDoxOCBBTSwgV2F0c29uIExhZGQgd3JvdGU6DQo+PiANCj4+ IA0KPj4gT24gTW9uLCBNYXIgMTYsIDIwMjAsIDc6MDEgQU0gU3Rld2FydCBCcnlhbnQgPHN0ZXdh cnQuYnJ5YW50QGdtYWlsLmNvbT4gd3JvdGU6DQo+Pj4gVGhlIHJlcXVpcmVtZW50IGlzIE5PVCBm b3IgYSBkcmFmdCB0byBwcm92aWRlIHRoZSBzZWN1cml0eSBhbmFseXNpcyBvZiBhbGwgb2YgYWxs IG9mIHRoZSB0ZWNobm9sb2dpZXMgdGhhdCBpdCBjYWxscyB1cC4gSXQgaXMsIEkgYmVsaWV2ZSwg dG8gZGVzY3JpYmUgdGhlIGRlbHRhcyB0aGF0IGFwcGx5IHRvIHRoZSBuZXcgaWRlYS4gQW55dGhp bmcgZWxzZSBhbmQgdGhlIHRleHQgd291bGQgYmUgYSBzZWN1cml0eSBhbmFseXNpcyB3aXRoIGEg c2hvcnQgdGVjaG5vbG9neSBwcmVhbWJsZS4NCj4+PiANCj4+PiBXZSBhcmUgZGVzY3JpYmluZyBh IHRlY2hub2xvZ3kgdGhhdCBpcyBvdmVybGFpZCBvbiBNUExTLiBXZSBzaG91bGQgbm90IG5lZWQg dG8gZGVzY3JpYmUgdGhlIHNlY3VyaXR5IG1vZGVsIG9mIE1QTFMsICBidXQgaW5zdGVhZCBjb25m aW5lIG91ciByZW1hcmtzIHRvIGlzc3VlcyB0aGF0IHNwZWNpZmljYWxseSBhcHBseSB0byB0aGUg YWRkaXRpb25hbCB0ZWNobm9sb2d5IHdlIGFyZSBkZXNjcmliaW5nLg0KPj4gDQo+PiANCj4+IFJG QyAzNTUyIHJlcXVpcmVzIHRoYXQgaW4gYSBjYXNlIHN1Y2ggYXMgdGhpcyB5b3UgZXhwbGljaXRs eSBkZXNjcmliZSB3aGF0IHRoZSBsb3dlciBsYXllciBpcyBwcm92aWRpbmcgdG8gdGhlIHRvcCBs YXllci4gUkZDIDM1NTIgc2VjdGlvbiA1IGFsc28gZGVtYW5kcyB0aGF0IGF0dGFja3MgYmUgZW51 bWVyYXRlZCBhbmQgdGhvc2Ugb3V0IG9mIHNjb3BlIGJlIGNhbGxlZCBvdXQuDQo+PiANCj4+IEUu ZyAidXNlIFRMUyIgaXNuJ3QgZ29vZCBlbm91Z2ggYW5kIGltaG8gbmVpdGhlciBpcyAidXNlIE1Q TFMiLg0KPj4gDQo+PiBBZ2FpbiwgdGhlIHNlbnRlbmNlcyBpbiB0aGUgc2VjdXJpdHkgY29uc2lk ZXJhdGlvbnMgYXMgaXQgc3RhbmRzIGFyZSBhYm91dCBNUExTIGFuZCBEZXRuZXQsIGFuZCB0aGV5 IGRvbid0IHNlZW0gdG8gY29tZSB0b2dldGhlci4gQXJlIHRoZXJlIHJlYWxseSBubyBzZWN1cml0 eSBjb25zaWRlcmF0aW9ucyB3aGVuIHB1dHRpbmcgdGhlIHR3byB0b2dldGhlcj8gRXZlcnkgTVBM UyBuZXR3b3JrIHdpbGwganVzdCB3b3JrIHdpdGggRGV0bmV0IG9uIHRvcCwgbm8gbWF0dGVyIGhv dyBydXNoZWQgdGhlIGRlcGxveSBpcz8NCj4+IA0KPj4+IA0KPj4+IEVhcmx5IGluIHRoZSBkb2N1 bWVudCB3ZSBjYWxsIHVwIFJGQzMwMzEgYW5kIFJGQzMwMzIsIHRoZSBmdW5kYW1lbnRhbCBNUExT IFJGQ3MuIFRoZXkgYXJlIGluIHNlY3Rpb24gMy4xIHRoZSBmaXJzdCBwYXJ0IG9mIHRoZSBzZXJp b3VzIHRlY2huaWNhbCBkaXNjdXNzaW9uLiBJbiBteSB2aWV3IHRoZXNlIGVzdGFibGlzaCBhIGJh c2VsaW5lIG9mIHVuZGVyc3RhbmQgdGhhdCB0aGUgcmVhZGVyIGlzIGV4cGVjdGVkIHRvIGhhdmUu DQo+Pj4gDQo+Pj4gSXQgaXMgaW1wb3J0YW50IHRvIHJlYWxpc2UsIGFzIEkgaGF2ZSBzYWlkIGJl Zm9yZSwgdGhhdCB3aXRob3V0IHVuZGVyc3RhbmRpbmcgdGhhdCBiYXNlbGluZSB0aGUgcmVzdCBv ZiB0aGUgZG9jdW1lbnQgaXMgbWVhbmluZ2xlc3MuDQo+Pj4gDQo+Pj4gUmVnYXJkcw0KPj4+IA0K Pj4+IFN0ZXdhcnQNCj4+PiANCj4+PiBCVFcNCj4+PiANCj4+PiBJdCBtaWdodCBiZSBhcyB3ZWxs IGlmIHlvdSByZWZyYWluZWQgZnJvbSBpbGx1c3RyYXRpbmcgdGhlIGxhY2sgb2YgcHJvZmVzc2lv bmFsaXNtIHRoYXQgdGhlIHNlY3VyaXR5IGFyZWEgYXBwbGllcyB0byBpdHMgcmV2aWV3cyBieSBj b250aW51aW5nIHdpdGggdGhlIGZsaXBwYW5jeS4gVGhlcmUgaXMgYSBzZXJpb3VzIHBvaW50IHRo YXQgbmVlZHMgdG8gYmUgZGViYXRlZCBoZXJlIGFib3V0IHdoYXQgYXNzdW1wdGlvbnMgYXJlIGEg Z2l2ZW4gYW5kIHdoYXQgYXNzdW1wdGlvbnMgbmVlZCB0byBiZSBzcGVsbGVkIG91dCB3aGVuIG1v ZGlmeWluZyBvciBsYXllcmluZyBhIHRlY2hub2xvZ3kuDQo+Pj4gDQo+Pj4gDQo+Pj4gPiBPbiAx NiBNYXIgMjAyMCwgYXQgMTI6MjIsIFVyaSBCbHVtZW50aGFsIDx1cmlAbWl0LmVkdT4gd3JvdGU6 DQo+Pj4gPiANCj4+PiA+IElFVEYgcG9zaXRpb24gKGFkZCBmYXQgYXMgSSByZW1lbWJlcikgcmVn YXJkaW5nIFJGQ3MgaGFzIGJlZW4gdGhhdCBSRkNzIHNob3VsZCBwcm92aWRlIHdpdGggZXZlcnl0 aGluZyBpbmZvcm1hdGlvbiBmb3IgYSByZWFzb25hYmxlIGRldmVsb3BlciB0byBpbXBsZW1lbnQg Y29ycmVjdGx5IGFuZCBzZWN1cmVseSB0aGUgc3RhbmRhcmQgdGhleSBkZWZpbmUsIGFuZCBwcm92 aWRlIGVub3VnaCBpbmZvcm1hdGlvbiBmb3IgdGhlIHBlcnNvbiB3aG8gd2lsbCBkZXBsb3kgYSBj b21wbGlhbnQgaW1wbGVtZW50YXRpb24gdG8gZG8gdGhhdCBjb3JyZWN0bHkgYW5kIHNlY3VyZWx5 Lg0KPj4+ID4gDQo+Pj4gPiBPbmUgcHVycG9zZSBvZiBTZWN1cml0eSBSZXZpZXcgaXMgdG8gZW5z dXJlIHRoYXQgYSBwZXJzb24gZG9lc24ndCBoYXZlIHRvIGJlIGFuIGV4cGVydCBpbiB0aGUgZmll bGQgdG8gZGVhbCB3aXRoIHRoZSBwcm9wb3NlZCBkb2N1bWVudC4NCj4+PiA+IA0KPj4+ID4gSW4g YSBmbGlwcGFudCB3YXksIGlmIHVzaW5nIHlvdXIgc3R1ZmYgaXMgcmVxdWlyZXMgc3BlY2lhbCBj bGFzc2VzIC0gcGVyaGFwcyBpdCBiZWxvbmdzIHRvIGEgYm9vayByYXRoZXIgdGhhbiBhbiBSRkMu DQo+Pj4gPiANCj4+PiA+IEluIGEgbm9uLWZsaXBwYW50IHdheSAtIHdoYXQncyB0aGUgcHJvYmxl bSBpbiBtZW50aW9uaW5nIHRoZSBpc3N1ZXMgYW5kIHByb3ZpZGluZyB0aGUgYXBwcm9wcmlhdGUg cmVmZXJlbmNlcz8gQSAibm9ybWFsIiBSRkMgY2Fubm90IGJlIHNlbGYtY29udGFpbmVkLCBidXQg aXQncyB1bnJlYXNvbmFibGUgdG8gZXBlY3QgYSByZWFkZXIgdG8ganVzdCAia25vdyIgd2hlcmUg YWxsIHRoZSBvbWl0dGVkIHRoaW5ncyBhcmUgZGVzY3JpYmVkLiANCj4+PiA+IA0KPj4+ID4+IE9u IE1hciAxNiwgMjAyMCwgYXQgMDY6MzMsIFN0ZXdhcnQgQnJ5YW50IDxzdGV3YXJ0LmJyeWFudEBn bWFpbC5jb20+IHdyb3RlOg0KPj4+ID4+IA0KPj4+ID4+IO+7v1VyaSwNCj4+PiA+PiANCj4+PiA+ PiBUaGF0IGlzIGEgcmlkaWN1bG91cyBwb3NpdGlvbiwgYW5kIHlvdSBmbGlwcGFuY3kgZGVtb25z dHJhdGVzIHRoYXQuDQo+Pj4gPj4gDQo+Pj4gPj4gVGhpcyB0ZWNobm9sb2d5IGZ1bmRhbWVudGFs bHkgcmVzdHMgb24gTVBMUyBhbmQgaXQgaXMgcmVhc29uYWJsZSB0aGF0IHRoZSByZWFkZXIgb2Yg dGhpcyBSRkMgd2lsbCB1bmRlcnN0YW5kIE1QTFMgYW5kIHRoZSBzZWN1cml0eSBtb2RlbCBpdCB1 c2VzIGJlZm9yZSB0aGV5IGltcGxlbWVudCBvciBkZXBsb3kgaXQuIEluZGVlZCBJIGNhbm5vdCB0 aGluayBvZiBhbnkgaW1wbGVtZW50b3Igb3Igb3BlcmF0b3IgdGhhdCB3b3VsZCBub3QgYWxyZWFk eSBoYXZlIHRoYXQga25vd2xlZGdlIGJlZm9yZSB0YWtpbmcgb24gdGhlIHRhc2sgb2YgYnVpbGRp bmcgb3IgcnVubmluZyBETiBvdmVyIE1QTFMuDQo+Pj4gPj4gDQo+Pj4gPj4gSWYgU2VjRGlyIHJl dmlld3MgYXJlIHRvIHJldGFpbiBhbnkgY3JlZGliaWxpdHkgYXMgZXhwZXJ0IHJldmlld3MgYXMg b3Bwb3NlZCB0byBHZW5hcnQgcmFuZG9tIHJlYWRlciByZXZpZXdzIHRoZXkgaGF2ZSB0byBiZSBj YXJyaWVkIG91dCB3aXRoIHNoYXJlZCBrbm93bGVkZ2Ugb2YgYm90aCB0aGUgc2VjdXJpdHkgYXJl YSBhbmQgdGhlIGRyYWZ04oCZcyBob3N0IGFyZWEuDQo+Pj4gPj4gDQo+Pj4gPj4gSSBoYXZlIGJl ZW4gdGhpbmtpbmcgZm9yIHNvbWUgdGltZSB0aGF0IHRoZXJlIG5lZWRzIHRvIGJlIGEgZnVuZGFt ZW50YWwgcmV2aWV3IG9mIHRoZSBzZWN1cml0eSByZXZpZXcgcHJvY2Vzcy4NCj4+PiA+PiANCj4+ PiA+PiBTdGV3YXJ0DQo+Pj4gPj4gDQo+Pj4gPj4+IE9uIDE1IE1hciAyMDIwLCBhdCAyMjo0NCwg VXJpIEJsdW1lbnRoYWwgPHVyaUBtaXQuZWR1PiB3cm90ZToNCj4+PiA+Pj4gDQo+Pj4gPj4+IEkg c2F5IHllcyAtIHVubGVzcyB5b3UgZXhwZWN0IGEgcGVyc29uIHdobyB3YW50cyBqdXN0IG9uZSBS RkMgdG8gaGF2ZSB0byByZWFkIGV2ZXJ5IGNyXmheaCBzdHVmZiB0aGF0IGNhbWUgb3V0IG9mIHRo ZSByb3V0aW5nIGFyZWEuDQo+Pj4gPj4+IA0KPj4+ID4+PiAiSnVzdCBkbyBpdCINCj4+PiA+Pj4g DQo+Pj4gPj4+IA0KPj4+ID4+Pj4+IE9uIE1hciAxNSwgMjAyMCwgYXQgMTc6MzksIExvdSBCZXJn ZXIgPGxiZXJnZXJAbGFibi5uZXQ+IHdyb3RlOg0KPj4+ID4+Pj4gDQo+Pj4gPj4+PiDvu78NCj4+ PiA+Pj4+PiBPbiAzLzE1LzIwMjAgNToyMiBQTSwgV2F0c29uIExhZGQgd3JvdGU6DQo+Pj4gPj4+ Pj4+IE9uIFN1biwgTWFyIDE1LCAyMDIwIGF0IDI6MTQgUE0gTG91IEJlcmdlciA8bGJlcmdlckBs YWJuLm5ldD4gd3JvdGU6DQo+Pj4gPj4+Pj4+IEhpIFdhdHNvbiwNCj4+PiA+Pj4+Pj4gDQo+Pj4g Pj4+Pj4+ICAgSSB0aGluayBTdGV3YXJ0J3MgcmVzcG9uc2UgcmVhbGx5IGNvdmVycyB0aGUgbWFp biBwb2ludHMuIERldE5ldCBpcw0KPj4+ID4+Pj4+PiByZWFsbHkganVzdCBNUExTIChhbmQgSVAp IHdpdGggc29tZSBzcGVjaWZpYyBmb3J3YXJkaW5nIGJlaGF2aW9ycyBhbmQNCj4+PiA+Pj4+Pj4g cXVldWluZy4gIFRoZSBvbmx5IHRoaW5nIEknZCBhZGQsIGlzIEkgc2VlIERldE5ldCBpbiBnZW5l cmFsIGFzIGENCj4+PiA+Pj4+Pj4gc3BlY2lmaWMgZm9ybSBvZiBwb2xpY3kgYmFzZWQgcm91dGlu Zy4gKFRoZSBnZW5lcmFsIGZvcm0gb2Ygd2hpY2ggaXMNCj4+PiA+Pj4+Pj4gcHJldHR5IG11Y2gg YXMgb2xkIGFzIElQKS4NCj4+PiA+Pj4+PiBUaGVuIFN0ZXdhcnQgY2FuIHB1dCB0aG9zZSBwb2lu dHMgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zDQo+Pj4gPj4+Pj4gc2VjdGlvbi4gV2hh dCdzIHRoZSBkaXNhZHZhbnRhZ2Ugb2YgZG9pbmcgc28/DQo+Pj4gPj4+PiANCj4+PiA+Pj4+IEF0 IG9uZSBsZXZlbCwgaXQgd291bGQgYmUgZWFzaWVzdCBmb3IgdGhlIGF1dGhvcnMgdG8ganVzdCBw dXQgdGhlc2UgaW4uICBPbiB0aGUgb3RoZXIgaGFuZCwgdGhpcyB3b3VsZCBtZWFuIHRoYXQgZXZl cnkgUkZDIHByb2R1Y2VkIGluIHRoZSByb3V0aW5nIGFyZWEgd2lsbCBhY3F1aXJlIHNpbWlsYXIg bm90ZXMsIGUuZy4sIHJvdXRpbmcgcHJvdG9jb2xzIGFyZSBjdXJyZW50bHkgYnVpbHQgd2l0aCBh IGNoYWluIG9mIHRydXN0IG1vZGVsLiAgSXMgdGhpcyB3aGF0IHRoZSBzZWMtZGlyIHJlYWxseSBp cyBhc2tpbmcgdGhlIHJvdXRpbmcgYXJlYSB0byBkbz8NCj4+PiA+Pj4+IA0KPj4+ID4+Pj4gQURz LA0KPj4+ID4+Pj4gDQo+Pj4gPj4+PiAgYW55IG9waW5pb24gb24gdGhpcz8gICAgIChmb3IgY29u dGV4dCwgU3Rld2FydCdzIHJlc3BvbnNlIGNhbiBiZSBmb3VuZCBhdDogaHR0cHM6Ly9tYWlsYXJj aGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9kZXRuZXQvLWVwTDVGYjZiRklVbHRNcmpINTNDMjMxNlpB LykNCj4+PiA+Pj4+IA0KPj4+ID4+Pj4gVGhhbmtzLA0KPj4+ID4+Pj4gDQo+Pj4gPj4+PiBMb3UN Cj4+PiA+Pj4+IA0KPj4+ID4+Pj4+PiBMb3UNCj4+PiA+Pj4+Pj4gDQo+Pj4gPj4+Pj4+IE9uIDMv MTIvMjAyMCA5OjM1IFBNLCBXYXRzb24gTGFkZCB3cm90ZToNCj4+PiA+Pj4+Pj4+IE9uIFRodSwg TWFyIDEyLCAyMDIwIGF0IDQ6MDcgQU0gTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4gd3Jv dGU6DQo+Pj4gPj4+Pj4+Pj4gV2F0c29uLA0KPj4+ID4+Pj4+Pj4+IA0KPj4+ID4+Pj4+Pj4+IENh biB5b3UgcHJvdmlkZSBjb250ZXh0IGhlcmU/IENhbiB5b3UgYmUgZXhwbGljaXQgb24gd2hhdCB5 b3Ugc2VlIG5lZWRzIHRvDQo+Pj4gPj4+Pj4+Pj4gYmUgYWRkcmVzc2VkIChiZXlvbmQgd2hhdCBp cyBpbiB0aGlzIGRvY3VtZW50IGFzIHdlbGwgYXMgcmVsYXRlZCByZmNzKT8NCj4+PiA+Pj4+Pj4+ IFlvdSBoYXZlIHRvIHRhbGsgYWJvdXQgaG93IHRoZSBsYXllcnMgaW50ZXJhY3QsIGFuZCBjYW4n dCBqdXN0IHNheSB0aGUNCj4+PiA+Pj4+Pj4+IGxvd2VyIGxldmVsIGhhbmRsZXMgYW55dGhpbmcg d2l0aG91dCBhbnkgZ3VpZGUgYXMgdG8gd2hhdCBuZWVkcyB0byBiZQ0KPj4+ID4+Pj4+Pj4gcHJv dmlkZWQgYnkgdGhhdCBsb3dlciBsYXllci4NCj4+PiA+Pj4+Pj4+IA0KPj4+ID4+Pj4+Pj4gSSB0 aGluayBteSBjb25jZXJucyBhYm91dCB0aGUgYXNzdW1wdGlvbnMgdGhpcyBjb3VsZCBiZSBmaXhl ZCBieQ0KPj4+ID4+Pj4+Pj4gc2F5aW5nLiAiQWxsIG5vZGVzIGFyZSB0cnVzdGVkIGFuZCBhbnkg b2YgdGhlbSBjYW4gbWlzYmVoYXZlIGluIHdheXMNCj4+PiA+Pj4+Pj4+IHRoYXQgYWZmZWN0IHRo ZSBuZXR3b3JrLiAgSWYgdGhlIE1QTFMgbGF5ZXIgY2Fubm90IHByb3ZpZGUgc3VmZmljaWVudA0K Pj4+ID4+Pj4+Pj4gZGV0ZXJtaW5pc20sIHRoZW4gdGhlIERldE5ldCBtZWNoYW5pc21zIHdvbid0 IHdvcmsiLiAgSSBhZ3JlZSB3ZQ0KPj4+ID4+Pj4+Pj4gc2hvdWRuJ3QgcmVxdWlyZSBhbiBlbnRp cmUgbWFzc2l2ZSBzZWN1cml0eSBmcmFtZXdvcmsgdG8gYmUgcXVvdGVkDQo+Pj4gPj4+Pj4+PiBh Z2FpbiBoZXJlLCBidXQgdGhlcmUgbXVzdCBiZSBzb21lIGRldGFpbHMgb2YgdGhpcyBlbWJlZGRp bmcgdGhhdCBhcmUNCj4+PiA+Pj4+Pj4+IHdvcnRoIG5vdGluZywgYW5kIHlldCBJIGRvbid0IHNl ZSB0aGVtIGNhbGxlZCBvdXQgaW4gdGhlIHNlY3VyaXR5DQo+Pj4gPj4+Pj4+PiBjb25zaWRlcmF0 aW9ucyBzZWN0aW9uLg0KPj4+ID4+Pj4+Pj4gDQo+Pj4gPj4+Pj4+PiBBcmUgdGhlcmUgcmVhbGx5 IG5vIHNwZWNpZmljIGNvbmNlcm5zIGFib3V0IHRoZSBpbnRlcmFjdGlvbiBiZXR3ZWVuDQo+Pj4g Pj4+Pj4+PiBEZXROZXQgYW5kIE1QTFM/DQo+Pj4gPj4+Pj4+PiANCj4+PiA+Pj4+Pj4+PiBUaGFu ayB5b3UsDQo+Pj4gPj4+Pj4+Pj4gTG91DQo+Pj4gPj4+Pj4+Pj4gDQo+Pj4gPj4+Pj4+Pj4gDQo+ Pj4gPj4+Pj4+Pj4gLS0tLS0tLS0tLQ0KPj4+ID4+Pj4+Pj4+IE9uIE1hcmNoIDExLCAyMDIwIDEw OjMwOjI3IFBNIFdhdHNvbiBMYWRkIDx3YXRzb25ibGFkZEBnbWFpbC5jb20+IHdyb3RlOg0KPj4+ ID4+Pj4+Pj4+IA0KPj4+ID4+Pj4+Pj4+PiBJIGRvbid0IHNlZSBhbnkgcmVhc29uIHdoeSBSRkMg MzU1MidzIGd1aWRlbGluZXMgc2hvdWRuJ3QgYXBwbHkgdG8gdGhpcyBkcmFmdC4NCj4+PiA+Pj4+ Pj4+Pj4gDQo+Pj4gPj4+Pj4+Pj4+IElmIHRoZXJlIGlzIGEgTVBMUyBleGNlcHRpb24gSSdkIGxp a2UgdG8gc2VlIHRoZSBydWxlcyB0aGF0IHNob3VsZCBiZSBhcHBsaWVkLg0KPj4+ID4+Pj4+Pj4+ PiANCj4+PiA+Pj4+Pj4+Pj4gQXMgaXMgSSBkb24ndCBzZWUgYW55IHJlYXNvbiB3aHkgdGhlIGFz c3VtcHRpb25zIGNhbid0IGJlIGV4cGxpY2l0bHkNCj4+PiA+Pj4+Pj4+Pj4gc3BlbGxlZCBvdXQs IGVpdGhlciBpbiB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgb3IgZWxzZXdoZXJlLg0KPj4+ ID4+Pj4+Pj4+PiANCj4+PiA+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+PiA+Pj4+Pj4+Pj4gZGV0bmV0IG1haWxpbmcgbGlzdA0KPj4+ ID4+Pj4+Pj4+PiBkZXRuZXRAaWV0Zi5vcmcNCj4+PiA+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kZXRuZXQNCj4+PiA+Pj4+Pj4+Pj4gDQo+Pj4gPj4+Pj4g DQo+Pj4gPj4+Pj4gDQo+Pj4gPj4+PiANCj4+PiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gPj4+PiBzZWNkaXIgbWFpbGluZyBsaXN0DQo+ Pj4gPj4+PiBzZWNkaXJAaWV0Zi5vcmcNCj4+PiA+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2VjZGlyDQo+Pj4gPj4+PiB3aWtpOiBodHRwOi8vdG9vbHMuaWV0Zi5v cmcvYXJlYS9zZWMvdHJhYy93aWtpL1NlY0RpclJldmlldw0KPj4+ID4+IA0KPj4+IA0K --Apple-Mail-E332C98A-9D45-4540-B7F4-8CFBD022EB9B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPkxvdSw8ZGl2Pjxi cj48L2Rpdj48ZGl2PlllcywgYWRkaW5nIHRoYXQgcmVmZXJlbmNlIHdvdWxkIGhlbHAgKElNSE8p LjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+SWYgaW5kZWVkLCBhcyBTdGV3YXJ0IHNheXMsIGRl dG5ldCBkb2VzIG5vdCBhZGQgYW55IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHRvIHRob3NlIGFs cmVhZHkgZGVzY3JpYmVkIGluIHRoZSBNUExTIGRvY3VtZW50cyAtIHRoZSBkcmFmdCBzaG91bGQg c3RhdGUgc28gZXhwbGljaXRseS4gVGhvdWdoIEkgcGVyc29uYWxseSBmaW5kIGl0IGhhcmQgdG8g YmVsaWV2ZS48YnI+PGJyPjxkaXYgZGlyPSJsdHIiPldoYXQgaXMgYW4gIm9idmlvdXMgY29tbW9u IHNlbnNlIiBmb3IgeW91IGFuZCBTdGV3YXJ0LCBtYXkgbm90IGJlIHNvIG9idmlvdXMgdG8gb3Ro ZXIgcmVhZGVycy48L2Rpdj48ZGl2IGRpcj0ibHRyIj48YnI+PC9kaXY+PGRpdiBkaXI9Imx0ciI+ QXMgYSBub3RlIHRvIG90aGVycywgaXQgaXMgZXhwZWN0ZWQgdGhhdCBSRkMgYXV0aG9ycyBkbyBw ZXJmb3JtIGEgY29tcHJlaGVuc2l2ZSBzZWN1cml0eSBhbmFseXNpcywgYW5kIGRvY3VtZW50IHRo ZWlyIGZpbmRpbmdzIGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uLiBJIHRo b3VnaHQgdGhhdCB3YXMgb2J2aW91cy48L2Rpdj48ZGl2IGRpcj0ibHRyIj48YnI+PC9kaXY+PGRp diBkaXI9Imx0ciI+PGJyPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPk9uIE1hciAxNiwgMjAyMCwg YXQgMTA6MjIsIExvdSBCZXJnZXIgJmx0O2xiZXJnZXJAbGFibi5uZXQmZ3Q7IHdyb3RlOjxicj48 YnI+PC9ibG9ja3F1b3RlPjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXYgZGlyPSJs dHIiPu+7vw0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0 bWw7IGNoYXJzZXQ9dXRmLTgiPg0KICANCiAgDQogICAgPHA+V2F0c29uLCBVcmksPC9wPg0KICAg IDxwPndvdWxkIGEgcmVmZXJlbmNlIHRvIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLWRldG5ldC1zZWN1cml0eS0wOCNzZWN0aW9uLTciPmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRldG5ldC1zZWN1cml0eS0wOCNzZWN0aW9uLTc8 L2E+DQogICAgICBoZWxwPyBub3RlIHRoYXQgRGV0bmV0IG9wZXJhdGVzL2V4dGVuZHMgdGhlIElQ IGFuZCBNUExTIGxheWVycy4mbmJzcDsNCiAgICAgIEl0IGlzIG5vdCBhIHNlcnZpY2UgdGhhdCBy aWRlcyBvbiBnZW5lcmFsIElQIG9yIHNlcGFyYXRlIGZyb20gdGhlDQogICAgICBNUExTIGxheWVy cy48L3A+DQogICAgPHA+TG91PGJyPg0KICAgIDwvcD4NCiAgICA8ZGl2IGNsYXNzPSJtb3otY2l0 ZS1wcmVmaXgiPk9uIDMvMTYvMjAyMCAxMDoxOCBBTSwgV2F0c29uIExhZGQNCiAgICAgIHdyb3Rl Ojxicj4NCiAgICA8L2Rpdj4NCiAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjaXRlPSJtaWQ6 Q0FDc24wY25DQW8wODJoQjRNSz1kUlR4YmhhMW5pR3NTUTQtZFc0X1V2UThiWjBUQkx3QG1haWwu Z21haWwuY29tIj4NCiAgICAgIA0KICAgICAgPGRpdiBkaXI9ImF1dG8iPg0KICAgICAgICA8ZGl2 Pjxicj4NCiAgICAgICAgICA8YnI+DQogICAgICAgICAgPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUi Pg0KICAgICAgICAgICAgPGRpdiBkaXI9Imx0ciIgY2xhc3M9ImdtYWlsX2F0dHIiPk9uIE1vbiwg TWFyIDE2LCAyMDIwLCA3OjAxDQogICAgICAgICAgICAgIEFNIFN0ZXdhcnQgQnJ5YW50ICZsdDs8 YSBocmVmPSJtYWlsdG86c3Rld2FydC5icnlhbnRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayIg cmVsPSJub3JlZmVycmVyIiBtb3otZG8tbm90LXNlbmQ9InRydWUiPnN0ZXdhcnQuYnJ5YW50QGdt YWlsLmNvbTwvYT4mZ3Q7DQogICAgICAgICAgICAgIHdyb3RlOjxicj4NCiAgICAgICAgICAgIDwv ZGl2Pg0KICAgICAgICAgICAgPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0i bWFyZ2luOjAgMCAwDQogICAgICAgICAgICAgIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29s aWQ7cGFkZGluZy1sZWZ0OjFleCI+VGhlDQogICAgICAgICAgICAgIHJlcXVpcmVtZW50IGlzIE5P VCBmb3IgYSBkcmFmdCB0byBwcm92aWRlIHRoZSBzZWN1cml0eQ0KICAgICAgICAgICAgICBhbmFs eXNpcyBvZiBhbGwgb2YgYWxsIG9mIHRoZSB0ZWNobm9sb2dpZXMgdGhhdCBpdCBjYWxscw0KICAg ICAgICAgICAgICB1cC4gSXQgaXMsIEkgYmVsaWV2ZSwgdG8gZGVzY3JpYmUgdGhlIGRlbHRhcyB0 aGF0IGFwcGx5IHRvDQogICAgICAgICAgICAgIHRoZSBuZXcgaWRlYS4gQW55dGhpbmcgZWxzZSBh bmQgdGhlIHRleHQgd291bGQgYmUgYQ0KICAgICAgICAgICAgICBzZWN1cml0eSBhbmFseXNpcyB3 aXRoIGEgc2hvcnQgdGVjaG5vbG9neSBwcmVhbWJsZS48YnI+DQogICAgICAgICAgICAgIDxicj4N CiAgICAgICAgICAgICAgV2UgYXJlIGRlc2NyaWJpbmcgYSB0ZWNobm9sb2d5IHRoYXQgaXMgb3Zl cmxhaWQgb24gTVBMUy4NCiAgICAgICAgICAgICAgV2Ugc2hvdWxkIG5vdCBuZWVkIHRvIGRlc2Ny aWJlIHRoZSBzZWN1cml0eSBtb2RlbCBvZg0KICAgICAgICAgICAgICBNUExTLCZuYnNwOyBidXQg aW5zdGVhZCBjb25maW5lIG91ciByZW1hcmtzIHRvIGlzc3VlcyB0aGF0DQogICAgICAgICAgICAg IHNwZWNpZmljYWxseSBhcHBseSB0byB0aGUgYWRkaXRpb25hbCB0ZWNobm9sb2d5IHdlIGFyZQ0K ICAgICAgICAgICAgICBkZXNjcmliaW5nLjxicj4NCiAgICAgICAgICAgIDwvYmxvY2txdW90ZT4N CiAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgPC9kaXY+DQogICAgICAgIDxkaXYgZGlyPSJhdXRv Ij48YnI+DQogICAgICAgIDwvZGl2Pg0KICAgICAgICA8ZGl2IGRpcj0iYXV0byI+UkZDIDM1NTIg cmVxdWlyZXMgdGhhdCBpbiBhIGNhc2Ugc3VjaCBhcyB0aGlzDQogICAgICAgICAgeW91IGV4cGxp Y2l0bHkgZGVzY3JpYmUgd2hhdCB0aGUgbG93ZXIgbGF5ZXIgaXMgcHJvdmlkaW5nIHRvDQogICAg ICAgICAgdGhlIHRvcCBsYXllci4gUkZDIDM1NTIgc2VjdGlvbiA1IGFsc28gZGVtYW5kcyB0aGF0 IGF0dGFja3MgYmUNCiAgICAgICAgICBlbnVtZXJhdGVkIGFuZCB0aG9zZSBvdXQgb2Ygc2NvcGUg YmUgY2FsbGVkIG91dC48L2Rpdj4NCiAgICAgICAgPGRpdiBkaXI9ImF1dG8iPjxicj4NCiAgICAg ICAgPC9kaXY+DQogICAgICAgIDxkaXYgZGlyPSJhdXRvIj5FLmcgInVzZSBUTFMiIGlzbid0IGdv b2QgZW5vdWdoIGFuZCBpbWhvIG5laXRoZXINCiAgICAgICAgICBpcyAidXNlIE1QTFMiLjwvZGl2 Pg0KICAgICAgICA8ZGl2IGRpcj0iYXV0byI+PGJyPg0KICAgICAgICA8L2Rpdj4NCiAgICAgICAg PGRpdiBkaXI9ImF1dG8iPkFnYWluLCB0aGUgc2VudGVuY2VzIGluIHRoZSBzZWN1cml0eQ0KICAg ICAgICAgIGNvbnNpZGVyYXRpb25zIGFzIGl0IHN0YW5kcyBhcmUgYWJvdXQgTVBMUyBhbmQgRGV0 bmV0LCBhbmQNCiAgICAgICAgICB0aGV5IGRvbid0IHNlZW0gdG8gY29tZSB0b2dldGhlci4gQXJl IHRoZXJlIHJlYWxseSBubyBzZWN1cml0eQ0KICAgICAgICAgIGNvbnNpZGVyYXRpb25zIHdoZW4g cHV0dGluZyB0aGUgdHdvIHRvZ2V0aGVyPyBFdmVyeSBNUExTDQogICAgICAgICAgbmV0d29yayB3 aWxsIGp1c3Qgd29yayB3aXRoIERldG5ldCBvbiB0b3AsIG5vIG1hdHRlciBob3cNCiAgICAgICAg ICBydXNoZWQgdGhlIGRlcGxveSBpcz88L2Rpdj4NCiAgICAgICAgPGRpdiBkaXI9ImF1dG8iPjxi cj4NCiAgICAgICAgPC9kaXY+DQogICAgICAgIDxkaXYgZGlyPSJhdXRvIj4NCiAgICAgICAgICA8 ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQogICAgICAgICAgICA8YmxvY2txdW90ZSBjbGFzcz0i Z21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDANCiAgICAgICAgICAgICAgLjhleDtib3Jk ZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCiAgICAgICAgICAgICAg PGJyPg0KICAgICAgICAgICAgICBFYXJseSBpbiB0aGUgZG9jdW1lbnQgd2UgY2FsbCB1cCBSRkMz MDMxIGFuZCBSRkMzMDMyLCB0aGUNCiAgICAgICAgICAgICAgZnVuZGFtZW50YWwgTVBMUyBSRkNz LiBUaGV5IGFyZSBpbiBzZWN0aW9uIDMuMSB0aGUgZmlyc3QNCiAgICAgICAgICAgICAgcGFydCBv ZiB0aGUgc2VyaW91cyB0ZWNobmljYWwgZGlzY3Vzc2lvbi4gSW4gbXkgdmlldyB0aGVzZQ0KICAg ICAgICAgICAgICBlc3RhYmxpc2ggYSBiYXNlbGluZSBvZiB1bmRlcnN0YW5kIHRoYXQgdGhlIHJl YWRlciBpcw0KICAgICAgICAgICAgICBleHBlY3RlZCB0byBoYXZlLjxicj4NCiAgICAgICAgICAg ICAgPGJyPg0KICAgICAgICAgICAgICBJdCBpcyBpbXBvcnRhbnQgdG8gcmVhbGlzZSwgYXMgSSBo YXZlIHNhaWQgYmVmb3JlLCB0aGF0DQogICAgICAgICAgICAgIHdpdGhvdXQgdW5kZXJzdGFuZGlu ZyB0aGF0IGJhc2VsaW5lIHRoZSByZXN0IG9mIHRoZQ0KICAgICAgICAgICAgICBkb2N1bWVudCBp cyBtZWFuaW5nbGVzcy48YnI+DQogICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgUmVn YXJkczxicj4NCiAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICBTdGV3YXJ0PGJyPg0K ICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgIEJUVzxicj4NCiAgICAgICAgICAgICAg PGJyPg0KICAgICAgICAgICAgICBJdCBtaWdodCBiZSBhcyB3ZWxsIGlmIHlvdSByZWZyYWluZWQg ZnJvbSBpbGx1c3RyYXRpbmcgdGhlDQogICAgICAgICAgICAgIGxhY2sgb2YgcHJvZmVzc2lvbmFs aXNtIHRoYXQgdGhlIHNlY3VyaXR5IGFyZWEgYXBwbGllcyB0bw0KICAgICAgICAgICAgICBpdHMg cmV2aWV3cyBieSBjb250aW51aW5nIHdpdGggdGhlIGZsaXBwYW5jeS4gVGhlcmUgaXMgYQ0KICAg ICAgICAgICAgICBzZXJpb3VzIHBvaW50IHRoYXQgbmVlZHMgdG8gYmUgZGViYXRlZCBoZXJlIGFi b3V0IHdoYXQNCiAgICAgICAgICAgICAgYXNzdW1wdGlvbnMgYXJlIGEgZ2l2ZW4gYW5kIHdoYXQg YXNzdW1wdGlvbnMgbmVlZCB0byBiZQ0KICAgICAgICAgICAgICBzcGVsbGVkIG91dCB3aGVuIG1v ZGlmeWluZyBvciBsYXllcmluZyBhIHRlY2hub2xvZ3kuPGJyPg0KICAgICAgICAgICAgICA8YnI+ DQogICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgJmd0OyBPbiAxNiBNYXIgMjAyMCwg YXQgMTI6MjIsIFVyaSBCbHVtZW50aGFsICZsdDs8YSBocmVmPSJtYWlsdG86dXJpQG1pdC5lZHUi IHJlbD0ibm9yZWZlcnJlciBub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1z ZW5kPSJ0cnVlIj51cmlAbWl0LmVkdTwvYT4mZ3Q7DQogICAgICAgICAgICAgIHdyb3RlOjxicj4N CiAgICAgICAgICAgICAgJmd0OyA8YnI+DQogICAgICAgICAgICAgICZndDsgSUVURiBwb3NpdGlv biAoYWRkIGZhdCBhcyBJIHJlbWVtYmVyKSByZWdhcmRpbmcgUkZDcw0KICAgICAgICAgICAgICBo YXMgYmVlbiB0aGF0IFJGQ3Mgc2hvdWxkIHByb3ZpZGUgd2l0aCBldmVyeXRoaW5nDQogICAgICAg ICAgICAgIGluZm9ybWF0aW9uIGZvciBhIHJlYXNvbmFibGUgZGV2ZWxvcGVyIHRvIGltcGxlbWVu dA0KICAgICAgICAgICAgICBjb3JyZWN0bHkgYW5kIHNlY3VyZWx5IHRoZSBzdGFuZGFyZCB0aGV5 IGRlZmluZSwgYW5kDQogICAgICAgICAgICAgIHByb3ZpZGUgZW5vdWdoIGluZm9ybWF0aW9uIGZv ciB0aGUgcGVyc29uIHdobyB3aWxsIGRlcGxveQ0KICAgICAgICAgICAgICBhIGNvbXBsaWFudCBp bXBsZW1lbnRhdGlvbiB0byBkbyB0aGF0IGNvcnJlY3RseSBhbmQNCiAgICAgICAgICAgICAgc2Vj dXJlbHkuPGJyPg0KICAgICAgICAgICAgICAmZ3Q7IDxicj4NCiAgICAgICAgICAgICAgJmd0OyBP bmUgcHVycG9zZSBvZiBTZWN1cml0eSBSZXZpZXcgaXMgdG8gZW5zdXJlIHRoYXQgYQ0KICAgICAg ICAgICAgICBwZXJzb24gZG9lc24ndCBoYXZlIHRvIGJlIGFuIGV4cGVydCBpbiB0aGUgZmllbGQg dG8gZGVhbA0KICAgICAgICAgICAgICB3aXRoIHRoZSBwcm9wb3NlZCBkb2N1bWVudC48YnI+DQog ICAgICAgICAgICAgICZndDsgPGJyPg0KICAgICAgICAgICAgICAmZ3Q7IEluIGEgZmxpcHBhbnQg d2F5LCBpZiB1c2luZyB5b3VyIHN0dWZmIGlzIHJlcXVpcmVzDQogICAgICAgICAgICAgIHNwZWNp YWwgY2xhc3NlcyAtIHBlcmhhcHMgaXQgYmVsb25ncyB0byBhIGJvb2sgcmF0aGVyIHRoYW4NCiAg ICAgICAgICAgICAgYW4gUkZDLjxicj4NCiAgICAgICAgICAgICAgJmd0OyA8YnI+DQogICAgICAg ICAgICAgICZndDsgSW4gYSBub24tZmxpcHBhbnQgd2F5IC0gd2hhdCdzIHRoZSBwcm9ibGVtIGlu DQogICAgICAgICAgICAgIG1lbnRpb25pbmcgdGhlIGlzc3VlcyBhbmQgcHJvdmlkaW5nIHRoZSBh cHByb3ByaWF0ZQ0KICAgICAgICAgICAgICByZWZlcmVuY2VzPyBBICJub3JtYWwiIFJGQyBjYW5u b3QgYmUgc2VsZi1jb250YWluZWQsIGJ1dA0KICAgICAgICAgICAgICBpdCdzIHVucmVhc29uYWJs ZSB0byBlcGVjdCBhIHJlYWRlciB0byBqdXN0ICJrbm93IiB3aGVyZQ0KICAgICAgICAgICAgICBh bGwgdGhlIG9taXR0ZWQgdGhpbmdzIGFyZSBkZXNjcmliZWQuIDxicj4NCiAgICAgICAgICAgICAg Jmd0OyA8YnI+DQogICAgICAgICAgICAgICZndDsmZ3Q7IE9uIE1hciAxNiwgMjAyMCwgYXQgMDY6 MzMsIFN0ZXdhcnQgQnJ5YW50ICZsdDs8YSBocmVmPSJtYWlsdG86c3Rld2FydC5icnlhbnRAZ21h aWwuY29tIiByZWw9Im5vcmVmZXJyZXINCiAgICAgICAgICAgICAgICBub3JlZmVycmVyIiB0YXJn ZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5zdGV3YXJ0LmJyeWFudEBnbWFpbC5j b208L2E+Jmd0Ow0KICAgICAgICAgICAgICB3cm90ZTo8YnI+DQogICAgICAgICAgICAgICZndDsm Z3Q7IDxicj4NCiAgICAgICAgICAgICAgJmd0OyZndDsg77u/VXJpLDxicj4NCiAgICAgICAgICAg ICAgJmd0OyZndDsgPGJyPg0KICAgICAgICAgICAgICAmZ3Q7Jmd0OyBUaGF0IGlzIGEgcmlkaWN1 bG91cyBwb3NpdGlvbiwgYW5kIHlvdSBmbGlwcGFuY3kNCiAgICAgICAgICAgICAgZGVtb25zdHJh dGVzIHRoYXQuPGJyPg0KICAgICAgICAgICAgICAmZ3Q7Jmd0OyA8YnI+DQogICAgICAgICAgICAg ICZndDsmZ3Q7IFRoaXMgdGVjaG5vbG9neSBmdW5kYW1lbnRhbGx5IHJlc3RzIG9uIE1QTFMgYW5k DQogICAgICAgICAgICAgIGl0IGlzIHJlYXNvbmFibGUgdGhhdCB0aGUgcmVhZGVyIG9mIHRoaXMg UkZDIHdpbGwNCiAgICAgICAgICAgICAgdW5kZXJzdGFuZCBNUExTIGFuZCB0aGUgc2VjdXJpdHkg bW9kZWwgaXQgdXNlcyBiZWZvcmUgdGhleQ0KICAgICAgICAgICAgICBpbXBsZW1lbnQgb3IgZGVw bG95IGl0LiBJbmRlZWQgSSBjYW5ub3QgdGhpbmsgb2YgYW55DQogICAgICAgICAgICAgIGltcGxl bWVudG9yIG9yIG9wZXJhdG9yIHRoYXQgd291bGQgbm90IGFscmVhZHkgaGF2ZSB0aGF0DQogICAg ICAgICAgICAgIGtub3dsZWRnZSBiZWZvcmUgdGFraW5nIG9uIHRoZSB0YXNrIG9mIGJ1aWxkaW5n IG9yIHJ1bm5pbmcNCiAgICAgICAgICAgICAgRE4gb3ZlciBNUExTLjxicj4NCiAgICAgICAgICAg ICAgJmd0OyZndDsgPGJyPg0KICAgICAgICAgICAgICAmZ3Q7Jmd0OyBJZiBTZWNEaXIgcmV2aWV3 cyBhcmUgdG8gcmV0YWluIGFueSBjcmVkaWJpbGl0eQ0KICAgICAgICAgICAgICBhcyBleHBlcnQg cmV2aWV3cyBhcyBvcHBvc2VkIHRvIEdlbmFydCByYW5kb20gcmVhZGVyDQogICAgICAgICAgICAg IHJldmlld3MgdGhleSBoYXZlIHRvIGJlIGNhcnJpZWQgb3V0IHdpdGggc2hhcmVkIGtub3dsZWRn ZQ0KICAgICAgICAgICAgICBvZiBib3RoIHRoZSBzZWN1cml0eSBhcmVhIGFuZCB0aGUgZHJhZnTi gJlzIGhvc3QgYXJlYS48YnI+DQogICAgICAgICAgICAgICZndDsmZ3Q7IDxicj4NCiAgICAgICAg ICAgICAgJmd0OyZndDsgSSBoYXZlIGJlZW4gdGhpbmtpbmcgZm9yIHNvbWUgdGltZSB0aGF0IHRo ZXJlDQogICAgICAgICAgICAgIG5lZWRzIHRvIGJlIGEgZnVuZGFtZW50YWwgcmV2aWV3IG9mIHRo ZSBzZWN1cml0eSByZXZpZXcNCiAgICAgICAgICAgICAgcHJvY2Vzcy48YnI+DQogICAgICAgICAg ICAgICZndDsmZ3Q7IDxicj4NCiAgICAgICAgICAgICAgJmd0OyZndDsgU3Rld2FydDxicj4NCiAg ICAgICAgICAgICAgJmd0OyZndDsgPGJyPg0KICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsgT24g MTUgTWFyIDIwMjAsIGF0IDIyOjQ0LCBVcmkgQmx1bWVudGhhbCAmbHQ7PGEgaHJlZj0ibWFpbHRv OnVyaUBtaXQuZWR1IiByZWw9Im5vcmVmZXJyZXIgbm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsi IG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+dXJpQG1pdC5lZHU8L2E+Jmd0Ow0KICAgICAgICAgICAg ICB3cm90ZTo8YnI+DQogICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyA8YnI+DQogICAgICAgICAg ICAgICZndDsmZ3Q7Jmd0OyBJIHNheSB5ZXMgLSB1bmxlc3MgeW91IGV4cGVjdCBhIHBlcnNvbiB3 aG8NCiAgICAgICAgICAgICAgd2FudHMganVzdCBvbmUgUkZDIHRvIGhhdmUgdG8gcmVhZCBldmVy eSBjcl5oXmggc3R1ZmYgdGhhdA0KICAgICAgICAgICAgICBjYW1lIG91dCBvZiB0aGUgcm91dGlu ZyBhcmVhLjxicj4NCiAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7IDxicj4NCiAgICAgICAgICAg ICAgJmd0OyZndDsmZ3Q7ICJKdXN0IGRvIGl0Ijxicj4NCiAgICAgICAgICAgICAgJmd0OyZndDsm Z3Q7IDxicj4NCiAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7IDxicj4NCiAgICAgICAgICAgICAg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24gTWFyIDE1LCAyMDIwLCBhdCAxNzozOSwgTG91IEJlcmdl cg0KICAgICAgICAgICAgICAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxiZXJnZXJAbGFibi5uZXQiIHJl bD0ibm9yZWZlcnJlcg0KICAgICAgICAgICAgICAgIG5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5r IiBtb3otZG8tbm90LXNlbmQ9InRydWUiPmxiZXJnZXJAbGFibi5uZXQ8L2E+Jmd0Ow0KICAgICAg ICAgICAgICB3cm90ZTo8YnI+DQogICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0K ICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7IO+7vzxicj4NCiAgICAgICAgICAgICAgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgT24gMy8xNS8yMDIwIDU6MjIgUE0sIFdhdHNvbiBMYWRkDQogICAg ICAgICAgICAgIHdyb3RlOjxicj4NCiAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IE9uIFN1biwgTWFyIDE1LCAyMDIwIGF0IDI6MTQgUE0NCiAgICAgICAgICAgICAgTG91IEJl cmdlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxiZXJnZXJAbGFibi5uZXQiIHJlbD0ibm9yZWZlcnJl ciBub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5sYmVy Z2VyQGxhYm4ubmV0PC9hPiZndDsgd3JvdGU6PGJyPg0KICAgICAgICAgICAgICAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgSGkgV2F0c29uLDxicj4NCiAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IDxicj4NCiAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jm5ic3A7ICZuYnNwO0kgdGhpbmsgU3Rld2FydCdzIHJlc3BvbnNlDQogICAgICAgICAgICAgIHJl YWxseSBjb3ZlcnMgdGhlIG1haW4gcG9pbnRzLiBEZXROZXQgaXM8YnI+DQogICAgICAgICAgICAg ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZWFsbHkganVzdCBNUExTIChhbmQgSVApIHdpdGgN CiAgICAgICAgICAgICAgc29tZSBzcGVjaWZpYyBmb3J3YXJkaW5nIGJlaGF2aW9ycyBhbmQ8YnI+ DQogICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBxdWV1aW5nLiZuYnNwOyBU aGUgb25seSB0aGluZyBJJ2QgYWRkLA0KICAgICAgICAgICAgICBpcyBJIHNlZSBEZXROZXQgaW4g Z2VuZXJhbCBhcyBhPGJyPg0KICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg c3BlY2lmaWMgZm9ybSBvZiBwb2xpY3kgYmFzZWQNCiAgICAgICAgICAgICAgcm91dGluZy4gKFRo ZSBnZW5lcmFsIGZvcm0gb2Ygd2hpY2ggaXM8YnI+DQogICAgICAgICAgICAgICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBwcmV0dHkgbXVjaCBhcyBvbGQgYXMgSVApLjxicj4NCiAgICAgICAgICAg ICAgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlbiBTdGV3YXJ0IGNhbiBwdXQgdGhvc2UgcG9pbnRz IGluDQogICAgICAgICAgICAgIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9uczxicj4NCiAgICAg ICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2VjdGlvbi4gV2hhdCdzIHRoZSBkaXNhZHZh bnRhZ2Ugb2YNCiAgICAgICAgICAgICAgZG9pbmcgc28/PGJyPg0KICAgICAgICAgICAgICAmZ3Q7 Jmd0OyZndDsmZ3Q7IDxicj4NCiAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyBBdCBvbmUg bGV2ZWwsIGl0IHdvdWxkIGJlIGVhc2llc3QgZm9yIHRoZQ0KICAgICAgICAgICAgICBhdXRob3Jz IHRvIGp1c3QgcHV0IHRoZXNlIGluLiZuYnNwOyBPbiB0aGUgb3RoZXIgaGFuZCwgdGhpcw0KICAg ICAgICAgICAgICB3b3VsZCBtZWFuIHRoYXQgZXZlcnkgUkZDIHByb2R1Y2VkIGluIHRoZSByb3V0 aW5nIGFyZWENCiAgICAgICAgICAgICAgd2lsbCBhY3F1aXJlIHNpbWlsYXIgbm90ZXMsIGUuZy4s IHJvdXRpbmcgcHJvdG9jb2xzIGFyZQ0KICAgICAgICAgICAgICBjdXJyZW50bHkgYnVpbHQgd2l0 aCBhIGNoYWluIG9mIHRydXN0IG1vZGVsLiZuYnNwOyBJcyB0aGlzIHdoYXQNCiAgICAgICAgICAg ICAgdGhlIHNlYy1kaXIgcmVhbGx5IGlzIGFza2luZyB0aGUgcm91dGluZyBhcmVhIHRvIGRvPzxi cj4NCiAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQogICAgICAgICAgICAgICZn dDsmZ3Q7Jmd0OyZndDsgQURzLDxicj4NCiAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyA8 YnI+DQogICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgYW55IG9waW5pb24gb24g dGhpcz8mbmJzcDsgJm5ic3A7ICZuYnNwOyhmb3IgY29udGV4dCwNCiAgICAgICAgICAgICAgU3Rl d2FydCdzIHJlc3BvbnNlIGNhbiBiZSBmb3VuZCBhdDogPGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJj aGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9kZXRuZXQvLWVwTDVGYjZiRklVbHRNcmpINTNDMjMxNlpB LyIgcmVsPSJub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsi IG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNo L21zZy9kZXRuZXQvLWVwTDVGYjZiRklVbHRNcmpINTNDMjMxNlpBLzwvYT4pPGJyPg0KICAgICAg ICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7 Jmd0OyBUaGFua3MsPGJyPg0KICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiAg ICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyBMb3U8YnI+DQogICAgICAgICAgICAgICZndDsm Z3Q7Jmd0OyZndDsgPGJyPg0KICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg TG91PGJyPg0KICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KICAg ICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24gMy8xMi8yMDIwIDk6MzUgUE0s IFdhdHNvbiBMYWRkDQogICAgICAgICAgICAgIHdyb3RlOjxicj4NCiAgICAgICAgICAgICAgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiBUaHUsIE1hciAxMiwgMjAyMCBhdCA0OjA3DQog ICAgICAgICAgICAgIEFNIExvdSBCZXJnZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpsYmVyZ2VyQGxh Ym4ubmV0IiByZWw9Im5vcmVmZXJyZXIgbm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIG1vei1k by1ub3Qtc2VuZD0idHJ1ZSI+bGJlcmdlckBsYWJuLm5ldDwvYT4mZ3Q7IHdyb3RlOjxicj4NCiAg ICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgV2F0c29uLDxicj4N CiAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KICAg ICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBDYW4geW91IHByb3Zp ZGUgY29udGV4dA0KICAgICAgICAgICAgICBoZXJlPyBDYW4geW91IGJlIGV4cGxpY2l0IG9uIHdo YXQgeW91IHNlZSBuZWVkcyB0bzxicj4NCiAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgYmUgYWRkcmVzc2VkIChiZXlvbmQgd2hhdA0KICAgICAgICAgICAgICBp cyBpbiB0aGlzIGRvY3VtZW50IGFzIHdlbGwgYXMgcmVsYXRlZCByZmNzKT88YnI+DQogICAgICAg ICAgICAgICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgWW91IGhhdmUgdG8gdGFsayBhYm91 dCBob3cNCiAgICAgICAgICAgICAgdGhlIGxheWVycyBpbnRlcmFjdCwgYW5kIGNhbid0IGp1c3Qg c2F5IHRoZTxicj4NCiAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBs b3dlciBsZXZlbCBoYW5kbGVzIGFueXRoaW5nDQogICAgICAgICAgICAgIHdpdGhvdXQgYW55IGd1 aWRlIGFzIHRvIHdoYXQgbmVlZHMgdG8gYmU8YnI+DQogICAgICAgICAgICAgICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgcHJvdmlkZWQgYnkgdGhhdCBsb3dlciBsYXllci48YnI+DQogICAg ICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KICAgICAgICAgICAg ICAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgdGhpbmsgbXkgY29uY2VybnMgYWJvdXQg dGhlDQogICAgICAgICAgICAgIGFzc3VtcHRpb25zIHRoaXMgY291bGQgYmUgZml4ZWQgYnk8YnI+ DQogICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2F5aW5nLiAiQWxs IG5vZGVzIGFyZQ0KICAgICAgICAgICAgICB0cnVzdGVkIGFuZCBhbnkgb2YgdGhlbSBjYW4gbWlz YmVoYXZlIGluIHdheXM8YnI+DQogICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgdGhhdCBhZmZlY3QgdGhlIG5ldHdvcmsuJm5ic3A7IElmDQogICAgICAgICAgICAgIHRo ZSBNUExTIGxheWVyIGNhbm5vdCBwcm92aWRlIHN1ZmZpY2llbnQ8YnI+DQogICAgICAgICAgICAg ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZGV0ZXJtaW5pc20sIHRoZW4gdGhlIERldE5l dA0KICAgICAgICAgICAgICBtZWNoYW5pc21zIHdvbid0IHdvcmsiLiZuYnNwOyBJIGFncmVlIHdl PGJyPg0KICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNob3Vkbid0 IHJlcXVpcmUgYW4gZW50aXJlDQogICAgICAgICAgICAgIG1hc3NpdmUgc2VjdXJpdHkgZnJhbWV3 b3JrIHRvIGJlIHF1b3RlZDxicj4NCiAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBhZ2FpbiBoZXJlLCBidXQgdGhlcmUgbXVzdCBiZQ0KICAgICAgICAgICAgICBzb21l IGRldGFpbHMgb2YgdGhpcyBlbWJlZGRpbmcgdGhhdCBhcmU8YnI+DQogICAgICAgICAgICAgICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgd29ydGggbm90aW5nLCBhbmQgeWV0IEkgZG9uJ3QN CiAgICAgICAgICAgICAgc2VlIHRoZW0gY2FsbGVkIG91dCBpbiB0aGUgc2VjdXJpdHk8YnI+DQog ICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY29uc2lkZXJhdGlvbnMg c2VjdGlvbi48YnI+DQogICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg PGJyPg0KICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEFyZSB0aGVy ZSByZWFsbHkgbm8gc3BlY2lmaWMNCiAgICAgICAgICAgICAgY29uY2VybnMgYWJvdXQgdGhlIGlu dGVyYWN0aW9uIGJldHdlZW48YnI+DQogICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgRGV0TmV0IGFuZCBNUExTPzxicj4NCiAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQogICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IFRoYW5rIHlvdSw8YnI+DQogICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IExvdTxicj4NCiAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyA8YnI+DQogICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IC0tLS0tLS0tLS08YnI+DQogICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IE9uIE1hcmNoIDExLCAyMDIwDQogICAgICAgICAgICAgIDEwOjMwOjI3 IFBNIFdhdHNvbiBMYWRkICZsdDs8YSBocmVmPSJtYWlsdG86d2F0c29uYmxhZGRAZ21haWwuY29t IiByZWw9Im5vcmVmZXJyZXINCiAgICAgICAgICAgICAgICBub3JlZmVycmVyIiB0YXJnZXQ9Il9i bGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj53YXRzb25ibGFkZEBnbWFpbC5jb208L2E+Jmd0 Ow0KICAgICAgICAgICAgICB3cm90ZTo8YnI+DQogICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgZG9uJ3Qgc2VlIGFueQ0KICAgICAgICAgICAgICByZWFzb24g d2h5IFJGQyAzNTUyJ3MgZ3VpZGVsaW5lcyBzaG91ZG4ndCBhcHBseSB0byB0aGlzDQogICAgICAg ICAgICAgIGRyYWZ0Ljxicj4NCiAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IDxicj4NCiAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IElmIHRoZXJlIGlzIGEgTVBMUw0KICAgICAgICAgICAgICBleGNlcHRpb24g SSdkIGxpa2UgdG8gc2VlIHRoZSBydWxlcyB0aGF0IHNob3VsZCBiZQ0KICAgICAgICAgICAgICBh cHBsaWVkLjxicj4NCiAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IDxicj4NCiAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IEFzIGlzIEkgZG9uJ3Qgc2VlIGFueQ0KICAgICAgICAgICAgICByZWFzb24gd2h5IHRo ZSBhc3N1bXB0aW9ucyBjYW4ndCBiZSBleHBsaWNpdGx5PGJyPg0KICAgICAgICAgICAgICAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc3BlbGxlZCBvdXQsIGVpdGhlcg0KICAg ICAgICAgICAgICBpbiB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgb3IgZWxzZXdoZXJlLjxi cj4NCiAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxi cj4NCiAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7DQog ICAgICAgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgZGV0bmV0IG1haWxpbmcgbGlzdDxicj4NCiAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpkZXRuZXRAaWV0Zi5vcmciIHJl bD0ibm9yZWZlcnJlcg0KICAgICAgICAgICAgICAgIG5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5r IiBtb3otZG8tbm90LXNlbmQ9InRydWUiPmRldG5ldEBpZXRmLm9yZzwvYT48YnI+DQogICAgICAg ICAgICAgICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RldG5ldCIgcmVsPSJub3JlZmVycmVy IG5vcmVmZXJyZXIgbm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIG1vei1kby1ub3Qtc2VuZD0i dHJ1ZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kZXRuZXQ8L2E+PGJy Pg0KICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJy Pg0KICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQogICAgICAgICAgICAg ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiAgICAgICAgICAgICAgJmd0OyZndDsmZ3Q7Jmd0 OyA8YnI+DQogICAgICAgICAgICAgICZndDsmZ3Q7Jmd0OyZndDsNCiAgICAgICAgICAgICAgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQogICAgICAg ICAgICAgICZndDsmZ3Q7Jmd0OyZndDsgc2VjZGlyIG1haWxpbmcgbGlzdDxicj4NCiAgICAgICAg ICAgICAgJmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86c2VjZGlyQGlldGYub3JnIiBy ZWw9Im5vcmVmZXJyZXIgbm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIG1vei1kby1ub3Qtc2Vu ZD0idHJ1ZSI+c2VjZGlyQGlldGYub3JnPC9hPjxicj4NCiAgICAgICAgICAgICAgJmd0OyZndDsm Z3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nl Y2RpciIgcmVsPSJub3JlZmVycmVyIG5vcmVmZXJyZXIgbm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxh bmsiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZWNkaXI8L2E+PGJyPg0KICAgICAgICAgICAgICAmZ3Q7Jmd0OyZndDsmZ3Q7IHdp a2k6IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9hcmVhL3NlYy90cmFjL3dpa2kvU2Vj RGlyUmV2aWV3IiByZWw9Im5vcmVmZXJyZXIgbm9yZWZlcnJlciBub3JlZmVycmVyIiB0YXJnZXQ9 Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvYXJl YS9zZWMvdHJhYy93aWtpL1NlY0RpclJldmlldzwvYT48YnI+DQogICAgICAgICAgICAgICZndDsm Z3Q7IDxicj4NCiAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgPC9ibG9ja3F1b3RlPg0K ICAgICAgICAgIDwvZGl2Pg0KICAgICAgICA8L2Rpdj4NCiAgICAgIDwvZGl2Pg0KICAgIDwvYmxv Y2txdW90ZT4NCiAgDQoNCjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48L2JvZHk+PC9odG1sPg== --Apple-Mail-E332C98A-9D45-4540-B7F4-8CFBD022EB9B-- --Apple-Mail-7EF9E05F-3137-4065-9FD1-9DD5C2A23CC4 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCGsw ggQkMIICjKADAgECAgRbkXGgMA0GCSqGSIb3DQEBDAUAMBoxGDAWBgNVBAMMD0ZvcmVzdCBDQSBS U0EgNDAeFw0xODA5MDYxODI3NDRaFw0yMTA5MDYxODI3NDRaMA4xDDAKBgNVBAMMA1VyaTCCAaIw DQYJKoZIhvcNAQEBBQADggGPADCCAYoCggGBANJi8+lfrSCcWThbn0vQzXsW7AYTyTZSo/pv/274 xD/t1rpn/X/vegP2lSfr+SRJ4oJ+51MFJvRl/sAveroDN8gGrFyYaCg5ZsOMqksCmLha4Ttgk04L I/aqrPGuzF1OVgjhi6WrnFr80KS6sy3MWzYIYV6G1FycKEup5snMr1B1WWzFKOwSslnJwvCuHu2W Tc5OzJKPtxMcDIS9y6VOZTzsJUFe0bRiw0LICDBcB3fgKCvYMcDfke0pw13I4O7wEG40s9E6rTIj Q0H1LVk69pSo1ikzpikl5W8pXUQQrSmjHqhFn/Q+PwSzHSOralN0p1UMziUv57lgvvZbTaH1ooqq MZBuTed0xLye3w+h9+/iqDY4B7lFqbegzseBh7/Q6KdtfpkwwI7xSpZEME/V77KAMw+ipb+Itbij Bi3r/t81fDW8eitIAbVtalpFROlYIaZnIIohOZRyVjn2unZ+lj3jDKsDq53g+oleo+Ruszlt8nju 6uKhzE7bdX1xJuvCtwIDAQABo34wfDAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFIDAWBgNV HREEDzANgQt1cmlAbWl0LmVkdTAdBgNVHQ4EFgQU2p+nwSyQFM6byFBhc7oIZephJbcwJQYDVR0l BB4wHAYIKwYBBQUHAwQGCisGAQQBgjcKAwQGBFUdJQAwDQYJKoZIhvcNAQEMBQADggGBAH/zzG9P gU+ogFbc75JpUK0amUUtmtSsGDe4599GolCDiuPHrnbCGcaNc9aQjRaP3Q3aU7BB3aOjwssjQSN0 tsfZD8p+XPny/odhDSwS/25jCg0dVasd8q+Jd1S1g34RGUqPQ+5ofTrBSEkHBdLdJOnxBGo9GRzA yiDg34r6zK6BXNYv2GdqRk+GGGvL/w3CDR+ih36ZDBxw/EO19oH/aV4+mVlcRI6aoj4KMb+h4zMY S8jLDArIZSce4EWzJqxKVcX6Q7CE/0Br/7R8Ixs+vt5YKPUVpEbFM6koH624GDQYKM2kzXBnwYgS /jvl02KUx6uNmIgo+ufK2l7sc83vRLxBTJKhT0/USVkwu9uzg2zHJeGBZ4pmDhkIVkGcamW7KPYZ dgOz8zAOy8Ntk7GebPn85XuPcQS9UntdO61X1EyEXg4Ixl/qapidfJQfdCqEeZZXpaV3WKWE8u1l fNB00mC0/xhG3bikQxl3O20nyPjXvl6VZFzglsPRy1Xh5L//rzCCBD8wggKnoAMCAQICBFuRckIw DQYJKoZIhvcNAQEMBQAwGjEYMBYGA1UEAwwPRm9yZXN0IENBIFJTQSA0MB4XDTE4MDkwNjE4MzAy NloXDTIxMDkwNjE4MzAyNlowDjEMMAoGA1UEAwwDVXJpMIIBojANBgkqhkiG9w0BAQEFAAOCAY8A MIIBigKCAYEAtZvms8stf9xj5w7pjYzgmHe7TH0eX/q3buMBqdLufhFuqCizZPhXJmSbue8WHm8H HO7SHQPUqIqbPOMIQfAL8nwWhuTfsN5nrtFW77eiNsEexRNkbhw/U6RzamCGl6xQmUxOD0nabEmd Xdces+rjtzlvjpNHI7xrR32ee4JuGTjwAWlAHPtBC8TqiOR/ysR2K2umk5BkjCEWV9kDfGklfKmu IhuCzzpTvN3AnLMX9kP9IY6E9B8OsLOhkOFBbAMzyqkXibtPWluqOnYW3V3MVc9H1ir6sGLF5onW lHLEorI51WuHlfVO8WJRYwhrzQIIAWAYheZaH2wdb87Kw6o4JbHDLTDJHHrBDwfqa5OtFTeQNWCD JPdHa4xfFpjnMTzP18POa5C6QN5XBpTFsfccWyEdt+ykGB2FMzhB3GgMVRfWPgo8TgxVwU9MHt8s vmxj8KMUd7afSJBOjMIRPZ6gi8Vja9SR9+Hj/YWgpKZMHhI7irJVpWF++7hhfxxDbgDBAgMBAAGj gZgwgZUwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBsAwFgYDVR0RBA8wDYELdXJpQG1pdC5l ZHUwHQYDVR0OBBYEFK3WLENy4CH330dGZEWchN+L1r28MD4GA1UdJQQ3MDUGCCsGAQUFBwMCBggr BgEFBQcDAwYKKwYBBAGCNwoDDAYJKoZIhvcvAQEFBggrBgEFBQcDBDANBgkqhkiG9w0BAQwFAAOC AYEACYbThcFo+JTQNP5UacMtYogWU/yOx5GBLSNNa5cpvoRrOJc9CUDfzfnrd7IhDLXvnFUYNt3i oyU13LKRoPsp/YYuZ2CBI1om9g27SSqqEcOom0eojIKkPNw+sJzYVl7Dz2I7f9DHN6nEC9BeT8Do rjuq67UOlZZw0YvlvCmtMI4xJ7CUM8NrphoeRN18OnbwmkHWIYnYwdxipTJ8oLWi5EbKaUEYyLlC JWd6o9vH8cFNzsViPUl9POxBtX++o5KxtW7/JQwrQt3uFubF6rHQag6HDeXcXSyI0DmL8MrfVtHi Ma2bN+7z8N9Wnuvx8v0qlqfwd+uhmP7OvD32PuzjQxuGyPd43DZazlMhY9IRpSSCPhdbxzS3YwKr jnTZlKGwPiYCmiQ0XSEW3K64Exe4t+jrkBReocr9ccslB4d4XhxQPdAvUdI43xGMbnFea7pyTDyP b0z1vMrYt6dAguU0QTgRZsPFoIldK70ILvncq9amhxuQ4Uw+u2WUXiYba2R1MYICoTCCAp0CAQEw IjAaMRgwFgYDVQQDDA9Gb3Jlc3QgQ0EgUlNBIDQCBFuRckIwDQYJYIZIAWUDBAIBBQCggdEwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwMzE2MTYxNzA2WjAvBgkq hkiG9w0BCQQxIgQgxijZxkxmZzrSGHB7bkr2Sx5TO1tSzasRPo4v+BJKfoQwMQYJKwYBBAGCNxAE MSQwIjAaMRgwFgYDVQQDDA9Gb3Jlc3QgQ0EgUlNBIDQCBFuRcaAwMwYLKoZIhvcNAQkQAgsxJKAi MBoxGDAWBgNVBAMMD0ZvcmVzdCBDQSBSU0EgNAIEW5FxoDANBgkqhkiG9w0BAQEFAASCAYBh+s3H O1aueE0zcoclH5Xl5JarKN9U173zj0Vleon3erAr+u3HdF/lP7zPm50fd3kU/+RTAUNUY7kC0Pjb 8IuT4VUlnXOhM4NFjVY5NAi7cSNcuf97RF8gfyMGhm1qK7xjK+d5fFlqGUddXINJK1uOqHP+0ZMf B2seIZOwbTARhW8PSBGhl3a0C9hmTPYTU5P++iqBfildMovQtxSURxf3flrjR2eWXEMkLZk4iE1W cuFC8/pfMjC66lUFGemxcz447+S4xHcqBGEV0DB9Z3DLBIh1iHGq8VpKfqk9BmfMvsGG3gSWwYrz y6q7gnFYImxdPTfS6hfjQi2I9nOr5B83giMuo4x+/TnLp/EbsrQFC2sRqZZN9+k1v3rKRNej6Jl0 ml7Q07y82pot+ea2Q0U/MQcopxqGG8M+Kj2qDqt7hs6UigHHstWzfTC3GYeb79L4iZMzPWYwhQog 7R42d9tJZaOY+095KOW+nGoro59BztmQf9nzkRgCRDJjT9fg3cAAAAAAAAA= --Apple-Mail-7EF9E05F-3137-4065-9FD1-9DD5C2A23CC4-- From nobody Mon Mar 16 11:29:43 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0403A0EDC for ; Mon, 16 Mar 2020 11:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.361 X-Spam-Level: X-Spam-Status: No, score=-3.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSlY02mdVvfi for ; Mon, 16 Mar 2020 11:29:35 -0700 (PDT) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (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 1300D3A0EE2 for ; Mon, 16 Mar 2020 11:29:35 -0700 (PDT) Received: from cmgw15.unifiedlayer.com (unknown [10.9.0.15]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id 3B88B1406B2 for ; Mon, 16 Mar 2020 12:29:31 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id DuUVjI9mXrO3uDuUVj2ssA; Mon, 16 Mar 2020 12:29:31 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.3 cv=AOVAo1NW c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=xqWC_Br6kY4A:10:nop_ipv6 a=SS2py6AdgQ4A:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=r77TgQKjGQsHNAKrUKIA:9 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=5d0h99IZWOIExYMWLdkA:9 a=L75AaZRqB37Znoqc:21 a=k-gQSiECyJF_Kim_:21 a=QEXdDO2ut3YA:10:nop_charset_2 a=lUm87qFpoVBu-1w3zBgA:9 a=4jWACSAJAMO98Wg4:21 a=cHhwmzRxVjq3wY-y:21 a=h9ZLzQ1wOnLhBakF:21 a=_W_S_7VecoQA:10:nop_html a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Sender:Reply-To:Content-Transfer-Encoding:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=JnhDnROtCmHZ6+m8s+mdDQr6fnPMcwqNKw0TGV/yrvg=; b=sZ9poxicS4VnM37zeLFgloLqbG kuzTEdV/mVIgr6DetG81HEscdMP07038xdQ/0vijI51fOUz/EOzFJ4W4DuvNPNcC4rYaZogYn2nJA XPj0N8wCwOZVCkXTM307Fp6pj; Received: from [127.0.0.1] (port=46357 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1jDuUU-0012Hi-Oc; Mon, 16 Mar 2020 12:29:30 -0600 To: Uri Blumenthal Cc: secdir , "rtg-ads@ietf.org" , Watson Ladd , "draft-ietf-detnet-mpls.all@ietf.org" , Stewart Bryant , "" , DetNet WG References: <73942657-B55A-431F-AB55-444C3C587AE1@mit.edu> From: Lou Berger Message-ID: Date: Mon, 16 Mar 2020 14:29:29 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <73942657-B55A-431F-AB55-444C3C587AE1@mit.edu> Content-Type: multipart/alternative; boundary="------------70899AA735A7992CB77D19FF" Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 127.0.0.1 X-Source-L: Yes X-Exim-ID: 1jDuUU-0012Hi-Oc X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPv6:::1]) [127.0.0.1]:46357 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 18:29:38 -0000 This is a multi-part message in MIME format. --------------70899AA735A7992CB77D19FF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Uri, On 3/16/2020 12:17 PM, Uri Blumenthal wrote: > Lou, > > Yes, adding that reference would help (IMHO). > This seems reasonable to me (as a contributor) > If indeed, as Stewart says, detnet does not add any security > considerations to those already described in the MPLS documents - the > draft should state so explicitly. Though I personally find it hard to > believe. > > What is an "obvious common sense" for you and Stewart, may not be so > obvious to other readers. > > As a note to others, it is expected that RFC authors do perform a > comprehensive security analysis, and document their findings in the > Security Considerations section. I thought that was obvious. > I think either we agree or that the words "a comprehensive security analysis" is the source of a disconnect.  My view is that the such analysis is a *delta* analysis for previous IETF work/RFCs.  Certainly authors should reference the prior work/RFCs that are needed to understand the analysis, but they need not (even should not) rehash all the material form this existing work -- only what has changed. Does this match your expectation or do you expect something different?  If so, what do you expect? Lou > >> On Mar 16, 2020, at 10:22, Lou Berger wrote: >> >>  >> >> Watson, Uri, >> >> would a reference to >> https://tools.ietf.org/html/draft-ietf-detnet-security-08#section-7 >> help? note that Detnet operates/extends the IP and MPLS layers.  It >> is not a service that rides on general IP or separate from the MPLS >> layers. >> >> Lou >> >> On 3/16/2020 10:18 AM, Watson Ladd wrote: >>> >>> >>> On Mon, Mar 16, 2020, 7:01 AM Stewart Bryant >>> > wrote: >>> >>> The requirement is NOT for a draft to provide the security >>> analysis of all of all of the technologies that it calls up. It >>> is, I believe, to describe the deltas that apply to the new >>> idea. Anything else and the text would be a security analysis >>> with a short technology preamble. >>> >>> We are describing a technology that is overlaid on MPLS. We >>> should not need to describe the security model of MPLS,  but >>> instead confine our remarks to issues that specifically apply to >>> the additional technology we are describing. >>> >>> >>> RFC 3552 requires that in a case such as this you explicitly >>> describe what the lower layer is providing to the top layer. RFC >>> 3552 section 5 also demands that attacks be enumerated and those out >>> of scope be called out. >>> >>> E.g "use TLS" isn't good enough and imho neither is "use MPLS". >>> >>> Again, the sentences in the security considerations as it stands are >>> about MPLS and Detnet, and they don't seem to come together. Are >>> there really no security considerations when putting the two >>> together? Every MPLS network will just work with Detnet on top, no >>> matter how rushed the deploy is? >>> >>> >>> Early in the document we call up RFC3031 and RFC3032, the >>> fundamental MPLS RFCs. They are in section 3.1 the first part of >>> the serious technical discussion. In my view these establish a >>> baseline of understand that the reader is expected to have. >>> >>> It is important to realise, as I have said before, that without >>> understanding that baseline the rest of the document is meaningless. >>> >>> Regards >>> >>> Stewart >>> >>> BTW >>> >>> It might be as well if you refrained from illustrating the lack >>> of professionalism that the security area applies to its reviews >>> by continuing with the flippancy. There is a serious point that >>> needs to be debated here about what assumptions are a given and >>> what assumptions need to be spelled out when modifying or >>> layering a technology. >>> >>> >>> > On 16 Mar 2020, at 12:22, Uri Blumenthal >> > wrote: >>> > >>> > IETF position (add fat as I remember) regarding RFCs has been >>> that RFCs should provide with everything information for a >>> reasonable developer to implement correctly and securely the >>> standard they define, and provide enough information for the >>> person who will deploy a compliant implementation to do that >>> correctly and securely. >>> > >>> > One purpose of Security Review is to ensure that a person >>> doesn't have to be an expert in the field to deal with the >>> proposed document. >>> > >>> > In a flippant way, if using your stuff is requires special >>> classes - perhaps it belongs to a book rather than an RFC. >>> > >>> > In a non-flippant way - what's the problem in mentioning the >>> issues and providing the appropriate references? A "normal" RFC >>> cannot be self-contained, but it's unreasonable to epect a >>> reader to just "know" where all the omitted things are described. >>> > >>> >> On Mar 16, 2020, at 06:33, Stewart Bryant >>> > wrote: >>> >> >>> >> Uri, >>> >> >>> >> That is a ridiculous position, and you flippancy demonstrates >>> that. >>> >> >>> >> This technology fundamentally rests on MPLS and it is >>> reasonable that the reader of this RFC will understand MPLS and >>> the security model it uses before they implement or deploy it. >>> Indeed I cannot think of any implementor or operator that would >>> not already have that knowledge before taking on the task of >>> building or running DN over MPLS. >>> >> >>> >> If SecDir reviews are to retain any credibility as expert >>> reviews as opposed to Genart random reader reviews they have to >>> be carried out with shared knowledge of both the security area >>> and the draft’s host area. >>> >> >>> >> I have been thinking for some time that there needs to be a >>> fundamental review of the security review process. >>> >> >>> >> Stewart >>> >> >>> >>> On 15 Mar 2020, at 22:44, Uri Blumenthal >> > wrote: >>> >>> >>> >>> I say yes - unless you expect a person who wants just one >>> RFC to have to read every cr^h^h stuff that came out of the >>> routing area. >>> >>> >>> >>> "Just do it" >>> >>> >>> >>> >>> >>>>> On Mar 15, 2020, at 17:39, Lou Berger >> > wrote: >>> >>>> >>> >>>>  >>> >>>>> On 3/15/2020 5:22 PM, Watson Ladd wrote: >>> >>>>>> On Sun, Mar 15, 2020 at 2:14 PM Lou Berger >>> > wrote: >>> >>>>>> Hi Watson, >>> >>>>>> >>> >>>>>>   I think Stewart's response really covers the main >>> points. DetNet is >>> >>>>>> really just MPLS (and IP) with some specific forwarding >>> behaviors and >>> >>>>>> queuing.  The only thing I'd add, is I see DetNet in >>> general as a >>> >>>>>> specific form of policy based routing. (The general form >>> of which is >>> >>>>>> pretty much as old as IP). >>> >>>>> Then Stewart can put those points in the security >>> considerations >>> >>>>> section. What's the disadvantage of doing so? >>> >>>> >>> >>>> At one level, it would be easiest for the authors to just >>> put these in.  On the other hand, this would mean that every RFC >>> produced in the routing area will acquire similar notes, e.g., >>> routing protocols are currently built with a chain of trust >>> model.  Is this what the sec-dir really is asking the routing >>> area to do? >>> >>>> >>> >>>> ADs, >>> >>>> >>> >>>>  any opinion on this?     (for context, Stewart's response >>> can be found at: >>> https://mailarchive.ietf.org/arch/msg/detnet/-epL5Fb6bFIUltMrjH53C2316ZA/) >>> >>>> >>> >>>> Thanks, >>> >>>> >>> >>>> Lou >>> >>>> >>> >>>>>> Lou >>> >>>>>> >>> >>>>>> On 3/12/2020 9:35 PM, Watson Ladd wrote: >>> >>>>>>> On Thu, Mar 12, 2020 at 4:07 AM Lou Berger >>> > wrote: >>> >>>>>>>> Watson, >>> >>>>>>>> >>> >>>>>>>> Can you provide context here? Can you be explicit on >>> what you see needs to >>> >>>>>>>> be addressed (beyond what is in this document as well >>> as related rfcs)? >>> >>>>>>> You have to talk about how the layers interact, and >>> can't just say the >>> >>>>>>> lower level handles anything without any guide as to >>> what needs to be >>> >>>>>>> provided by that lower layer. >>> >>>>>>> >>> >>>>>>> I think my concerns about the assumptions this could be >>> fixed by >>> >>>>>>> saying. "All nodes are trusted and any of them can >>> misbehave in ways >>> >>>>>>> that affect the network.  If the MPLS layer cannot >>> provide sufficient >>> >>>>>>> determinism, then the DetNet mechanisms won't work".  I >>> agree we >>> >>>>>>> shoudn't require an entire massive security framework to >>> be quoted >>> >>>>>>> again here, but there must be some details of this >>> embedding that are >>> >>>>>>> worth noting, and yet I don't see them called out in the >>> security >>> >>>>>>> considerations section. >>> >>>>>>> >>> >>>>>>> Are there really no specific concerns about the >>> interaction between >>> >>>>>>> DetNet and MPLS? >>> >>>>>>> >>> >>>>>>>> Thank you, >>> >>>>>>>> Lou >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> ---------- >>> >>>>>>>> On March 11, 2020 10:30:27 PM Watson Ladd >>> > wrote: >>> >>>>>>>> >>> >>>>>>>>> I don't see any reason why RFC 3552's guidelines >>> shoudn't apply to this draft. >>> >>>>>>>>> >>> >>>>>>>>> If there is a MPLS exception I'd like to see the rules >>> that should be applied. >>> >>>>>>>>> >>> >>>>>>>>> As is I don't see any reason why the assumptions can't >>> be explicitly >>> >>>>>>>>> spelled out, either in the Security Considerations or >>> elsewhere. >>> >>>>>>>>> >>> >>>>>>>>> _______________________________________________ >>> >>>>>>>>> detnet mailing list >>> >>>>>>>>> detnet@ietf.org >>> >>>>>>>>> https://www.ietf.org/mailman/listinfo/detnet >>> >>>>>>>>> >>> >>>>> >>> >>>>> >>> >>>> >>> >>>> _______________________________________________ >>> >>>> secdir mailing list >>> >>>> secdir@ietf.org >>> >>>> https://www.ietf.org/mailman/listinfo/secdir >>> >>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >>> >> >>> > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet --------------70899AA735A7992CB77D19FF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Uri,

On 3/16/2020 12:17 PM, Uri Blumenthal wrote:
Lou,

Yes, adding that reference would help (IMHO).

This seems reasonable to me (as a contributor)

If indeed, as Stewart says, detnet does not add any security considerations to those already described in the MPLS documents - the draft should state so explicitly. Though I personally find it hard to believe.

What is an "obvious common sense" for you and Stewart, may not be so obvious to other readers.

As a note to others, it is expected that RFC authors do perform a comprehensive security analysis, and document their findings in the Security Considerations section. I thought that was obvious.

I think either we agree or that the words "a comprehensive security analysis" is the source of a disconnect.  My view is that the such analysis is a *delta* analysis for previous IETF work/RFCs.  Certainly authors should reference the prior work/RFCs that are needed to understand the analysis, but they need not (even should not) rehash all the material form this existing work -- only what has changed.

Does this match your expectation or do you expect something different?  If so, what do you expect?

Lou



On Mar 16, 2020, at 10:22, Lou Berger <lberger@labn.net> wrote:



Watson, Uri,

would a reference to https://tools.ietf.org/html/draft-ietf-detnet-security-08#section-7 help? note that Detnet operates/extends the IP and MPLS layers.  It is not a service that rides on general IP or separate from the MPLS layers.

Lou

On 3/16/2020 10:18 AM, Watson Ladd wrote:


On Mon, Mar 16, 2020, 7:01 AM Stewart Bryant <stewart.bryant@gmail.com> wrote:
The requirement is NOT for a draft to provide the security analysis of all of all of the technologies that it calls up. It is, I believe, to describe the deltas that apply to the new idea. Anything else and the text would be a security analysis with a short technology preamble.

We are describing a technology that is overlaid on MPLS. We should not need to describe the security model of MPLS,  but instead confine our remarks to issues that specifically apply to the additional technology we are describing.

RFC 3552 requires that in a case such as this you explicitly describe what the lower layer is providing to the top layer. RFC 3552 section 5 also demands that attacks be enumerated and those out of scope be called out.

E.g "use TLS" isn't good enough and imho neither is "use MPLS".

Again, the sentences in the security considerations as it stands are about MPLS and Detnet, and they don't seem to come together. Are there really no security considerations when putting the two together? Every MPLS network will just work with Detnet on top, no matter how rushed the deploy is?


Early in the document we call up RFC3031 and RFC3032, the fundamental MPLS RFCs. They are in section 3.1 the first part of the serious technical discussion. In my view these establish a baseline of understand that the reader is expected to have.

It is important to realise, as I have said before, that without understanding that baseline the rest of the document is meaningless.

Regards

Stewart

BTW

It might be as well if you refrained from illustrating the lack of professionalism that the security area applies to its reviews by continuing with the flippancy. There is a serious point that needs to be debated here about what assumptions are a given and what assumptions need to be spelled out when modifying or layering a technology.


> On 16 Mar 2020, at 12:22, Uri Blumenthal <uri@mit.edu> wrote:
>
> IETF position (add fat as I remember) regarding RFCs has been that RFCs should provide with everything information for a reasonable developer to implement correctly and securely the standard they define, and provide enough information for the person who will deploy a compliant implementation to do that correctly and securely.
>
> One purpose of Security Review is to ensure that a person doesn't have to be an expert in the field to deal with the proposed document.
>
> In a flippant way, if using your stuff is requires special classes - perhaps it belongs to a book rather than an RFC.
>
> In a non-flippant way - what's the problem in mentioning the issues and providing the appropriate references? A "normal" RFC cannot be self-contained, but it's unreasonable to epect a reader to just "know" where all the omitted things are described.
>
>> On Mar 16, 2020, at 06:33, Stewart Bryant <stewart.bryant@gmail.com> wrote:
>>
>> Uri,
>>
>> That is a ridiculous position, and you flippancy demonstrates that.
>>
>> This technology fundamentally rests on MPLS and it is reasonable that the reader of this RFC will understand MPLS and the security model it uses before they implement or deploy it. Indeed I cannot think of any implementor or operator that would not already have that knowledge before taking on the task of building or running DN over MPLS.
>>
>> If SecDir reviews are to retain any credibility as expert reviews as opposed to Genart random reader reviews they have to be carried out with shared knowledge of both the security area and the draft’s host area.
>>
>> I have been thinking for some time that there needs to be a fundamental review of the security review process.
>>
>> Stewart
>>
>>> On 15 Mar 2020, at 22:44, Uri Blumenthal <uri@mit.edu> wrote:
>>>
>>> I say yes - unless you expect a person who wants just one RFC to have to read every cr^h^h stuff that came out of the routing area.
>>>
>>> "Just do it"
>>>
>>>
>>>>> On Mar 15, 2020, at 17:39, Lou Berger <lberger@labn.net> wrote:
>>>>
>>>> 
>>>>> On 3/15/2020 5:22 PM, Watson Ladd wrote:
>>>>>> On Sun, Mar 15, 2020 at 2:14 PM Lou Berger <lberger@labn.net> wrote:
>>>>>> Hi Watson,
>>>>>>
>>>>>>   I think Stewart's response really covers the main points. DetNet is
>>>>>> really just MPLS (and IP) with some specific forwarding behaviors and
>>>>>> queuing.  The only thing I'd add, is I see DetNet in general as a
>>>>>> specific form of policy based routing. (The general form of which is
>>>>>> pretty much as old as IP).
>>>>> Then Stewart can put those points in the security considerations
>>>>> section. What's the disadvantage of doing so?
>>>>
>>>> At one level, it would be easiest for the authors to just put these in.  On the other hand, this would mean that every RFC produced in the routing area will acquire similar notes, e.g., routing protocols are currently built with a chain of trust model.  Is this what the sec-dir really is asking the routing area to do?
>>>>
>>>> ADs,
>>>>
>>>>  any opinion on this?     (for context, Stewart's response can be found at: https://mailarchive.ietf.org/arch/msg/detnet/-epL5Fb6bFIUltMrjH53C2316ZA/)
>>>>
>>>> Thanks,
>>>>
>>>> Lou
>>>>
>>>>>> Lou
>>>>>>
>>>>>> On 3/12/2020 9:35 PM, Watson Ladd wrote:
>>>>>>> On Thu, Mar 12, 2020 at 4:07 AM Lou Berger <lberger@labn.net> wrote:
>>>>>>>> Watson,
>>>>>>>>
>>>>>>>> Can you provide context here? Can you be explicit on what you see needs to
>>>>>>>> be addressed (beyond what is in this document as well as related rfcs)?
>>>>>>> You have to talk about how the layers interact, and can't just say the
>>>>>>> lower level handles anything without any guide as to what needs to be
>>>>>>> provided by that lower layer.
>>>>>>>
>>>>>>> I think my concerns about the assumptions this could be fixed by
>>>>>>> saying. "All nodes are trusted and any of them can misbehave in ways
>>>>>>> that affect the network.  If the MPLS layer cannot provide sufficient
>>>>>>> determinism, then the DetNet mechanisms won't work".  I agree we
>>>>>>> shoudn't require an entire massive security framework to be quoted
>>>>>>> again here, but there must be some details of this embedding that are
>>>>>>> worth noting, and yet I don't see them called out in the security
>>>>>>> considerations section.
>>>>>>>
>>>>>>> Are there really no specific concerns about the interaction between
>>>>>>> DetNet and MPLS?
>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> Lou
>>>>>>>>
>>>>>>>>
>>>>>>>> ----------
>>>>>>>> On March 11, 2020 10:30:27 PM Watson Ladd <watsonbladd@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> I don't see any reason why RFC 3552's guidelines shoudn't apply to this draft.
>>>>>>>>>
>>>>>>>>> If there is a MPLS exception I'd like to see the rules that should be applied.
>>>>>>>>>
>>>>>>>>> As is I don't see any reason why the assumptions can't be explicitly
>>>>>>>>> spelled out, either in the Security Considerations or elsewhere.
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> detnet mailing list
>>>>>>>>> detnet@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/detnet
>>>>>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> secdir mailing list
>>>> secdir@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/secdir
>>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>> 


_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet
--------------70899AA735A7992CB77D19FF-- From nobody Mon Mar 16 12:57:12 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335493A0FF3; Mon, 16 Mar 2020 12:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hNVWgrjju64; Mon, 16 Mar 2020 12:57:02 -0700 (PDT) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) (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 91D853A0FCE; Mon, 16 Mar 2020 12:56:56 -0700 (PDT) Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) by outgoing-exchange-1.mit.edu (8.14.7/8.12.4) with ESMTP id 02GJuq2h021042; Mon, 16 Mar 2020 15:56:57 -0400 Received: from w92expo31.exchange.mit.edu (18.7.74.43) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 16 Mar 2020 15:56:20 -0400 Received: from oc11expo31.exchange.mit.edu (18.9.4.104) by w92expo31.exchange.mit.edu (18.7.74.43) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 16 Mar 2020 15:56:30 -0400 Received: from oc11expo31.exchange.mit.edu ([18.9.4.104]) by oc11expo31.exchange.mit.edu ([18.9.4.104]) with mapi id 15.00.1365.000; Mon, 16 Mar 2020 15:56:30 -0400 From: Uri Blumenthal To: Lou Berger CC: secdir , "rtg-ads@ietf.org" , "Watson Ladd" , "draft-ietf-detnet-mpls.all@ietf.org" , Stewart Bryant , "" , "DetNet WG" Thread-Topic: [Detnet] [secdir] Secdir last call review of draft-ietf-detnet-mpls-05 Thread-Index: AQHV+8DZP29H4cjJ90qNnu6vrG/xK6hL5XQA Date: Mon, 16 Mar 2020 19:56:30 +0000 Message-ID: References: <73942657-B55A-431F-AB55-444C3C587AE1@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [24.62.106.45] Content-Type: multipart/signed; boundary="Apple-Mail=_B61E621A-1F4A-4D26-BB2C-BC5838CA9263"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 19:57:06 -0000 --Apple-Mail=_B61E621A-1F4A-4D26-BB2C-BC5838CA9263 Content-Type: multipart/alternative; boundary="Apple-Mail=_40969D7D-C255-4215-8CEE-5CF5372D46A2" --Apple-Mail=_40969D7D-C255-4215-8CEE-5CF5372D46A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 16, 2020, at 14:29 , Lou Berger wrote: >=20 >> If indeed, as Stewart says, detnet does not add any security = considerations to those already described in the MPLS documents - the = draft should state so explicitly. Though I personally find it hard to = believe. >>=20 >> What is an "obvious common sense" for you and Stewart, may not be so = obvious to other readers. >>=20 >> As a note to others, it is expected that RFC authors do perform a = comprehensive security analysis, and document their findings in the = Security Considerations section. I thought that was obvious. > I think either we agree or that the words "a comprehensive security = analysis" is the source of a disconnect. My view is that the such = analysis is a *delta* analysis for previous IETF work/RFCs.=20 >=20 Yes, it should be a *comprehensive* analysis of the possible security = impacts that the *changes* introduce. I.e., in general, when you add some capability, you describe What your security assumptions are - what kind of access you assume your = adversary can or cannot have. How your added capability impacts/changes the existing security posture = (and what you assume that posture is/was) - new attack surface(s), etc.=20= What of the newly-introduced stuff may require protection, and what kind = of protection (should stay secret, no problem if disclosed but a big = deal if modified, etc). How you recommend protecting the above. The reader should learn what new requires protection, ideally - why, and = probably, how. But (IMHO) saying =E2=80=9Cjust use TLS=E2=80=9D is not = nearly good enough - it doesn=E2=80=99t tell me what I=E2=80=99m trying = to protect, and why (what harm could come if left unprotected).=20 > Certainly authors should reference the prior work/RFCs that are needed = to understand the analysis, but they need not (even should not) rehash = all the material form this existing work -- only what has changed. >=20 Correct. BTW, by =E2=80=9Creference=E2=80=9D I mean stating what = concepts from those RFCs apply. > Does this match your expectation or do you expect something different? = If so, what do you expect? >=20 I think it does, with the above caveat ;). We may nit-argue about what =E2=80=9Crehashing existing work=E2=80=9D = means.=20 Referring the reader to go to RFC XXXX for details on specific = concerns/issues/etc is fine. We wouldn=E2=80=99t be able to operate if = every RFC had to be self-contained, and included everything related. But = you should tell the reader why you=E2=80=99re referring him to an = external document, and what in particular he=E2=80=99s supposed to = find/look for there.=20 To just say =E2=80=9Cthis is MPLS-based, so to figure it=E2=80=99s = security risks go read MPLS RFCs=E2=80=9D IMHO is not good enough. = Mainly because I don=E2=80=99t agree that no new exposures are = introduced. If the authors, however, believe this - their analysis (put = in the Security Considerations section) should show why there are no new = exposures. It doesn=E2=80=99t have to be lengthy - but it does have to = make sense.=20 >>> On Mar 16, 2020, at 10:22, Lou Berger = wrote: >>> Watson, Uri, >>>=20 >>> would a reference to = https://tools.ietf.org/html/draft-ietf-detnet-security-08#section-7 = = help? note that Detnet operates/extends the IP and MPLS layers. It is = not a service that rides on general IP or separate from the MPLS layers. >>>=20 >>> Lou >>>=20 >>> On 3/16/2020 10:18 AM, Watson Ladd wrote: >>>>=20 >>>>=20 >>>> On Mon, Mar 16, 2020, 7:01 AM Stewart Bryant = > wrote: >>>> The requirement is NOT for a draft to provide the security analysis = of all of all of the technologies that it calls up. It is, I believe, to = describe the deltas that apply to the new idea. Anything else and the = text would be a security analysis with a short technology preamble. >>>>=20 >>>> We are describing a technology that is overlaid on MPLS. We should = not need to describe the security model of MPLS, but instead confine = our remarks to issues that specifically apply to the additional = technology we are describing. >>>>=20 >>>> RFC 3552 requires that in a case such as this you explicitly = describe what the lower layer is providing to the top layer. RFC 3552 = section 5 also demands that attacks be enumerated and those out of scope = be called out. >>>>=20 >>>> E.g "use TLS" isn't good enough and imho neither is "use MPLS". >>>>=20 >>>> Again, the sentences in the security considerations as it stands = are about MPLS and Detnet, and they don't seem to come together. Are = there really no security considerations when putting the two together? = Every MPLS network will just work with Detnet on top, no matter how = rushed the deploy is? >>>>=20 >>>>=20 >>>> Early in the document we call up RFC3031 and RFC3032, the = fundamental MPLS RFCs. They are in section 3.1 the first part of the = serious technical discussion. In my view these establish a baseline of = understand that the reader is expected to have. >>>>=20 >>>> It is important to realise, as I have said before, that without = understanding that baseline the rest of the document is meaningless. >>>>=20 >>>> Regards >>>>=20 >>>> Stewart >>>>=20 >>>> BTW >>>>=20 >>>> It might be as well if you refrained from illustrating the lack of = professionalism that the security area applies to its reviews by = continuing with the flippancy. There is a serious point that needs to be = debated here about what assumptions are a given and what assumptions = need to be spelled out when modifying or layering a technology. >>>>=20 >>>>=20 >>>> > On 16 Mar 2020, at 12:22, Uri Blumenthal > wrote: >>>> >=20 >>>> > IETF position (add fat as I remember) regarding RFCs has been = that RFCs should provide with everything information for a reasonable = developer to implement correctly and securely the standard they define, = and provide enough information for the person who will deploy a = compliant implementation to do that correctly and securely. >>>> >=20 >>>> > One purpose of Security Review is to ensure that a person doesn't = have to be an expert in the field to deal with the proposed document. >>>> >=20 >>>> > In a flippant way, if using your stuff is requires special = classes - perhaps it belongs to a book rather than an RFC. >>>> >=20 >>>> > In a non-flippant way - what's the problem in mentioning the = issues and providing the appropriate references? A "normal" RFC cannot = be self-contained, but it's unreasonable to epect a reader to just = "know" where all the omitted things are described.=20 >>>> >=20 >>>> >> On Mar 16, 2020, at 06:33, Stewart Bryant = > wrote: >>>> >>=20 >>>> >> =EF=BB=BFUri, >>>> >>=20 >>>> >> That is a ridiculous position, and you flippancy demonstrates = that. >>>> >>=20 >>>> >> This technology fundamentally rests on MPLS and it is reasonable = that the reader of this RFC will understand MPLS and the security model = it uses before they implement or deploy it. Indeed I cannot think of any = implementor or operator that would not already have that knowledge = before taking on the task of building or running DN over MPLS. >>>> >>=20 >>>> >> If SecDir reviews are to retain any credibility as expert = reviews as opposed to Genart random reader reviews they have to be = carried out with shared knowledge of both the security area and the = draft=E2=80=99s host area. >>>> >>=20 >>>> >> I have been thinking for some time that there needs to be a = fundamental review of the security review process. >>>> >>=20 >>>> >> Stewart >>>> >>=20 >>>> >>> On 15 Mar 2020, at 22:44, Uri Blumenthal > wrote: >>>> >>>=20 >>>> >>> I say yes - unless you expect a person who wants just one RFC = to have to read every cr^h^h stuff that came out of the routing area. >>>> >>>=20 >>>> >>> "Just do it" >>>> >>>=20 >>>> >>>=20 >>>> >>>>> On Mar 15, 2020, at 17:39, Lou Berger > wrote: >>>> >>>>=20 >>>> >>>> =EF=BB=BF >>>> >>>>> On 3/15/2020 5:22 PM, Watson Ladd wrote: >>>> >>>>>> On Sun, Mar 15, 2020 at 2:14 PM Lou Berger > wrote: >>>> >>>>>> Hi Watson, >>>> >>>>>>=20 >>>> >>>>>> I think Stewart's response really covers the main points. = DetNet is >>>> >>>>>> really just MPLS (and IP) with some specific forwarding = behaviors and >>>> >>>>>> queuing. The only thing I'd add, is I see DetNet in general = as a >>>> >>>>>> specific form of policy based routing. (The general form of = which is >>>> >>>>>> pretty much as old as IP). >>>> >>>>> Then Stewart can put those points in the security = considerations >>>> >>>>> section. What's the disadvantage of doing so? >>>> >>>>=20 >>>> >>>> At one level, it would be easiest for the authors to just put = these in. On the other hand, this would mean that every RFC produced in = the routing area will acquire similar notes, e.g., routing protocols are = currently built with a chain of trust model. Is this what the sec-dir = really is asking the routing area to do? >>>> >>>>=20 >>>> >>>> ADs, >>>> >>>>=20 >>>> >>>> any opinion on this? (for context, Stewart's response can = be found at: = https://mailarchive.ietf.org/arch/msg/detnet/-epL5Fb6bFIUltMrjH53C2316ZA/ = ) >>>> >>>>=20 >>>> >>>> Thanks, >>>> >>>>=20 >>>> >>>> Lou >>>> >>>>=20 >>>> >>>>>> Lou >>>> >>>>>>=20 >>>> >>>>>> On 3/12/2020 9:35 PM, Watson Ladd wrote: >>>> >>>>>>> On Thu, Mar 12, 2020 at 4:07 AM Lou Berger = > wrote: >>>> >>>>>>>> Watson, >>>> >>>>>>>>=20 >>>> >>>>>>>> Can you provide context here? Can you be explicit on what = you see needs to >>>> >>>>>>>> be addressed (beyond what is in this document as well as = related rfcs)? >>>> >>>>>>> You have to talk about how the layers interact, and can't = just say the >>>> >>>>>>> lower level handles anything without any guide as to what = needs to be >>>> >>>>>>> provided by that lower layer. >>>> >>>>>>>=20 >>>> >>>>>>> I think my concerns about the assumptions this could be = fixed by >>>> >>>>>>> saying. "All nodes are trusted and any of them can = misbehave in ways >>>> >>>>>>> that affect the network. If the MPLS layer cannot provide = sufficient >>>> >>>>>>> determinism, then the DetNet mechanisms won't work". I = agree we >>>> >>>>>>> shoudn't require an entire massive security framework to be = quoted >>>> >>>>>>> again here, but there must be some details of this = embedding that are >>>> >>>>>>> worth noting, and yet I don't see them called out in the = security >>>> >>>>>>> considerations section. >>>> >>>>>>>=20 >>>> >>>>>>> Are there really no specific concerns about the interaction = between >>>> >>>>>>> DetNet and MPLS? >>>> >>>>>>>=20 >>>> >>>>>>>> Thank you, >>>> >>>>>>>> Lou >>>> >>>>>>>>=20 >>>> >>>>>>>>=20 >>>> >>>>>>>> ---------- >>>> >>>>>>>> On March 11, 2020 10:30:27 PM Watson Ladd = > wrote: >>>> >>>>>>>>=20 >>>> >>>>>>>>> I don't see any reason why RFC 3552's guidelines shoudn't = apply to this draft. >>>> >>>>>>>>>=20 >>>> >>>>>>>>> If there is a MPLS exception I'd like to see the rules = that should be applied. >>>> >>>>>>>>>=20 >>>> >>>>>>>>> As is I don't see any reason why the assumptions can't be = explicitly >>>> >>>>>>>>> spelled out, either in the Security Considerations or = elsewhere. >>>> >>>>>>>>>=20 >>>> >>>>>>>>> _______________________________________________ >>>> >>>>>>>>> detnet mailing list >>>> >>>>>>>>> detnet@ietf.org >>>> >>>>>>>>> https://www.ietf.org/mailman/listinfo/detnet = >>>> >>>>>>>>>=20 >>>> >>>>>=20 >>>> >>>>>=20 >>>> >>>>=20 >>>> >>>> _______________________________________________ >>>> >>>> secdir mailing list >>>> >>>> secdir@ietf.org >>>> >>>> https://www.ietf.org/mailman/listinfo/secdir = >>>> >>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview = >>>> >>=20 >>>>=20 >>=20 >>=20 >> _______________________________________________ >> detnet mailing list >> detnet@ietf.org >> https://www.ietf.org/mailman/listinfo/detnet = Uri --Apple-Mail=_40969D7D-C255-4215-8CEE-5CF5372D46A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Mar 16, 2020, at 14:29 , Lou Berger <lberger@labn.net> = wrote:

If indeed, as Stewart says, detnet does not = add any security considerations to those already described in the MPLS = documents - the draft should state so explicitly. Though I personally = find it hard to believe.

What is an "obvious common sense" for you and Stewart, may = not be so obvious to other readers.

As a note to others, it is = expected that RFC authors do perform a comprehensive security analysis, = and document their findings in the Security Considerations section. I = thought that was obvious.

I= think either we agree or that the words "a comprehensive security = analysis" is the source of a disconnect.  My view is that the such = analysis is a *delta* analysis for previous IETF = work/RFCs. 

Yes, it should be a = *comprehensive* analysis of the possible security impacts that the = *changes* introduce.

I.e., in = general, when you add some capability, you describe
  • What your security assumptions are = - what kind of access you assume your adversary can or cannot = have.
  • How your added capability impacts/changes the = existing security posture (and what you assume that posture is/was) - = new attack surface(s), etc. 
  • What of the = newly-introduced stuff may require protection, and what kind of = protection (should stay secret, no problem if disclosed but a big deal = if modified, etc).
  • How you recommend protecting the = above.

The = reader should learn what new requires protection, ideally - why, and = probably, how. But (IMHO) saying =E2=80=9Cjust use TLS=E2=80=9D is not = nearly good enough - it doesn=E2=80=99t tell me what I=E2=80=99m trying = to protect, and why (what harm could come if left = unprotected). 

= Certainly authors should reference the prior work/RFCs that are needed = to understand the analysis, but they need not (even should not) rehash = all the material form this existing work -- only what has = changed.

Correct. BTW, by =E2=80=9Creference=E2=80=9D= I mean stating what concepts from those RFCs apply.

Does this match your expectation or = do you expect something different?  If so, what do you = expect?

I think it does, with the above = caveat ;).

We may nit-argue about = what =E2=80=9Crehashing existing work=E2=80=9D = means. 

Referring the reader to = go to RFC XXXX for details on specific concerns/issues/etc is fine. We = wouldn=E2=80=99t be able to operate if every RFC had to be = self-contained, and included everything related. = But you should tell the reader why you=E2=80=99re referring him to an = external document, and what in particular he=E2=80=99s supposed to = find/look for there. 

To just = say =E2=80=9Cthis is MPLS-based, so to figure it=E2=80=99s security = risks go read MPLS RFCs=E2=80=9D IMHO is not good enough. Mainly because = I don=E2=80=99t agree that  no new exposures are introduced. If the = authors, however, believe this - their analysis (put in the Security = Considerations section) should show why there are = no new exposures. It doesn=E2=80=99t have to be lengthy - but it does = have to make sense. 


On Mar 16, 2020, at 10:22, Lou Berger <lberger@labn.net> wrote:

Watson, Uri,

would = a reference to https://tools.ietf.org/html/draft-ietf-detnet-security-08#secti= on-7 help? note = that Detnet operates/extends the IP and MPLS layers.  It is not a = service that rides on general IP or separate from the MPLS layers.

Lou

On = 3/16/2020 10:18 AM, Watson Ladd wrote:


On Mon, Mar 16, 2020, 7:01 AM Stewart Bryant <stewart.bryant@gmail.com> wrote:
The = requirement is NOT for a draft to provide the security analysis of all = of all of the technologies that it calls up. It is, I believe, to = describe the deltas that apply to the new idea. Anything else and the = text would be a security analysis with a short technology preamble.

We are describing a technology that is = overlaid on MPLS. We should not need to describe the security model of = MPLS,  but instead confine our remarks to issues that specifically = apply to the additional technology we are describing.

RFC 3552 requires that in = a case such as this you explicitly describe what the lower layer is = providing to the top layer. RFC 3552 section 5 also demands that attacks = be enumerated and those out of scope be called out.

E.g "use = TLS" isn't good enough and imho neither is "use MPLS".

Again, the sentences in the security considerations as it = stands are about MPLS and Detnet, and they don't seem to come together. = Are there really no security considerations when putting the two = together? Every MPLS network will just work with Detnet on top, no = matter how rushed the deploy is?


Early in the document we call up RFC3031 and RFC3032, the = fundamental MPLS RFCs. They are in section 3.1 the first part of the = serious technical discussion. In my view these establish a baseline of = understand that the reader is expected to have.

It is important to realise, as I have said before, that = without understanding that baseline the rest of the document is = meaningless.

Regards

Stewart

BTW

It might be as well if you refrained from illustrating the = lack of professionalism that the security area applies to its reviews by = continuing with the flippancy. There is a serious point that needs to be = debated here about what assumptions are a given and what assumptions = need to be spelled out when modifying or layering a technology.


> On 16 Mar 2020, at 12:22, = Uri Blumenthal <uri@mit.edu> wrote:
> 
> IETF position (add fat as I remember) regarding RFCs has = been that RFCs should provide with everything information for a = reasonable developer to implement correctly and securely the standard = they define, and provide enough information for the person who will = deploy a compliant implementation to do that correctly and securely.
> 
> One purpose of Security Review is to ensure that a = person doesn't have to be an expert in the field to deal with the = proposed document.
> 
> In a = flippant way, if using your stuff is requires special classes - perhaps = it belongs to a book rather than an RFC.
> 
> In a = non-flippant way - what's the problem in mentioning the issues and = providing the appropriate references? A "normal" RFC cannot be = self-contained, but it's unreasonable to epect a reader to just "know" = where all the omitted things are described. 
> 
>> On = Mar 16, 2020, at 06:33, Stewart Bryant <stewart.bryant@gmail.com> wrote:
>> 
>> =EF=BB=BFUri,
>> 
>> = That is a ridiculous position, and you flippancy demonstrates that.
>> 
>> This technology fundamentally rests on MPLS and it = is reasonable that the reader of this RFC will understand MPLS and the = security model it uses before they implement or deploy it. Indeed I = cannot think of any implementor or operator that would not already have = that knowledge before taking on the task of building or running DN over = MPLS.
>> 
>> If = SecDir reviews are to retain any credibility as expert reviews as = opposed to Genart random reader reviews they have to be carried out with = shared knowledge of both the security area and the draft=E2=80=99s host = area.
>> 
>> I = have been thinking for some time that there needs to be a fundamental = review of the security review process.
>> 
>> = Stewart
>> 
>>> = On 15 Mar 2020, at 22:44, Uri Blumenthal <uri@mit.edu> = wrote:
>>> 
>>> = I say yes - unless you expect a person who wants just one RFC to have to = read every cr^h^h stuff that came out of the routing area.
>>> 
>>> = "Just do it"
>>> 
>>> 
>>>>> On Mar 15, 2020, at 17:39, Lou Berger = <lberger@labn.net> wrote:
>>>> 
>>>> =EF=BB=BF
>>>>> = On 3/15/2020 5:22 PM, Watson Ladd wrote:
>>>>>> On Sun, Mar 15, 2020 at 2:14 PM Lou = Berger <lberger@labn.net> wrote:
>>>>>> Hi Watson,
>>>>>> 
>>>>>>   I think Stewart's = response really covers the main points. DetNet is
>>>>>> really just MPLS (and IP) with some = specific forwarding behaviors and
>>>>>> = queuing.  The only thing I'd add, is I see DetNet in general as = a
>>>>>> specific form of policy based = routing. (The general form of which is
>>>>>> pretty much as old as IP).
>>>>> Then Stewart can put those points in the = security considerations
>>>>> section. = What's the disadvantage of doing so?
>>>> 
>>>> At one level, it would be easiest for the = authors to just put these in.  On the other hand, this would mean = that every RFC produced in the routing area will acquire similar notes, = e.g., routing protocols are currently built with a chain of trust = model.  Is this what the sec-dir really is asking the routing area = to do?
>>>> 
>>>> ADs,
>>>> 
>>>>  any opinion on this?    =  (for context, Stewart's response can be found at: https://mailarchive.ietf.org/arch/msg/detnet/-epL5Fb6bFIUltMrjH= 53C2316ZA/)
>>>> 
>>>> Thanks,
>>>> 
>>>> Lou
>>>> 
>>>>>> Lou
>>>>>> 
>>>>>> On 3/12/2020 9:35 PM, Watson Ladd = wrote:
>>>>>>> On Thu, Mar 12, 2020 = at 4:07 AM Lou Berger <lberger@labn.net> wrote:
>>>>>>>> Watson,
>>>>>>>> 
>>>>>>>> Can you provide context = here? Can you be explicit on what you see needs to
>>>>>>>> be addressed (beyond what is = in this document as well as related rfcs)?
>>>>>>> You have to talk about how the = layers interact, and can't just say the
>>>>>>> lower level handles anything = without any guide as to what needs to be
>>>>>>> provided by that lower layer.
>>>>>>> 
>>>>>>> I think my concerns about the = assumptions this could be fixed by
>>>>>>> saying. "All nodes are trusted = and any of them can misbehave in ways
>>>>>>> that affect the network.  = If the MPLS layer cannot provide sufficient
>>>>>>> determinism, then the DetNet = mechanisms won't work".  I agree we
>>>>>>> shoudn't require an entire = massive security framework to be quoted
>>>>>>> again here, but there must be = some details of this embedding that are
>>>>>>> worth noting, and yet I don't = see them called out in the security
>>>>>>> considerations section.
>>>>>>> 
>>>>>>> Are there really no specific = concerns about the interaction between
>>>>>>> DetNet and MPLS?
>>>>>>> 
>>>>>>>> Thank you,
>>>>>>>> Lou
>>>>>>>> 
>>>>>>>> 
>>>>>>>> ----------
>>>>>>>> On March 11, 2020 10:30:27 = PM Watson Ladd <watsonbladd@gmail.com> wrote:
>>>>>>>> 
>>>>>>>>> I don't see any reason = why RFC 3552's guidelines shoudn't apply to this draft.
>>>>>>>>> 
>>>>>>>>> If there is a MPLS = exception I'd like to see the rules that should be applied.
>>>>>>>>> 
>>>>>>>>> As is I don't see any = reason why the assumptions can't be explicitly
>>>>>>>>> spelled out, either in = the Security Considerations or elsewhere.
>>>>>>>>> 
>>>>>>>>> = _______________________________________________
>>>>>>>>> detnet mailing list
>>>>>>>>> detnet@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/detnet
>>>>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> = _______________________________________________
>>>> secdir mailing list
>>>> secdir@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/secdir
>>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>> 

= 

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

Uri

= --Apple-Mail=_40969D7D-C255-4215-8CEE-5CF5372D46A2-- --Apple-Mail=_B61E621A-1F4A-4D26-BB2C-BC5838CA9263 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCA70w ggO5MIIDIqADAgECAhBdZAK63nchU5yFJ3D5ChXkMA0GCSqGSIb3DQEBCwUAMGwxCzAJBgNVBAYT AlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMS4wLAYDVQQKEyVNYXNzYWNodXNldHRzIEluc3Rp dHV0ZSBvZiBUZWNobm9sb2d5MRUwEwYDVQQLEwxDbGllbnQgQ0EgdjEwHhcNMTkwNzMxMDMxMDA3 WhcNMjAwNzMxMDMxMDA3WjCBoTELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMx LjAsBgNVBAoTJU1hc3NhY2h1c2V0dHMgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsT DENsaWVudCBDQSB2MTEXMBUGA1UEAxMOVXJpIEJsdW1lbnRoYWwxGjAYBgkqhkiG9w0BCQEWC3Vy aUBNSVQuRURVMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAn7po/olfBbdflh0fEdQ+ t+I8E1LXvU6codZBlKbB9ITxFCHgFRAoGs5acPBhA9x0nULDag4v/XPgVCqFYbQiH12NTsqC/y6j uRlJEKD3tsgelrG69Rhi/uTX8kX+UWlR3ESgsRrBTlBhdFri3irgFzo8H7jOGfB7i3M6lM+qBDcf hdlFNvYP5gy7yCPWbSqT+vG2Runqs/ZPZbzEjdO0ZIAGY9mXAxJhGRQYGoHv6l7I6YkKJFjaXa+c iGNNEVdRjMglBlzutlKdxwvNjddktt1xFfNK+5RekutIaKM5aiAk0g8p9VwyF30a8E3vaVqiAlCK p8ow80Tf6pCsWzd+3wIDAQABo4GhMIGeMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMB0G A1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjALBgNVHQ8EBAMCBeAwHQYDVR0OBBYEFKfGEmEN xBmzwFf7/C/woTfy2QTnMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jYS5taXQuZWR1L2NhL21p dGNsaWVudC5jcmwwDQYJKoZIhvcNAQELBQADgYEASLiK0bsEYVsX61pV4QHdrtmoxlXRHxGFt2AR OFWBrhYUMvpUgrQXzafRzldyS22lXQP4Zr+nw2drFdUL1K4H+VuNtYsUgZ/jtGl5qd1re8cmgq0o LAy3wLIIoA4g8l9M8GkfbWCKtYPLaa2rqmD2AU6vp7zRgHxbiRee5k1jbEIxggNDMIIDPwIBATCB gDBsMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEuMCwGA1UEChMlTWFzc2Fj aHVzZXR0cyBJbnN0aXR1dGUgb2YgVGVjaG5vbG9neTEVMBMGA1UECxMMQ2xpZW50IENBIHYxAhBd ZAK63nchU5yFJ3D5ChXkMA0GCWCGSAFlAwQCAQUAoIIBkzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAzMTYxOTU2MTZaMC8GCSqGSIb3DQEJBDEiBCCEUHA3MY9c JOHdYTnRqlQqnnalUpqnjk6bp/QFMy3jzzCBkQYJKwYBBAGCNxAEMYGDMIGAMGwxCzAJBgNVBAYT AlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMS4wLAYDVQQKEyVNYXNzYWNodXNldHRzIEluc3Rp dHV0ZSBvZiBUZWNobm9sb2d5MRUwEwYDVQQLEwxDbGllbnQgQ0EgdjECEF1kArredyFTnIUncPkK FeQwgZMGCyqGSIb3DQEJEAILMYGDoIGAMGwxCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNo dXNldHRzMS4wLAYDVQQKEyVNYXNzYWNodXNldHRzIEluc3RpdHV0ZSBvZiBUZWNobm9sb2d5MRUw EwYDVQQLEwxDbGllbnQgQ0EgdjECEF1kArredyFTnIUncPkKFeQwDQYJKoZIhvcNAQEBBQAEggEA NLVnYHpwWV3oTEVw62LtTv4r0JF8zjRnQ11iDCusmt3nl+y7Kn2Vax+XFfC/OdLR+tYXfg6cPAME FRRqH5+wAzGv0TbOc6Hmp7LmGdjw8eKbYrouGOcpHi2WxVCnSEZfpkVdHr7mewMvxCwbPy9pXLdc GNaowrGGWS4B70s3JfkH2IiRJAFrRMZIpvqfGLG09yP/uiFzkc6WHjQs+W316EfbL4EPYNVgwia/ j8mo5QOVs5Ko2pyJEzlcowCUaLuhRQKSF+7tsY+JThfIDzF4VX2D5RvaUsuRQdm6o5fvC2ACtxCg ULUcuLIpbn1ioFB4DYSMMW4mKMxBjSbsiSgnWgAAAAAAAA== --Apple-Mail=_B61E621A-1F4A-4D26-BB2C-BC5838CA9263-- From nobody Tue Mar 17 04:09:34 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B300C3A1D0D; Tue, 17 Mar 2020 04:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sW8jxHQ4eqCl; Tue, 17 Mar 2020 04:09:05 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [IPv6:2a00:1c30:1c1::55]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 532493A1D0E; Tue, 17 Mar 2020 04:09:04 -0700 (PDT) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 7FE861B00140; Tue, 17 Mar 2020 13:09:00 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1584443340; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=o/CPzkz34so07qwqgwtvOzmJplcBd3VeafOVT/DDWOo=; b=rLmrDe8vsWC7KTSHV1QIO1wUjxXmiSIdeCztsCP0Bbr/Y2AbP4Ir7gEoDgB5W6WtbtG/56 5d9/DdgrdK8TGNaL8wwfV7RkehwRd73lvApe/QIwVXXSwix8YmgZxzSJYjOL1WDnM1Ivjb 7123FR1rhbnGrh76lqhZ4FZKYge8+hctFUxpex/y617cg+E7gq6LxTIrkzY1DREYZamYlm BO2lJze05Qb9YQjRr5Sddm7d+WmEfBcyKvsSwZGQXu+hV6587euJNkJKrVeToZYQuVs1La C3U2Ej9omG2Cif8J8p4Zl/4WDPXXhawniHcBOzKe+D86eKS7LBKDz8g2mIlZhg== Received: by fireball.acr.fi (Postfix, from userid 15204) id 8035625C1114; Tue, 17 Mar 2020 13:08:59 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <24176.45003.478503.30942@fireball.acr.fi> Date: Tue, 17 Mar 2020 13:08:59 +0200 From: Tero Kivinen To: Lou Berger Cc: secdir@ietf.org, draft-ietf-detnet-ip.all@ietf.org, detnet@ietf.org, last-call@ietf.org In-Reply-To: <57456b4d-79a4-191a-8e25-7a2d2157f5d8@labn.net> References: <158406212471.18347.14473548719649982992@ietfa.amsl.com> <57456b4d-79a4-191a-8e25-7a2d2157f5d8@labn.net> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 24 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1584443340; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=o/CPzkz34so07qwqgwtvOzmJplcBd3VeafOVT/DDWOo=; b=f5/qY8iXpKm1iPANBx5U+cjVsjYap2Cm4a46zjdH8pSzeqTGPu71CGq8yAvYV4y5hkH+9n 6G2DY3obyE3jNbYfwmNnbA4MCoriiDQYAhj38rG1KHzKRgNUprQOolYeyF6N7MGPqe7pdC OPxulWh1gEIjr78coccEt4GToe7kuFIKZFawwLZL8RPfb9Zm5e6Wy6HYubjkY5ssvjVFjU 8u3TR3GR40j0HocAOUTC/02rZPFcuBt0GtY9L+2+6ZnHtljbozFTliOGuHLlnzx4ZgJEOn JrK2geG0u2pMxnJ8LO29Kxel1uPVtbvlBKljVX5lV2mMBWf2PaA7z5Wzk5V07w== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1584443340; a=rsa-sha256; cv=none; b=o1YaBom+rkmWKRh/hBelseF+DrxnT1/E4mDp75nu210v9J+Cx6maeOcz4FrUJ4AdCLMACC zcFkESx5tWgTJYXdtnYu6pmo4SWAb8A34/yU4L5IvepE4Of+JBuWmpfjK/SOh3/PoskPbO wIPwRLsyaIxXJX9HefyuUIOp89sfmR9z7DUJh1hBP/Cr0HDXcWxLDm87qLhC/lV7eqWlAs 3EWzwzp5n+AtPI8kx2SYeVpVdwG1Cy9n0gPjE55JuqN/OtHGDz5tzr2OcpZMpeSbkE0b7b w4bKYrGG4KKn61NrSVLp1D/YPMY/Y9JeTnF12/vJuspgkinZikhPJYpUwxzanA== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-ip-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2020 11:09:24 -0000 Lou Berger writes: > > In section 5.1.2.2 it says that SPI field of the ESP and AH is > > used, but in case the IPsec is configured to use UDP encapsulation > > (rfc3948, i.e., UDP destination port is 4500) there is different > > location for the SPI. Should this document also dig SPI out from > > the UDP encapsulated ESP/AH=3F >=20 > no.=A0 I'll add qualifications that this applies when the "IPv4 Proto= col=20 > and IPv6 Next Header Fields" are set to AH and ESP. specifically: >=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 The rules defined in this secti= on only apply when the > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 IPv4 Protocol or IPv6 Next H= eader Field contains the IANA > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 defined value for AH or ESP.= >=20 >=20 > > There is also > > wrapped ESP (rfc5840) with bit different format, i.e., having wrapp= ed ESP > > header before the normal ESP header. Should this be included also=3F= >=20 > This was not discussed in the working group -- so a really great poin= t=20 > to raise in this review.=A0 Thank you! >=20 > As it has it's own protocol number, it would be not too hard to add.=A0= =20 > That said, there's no reason it couldn't be added later and no one in= =20 > the working group raised it.=A0 What do you think, is it important to= add=20 > it now. If you are not concerned UDP encapsulated IPsec, then I think you can ignore the Wrapped ESP too. I have not seen wrapped ESP in any real use, compared to the UDP encapsulated IPsec, which is very commonly used. Wrapped ESP was meanly meant for enterprice use cases where they want authentication only, but no encryption, as they do want to look inside the packets. UDP encapsulated IPsec is used when there is NATs in play, i.e., most of the IPsec traffic from roadwarriors, i.e. laptops in hotels etc. --=20 kivinen@iki.fi From nobody Tue Mar 17 05:32:09 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F483A1E1C for ; Tue, 17 Mar 2020 05:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.362 X-Spam-Level: X-Spam-Status: No, score=-3.362 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UEGS1995b_J for ; Tue, 17 Mar 2020 05:31:51 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) (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 756873A1E1E for ; Tue, 17 Mar 2020 05:31:50 -0700 (PDT) Received: from cmgw15.unifiedlayer.com (unknown [10.9.0.15]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id 503B91E0894 for ; Tue, 17 Mar 2020 06:31:45 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id EBNpjQFDorO3uEBNpjArN9; Tue, 17 Mar 2020 06:31:45 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.3 cv=O+YXQi1W c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10:nop_charset_1 a=SS2py6AdgQ4A:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=DTyjI2X_OpCmv7G-di0A:9 a=QEXdDO2ut3YA:10:nop_charset_2 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=IVV7oHsZue2yDbp/7uz4KoY88qVAwCgcSStXw/NNe/E=; b=VUK34qvu5TZQauvJQeNUHoifuQ bTiYT/cDfpVvffUPDduJCeEjvqjgXFrxpJJ062WkxgYxBN9DrBria51BXEQhiFHU18sYGlCpflVVe o99zMTvH11FBtjfks31nINokF; Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:55932 helo=fs2.dc.labn.net) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1jEBNo-003mra-U9; Tue, 17 Mar 2020 06:31:44 -0600 To: Tero Kivinen Cc: draft-ietf-detnet-ip.all@ietf.org, detnet@ietf.org, last-call@ietf.org, secdir@ietf.org References: <158406212471.18347.14473548719649982992@ietfa.amsl.com> <57456b4d-79a4-191a-8e25-7a2d2157f5d8@labn.net> <24176.45003.478503.30942@fireball.acr.fi> From: Lou Berger Openpgp: preference=signencrypt Autocrypt: addr=lberger@labn.net; prefer-encrypt=mutual; keydata= mQENBERW5dYBCAC1Bjgr/mVovBhi1rbqkowJShVtvLitNEGOTd6RtmwO7FPebg61J9+kRFTz 1wt869yiAjtQO1EtQs26QFTH5ZDZJU/LDAOzxTi12mpBic+AWI8W0yrB1C+KOZ0gw2p7Vnfj EKc3ohwkCICHTnZ3blO8Mslb4qHGxDm7Uy3luRjvH1ZDifuZvfFHcHVw2dJyGwLg2MhXCqpo OyUqFN0tlGqz1TOCAy3/IMG6OdNK27DGF5+vJyIqek/2xkIVDOLgzVCek3dARLqPP37W1Lx2 uXJUsgcJ7t7om5AEV2LTFrafvAvJbKLT9RZ0fgF4LXeRTIVlFXKkvYJFgygW+r4JCTvHABEB AAG0HUxvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+iQGHBBABAgBxBQJEVuXyMBSAAAAA ACAAB3ByZWZlcnJlZC1lbWFpbC1lbmNvZGluZ0BwZ3AuY29tcGdwbWltZQcLCQgHAwIKAhkB GRhsZGFwOi8va2V5c2VydmVyLnBncC5jb20FGwMAAAADFgIBBR4BAAAABBUICQoACgkQgbLN W8HBX9eB9QgAl8/lFnNh43at51P//sRX8cDg33C/biok8st8Fff0Y/6p+6HkYKQcxiuZuOLr HHtBFxTdMGfFrlJIFob/N6m92CwVwoTRZu8QIe68DLewd+72PIEzvlSy/iTq3e91XqfGWCE7 oqw7H/weJJlB7yzPWXra/BwgPD+WkTxUiKeG2F2HzBTQfBQ6VpHiMqW6AL0jcCh/Drya93ZA aAdWfW2ywVPqIKETZIk04SBsZCw9WESB2If/NqeZu/DNwBg4FsXCrfp3WfMSTkYmfT3zcU11 MpKcv20YUpG8Jf9lyMY1DgMHHdpUHdjo/fuLz4aVSQvt8EygRSzCxGWOWb89bUosAbkBDQRE VuXXAQgApBEy7m0+xMm4SEcQtFi/UQQqjVOllc2227M1ypbcEMRa46Tq6p0P5QBM9C9pxjAl tyI2m3hzvBxBJNnjknXTp875DGyj/yDwj9VeA18Tj9q6PRsJIxAnGKBgWO0yGdZLpsp0AN5n kMamxdVFGYojzUiwkPBayST6sEUp33o4xHsx99TA2bFxZRj6k0igWgdrPVq4qeEgD1l7Cl3f pj96owzm+7wecswAts2b545gfR4/V/Vx3VUebETR/LwMDecXokP5fiDAIRHhEUi/+FXcwg6w 6jtPilFcJ64HJP6P81OUdfeMDUxvSmbeRqXaZrbRN+hF6XfWODTKepsqPaX8TQARAQABiQEi BBgBAgAMBQJEVuXXBRsMAAAAAAoJEIGyzVvBwV/XUcMH/2eB6dvsP52su9KgaDHqsgPbxF21 AQL9oDCheN+AJKD3Eouj/d/MbQdsp/M/pjgTAqB3G4/rtoyJw+BDjnvZwdUe4HQ656IPZOub e10sOgq1taJQZtQIl+mWKURMGlIihScYeuGfi/1RzMqXeCcFW63n5POVG55FzU8B7DBwQ2oJ Zy7NL0YVbT0ROXGson6WHLhzGnVP8CjHq5TN5co/FH/2BntaQIdSaOmTqN+vy38KkRsYa3cx k9eTbP99ypebZclmw6kxlOZGl9DBp4qNkTn/7LgQ7iZNVyESs9rSE7hQXnmfM+C+TCpeZo62 8AwC5SYEqa5YlkpgsP0NIEMAIoU= Message-ID: Date: Tue, 17 Mar 2020 08:31:43 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <24176.45003.478503.30942@fireball.acr.fi> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 72.66.11.201 X-Source-L: No X-Exim-ID: 1jEBNo-003mra-U9 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net (fs2.dc.labn.net) [72.66.11.201]:55932 X-Source-Auth: lberger@labn.net X-Email-Count: 9 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-ip-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2020 12:32:08 -0000 Thanks again Tero. I've made the changes in a PR to the document git repo and they will be in the post LC update version. Lou On 3/17/20 7:08 AM, Tero Kivinen wrote: > Lou Berger writes: >>> In section 5.1.2.2 it says that SPI field of the ESP and AH is >>> used, but in case the IPsec is configured to use UDP encapsulation >>> (rfc3948, i.e., UDP destination port is 4500) there is different >>> location for the SPI. Should this document also dig SPI out from >>> the UDP encapsulated ESP/AH? >> >> no.  I'll add qualifications that this applies when the "IPv4 Protocol >> and IPv6 Next Header Fields" are set to AH and ESP. specifically: >> >>              The rules defined in this section only apply when the >>               IPv4 Protocol or IPv6 Next Header Field contains the IANA >>               defined value for AH or ESP. >> >> >>> There is also >>> wrapped ESP (rfc5840) with bit different format, i.e., having wrapped ESP >>> header before the normal ESP header. Should this be included also? >> >> This was not discussed in the working group -- so a really great point >> to raise in this review.  Thank you! >> >> As it has it's own protocol number, it would be not too hard to add.  >> That said, there's no reason it couldn't be added later and no one in >> the working group raised it.  What do you think, is it important to add >> it now. > > If you are not concerned UDP encapsulated IPsec, then I think you can > ignore the Wrapped ESP too. I have not seen wrapped ESP in any real > use, compared to the UDP encapsulated IPsec, which is very commonly > used. > > Wrapped ESP was meanly meant for enterprice use cases where they want > authentication only, but no encryption, as they do want to look inside > the packets. > > UDP encapsulated IPsec is used when there is NATs in play, i.e., most > of the IPsec traffic from roadwarriors, i.e. laptops in hotels etc. > From nobody Tue Mar 17 05:40:20 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029E63A1E46 for ; Tue, 17 Mar 2020 05:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.361 X-Spam-Level: X-Spam-Status: No, score=-3.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wk5a3QgZZaz9 for ; Tue, 17 Mar 2020 05:39:59 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) (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 88A133A1E42 for ; Tue, 17 Mar 2020 05:39:59 -0700 (PDT) Received: from cmgw12.unifiedlayer.com (unknown [10.9.0.12]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id 3EAFE1E09C6 for ; Tue, 17 Mar 2020 06:39:59 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id EBVnjTguhN8ArEBVnjZAyi; Tue, 17 Mar 2020 06:39:59 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.3 cv=Ye2TGTZf c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=xqWC_Br6kY4A:10:nop_ipv6 a=SS2py6AdgQ4A:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=r77TgQKjGQsHNAKrUKIA:9 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=7ji3lbUPzGw7hHbqHAMA:9 a=tGLlV30DdcmNEdlS:21 a=I92aSuSJl1YgzEi_:21 a=QEXdDO2ut3YA:10:nop_charset_2 a=divCYUUttnDrMqcDkuEA:9 a=GzI9915wpOS0RxUy:21 a=2UqIaCplluZ15t8b:21 a=NxWw3CgrLwRhhbKO:21 a=_W_S_7VecoQA:10:nop_html a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Sender:Reply-To:Content-Transfer-Encoding:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=Hw/U8R5F50QfBrMGuYIdzaKPCEsfKvpl5xREm7byi+g=; b=0/PiDhZkkQcB+sLwne3vzHrkZ8 0dY9nRon2bvyAwx7r/7cQq/1RKVD5FSdHwcw13uoKG2KxYersG8lSDkT8aTn/GYzcitCZzpi79hqN R/VCnioNEuSj0QuqtY1rDiINe; Received: from [127.0.0.1] (port=56469 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1jEBVm-003psZ-RF; Tue, 17 Mar 2020 06:39:59 -0600 To: Uri Blumenthal Cc: secdir , "rtg-ads@ietf.org" , Watson Ladd , "draft-ietf-detnet-mpls.all@ietf.org" , Stewart Bryant , "" , DetNet WG References: <73942657-B55A-431F-AB55-444C3C587AE1@mit.edu> From: Lou Berger Message-ID: Date: Tue, 17 Mar 2020 08:39:49 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B717831FBE174360A43715A0" Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 127.0.0.1 X-Source-L: Yes X-Exim-ID: 1jEBVm-003psZ-RF X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPv6:::1]) [127.0.0.1]:56469 X-Source-Auth: lberger@labn.net X-Email-Count: 11 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2020 12:40:19 -0000 This is a multi-part message in MIME format. --------------B717831FBE174360A43715A0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, On 3/16/2020 3:56 PM, Uri Blumenthal wrote: > On Mar 16, 2020, at 14:29 , Lou Berger > wrote: >> >>> If indeed, as Stewart says, detnet does not add any security >>> considerations to those already described in the MPLS documents - >>> the draft should state so explicitly. Though I personally find it >>> hard to believe. >>> >>> What is an "obvious common sense" for you and Stewart, may not be so >>> obvious to other readers. >>> >>> As a note to others, it is expected that RFC authors do perform a >>> comprehensive security analysis, and document their findings in the >>> Security Considerations section. I thought that was obvious. >> >> I think either we agree or that the words "a comprehensive security >> analysis" is the source of a disconnect.  My view is that the such >> analysis is a *delta* analysis for previous IETF work/RFCs. >> > Yes, it should be a *comprehensive* analysis of the possible security > impacts that the *changes* introduce. > > I.e., in general, when you add some capability, you describe > > * What your security assumptions are - what kind of access you > assume your adversary can or cannot have. > * How your added capability impacts/changes the existing security > posture (and what you assume that posture is/was) - new attack > surface(s), etc. > * What of the newly-introduced stuff may require protection, and > what kind of protection (should stay secret, no problem if > disclosed but a big deal if modified, etc). > * How you recommend protecting the above. > > > The reader should learn what new requires protection, ideally - why, > and probably, how. But (IMHO) saying “just use TLS” is not nearly good > enough - it doesn’t tell me what I’m trying to protect, and why (what > harm could come if left unprotected). explaining why a security mechanism is needed seems reasonable to me. > >> Certainly authors should reference the prior work/RFCs that are >> needed to understand the analysis, but they need not (even should >> not) rehash all the material form this existing work -- only what has >> changed. >> > Correct. BTW, by “reference” I mean stating what concepts from those > RFCs apply. > so you want to repeat all the concepts from prior work/rfcs? This makes little sense to me as it means the likely introduction of differences and errors from the original work.  Pointers to the relevant work/sections seem right to me as the implementations are going to have to support the prior work in any case. >> Does this match your expectation or do you expect something >> different?  If so, what do you expect? >> > I think it does, with the above caveat ;). > > We may nit-argue about what “rehashing existing work” means. > > Referring the reader to go to RFC XXXX for details on specific > concerns/issues/etc is fine. We wouldn’t be able to operate if every > RFC had to be self-contained, and included _everything_ related. very happy we agree on this key point. > But you should tell the reader why you’re referring him to an external > document, and what in particular he’s supposed to find/look for there. Sure, but it sounds like we may differ on detail level needed in the reference. > > To just say “this is MPLS-based, so to figure it’s security risks go > read MPLS RFCs” IMHO is not good enough. Mainly because I don’t agree > that  no new exposures are introduced. I don't think this is a valid solution to your concern. > If the authors, however, believe this - their analysis (put in the > Security Considerations section) should show _why_ there are no new > exposures. It doesn’t have to be lengthy - but it does have to make > sense. This is a good solution -- in other words, I do think it's fair to add something on this to the section.  I suspect it will be at most two sentences. Lou > > >>>> On Mar 16, 2020, at 10:22, Lou Bergerwrote: >>>> >>>> Watson, Uri, >>>> >>>> would a reference >>>> tohttps://tools.ietf.org/html/draft-ietf-detnet-security-08#section-7help? >>>> note that Detnet operates/extends the IP and MPLS layers.  It is >>>> not a service that rides on general IP or separate from the MPLS >>>> layers. >>>> >>>> Lou >>>> >>>> On 3/16/2020 10:18 AM, Watson Ladd wrote: >>>>> >>>>> >>>>> On Mon, Mar 16, 2020, 7:01 AM Stewart Bryant >>>>> > wrote: >>>>> >>>>> The requirement is NOT for a draft to provide the security >>>>> analysis of all of all of the technologies that it calls up. >>>>> It is, I believe, to describe the deltas that apply to the new >>>>> idea. Anything else and the text would be a security analysis >>>>> with a short technology preamble. >>>>> >>>>> We are describing a technology that is overlaid on MPLS. We >>>>> should not need to describe the security model of MPLS,  but >>>>> instead confine our remarks to issues that specifically apply >>>>> to the additional technology we are describing. >>>>> >>>>> >>>>> RFC 3552 requires that in a case such as this you explicitly >>>>> describe what the lower layer is providing to the top layer. RFC >>>>> 3552 section 5 also demands that attacks be enumerated and those >>>>> out of scope be called out. >>>>> >>>>> E.g "use TLS" isn't good enough and imho neither is "use MPLS". >>>>> >>>>> Again, the sentences in the security considerations as it stands >>>>> are about MPLS and Detnet, and they don't seem to come together. >>>>> Are there really no security considerations when putting the two >>>>> together? Every MPLS network will just work with Detnet on top, no >>>>> matter how rushed the deploy is? >>>>> >>>>> >>>>> Early in the document we call up RFC3031 and RFC3032, the >>>>> fundamental MPLS RFCs. They are in section 3.1 the first part >>>>> of the serious technical discussion. In my view these >>>>> establish a baseline of understand that the reader is expected >>>>> to have. >>>>> >>>>> It is important to realise, as I have said before, that >>>>> without understanding that baseline the rest of the document >>>>> is meaningless. >>>>> >>>>> Regards >>>>> >>>>> Stewart >>>>> >>>>> BTW >>>>> >>>>> It might be as well if you refrained from illustrating the >>>>> lack of professionalism that the security area applies to its >>>>> reviews by continuing with the flippancy. There is a serious >>>>> point that needs to be debated here about what assumptions are >>>>> a given and what assumptions need to be spelled out when >>>>> modifying or layering a technology. >>>>> >>>>> >>>>> > On 16 Mar 2020, at 12:22, Uri Blumenthal >>>> > wrote: >>>>> > >>>>> > IETF position (add fat as I remember) regarding RFCs has >>>>> been that RFCs should provide with everything information for >>>>> a reasonable developer to implement correctly and securely the >>>>> standard they define, and provide enough information for the >>>>> person who will deploy a compliant implementation to do that >>>>> correctly and securely. >>>>> > >>>>> > One purpose of Security Review is to ensure that a person >>>>> doesn't have to be an expert in the field to deal with the >>>>> proposed document. >>>>> > >>>>> > In a flippant way, if using your stuff is requires special >>>>> classes - perhaps it belongs to a book rather than an RFC. >>>>> > >>>>> > In a non-flippant way - what's the problem in mentioning the >>>>> issues and providing the appropriate references? A "normal" >>>>> RFC cannot be self-contained, but it's unreasonable to epect a >>>>> reader to just "know" where all the omitted things are described. >>>>> > >>>>> >> On Mar 16, 2020, at 06:33, Stewart Bryant >>>>> > >>>>> wrote: >>>>> >> >>>>> >> Uri, >>>>> >> >>>>> >> That is a ridiculous position, and you flippancy >>>>> demonstrates that. >>>>> >> >>>>> >> This technology fundamentally rests on MPLS and it is >>>>> reasonable that the reader of this RFC will understand MPLS >>>>> and the security model it uses before they implement or deploy >>>>> it. Indeed I cannot think of any implementor or operator that >>>>> would not already have that knowledge before taking on the >>>>> task of building or running DN over MPLS. >>>>> >> >>>>> >> If SecDir reviews are to retain any credibility as expert >>>>> reviews as opposed to Genart random reader reviews they have >>>>> to be carried out with shared knowledge of both the security >>>>> area and the draft’s host area. >>>>> >> >>>>> >> I have been thinking for some time that there needs to be a >>>>> fundamental review of the security review process. >>>>> >> >>>>> >> Stewart >>>>> >> >>>>> >>> On 15 Mar 2020, at 22:44, Uri Blumenthal >>>> > wrote: >>>>> >>> >>>>> >>> I say yes - unless you expect a person who wants just one >>>>> RFC to have to read every cr^h^h stuff that came out of the >>>>> routing area. >>>>> >>> >>>>> >>> "Just do it" >>>>> >>> >>>>> >>> >>>>> >>>>> On Mar 15, 2020, at 17:39, Lou Berger >>>> > wrote: >>>>> >>>> >>>>> >>>>  >>>>> >>>>> On 3/15/2020 5:22 PM, Watson Ladd wrote: >>>>> >>>>>> On Sun, Mar 15, 2020 at 2:14 PM Lou Berger >>>>> > wrote: >>>>> >>>>>> Hi Watson, >>>>> >>>>>> >>>>> >>>>>>   I think Stewart's response really covers the main >>>>> points. DetNet is >>>>> >>>>>> really just MPLS (and IP) with some specific forwarding >>>>> behaviors and >>>>> >>>>>> queuing.  The only thing I'd add, is I see DetNet in >>>>> general as a >>>>> >>>>>> specific form of policy based routing. (The general >>>>> form of which is >>>>> >>>>>> pretty much as old as IP). >>>>> >>>>> Then Stewart can put those points in the security >>>>> considerations >>>>> >>>>> section. What's the disadvantage of doing so? >>>>> >>>> >>>>> >>>> At one level, it would be easiest for the authors to just >>>>> put these in.  On the other hand, this would mean that every >>>>> RFC produced in the routing area will acquire similar notes, >>>>> e.g., routing protocols are currently built with a chain of >>>>> trust model.  Is this what the sec-dir really is asking the >>>>> routing area to do? >>>>> >>>> >>>>> >>>> ADs, >>>>> >>>> >>>>> >>>>  any opinion on this?  (for context, Stewart's response >>>>> can be found >>>>> at:https://mailarchive.ietf.org/arch/msg/detnet/-epL5Fb6bFIUltMrjH53C2316ZA/) >>>>> >>>> >>>>> >>>> Thanks, >>>>> >>>> >>>>> >>>> Lou >>>>> >>>> >>>>> >>>>>> Lou >>>>> >>>>>> >>>>> >>>>>> On 3/12/2020 9:35 PM, Watson Ladd wrote: >>>>> >>>>>>> On Thu, Mar 12, 2020 at 4:07 AM Lou Berger >>>>> > wrote: >>>>> >>>>>>>> Watson, >>>>> >>>>>>>> >>>>> >>>>>>>> Can you provide context here? Can you be explicit on >>>>> what you see needs to >>>>> >>>>>>>> be addressed (beyond what is in this document as well >>>>> as related rfcs)? >>>>> >>>>>>> You have to talk about how the layers interact, and >>>>> can't just say the >>>>> >>>>>>> lower level handles anything without any guide as to >>>>> what needs to be >>>>> >>>>>>> provided by that lower layer. >>>>> >>>>>>> >>>>> >>>>>>> I think my concerns about the assumptions this could >>>>> be fixed by >>>>> >>>>>>> saying. "All nodes are trusted and any of them can >>>>> misbehave in ways >>>>> >>>>>>> that affect the network.  If the MPLS layer cannot >>>>> provide sufficient >>>>> >>>>>>> determinism, then the DetNet mechanisms won't work".  >>>>> I agree we >>>>> >>>>>>> shoudn't require an entire massive security framework >>>>> to be quoted >>>>> >>>>>>> again here, but there must be some details of this >>>>> embedding that are >>>>> >>>>>>> worth noting, and yet I don't see them called out in >>>>> the security >>>>> >>>>>>> considerations section. >>>>> >>>>>>> >>>>> >>>>>>> Are there really no specific concerns about the >>>>> interaction between >>>>> >>>>>>> DetNet and MPLS? >>>>> >>>>>>> >>>>> >>>>>>>> Thank you, >>>>> >>>>>>>> Lou >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> ---------- >>>>> >>>>>>>> On March 11, 2020 10:30:27 PM Watson Ladd >>>>> > wrote: >>>>> >>>>>>>> >>>>> >>>>>>>>> I don't see any reason why RFC 3552's guidelines >>>>> shoudn't apply to this draft. >>>>> >>>>>>>>> >>>>> >>>>>>>>> If there is a MPLS exception I'd like to see the >>>>> rules that should be applied. >>>>> >>>>>>>>> >>>>> >>>>>>>>> As is I don't see any reason why the assumptions >>>>> can't be explicitly >>>>> >>>>>>>>> spelled out, either in the Security Considerations >>>>> or elsewhere. >>>>> >>>>>>>>> >>>>> >>>>>>>>> _______________________________________________ >>>>> >>>>>>>>> detnet mailing list >>>>> >>>>>>>>>detnet@ietf.org >>>>> >>>>>>>>>https://www.ietf.org/mailman/listinfo/detnet >>>>> >>>>>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>>> >>>> _______________________________________________ >>>>> >>>> secdir mailing list >>>>> >>>>secdir@ietf.org >>>>> >>>>https://www.ietf.org/mailman/listinfo/secdir >>>>> >>>> wiki:http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >>>>> >> >>>>> >>> >>> _______________________________________________ >>> detnet mailing list >>> detnet@ietf.org >>> https://www.ietf.org/mailman/listinfo/detnet > > Uri > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet --------------B717831FBE174360A43715A0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi,

On 3/16/2020 3:56 PM, Uri Blumenthal wrote:
On Mar 16, 2020, at 14:29 , Lou Berger <lberger@labn.net> wrote:

If indeed, as Stewart says, detnet does not add any security considerations to those already described in the MPLS documents - the draft should state so explicitly. Though I personally find it hard to believe.

What is an "obvious common sense" for you and Stewart, may not be so obvious to other readers.

As a note to others, it is expected that RFC authors do perform a comprehensive security analysis, and document their findings in the Security Considerations section. I thought that was obvious.

I think either we agree or that the words "a comprehensive security analysis" is the source of a disconnect.  My view is that the such analysis is a *delta* analysis for previous IETF work/RFCs. 

Yes, it should be a *comprehensive* analysis of the possible security impacts that the *changes* introduce.

I.e., in general, when you add some capability, you describe
  • What your security assumptions are - what kind of access you assume your adversary can or cannot have.
  • How your added capability impacts/changes the existing security posture (and what you assume that posture is/was) - new attack surface(s), etc. 
  • What of the newly-introduced stuff may require protection, and what kind of protection (should stay secret, no problem if disclosed but a big deal if modified, etc).
  • How you recommend protecting the above.

The reader should learn what new requires protection, ideally - why, and probably, how. But (IMHO) saying “just use TLS” is not nearly good enough - it doesn’t tell me what I’m trying to protect, and why (what harm could come if left unprotected).

explaining why a security mechanism is needed seems reasonable to me.



Certainly authors should reference the prior work/RFCs that are needed to understand the analysis, but they need not (even should not) rehash all the material form this existing work -- only what has changed.

Correct. BTW, by “reference” I mean stating what concepts from those RFCs apply.

so you want to repeat all the concepts from prior work/rfcs?  This makes little sense to me as it means the likely introduction of differences and errors from the original work.  Pointers to the relevant work/sections seem right to me as the implementations are going to have to support the prior work in any case.

Does this match your expectation or do you expect something different?  If so, what do you expect?

I think it does, with the above caveat ;).

We may nit-argue about what “rehashing existing work” means. 

Referring the reader to go to RFC XXXX for details on specific concerns/issues/etc is fine. We wouldn’t be able to operate if every RFC had to be self-contained, and included everything related.

very happy we agree on this key point.

But you should tell the reader why you’re referring him to an external document, and what in particular he’s supposed to find/look for there.

Sure, but it sounds like we may differ on detail level needed in the reference.


To just say “this is MPLS-based, so to figure it’s security risks go read MPLS RFCs” IMHO is not good enough. Mainly because I don’t agree that  no new exposures are introduced.

I don't think this is a valid solution to your concern.

If the authors, however, believe this - their analysis (put in the Security Considerations section) should show why there are no new exposures. It doesn’t have to be lengthy - but it does have to make sense.

This is a good solution -- in other words, I do think it's fair to add something on this to the section.  I suspect it will be at most two sentences. 

Lou




On Mar 16, 2020, at 10:22, Lou Berger <lberger@labn.net> wrote:

Watson, Uri,

would a reference to https://tools.ietf.org/html/draft-ietf-detnet-security-08#section-7 help? note that Detnet operates/extends the IP and MPLS layers.  It is not a service that rides on general IP or separate from the MPLS layers.

Lou

On 3/16/2020 10:18 AM, Watson Ladd wrote:


On Mon, Mar 16, 2020, 7:01 AM Stewart Bryant <stewart.bryant@gmail.com> wrote:
The requirement is NOT for a draft to provide the security analysis of all of all of the technologies that it calls up. It is, I believe, to describe the deltas that apply to the new idea. Anything else and the text would be a security analysis with a short technology preamble.

We are describing a technology that is overlaid on MPLS. We should not need to describe the security model of MPLS,  but instead confine our remarks to issues that specifically apply to the additional technology we are describing.

RFC 3552 requires that in a case such as this you explicitly describe what the lower layer is providing to the top layer. RFC 3552 section 5 also demands that attacks be enumerated and those out of scope be called out.

E.g "use TLS" isn't good enough and imho neither is "use MPLS".

Again, the sentences in the security considerations as it stands are about MPLS and Detnet, and they don't seem to come together. Are there really no security considerations when putting the two together? Every MPLS network will just work with Detnet on top, no matter how rushed the deploy is?


Early in the document we call up RFC3031 and RFC3032, the fundamental MPLS RFCs. They are in section 3.1 the first part of the serious technical discussion. In my view these establish a baseline of understand that the reader is expected to have.

It is important to realise, as I have said before, that without understanding that baseline the rest of the document is meaningless.

Regards

Stewart

BTW

It might be as well if you refrained from illustrating the lack of professionalism that the security area applies to its reviews by continuing with the flippancy. There is a serious point that needs to be debated here about what assumptions are a given and what assumptions need to be spelled out when modifying or layering a technology.


> On 16 Mar 2020, at 12:22, Uri Blumenthal <uri@mit.edu> wrote:
> 
> IETF position (add fat as I remember) regarding RFCs has been that RFCs should provide with everything information for a reasonable developer to implement correctly and securely the standard they define, and provide enough information for the person who will deploy a compliant implementation to do that correctly and securely.
> 
> One purpose of Security Review is to ensure that a person doesn't have to be an expert in the field to deal with the proposed document.
> 
> In a flippant way, if using your stuff is requires special classes - perhaps it belongs to a book rather than an RFC.
> 
> In a non-flippant way - what's the problem in mentioning the issues and providing the appropriate references? A "normal" RFC cannot be self-contained, but it's unreasonable to epect a reader to just "know" where all the omitted things are described. 
> 
>> On Mar 16, 2020, at 06:33, Stewart Bryant <stewart.bryant@gmail.com> wrote:
>> 
>> Uri,
>> 
>> That is a ridiculous position, and you flippancy demonstrates that.
>> 
>> This technology fundamentally rests on MPLS and it is reasonable that the reader of this RFC will understand MPLS and the security model it uses before they implement or deploy it. Indeed I cannot think of any implementor or operator that would not already have that knowledge before taking on the task of building or running DN over MPLS.
>> 
>> If SecDir reviews are to retain any credibility as expert reviews as opposed to Genart random reader reviews they have to be carried out with shared knowledge of both the security area and the draft’s host area.
>> 
>> I have been thinking for some time that there needs to be a fundamental review of the security review process.
>> 
>> Stewart
>> 
>>> On 15 Mar 2020, at 22:44, Uri Blumenthal <uri@mit.edu> wrote:
>>> 
>>> I say yes - unless you expect a person who wants just one RFC to have to read every cr^h^h stuff that came out of the routing area.
>>> 
>>> "Just do it"
>>> 
>>> 
>>>>> On Mar 15, 2020, at 17:39, Lou Berger <lberger@labn.net> wrote:
>>>> 
>>>> 
>>>>> On 3/15/2020 5:22 PM, Watson Ladd wrote:
>>>>>> On Sun, Mar 15, 2020 at 2:14 PM Lou Berger <lberger@labn.net> wrote:
>>>>>> Hi Watson,
>>>>>> 
>>>>>>   I think Stewart's response really covers the main points. DetNet is
>>>>>> really just MPLS (and IP) with some specific forwarding behaviors and
>>>>>> queuing.  The only thing I'd add, is I see DetNet in general as a
>>>>>> specific form of policy based routing. (The general form of which is
>>>>>> pretty much as old as IP).
>>>>> Then Stewart can put those points in the security considerations
>>>>> section. What's the disadvantage of doing so?
>>>> 
>>>> At one level, it would be easiest for the authors to just put these in.  On the other hand, this would mean that every RFC produced in the routing area will acquire similar notes, e.g., routing protocols are currently built with a chain of trust model.  Is this what the sec-dir really is asking the routing area to do?
>>>> 
>>>> ADs,
>>>> 
>>>>  any opinion on this?     (for context, Stewart's response can be found at: https://mailarchive.ietf.org/arch/msg/detnet/-epL5Fb6bFIUltMrjH53C2316ZA/)
>>>> 
>>>> Thanks,
>>>> 
>>>> Lou
>>>> 
>>>>>> Lou
>>>>>> 
>>>>>> On 3/12/2020 9:35 PM, Watson Ladd wrote:
>>>>>>> On Thu, Mar 12, 2020 at 4:07 AM Lou Berger <lberger@labn.net> wrote:
>>>>>>>> Watson,
>>>>>>>> 
>>>>>>>> Can you provide context here? Can you be explicit on what you see needs to
>>>>>>>> be addressed (beyond what is in this document as well as related rfcs)?
>>>>>>> You have to talk about how the layers interact, and can't just say the
>>>>>>> lower level handles anything without any guide as to what needs to be
>>>>>>> provided by that lower layer.
>>>>>>> 
>>>>>>> I think my concerns about the assumptions this could be fixed by
>>>>>>> saying. "All nodes are trusted and any of them can misbehave in ways
>>>>>>> that affect the network.  If the MPLS layer cannot provide sufficient
>>>>>>> determinism, then the DetNet mechanisms won't work".  I agree we
>>>>>>> shoudn't require an entire massive security framework to be quoted
>>>>>>> again here, but there must be some details of this embedding that are
>>>>>>> worth noting, and yet I don't see them called out in the security
>>>>>>> considerations section.
>>>>>>> 
>>>>>>> Are there really no specific concerns about the interaction between
>>>>>>> DetNet and MPLS?
>>>>>>> 
>>>>>>>> Thank you,
>>>>>>>> Lou
>>>>>>>> 
>>>>>>>> 
>>>>>>>> ----------
>>>>>>>> On March 11, 2020 10:30:27 PM Watson Ladd <watsonbladd@gmail.com> wrote:
>>>>>>>> 
>>>>>>>>> I don't see any reason why RFC 3552's guidelines shoudn't apply to this draft.
>>>>>>>>> 
>>>>>>>>> If there is a MPLS exception I'd like to see the rules that should be applied.
>>>>>>>>> 
>>>>>>>>> As is I don't see any reason why the assumptions can't be explicitly
>>>>>>>>> spelled out, either in the Security Considerations or elsewhere.
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> detnet mailing list
>>>>>>>>> detnet@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/detnet
>>>>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> secdir mailing list
>>>> secdir@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/secdir
>>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>> 


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

Uri


_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet
--------------B717831FBE174360A43715A0-- From nobody Tue Mar 17 07:26:20 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087CE3A0832; Tue, 17 Mar 2020 07:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=gYobrsGK; dkim=pass (1024-bit key) header.d=dell.onmicrosoft.com header.b=mHrbZ24Y Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qPcdXJE3bcN; Tue, 17 Mar 2020 07:26:12 -0700 (PDT) Received: from mx0a-00154904.pphosted.com (mx0a-00154904.pphosted.com [148.163.133.20]) (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 1E6283A082E; Tue, 17 Mar 2020 07:26:12 -0700 (PDT) Received: from pps.filterd (m0170389.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 02HELEYh008616; Tue, 17 Mar 2020 10:26:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=smtpout1; bh=OuvJNw1eP4w3X/bgnPv7VdSAuIZI0ygUUVTg3WK7/Fo=; b=gYobrsGKhsve4pkcfRtkyk1IUR31vs6WZQXkk673+0bdSQGGdKJ3bTMmcAU6SG+/1T1F UApyITDJL5oOMIUAUczehb4uUuBXMc1H8ePrnbP9CXwX85W5LuLRpXlQ9ZYDc1K9rfvs sEt7Zqb9gvVKReSoXXZDfjgF/xJwCMF10TVbnGastfaRf4BJLhU1meWGcFVp7ynTw76C IPd0QlJsM0bDQUP8p/6w+nK7a35oHOATizjgx9KACdAo6dFsTr69oDN+1Xs0T7gDqcxq NBXKh7BlC59/LPs4KWCMXFzcTawChKDzYmX8DNNWRMFFDWdtSt+d0QahkKUM8DTJSsCc WA== Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0a-00154904.pphosted.com with ESMTP id 2yru9jr8ju-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Mar 2020 10:26:10 -0400 Received: from pps.filterd (m0144103.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 02HE9rfj043573; Tue, 17 Mar 2020 10:26:09 -0400 Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2045.outbound.protection.outlook.com [104.47.66.45]) by mx0b-00154901.pphosted.com with ESMTP id 2yrstacg8j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 17 Mar 2020 10:26:09 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WQVfdgp40w9oGyKqrjtBUFL4CEHeGuTrmVmyqrxJfIu1nK4TAdW7e41iOioaQLHwjjHMmCckNt/sYO0JVtP32NVXbsGwqjAtZJL9AimdxrByG1yY16U8GtsHpSfoAJpNxt+NsLtPpo/0B4SgGOM/vEhb+YBtemqCcnw37nFazaoXDkYWCi4FMlgZq+9V/gyoChGxzs6hekTZyRPyjTSr4OZ9t/X+lx95jozctM4KHxuPRBWzbY5G/cu/ANqhtf7kOm6lbvyY4rFDYCrJ/hcF0rpx0j1Oc1eauc39FhiHWQI31tjfQUX1ye0PGNxhsWHkTtXSq4zlNr+A3/aDVBYVvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OuvJNw1eP4w3X/bgnPv7VdSAuIZI0ygUUVTg3WK7/Fo=; b=Ami3WaOMqVADYOsSBRRes2b+26G4ice2M6qAft5wvLzoGeFB0ssqY3k4uGb5iJJFwuTNT6TMisv7xYClqClvpoSEPLhlY5alYSxi9oBjdXEIzUxDlFnZQmgI4prQK0Eo8ucLS//Y25ybxz8UqPIa+VZfc8ZHEHx4enQKyjrNaXmSt9ujEgAw2nyq2GmOJ30aPmqGh5WUmoD3XR/KaFT9fX1YdFIMTLVTyPxnjE7sTc1dyx3ob9My4qUqkZW47yALDdInhwoysFMrnyuU2DpQfwPi+JKBwt1CSauCASqjAjvAipMVyGPy8g7WyoJtGTH/FHWXv7o+tsEjZs1uyS8sqQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com; dkim=pass header.d=dell.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Dell.onmicrosoft.com; s=selector1-Dell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OuvJNw1eP4w3X/bgnPv7VdSAuIZI0ygUUVTg3WK7/Fo=; b=mHrbZ24YWnLkHYOkjrCLNjLBNmnAuKkozpmNfA8V5XPlC/CX8RGgVpKyGJrzmtRZqc4O6gTT/qSOJuWbCxis0EizFAWE0m1NNGSpJDVHq9H6dL0L9cXJxhHxdXimM5pYOkINyAElib7aKyibPPhgNbAU9buvLEsQ5lAzNpnVj04= Received: from MN2PR19MB4045.namprd19.prod.outlook.com (2603:10b6:208:1e4::9) by MN2PR19MB4111.namprd19.prod.outlook.com (2603:10b6:208:1e6::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.21; Tue, 17 Mar 2020 14:26:05 +0000 Received: from MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::8d12:8a24:ccb2:b2bd]) by MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::8d12:8a24:ccb2:b2bd%3]) with mapi id 15.20.2814.021; Tue, 17 Mar 2020 14:26:05 +0000 From: "Black, David" To: Lou Berger , Uri Blumenthal CC: secdir , "rtg-ads@ietf.org" , Watson Ladd , "draft-ietf-detnet-mpls.all@ietf.org" , Stewart Bryant , "" , DetNet WG , "Black, David" Thread-Topic: [Detnet] [secdir] Secdir last call review of draft-ietf-detnet-mpls-05 Thread-Index: AQHV+xtp7w5BDHT69kClfjdrlTdzvKhLBnsAgAAec4CAABtoAIAABQwAgAABIwCAAB/vAIAAJP2AgAAYUACAARhTgIAAGoLA Date: Tue, 17 Mar 2020 14:26:05 +0000 Message-ID: References: <73942657-B55A-431F-AB55-444C3C587AE1@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2020-03-17T14:23:39.8221899Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual; aiplabel=External Public x-originating-ip: [72.74.71.221] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6016c16a-a58c-4fcb-630b-08d7ca7f20cb x-ms-traffictypediagnostic: MN2PR19MB4111: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4 x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0345CFD558 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(366004)(39860400002)(396003)(136003)(199004)(26005)(107886003)(30864003)(786003)(316002)(4326008)(52536014)(8676002)(81166006)(81156014)(5660300002)(71200400001)(9326002)(33656002)(6506007)(8936002)(2906002)(53546011)(7696005)(66446008)(66476007)(66946007)(76116006)(66556008)(64756008)(86362001)(186003)(478600001)(55016002)(54906003)(110136005)(966005)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR19MB4111; H:MN2PR19MB4045.namprd19.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: dell.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Y4rVLhEItjBWWe7DEkisx6smQTknW6LzlC+XWV7vt8z3jSoZwqei73zPNVlaqpt9uycrgucAeXsNhSrVqvkqB4Yz5SIrj35lYRTv3l6u9n+wcxGNjgbHSpRUOf7Fe9NgeczSQ9BSLWAU1H3Iy3ArIPKhVwxcd0cihquaJ0Ap+Fy8U4cWkJn3UwjSSwHwVcw8o5OqTmpAidZSZbWC/RQlzSE2dchwkiEOHwHMU6RcFbKMsiI3pVvpnwA/FgC/iAcLwKsCNiAId2hSf9nob1ghcsJxxLS2byMjs1hzqNwBmMBtT2tZ7Blb4Mqm9e5ADCCRN+zsN8PLdV3H0O9lMadRfbYOvGP74fdJ/9burNGa2Sh7W20pC4es0dloE7uq1r25K9AuGqPcGEFNQz7dCz8iRg0yPFpz4cJ8R/JGDylRW5EO7fnxCp5PD3O7c3byaKv09PNPiUOJQlhGTjOKqZcPsWxzzfRQW8diZh/tTkTkoAymqbs27Q+QZN0oJj5Q25Vz/pmROvdIhue5niunr0x+8A== x-ms-exchange-antispam-messagedata: E3aItv2d0Rv6srl5mwexgdbpJCQ1VwCMpwgVGNnkO7uu19KZfBBTFV25zKjPMXbTzYGwJUP6KzrOFklk0s1K4fyB8Xw5ZLjTkLiPb4lf8RAENJmYHp09kHaJRqBJkx0uy90bsW5MO08mVOm/t13jxw== Content-Type: multipart/alternative; boundary="_000_MN2PR19MB404529C87F0765CDA8D202D583F60MN2PR19MB4045namp_" MIME-Version: 1.0 X-OriginatorOrg: Dell.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6016c16a-a58c-4fcb-630b-08d7ca7f20cb X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2020 14:26:05.4180 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: bzUiAXVLS03rvkYUAkWiwGKG2POQ52lgQAHDe7nmfe070qoJqst0dW7A+kTMO1cCgcBZC9KICCttbNiQEtxvrA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB4111 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.645 definitions=2020-03-17_05:2020-03-17, 2020-03-17 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 spamscore=0 clxscore=1011 mlxlogscore=999 malwarescore=0 priorityscore=1501 lowpriorityscore=0 suspectscore=0 bulkscore=0 mlxscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2003170061 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 lowpriorityscore=0 malwarescore=0 phishscore=0 adultscore=0 suspectscore=0 bulkscore=0 priorityscore=1501 spamscore=0 mlxscore=0 mlxlogscore=999 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2003170061 Archived-At: Subject: Re: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2020 14:26:17 -0000 --_000_MN2PR19MB404529C87F0765CDA8D202D583F60MN2PR19MB4045namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG91LA0KDQpXZWlnaGluZyBpbiBsYXRlIGluIHRoZSBkaXNjdXNzaW9uIC4uLiB0cnlpbmcg dG8gbWFrZSBhIHBvc2l0aXZlIGNvbnRyaWJ1dGlvbiAuLi4NCg0KPj4gSWYgdGhlIGF1dGhvcnMs IGhvd2V2ZXIsIGJlbGlldmUgdGhpcyAtIHRoZWlyIGFuYWx5c2lzIChwdXQgaW4gdGhlIFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24pIHNob3VsZCBzaG93IHdoeSB0aGVyZSBhcmUgbm8g bmV3IGV4cG9zdXJlcy4NCj4+IEl0IGRvZXNu4oCZdCBoYXZlIHRvIGJlIGxlbmd0aHkgLSBidXQg aXQgZG9lcyBoYXZlIHRvIG1ha2Ugc2Vuc2UuDQoNCj4gVGhpcyBpcyBhIGdvb2Qgc29sdXRpb24g LS0gaW4gb3RoZXIgd29yZHMsIEkgZG8gdGhpbmsgaXQncyBmYWlyIHRvIGFkZCBzb21ldGhpbmcg b24gdGhpcyB0byB0aGUgc2VjdGlvbi4gIEkgc3VzcGVjdCBpdCB3aWxsIGJlIGF0IG1vc3QgdHdv IHNlbnRlbmNlcy4NClR3byBpbXBvcnRhbnQgZGlmZmVyZW5jZXMgYmV0d2VlbiBEZXROZXQgYW5k IE1QTFMgYXJlIHRoYXQgRGV0TmV0IHVzZXMgYSBmcmFjdGlvbiBvZiB0aGUgcmVzb3VyY2VzIG9m IHRoZSBNUExTIGRhdGEgcGxhbmUgYW5kIERldE5ldCBoYXMgcmF0aGVyIHRpZ2h0IHRpbWluZyBy ZXF1aXJlbWVudHMuICBCeSBjb21wYXJpc29uIHRvIG9yZGluYXJ5IE1QTFMsIHRoYXQgY29tYmlu YXRpb24gcmVkdWNlcyB0aGUgZWZmb3J0IHJlcXVpcmVzIHRvIG92ZXJ3aGVsbSB0aGUgRGV0TmV0 IGZvcndhcmRpbmcgcmVzb3VyY2VzIGFuZCBpbmNyZWFzZXMgdGhlIGFiaWxpdHkgdG8gZG8gc2Vy aW91cyBkYW1hZ2UgKHRvIERldE5ldCBzZXJ2aWNlLCBub3QgTVBMUyBvdmVyYWxsKSBhdCByZWxh dGl2ZWx5IGxvdyBsZXZlbHMgb2Ygb3ZlcmxvYWQuDQoNCk15IGluaXRpYWwgaHVuY2ggaXMgdGhh dCBTdGV3YXJ0IGlzIGNvcnJlY3QgdGhhdCBNUExT4oCZcyBleGlzdGluZyByZXNpc3RhbmNlIHRv IGRlbmlhbCBvZiBzZXJ2aWNlIGF0dGFja3Mgc3VmZmljZXMgZm9yIERldE5ldCB3aXRob3V0IGFk ZGl0aW9uYWwgbWVhc3VyZXMsIGJ1dCBhIGJyaWVmIGV4cGxhbmF0aW9uIG9mIHdoeSB3b3VsZCBi ZSBhIGdvb2QgdGhpbmcgdG8gYWRkIHRvIHRoaXMgZHJhZnQuDQoNClRoYW5rcywgLS1EYXZpZA0K DQpGcm9tOiBkZXRuZXQgPGRldG5ldC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTG91 IEJlcmdlcg0KU2VudDogVHVlc2RheSwgTWFyY2ggMTcsIDIwMjAgODo0MCBBTQ0KVG86IFVyaSBC bHVtZW50aGFsDQpDYzogc2VjZGlyOyBydGctYWRzQGlldGYub3JnOyBXYXRzb24gTGFkZDsgZHJh ZnQtaWV0Zi1kZXRuZXQtbXBscy5hbGxAaWV0Zi5vcmc7IFN0ZXdhcnQgQnJ5YW50OyA8c2VjLWFk c0BpZXRmLm9yZz47IERldE5ldCBXRw0KU3ViamVjdDogUmU6IFtEZXRuZXRdIFtzZWNkaXJdIFNl Y2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtZGV0bmV0LW1wbHMtMDUNCg0KDQpb RVhURVJOQUwgRU1BSUxdDQoNCkhpLA0KT24gMy8xNi8yMDIwIDM6NTYgUE0sIFVyaSBCbHVtZW50 aGFsIHdyb3RlOg0KT24gTWFyIDE2LCAyMDIwLCBhdCAxNDoyOSAsIExvdSBCZXJnZXIgPGxiZXJn ZXJAbGFibi5uZXQ8bWFpbHRvOmxiZXJnZXJAbGFibi5uZXQ+PiB3cm90ZToNCg0KSWYgaW5kZWVk LCBhcyBTdGV3YXJ0IHNheXMsIGRldG5ldCBkb2VzIG5vdCBhZGQgYW55IHNlY3VyaXR5IGNvbnNp ZGVyYXRpb25zIHRvIHRob3NlIGFscmVhZHkgZGVzY3JpYmVkIGluIHRoZSBNUExTIGRvY3VtZW50 cyAtIHRoZSBkcmFmdCBzaG91bGQgc3RhdGUgc28gZXhwbGljaXRseS4gVGhvdWdoIEkgcGVyc29u YWxseSBmaW5kIGl0IGhhcmQgdG8gYmVsaWV2ZS4NCldoYXQgaXMgYW4gIm9idmlvdXMgY29tbW9u IHNlbnNlIiBmb3IgeW91IGFuZCBTdGV3YXJ0LCBtYXkgbm90IGJlIHNvIG9idmlvdXMgdG8gb3Ro ZXIgcmVhZGVycy4NCg0KQXMgYSBub3RlIHRvIG90aGVycywgaXQgaXMgZXhwZWN0ZWQgdGhhdCBS RkMgYXV0aG9ycyBkbyBwZXJmb3JtIGEgY29tcHJlaGVuc2l2ZSBzZWN1cml0eSBhbmFseXNpcywg YW5kIGRvY3VtZW50IHRoZWlyIGZpbmRpbmdzIGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9u cyBzZWN0aW9uLiBJIHRob3VnaHQgdGhhdCB3YXMgb2J2aW91cy4NCkkgdGhpbmsgZWl0aGVyIHdl IGFncmVlIG9yIHRoYXQgdGhlIHdvcmRzICJhIGNvbXByZWhlbnNpdmUgc2VjdXJpdHkgYW5hbHlz aXMiIGlzIHRoZSBzb3VyY2Ugb2YgYSBkaXNjb25uZWN0LiAgTXkgdmlldyBpcyB0aGF0IHRoZSBz dWNoIGFuYWx5c2lzIGlzIGEgKmRlbHRhKiBhbmFseXNpcyBmb3IgcHJldmlvdXMgSUVURiB3b3Jr L1JGQ3MuDQpZZXMsIGl0IHNob3VsZCBiZSBhICpjb21wcmVoZW5zaXZlKiBhbmFseXNpcyBvZiB0 aGUgcG9zc2libGUgc2VjdXJpdHkgaW1wYWN0cyB0aGF0IHRoZSAqY2hhbmdlcyogaW50cm9kdWNl Lg0KDQpJLmUuLCBpbiBnZW5lcmFsLCB3aGVuIHlvdSBhZGQgc29tZSBjYXBhYmlsaXR5LCB5b3Ug ZGVzY3JpYmUNCg0KICAqICAgV2hhdCB5b3VyIHNlY3VyaXR5IGFzc3VtcHRpb25zIGFyZSAtIHdo YXQga2luZCBvZiBhY2Nlc3MgeW91IGFzc3VtZSB5b3VyIGFkdmVyc2FyeSBjYW4gb3IgY2Fubm90 IGhhdmUuDQogICogICBIb3cgeW91ciBhZGRlZCBjYXBhYmlsaXR5IGltcGFjdHMvY2hhbmdlcyB0 aGUgZXhpc3Rpbmcgc2VjdXJpdHkgcG9zdHVyZSAoYW5kIHdoYXQgeW91IGFzc3VtZSB0aGF0IHBv c3R1cmUgaXMvd2FzKSAtIG5ldyBhdHRhY2sgc3VyZmFjZShzKSwgZXRjLg0KICAqICAgV2hhdCBv ZiB0aGUgbmV3bHktaW50cm9kdWNlZCBzdHVmZiBtYXkgcmVxdWlyZSBwcm90ZWN0aW9uLCBhbmQg d2hhdCBraW5kIG9mIHByb3RlY3Rpb24gKHNob3VsZCBzdGF5IHNlY3JldCwgbm8gcHJvYmxlbSBp ZiBkaXNjbG9zZWQgYnV0IGEgYmlnIGRlYWwgaWYgbW9kaWZpZWQsIGV0YykuDQogICogICBIb3cg eW91IHJlY29tbWVuZCBwcm90ZWN0aW5nIHRoZSBhYm92ZS4NCg0KVGhlIHJlYWRlciBzaG91bGQg bGVhcm4gd2hhdCBuZXcgcmVxdWlyZXMgcHJvdGVjdGlvbiwgaWRlYWxseSAtIHdoeSwgYW5kIHBy b2JhYmx5LCBob3cuIEJ1dCAoSU1ITykgc2F5aW5nIOKAnGp1c3QgdXNlIFRMU+KAnSBpcyBub3Qg bmVhcmx5IGdvb2QgZW5vdWdoIC0gaXQgZG9lc27igJl0IHRlbGwgbWUgd2hhdCBJ4oCZbSB0cnlp bmcgdG8gcHJvdGVjdCwgYW5kIHdoeSAod2hhdCBoYXJtIGNvdWxkIGNvbWUgaWYgbGVmdCB1bnBy b3RlY3RlZCkuDQoNCmV4cGxhaW5pbmcgd2h5IGEgc2VjdXJpdHkgbWVjaGFuaXNtIGlzIG5lZWRl ZCBzZWVtcyByZWFzb25hYmxlIHRvIG1lLg0KDQoNCg0KQ2VydGFpbmx5IGF1dGhvcnMgc2hvdWxk IHJlZmVyZW5jZSB0aGUgcHJpb3Igd29yay9SRkNzIHRoYXQgYXJlIG5lZWRlZCB0byB1bmRlcnN0 YW5kIHRoZSBhbmFseXNpcywgYnV0IHRoZXkgbmVlZCBub3QgKGV2ZW4gc2hvdWxkIG5vdCkgcmVo YXNoIGFsbCB0aGUgbWF0ZXJpYWwgZm9ybSB0aGlzIGV4aXN0aW5nIHdvcmsgLS0gb25seSB3aGF0 IGhhcyBjaGFuZ2VkLg0KQ29ycmVjdC4gQlRXLCBieSDigJxyZWZlcmVuY2XigJ0gSSBtZWFuIHN0 YXRpbmcgd2hhdCBjb25jZXB0cyBmcm9tIHRob3NlIFJGQ3MgYXBwbHkuDQoNCg0Kc28geW91IHdh bnQgdG8gcmVwZWF0IGFsbCB0aGUgY29uY2VwdHMgZnJvbSBwcmlvciB3b3JrL3JmY3M/ICBUaGlz IG1ha2VzIGxpdHRsZSBzZW5zZSB0byBtZSBhcyBpdCBtZWFucyB0aGUgbGlrZWx5IGludHJvZHVj dGlvbiBvZiBkaWZmZXJlbmNlcyBhbmQgZXJyb3JzIGZyb20gdGhlIG9yaWdpbmFsIHdvcmsuICBQ b2ludGVycyB0byB0aGUgcmVsZXZhbnQgd29yay9zZWN0aW9ucyBzZWVtIHJpZ2h0IHRvIG1lIGFz IHRoZSBpbXBsZW1lbnRhdGlvbnMgYXJlIGdvaW5nIHRvIGhhdmUgdG8gc3VwcG9ydCB0aGUgcHJp b3Igd29yayBpbiBhbnkgY2FzZS4NCkRvZXMgdGhpcyBtYXRjaCB5b3VyIGV4cGVjdGF0aW9uIG9y IGRvIHlvdSBleHBlY3Qgc29tZXRoaW5nIGRpZmZlcmVudD8gIElmIHNvLCB3aGF0IGRvIHlvdSBl eHBlY3Q/DQpJIHRoaW5rIGl0IGRvZXMsIHdpdGggdGhlIGFib3ZlIGNhdmVhdCA7KS4NCg0KV2Ug bWF5IG5pdC1hcmd1ZSBhYm91dCB3aGF0IOKAnHJlaGFzaGluZyBleGlzdGluZyB3b3Jr4oCdIG1l YW5zLg0KDQpSZWZlcnJpbmcgdGhlIHJlYWRlciB0byBnbyB0byBSRkMgWFhYWCBmb3IgZGV0YWls cyBvbiBzcGVjaWZpYyBjb25jZXJucy9pc3N1ZXMvZXRjIGlzIGZpbmUuIFdlIHdvdWxkbuKAmXQg YmUgYWJsZSB0byBvcGVyYXRlIGlmIGV2ZXJ5IFJGQyBoYWQgdG8gYmUgc2VsZi1jb250YWluZWQs IGFuZCBpbmNsdWRlZCBldmVyeXRoaW5nIHJlbGF0ZWQuDQoNCnZlcnkgaGFwcHkgd2UgYWdyZWUg b24gdGhpcyBrZXkgcG9pbnQuDQpCdXQgeW91IHNob3VsZCB0ZWxsIHRoZSByZWFkZXIgd2h5IHlv deKAmXJlIHJlZmVycmluZyBoaW0gdG8gYW4gZXh0ZXJuYWwgZG9jdW1lbnQsIGFuZCB3aGF0IGlu IHBhcnRpY3VsYXIgaGXigJlzIHN1cHBvc2VkIHRvIGZpbmQvbG9vayBmb3IgdGhlcmUuDQoNClN1 cmUsIGJ1dCBpdCBzb3VuZHMgbGlrZSB3ZSBtYXkgZGlmZmVyIG9uIGRldGFpbCBsZXZlbCBuZWVk ZWQgaW4gdGhlIHJlZmVyZW5jZS4NCg0KVG8ganVzdCBzYXkg4oCcdGhpcyBpcyBNUExTLWJhc2Vk LCBzbyB0byBmaWd1cmUgaXTigJlzIHNlY3VyaXR5IHJpc2tzIGdvIHJlYWQgTVBMUyBSRkNz4oCd IElNSE8gaXMgbm90IGdvb2QgZW5vdWdoLiBNYWlubHkgYmVjYXVzZSBJIGRvbuKAmXQgYWdyZWUg dGhhdCAgbm8gbmV3IGV4cG9zdXJlcyBhcmUgaW50cm9kdWNlZC4NCg0KSSBkb24ndCB0aGluayB0 aGlzIGlzIGEgdmFsaWQgc29sdXRpb24gdG8geW91ciBjb25jZXJuLg0KSWYgdGhlIGF1dGhvcnMs IGhvd2V2ZXIsIGJlbGlldmUgdGhpcyAtIHRoZWlyIGFuYWx5c2lzIChwdXQgaW4gdGhlIFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24pIHNob3VsZCBzaG93IHdoeSB0aGVyZSBhcmUgbm8g bmV3IGV4cG9zdXJlcy4gSXQgZG9lc27igJl0IGhhdmUgdG8gYmUgbGVuZ3RoeSAtIGJ1dCBpdCBk b2VzIGhhdmUgdG8gbWFrZSBzZW5zZS4NCg0KVGhpcyBpcyBhIGdvb2Qgc29sdXRpb24gLS0gaW4g b3RoZXIgd29yZHMsIEkgZG8gdGhpbmsgaXQncyBmYWlyIHRvIGFkZCBzb21ldGhpbmcgb24gdGhp cyB0byB0aGUgc2VjdGlvbi4gIEkgc3VzcGVjdCBpdCB3aWxsIGJlIGF0IG1vc3QgdHdvIHNlbnRl bmNlcy4NCg0KTG91DQoNCg0KDQoNCg0KT24gTWFyIDE2LCAyMDIwLCBhdCAxMDoyMiwgTG91IEJl cmdlciA8bGJlcmdlckBsYWJuLm5ldD48bWFpbHRvOmxiZXJnZXJAbGFibi5uZXQ+IHdyb3RlOg0K V2F0c29uLCBVcmksDQp3b3VsZCBhIHJlZmVyZW5jZSB0byBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1kZXRuZXQtc2VjdXJpdHktMDgjc2VjdGlvbi03IGhlbHA/IG5vdGUg dGhhdCBEZXRuZXQgb3BlcmF0ZXMvZXh0ZW5kcyB0aGUgSVAgYW5kIE1QTFMgbGF5ZXJzLiAgSXQg aXMgbm90IGEgc2VydmljZSB0aGF0IHJpZGVzIG9uIGdlbmVyYWwgSVAgb3Igc2VwYXJhdGUgZnJv bSB0aGUgTVBMUyBsYXllcnMuDQpMb3UNCk9uIDMvMTYvMjAyMCAxMDoxOCBBTSwgV2F0c29uIExh ZGQgd3JvdGU6DQoNCk9uIE1vbiwgTWFyIDE2LCAyMDIwLCA3OjAxIEFNIFN0ZXdhcnQgQnJ5YW50 IDxzdGV3YXJ0LmJyeWFudEBnbWFpbC5jb208bWFpbHRvOnN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNv bT4+IHdyb3RlOg0KVGhlIHJlcXVpcmVtZW50IGlzIE5PVCBmb3IgYSBkcmFmdCB0byBwcm92aWRl IHRoZSBzZWN1cml0eSBhbmFseXNpcyBvZiBhbGwgb2YgYWxsIG9mIHRoZSB0ZWNobm9sb2dpZXMg dGhhdCBpdCBjYWxscyB1cC4gSXQgaXMsIEkgYmVsaWV2ZSwgdG8gZGVzY3JpYmUgdGhlIGRlbHRh cyB0aGF0IGFwcGx5IHRvIHRoZSBuZXcgaWRlYS4gQW55dGhpbmcgZWxzZSBhbmQgdGhlIHRleHQg d291bGQgYmUgYSBzZWN1cml0eSBhbmFseXNpcyB3aXRoIGEgc2hvcnQgdGVjaG5vbG9neSBwcmVh bWJsZS4NCg0KV2UgYXJlIGRlc2NyaWJpbmcgYSB0ZWNobm9sb2d5IHRoYXQgaXMgb3ZlcmxhaWQg b24gTVBMUy4gV2Ugc2hvdWxkIG5vdCBuZWVkIHRvIGRlc2NyaWJlIHRoZSBzZWN1cml0eSBtb2Rl bCBvZiBNUExTLCAgYnV0IGluc3RlYWQgY29uZmluZSBvdXIgcmVtYXJrcyB0byBpc3N1ZXMgdGhh dCBzcGVjaWZpY2FsbHkgYXBwbHkgdG8gdGhlIGFkZGl0aW9uYWwgdGVjaG5vbG9neSB3ZSBhcmUg ZGVzY3JpYmluZy4NCg0KUkZDIDM1NTIgcmVxdWlyZXMgdGhhdCBpbiBhIGNhc2Ugc3VjaCBhcyB0 aGlzIHlvdSBleHBsaWNpdGx5IGRlc2NyaWJlIHdoYXQgdGhlIGxvd2VyIGxheWVyIGlzIHByb3Zp ZGluZyB0byB0aGUgdG9wIGxheWVyLiBSRkMgMzU1MiBzZWN0aW9uIDUgYWxzbyBkZW1hbmRzIHRo YXQgYXR0YWNrcyBiZSBlbnVtZXJhdGVkIGFuZCB0aG9zZSBvdXQgb2Ygc2NvcGUgYmUgY2FsbGVk IG91dC4NCg0KRS5nICJ1c2UgVExTIiBpc24ndCBnb29kIGVub3VnaCBhbmQgaW1obyBuZWl0aGVy IGlzICJ1c2UgTVBMUyIuDQoNCkFnYWluLCB0aGUgc2VudGVuY2VzIGluIHRoZSBzZWN1cml0eSBj b25zaWRlcmF0aW9ucyBhcyBpdCBzdGFuZHMgYXJlIGFib3V0IE1QTFMgYW5kIERldG5ldCwgYW5k IHRoZXkgZG9uJ3Qgc2VlbSB0byBjb21lIHRvZ2V0aGVyLiBBcmUgdGhlcmUgcmVhbGx5IG5vIHNl Y3VyaXR5IGNvbnNpZGVyYXRpb25zIHdoZW4gcHV0dGluZyB0aGUgdHdvIHRvZ2V0aGVyPyBFdmVy eSBNUExTIG5ldHdvcmsgd2lsbCBqdXN0IHdvcmsgd2l0aCBEZXRuZXQgb24gdG9wLCBubyBtYXR0 ZXIgaG93IHJ1c2hlZCB0aGUgZGVwbG95IGlzPw0KDQoNCkVhcmx5IGluIHRoZSBkb2N1bWVudCB3 ZSBjYWxsIHVwIFJGQzMwMzEgYW5kIFJGQzMwMzIsIHRoZSBmdW5kYW1lbnRhbCBNUExTIFJGQ3Mu IFRoZXkgYXJlIGluIHNlY3Rpb24gMy4xIHRoZSBmaXJzdCBwYXJ0IG9mIHRoZSBzZXJpb3VzIHRl Y2huaWNhbCBkaXNjdXNzaW9uLiBJbiBteSB2aWV3IHRoZXNlIGVzdGFibGlzaCBhIGJhc2VsaW5l IG9mIHVuZGVyc3RhbmQgdGhhdCB0aGUgcmVhZGVyIGlzIGV4cGVjdGVkIHRvIGhhdmUuDQoNCkl0 IGlzIGltcG9ydGFudCB0byByZWFsaXNlLCBhcyBJIGhhdmUgc2FpZCBiZWZvcmUsIHRoYXQgd2l0 aG91dCB1bmRlcnN0YW5kaW5nIHRoYXQgYmFzZWxpbmUgdGhlIHJlc3Qgb2YgdGhlIGRvY3VtZW50 IGlzIG1lYW5pbmdsZXNzLg0KDQpSZWdhcmRzDQoNClN0ZXdhcnQNCg0KQlRXDQoNCkl0IG1pZ2h0 IGJlIGFzIHdlbGwgaWYgeW91IHJlZnJhaW5lZCBmcm9tIGlsbHVzdHJhdGluZyB0aGUgbGFjayBv ZiBwcm9mZXNzaW9uYWxpc20gdGhhdCB0aGUgc2VjdXJpdHkgYXJlYSBhcHBsaWVzIHRvIGl0cyBy ZXZpZXdzIGJ5IGNvbnRpbnVpbmcgd2l0aCB0aGUgZmxpcHBhbmN5LiBUaGVyZSBpcyBhIHNlcmlv dXMgcG9pbnQgdGhhdCBuZWVkcyB0byBiZSBkZWJhdGVkIGhlcmUgYWJvdXQgd2hhdCBhc3N1bXB0 aW9ucyBhcmUgYSBnaXZlbiBhbmQgd2hhdCBhc3N1bXB0aW9ucyBuZWVkIHRvIGJlIHNwZWxsZWQg b3V0IHdoZW4gbW9kaWZ5aW5nIG9yIGxheWVyaW5nIGEgdGVjaG5vbG9neS4NCg0KDQo+IE9uIDE2 IE1hciAyMDIwLCBhdCAxMjoyMiwgVXJpIEJsdW1lbnRoYWwgPHVyaUBtaXQuZWR1PG1haWx0bzp1 cmlAbWl0LmVkdT4+IHdyb3RlOg0KPg0KPiBJRVRGIHBvc2l0aW9uIChhZGQgZmF0IGFzIEkgcmVt ZW1iZXIpIHJlZ2FyZGluZyBSRkNzIGhhcyBiZWVuIHRoYXQgUkZDcyBzaG91bGQgcHJvdmlkZSB3 aXRoIGV2ZXJ5dGhpbmcgaW5mb3JtYXRpb24gZm9yIGEgcmVhc29uYWJsZSBkZXZlbG9wZXIgdG8g aW1wbGVtZW50IGNvcnJlY3RseSBhbmQgc2VjdXJlbHkgdGhlIHN0YW5kYXJkIHRoZXkgZGVmaW5l LCBhbmQgcHJvdmlkZSBlbm91Z2ggaW5mb3JtYXRpb24gZm9yIHRoZSBwZXJzb24gd2hvIHdpbGwg ZGVwbG95IGEgY29tcGxpYW50IGltcGxlbWVudGF0aW9uIHRvIGRvIHRoYXQgY29ycmVjdGx5IGFu ZCBzZWN1cmVseS4NCj4NCj4gT25lIHB1cnBvc2Ugb2YgU2VjdXJpdHkgUmV2aWV3IGlzIHRvIGVu c3VyZSB0aGF0IGEgcGVyc29uIGRvZXNuJ3QgaGF2ZSB0byBiZSBhbiBleHBlcnQgaW4gdGhlIGZp ZWxkIHRvIGRlYWwgd2l0aCB0aGUgcHJvcG9zZWQgZG9jdW1lbnQuDQo+DQo+IEluIGEgZmxpcHBh bnQgd2F5LCBpZiB1c2luZyB5b3VyIHN0dWZmIGlzIHJlcXVpcmVzIHNwZWNpYWwgY2xhc3NlcyAt IHBlcmhhcHMgaXQgYmVsb25ncyB0byBhIGJvb2sgcmF0aGVyIHRoYW4gYW4gUkZDLg0KPg0KPiBJ biBhIG5vbi1mbGlwcGFudCB3YXkgLSB3aGF0J3MgdGhlIHByb2JsZW0gaW4gbWVudGlvbmluZyB0 aGUgaXNzdWVzIGFuZCBwcm92aWRpbmcgdGhlIGFwcHJvcHJpYXRlIHJlZmVyZW5jZXM/IEEgIm5v cm1hbCIgUkZDIGNhbm5vdCBiZSBzZWxmLWNvbnRhaW5lZCwgYnV0IGl0J3MgdW5yZWFzb25hYmxl IHRvIGVwZWN0IGEgcmVhZGVyIHRvIGp1c3QgImtub3ciIHdoZXJlIGFsbCB0aGUgb21pdHRlZCB0 aGluZ3MgYXJlIGRlc2NyaWJlZC4NCj4NCj4+IE9uIE1hciAxNiwgMjAyMCwgYXQgMDY6MzMsIFN0 ZXdhcnQgQnJ5YW50IDxzdGV3YXJ0LmJyeWFudEBnbWFpbC5jb208bWFpbHRvOnN0ZXdhcnQuYnJ5 YW50QGdtYWlsLmNvbT4+IHdyb3RlOg0KPj4NCj4+IO+7v1VyaSwNCj4+DQo+PiBUaGF0IGlzIGEg cmlkaWN1bG91cyBwb3NpdGlvbiwgYW5kIHlvdSBmbGlwcGFuY3kgZGVtb25zdHJhdGVzIHRoYXQu DQo+Pg0KPj4gVGhpcyB0ZWNobm9sb2d5IGZ1bmRhbWVudGFsbHkgcmVzdHMgb24gTVBMUyBhbmQg aXQgaXMgcmVhc29uYWJsZSB0aGF0IHRoZSByZWFkZXIgb2YgdGhpcyBSRkMgd2lsbCB1bmRlcnN0 YW5kIE1QTFMgYW5kIHRoZSBzZWN1cml0eSBtb2RlbCBpdCB1c2VzIGJlZm9yZSB0aGV5IGltcGxl bWVudCBvciBkZXBsb3kgaXQuIEluZGVlZCBJIGNhbm5vdCB0aGluayBvZiBhbnkgaW1wbGVtZW50 b3Igb3Igb3BlcmF0b3IgdGhhdCB3b3VsZCBub3QgYWxyZWFkeSBoYXZlIHRoYXQga25vd2xlZGdl IGJlZm9yZSB0YWtpbmcgb24gdGhlIHRhc2sgb2YgYnVpbGRpbmcgb3IgcnVubmluZyBETiBvdmVy IE1QTFMuDQo+Pg0KPj4gSWYgU2VjRGlyIHJldmlld3MgYXJlIHRvIHJldGFpbiBhbnkgY3JlZGli aWxpdHkgYXMgZXhwZXJ0IHJldmlld3MgYXMgb3Bwb3NlZCB0byBHZW5hcnQgcmFuZG9tIHJlYWRl ciByZXZpZXdzIHRoZXkgaGF2ZSB0byBiZSBjYXJyaWVkIG91dCB3aXRoIHNoYXJlZCBrbm93bGVk Z2Ugb2YgYm90aCB0aGUgc2VjdXJpdHkgYXJlYSBhbmQgdGhlIGRyYWZ04oCZcyBob3N0IGFyZWEu DQo+Pg0KPj4gSSBoYXZlIGJlZW4gdGhpbmtpbmcgZm9yIHNvbWUgdGltZSB0aGF0IHRoZXJlIG5l ZWRzIHRvIGJlIGEgZnVuZGFtZW50YWwgcmV2aWV3IG9mIHRoZSBzZWN1cml0eSByZXZpZXcgcHJv Y2Vzcy4NCj4+DQo+PiBTdGV3YXJ0DQo+Pg0KPj4+IE9uIDE1IE1hciAyMDIwLCBhdCAyMjo0NCwg VXJpIEJsdW1lbnRoYWwgPHVyaUBtaXQuZWR1PG1haWx0bzp1cmlAbWl0LmVkdT4+IHdyb3RlOg0K Pj4+DQo+Pj4gSSBzYXkgeWVzIC0gdW5sZXNzIHlvdSBleHBlY3QgYSBwZXJzb24gd2hvIHdhbnRz IGp1c3Qgb25lIFJGQyB0byBoYXZlIHRvIHJlYWQgZXZlcnkgY3JeaF5oIHN0dWZmIHRoYXQgY2Ft ZSBvdXQgb2YgdGhlIHJvdXRpbmcgYXJlYS4NCj4+Pg0KPj4+ICJKdXN0IGRvIGl0Ig0KPj4+DQo+ Pj4NCj4+Pj4+IE9uIE1hciAxNSwgMjAyMCwgYXQgMTc6MzksIExvdSBCZXJnZXIgPGxiZXJnZXJA bGFibi5uZXQ8bWFpbHRvOmxiZXJnZXJAbGFibi5uZXQ+PiB3cm90ZToNCj4+Pj4NCj4+Pj4g77u/ DQo+Pj4+PiBPbiAzLzE1LzIwMjAgNToyMiBQTSwgV2F0c29uIExhZGQgd3JvdGU6DQo+Pj4+Pj4g T24gU3VuLCBNYXIgMTUsIDIwMjAgYXQgMjoxNCBQTSBMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4u bmV0PG1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0Pj4gd3JvdGU6DQo+Pj4+Pj4gSGkgV2F0c29uLA0K Pj4+Pj4+DQo+Pj4+Pj4gICBJIHRoaW5rIFN0ZXdhcnQncyByZXNwb25zZSByZWFsbHkgY292ZXJz IHRoZSBtYWluIHBvaW50cy4gRGV0TmV0IGlzDQo+Pj4+Pj4gcmVhbGx5IGp1c3QgTVBMUyAoYW5k IElQKSB3aXRoIHNvbWUgc3BlY2lmaWMgZm9yd2FyZGluZyBiZWhhdmlvcnMgYW5kDQo+Pj4+Pj4g cXVldWluZy4gIFRoZSBvbmx5IHRoaW5nIEknZCBhZGQsIGlzIEkgc2VlIERldE5ldCBpbiBnZW5l cmFsIGFzIGENCj4+Pj4+PiBzcGVjaWZpYyBmb3JtIG9mIHBvbGljeSBiYXNlZCByb3V0aW5nLiAo VGhlIGdlbmVyYWwgZm9ybSBvZiB3aGljaCBpcw0KPj4+Pj4+IHByZXR0eSBtdWNoIGFzIG9sZCBh cyBJUCkuDQo+Pj4+PiBUaGVuIFN0ZXdhcnQgY2FuIHB1dCB0aG9zZSBwb2ludHMgaW4gdGhlIHNl Y3VyaXR5IGNvbnNpZGVyYXRpb25zDQo+Pj4+PiBzZWN0aW9uLiBXaGF0J3MgdGhlIGRpc2FkdmFu dGFnZSBvZiBkb2luZyBzbz8NCj4+Pj4NCj4+Pj4gQXQgb25lIGxldmVsLCBpdCB3b3VsZCBiZSBl YXNpZXN0IGZvciB0aGUgYXV0aG9ycyB0byBqdXN0IHB1dCB0aGVzZSBpbi4gIE9uIHRoZSBvdGhl ciBoYW5kLCB0aGlzIHdvdWxkIG1lYW4gdGhhdCBldmVyeSBSRkMgcHJvZHVjZWQgaW4gdGhlIHJv dXRpbmcgYXJlYSB3aWxsIGFjcXVpcmUgc2ltaWxhciBub3RlcywgZS5nLiwgcm91dGluZyBwcm90 b2NvbHMgYXJlIGN1cnJlbnRseSBidWlsdCB3aXRoIGEgY2hhaW4gb2YgdHJ1c3QgbW9kZWwuICBJ cyB0aGlzIHdoYXQgdGhlIHNlYy1kaXIgcmVhbGx5IGlzIGFza2luZyB0aGUgcm91dGluZyBhcmVh IHRvIGRvPw0KPj4+Pg0KPj4+PiBBRHMsDQo+Pj4+DQo+Pj4+ICBhbnkgb3BpbmlvbiBvbiB0aGlz PyAgICAgKGZvciBjb250ZXh0LCBTdGV3YXJ0J3MgcmVzcG9uc2UgY2FuIGJlIGZvdW5kIGF0OiBo dHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2RldG5ldC8tZXBMNUZiNmJGSVVs dE1yakg1M0MyMzE2WkEvKQ0KPj4+Pg0KPj4+PiBUaGFua3MsDQo+Pj4+DQo+Pj4+IExvdQ0KPj4+ Pg0KPj4+Pj4+IExvdQ0KPj4+Pj4+DQo+Pj4+Pj4gT24gMy8xMi8yMDIwIDk6MzUgUE0sIFdhdHNv biBMYWRkIHdyb3RlOg0KPj4+Pj4+PiBPbiBUaHUsIE1hciAxMiwgMjAyMCBhdCA0OjA3IEFNIExv dSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ8bWFpbHRvOmxiZXJnZXJAbGFibi5uZXQ+PiB3cm90 ZToNCj4+Pj4+Pj4+IFdhdHNvbiwNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBDYW4geW91IHByb3ZpZGUg Y29udGV4dCBoZXJlPyBDYW4geW91IGJlIGV4cGxpY2l0IG9uIHdoYXQgeW91IHNlZSBuZWVkcyB0 bw0KPj4+Pj4+Pj4gYmUgYWRkcmVzc2VkIChiZXlvbmQgd2hhdCBpcyBpbiB0aGlzIGRvY3VtZW50 IGFzIHdlbGwgYXMgcmVsYXRlZCByZmNzKT8NCj4+Pj4+Pj4gWW91IGhhdmUgdG8gdGFsayBhYm91 dCBob3cgdGhlIGxheWVycyBpbnRlcmFjdCwgYW5kIGNhbid0IGp1c3Qgc2F5IHRoZQ0KPj4+Pj4+ PiBsb3dlciBsZXZlbCBoYW5kbGVzIGFueXRoaW5nIHdpdGhvdXQgYW55IGd1aWRlIGFzIHRvIHdo YXQgbmVlZHMgdG8gYmUNCj4+Pj4+Pj4gcHJvdmlkZWQgYnkgdGhhdCBsb3dlciBsYXllci4NCj4+ Pj4+Pj4NCj4+Pj4+Pj4gSSB0aGluayBteSBjb25jZXJucyBhYm91dCB0aGUgYXNzdW1wdGlvbnMg dGhpcyBjb3VsZCBiZSBmaXhlZCBieQ0KPj4+Pj4+PiBzYXlpbmcuICJBbGwgbm9kZXMgYXJlIHRy dXN0ZWQgYW5kIGFueSBvZiB0aGVtIGNhbiBtaXNiZWhhdmUgaW4gd2F5cw0KPj4+Pj4+PiB0aGF0 IGFmZmVjdCB0aGUgbmV0d29yay4gIElmIHRoZSBNUExTIGxheWVyIGNhbm5vdCBwcm92aWRlIHN1 ZmZpY2llbnQNCj4+Pj4+Pj4gZGV0ZXJtaW5pc20sIHRoZW4gdGhlIERldE5ldCBtZWNoYW5pc21z IHdvbid0IHdvcmsiLiAgSSBhZ3JlZSB3ZQ0KPj4+Pj4+PiBzaG91ZG4ndCByZXF1aXJlIGFuIGVu dGlyZSBtYXNzaXZlIHNlY3VyaXR5IGZyYW1ld29yayB0byBiZSBxdW90ZWQNCj4+Pj4+Pj4gYWdh aW4gaGVyZSwgYnV0IHRoZXJlIG11c3QgYmUgc29tZSBkZXRhaWxzIG9mIHRoaXMgZW1iZWRkaW5n IHRoYXQgYXJlDQo+Pj4+Pj4+IHdvcnRoIG5vdGluZywgYW5kIHlldCBJIGRvbid0IHNlZSB0aGVt IGNhbGxlZCBvdXQgaW4gdGhlIHNlY3VyaXR5DQo+Pj4+Pj4+IGNvbnNpZGVyYXRpb25zIHNlY3Rp b24uDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEFyZSB0aGVyZSByZWFsbHkgbm8gc3BlY2lmaWMgY29uY2Vy bnMgYWJvdXQgdGhlIGludGVyYWN0aW9uIGJldHdlZW4NCj4+Pj4+Pj4gRGV0TmV0IGFuZCBNUExT Pw0KPj4+Pj4+Pg0KPj4+Pj4+Pj4gVGhhbmsgeW91LA0KPj4+Pj4+Pj4gTG91DQo+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4NCj4+Pj4+Pj4+IC0tLS0tLS0tLS0NCj4+Pj4+Pj4+IE9uIE1hcmNoIDExLCAyMDIw IDEwOjMwOjI3IFBNIFdhdHNvbiBMYWRkIDx3YXRzb25ibGFkZEBnbWFpbC5jb208bWFpbHRvOndh dHNvbmJsYWRkQGdtYWlsLmNvbT4+IHdyb3RlOg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBJIGRvbid0 IHNlZSBhbnkgcmVhc29uIHdoeSBSRkMgMzU1MidzIGd1aWRlbGluZXMgc2hvdWRuJ3QgYXBwbHkg dG8gdGhpcyBkcmFmdC4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IElmIHRoZXJlIGlzIGEgTVBMUyBl eGNlcHRpb24gSSdkIGxpa2UgdG8gc2VlIHRoZSBydWxlcyB0aGF0IHNob3VsZCBiZSBhcHBsaWVk Lg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gQXMgaXMgSSBkb24ndCBzZWUgYW55IHJlYXNvbiB3aHkg dGhlIGFzc3VtcHRpb25zIGNhbid0IGJlIGV4cGxpY2l0bHkNCj4+Pj4+Pj4+PiBzcGVsbGVkIG91 dCwgZWl0aGVyIGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBvciBlbHNld2hlcmUuDQo+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4+Pj4+Pj4+IGRldG5ldCBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4+PiBkZXRu ZXRAaWV0Zi5vcmc8bWFpbHRvOmRldG5ldEBpZXRmLm9yZz4NCj4+Pj4+Pj4+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RldG5ldA0KPj4+Pj4+Pj4+DQo+Pj4+Pg0KPj4+ Pj4NCj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+Pj4gc2VjZGlyIG1haWxpbmcgbGlzdA0KPj4+PiBzZWNkaXJAaWV0Zi5vcmc8bWFp bHRvOnNlY2RpckBpZXRmLm9yZz4NCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZWNkaXINCj4+Pj4gd2lraTogaHR0cDovL3Rvb2xzLmlldGYub3JnL2FyZWEvc2Vj L3RyYWMvd2lraS9TZWNEaXJSZXZpZXcNCj4+DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpkZXRuZXQgbWFpbGluZyBsaXN0DQoNCmRldG5l dEBpZXRmLm9yZzxtYWlsdG86ZGV0bmV0QGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2RldG5ldA0KDQpVcmkNCg0KDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KZGV0bmV0IG1haWxpbmcgbGlzdA0K DQpkZXRuZXRAaWV0Zi5vcmc8bWFpbHRvOmRldG5ldEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kZXRuZXQNCg== --_000_MN2PR19MB404529C87F0765CDA8D202D583F60MN2PR19MB4045namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0 O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBk aXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQg Q2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnAu bXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5h bWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6YmxhY2s7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6 YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNv LXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5 OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOiM5OTMzNjY7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9y bWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlz dCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NDk1NzI5MTI2Ow0KCW1z by1saXN0LXRlbXBsYXRlLWlkczotODk4MTkxMTgwO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0K CXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTkzMzY2Ij5IaSBMb3UsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5OTMzNjYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojOTkzMzY2Ij5XZWlnaGluZyBpbiBsYXRlIGluIHRoZSBkaXNjdXNzaW9uIC4u LiB0cnlpbmcgdG8gbWFrZSBhIHBvc2l0aXZlIGNvbnRyaWJ1dGlvbiAuLi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izk5MzM2 NiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0 OyZndDsgSWYgdGhlIGF1dGhvcnMsIGhvd2V2ZXIsIGJlbGlldmUgdGhpcyAtIHRoZWlyIGFuYWx5 c2lzIChwdXQgaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24pIHNob3VsZCBz aG93DQo8dT53aHk8L3U+Jm5ic3A7dGhlcmUgYXJlIG5vIG5ldyBleHBvc3VyZXMuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0OyBJdCBkb2VzbuKAmXQgaGF2ZSB0 byBiZSBsZW5ndGh5IC0gYnV0IGl0IGRvZXMgaGF2ZSB0byBtYWtlIHNlbnNlLg0KPG86cD48L286 cD48L3A+DQo8cD4mZ3Q7IFRoaXMgaXMgYSBnb29kIHNvbHV0aW9uIC0tIGluIG90aGVyIHdvcmRz LCBJIGRvIHRoaW5rIGl0J3MgZmFpciB0byBhZGQgc29tZXRoaW5nIG9uIHRoaXMgdG8gdGhlIHNl Y3Rpb24uJm5ic3A7IEkgc3VzcGVjdCBpdCB3aWxsIGJlIGF0IG1vc3QgdHdvIHNlbnRlbmNlcy4m bmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiM5OTMzNjYiPlR3byBpbXBvcnRhbnQgZGlmZmVyZW5jZXMgYmV0d2VlbiBEZXROZXQg YW5kIE1QTFMgYXJlIHRoYXQgRGV0TmV0IHVzZXMgYSBmcmFjdGlvbiBvZiB0aGUgcmVzb3VyY2Vz IG9mIHRoZSBNUExTIGRhdGEgcGxhbmUgYW5kIERldE5ldCBoYXMgcmF0aGVyIHRpZ2h0IHRpbWlu ZyByZXF1aXJlbWVudHMuJm5ic3A7IEJ5IGNvbXBhcmlzb24gdG8gb3JkaW5hcnkgTVBMUywgdGhh dA0KIGNvbWJpbmF0aW9uIHJlZHVjZXMgdGhlIGVmZm9ydCByZXF1aXJlcyB0byBvdmVyd2hlbG0g dGhlIERldE5ldCBmb3J3YXJkaW5nIHJlc291cmNlcyBhbmQgaW5jcmVhc2VzIHRoZSBhYmlsaXR5 IHRvIGRvIHNlcmlvdXMgZGFtYWdlICh0byBEZXROZXQgc2VydmljZSwgbm90IE1QTFMgb3ZlcmFs bCkgYXQgcmVsYXRpdmVseSBsb3cgbGV2ZWxzIG9mIG92ZXJsb2FkLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTkzMzY2Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6Izk5MzM2NiI+TXkgaW5pdGlhbCBodW5jaCBpcyB0aGF0IFN0ZXdhcnQgaXMg Y29ycmVjdCB0aGF0IE1QTFPigJlzIGV4aXN0aW5nIHJlc2lzdGFuY2UgdG8gZGVuaWFsIG9mIHNl cnZpY2UgYXR0YWNrcyBzdWZmaWNlcyBmb3IgRGV0TmV0IHdpdGhvdXQgYWRkaXRpb25hbCBtZWFz dXJlcywgYnV0IGEgYnJpZWYgZXhwbGFuYXRpb24gb2Ygd2h5IHdvdWxkIGJlIGEgZ29vZCB0aGlu ZyB0bw0KIGFkZCB0byB0aGlzIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTkzMzY2Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiM5OTMzNjYiPlRoYW5rcywgLS1EYXZpZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5OTMzNjYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29s b3I6d2luZG93dGV4dCI+IGRldG5ldCAmbHQ7ZGV0bmV0LWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DQo8 Yj5PbiBCZWhhbGYgT2YgPC9iPkxvdSBCZXJnZXI8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwg TWFyY2ggMTcsIDIwMjAgODo0MCBBTTxicj4NCjxiPlRvOjwvYj4gVXJpIEJsdW1lbnRoYWw8YnI+ DQo8Yj5DYzo8L2I+IHNlY2RpcjsgcnRnLWFkc0BpZXRmLm9yZzsgV2F0c29uIExhZGQ7IGRyYWZ0 LWlldGYtZGV0bmV0LW1wbHMuYWxsQGlldGYub3JnOyBTdGV3YXJ0IEJyeWFudDsgJmx0O3NlYy1h ZHNAaWV0Zi5vcmcmZ3Q7OyBEZXROZXQgV0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEZXRu ZXRdIFtzZWNkaXJdIFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtZGV0bmV0 LW1wbHMtMDU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHA+PHNwYW4gc3R5bGU9 ImNvbG9yOiNDRTExMjYiPltFWFRFUk5BTCBFTUFJTF0gPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8cD5IaSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiAzLzE2LzIwMjAgMzo1NiBQTSwgVXJpIEJsdW1lbnRoYWwgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTWFyIDE2LCAyMDIwLCBhdCAx NDoyOSAsIExvdSBCZXJnZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0Ij5s YmVyZ2VyQGxhYm4ubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0O2ZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczoNCiAgICAgICAgICAgICAgYXV0bzt0ZXh0LWFsaWdu OnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O2JhY2tncm91bmQtY29sb3I6cmdiKDI1NSwNCiAgICAg ICAgICAgICAgMjU1LCAyNTUpO3dvcmQtc3BhY2luZzowcHgiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PklmIGluZGVlZCwgYXMgU3Rld2FydCBzYXlzLCBkZXRuZXQgZG9lcyBub3QgYWRkIGFueSBzZWN1 cml0eSBjb25zaWRlcmF0aW9ucyB0byB0aG9zZSBhbHJlYWR5IGRlc2NyaWJlZCBpbiB0aGUgTVBM UyBkb2N1bWVudHMgLSB0aGUgZHJhZnQgc2hvdWxkDQogc3RhdGUgc28gZXhwbGljaXRseS4gVGhv dWdoIEkgcGVyc29uYWxseSBmaW5kIGl0IGhhcmQgdG8gYmVsaWV2ZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPldo YXQgaXMgYW4gJnF1b3Q7b2J2aW91cyBjb21tb24gc2Vuc2UmcXVvdDsgZm9yIHlvdSBhbmQgU3Rl d2FydCwgbWF5IG5vdCBiZSBzbyBvYnZpb3VzIHRvIG90aGVyIHJlYWRlcnMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5BcyBhIG5vdGUgdG8gb3RoZXJz LCBpdCBpcyBleHBlY3RlZCB0aGF0IFJGQyBhdXRob3JzIGRvIHBlcmZvcm0gYSBjb21wcmVoZW5z aXZlIHNlY3VyaXR5IGFuYWx5c2lzLCBhbmQgZG9jdW1lbnQgdGhlaXIgZmluZGluZ3MgaW4gdGhl IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24uIEkgdGhvdWdodA0KIHRoYXQgd2FzIG9i dmlvdXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQt dmFyaWFudC1jYXBzOg0KICAgICAgICAgICAgICBub3JtYWw7dGV4dC1hbGlnbjpzdGFydDstd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LA0KICAg ICAgICAgICAgICAyNTUsIDI1NSk7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+SSB0aGluayBlaXRoZXIgd2UgYWdyZWUgb3IgdGhhdCB0aGUgd29yZHMgJnF1b3Q7YSBjb21w cmVoZW5zaXZlIHNlY3VyaXR5IGFuYWx5c2lzJnF1b3Q7IGlzIHRoZSBzb3VyY2Ugb2YgYSBkaXNj b25uZWN0LiZuYnNwOyBNeSB2aWV3IGlzIHRoYXQgdGhlIHN1Y2ggYW5hbHlzaXMgaXMgYSAqZGVs dGEqIGFuYWx5c2lzIGZvciBwcmV2aW91cyBJRVRGIHdvcmsvUkZDcy4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5ZZXMsIGl0IHNob3VsZCBiZSBhICpjb21wcmVoZW5zaXZlKiBhbmFseXNpcyBvZiB0 aGUgcG9zc2libGUgc2VjdXJpdHkgaW1wYWN0cyB0aGF0IHRoZSAqY2hhbmdlcyogaW50cm9kdWNl LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J LmUuLCBpbiBnZW5lcmFsLCB3aGVuIHlvdSBhZGQgc29tZSBjYXBhYmlsaXR5LCB5b3UgZGVzY3Jp YmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KV2hhdCB5b3VyIHNl Y3VyaXR5IGFzc3VtcHRpb25zIGFyZSAtIHdoYXQga2luZCBvZiBhY2Nlc3MgeW91IGFzc3VtZSB5 b3VyIGFkdmVyc2FyeSBjYW4gb3IgY2Fubm90IGhhdmUuPG86cD48L286cD48L2xpPjxsaSBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KSG93IHlvdXIgYWRkZWQg Y2FwYWJpbGl0eSBpbXBhY3RzL2NoYW5nZXMgdGhlIGV4aXN0aW5nIHNlY3VyaXR5IHBvc3R1cmUg KGFuZCB3aGF0IHlvdSBhc3N1bWUgdGhhdCBwb3N0dXJlIGlzL3dhcykgLSBuZXcgYXR0YWNrIHN1 cmZhY2UocyksIGV0Yy4mbmJzcDs8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpXaGF0IG9mIHRoZSBuZXdseS1pbnRyb2R1Y2Vk IHN0dWZmIG1heSByZXF1aXJlIHByb3RlY3Rpb24sIGFuZCB3aGF0IGtpbmQgb2YgcHJvdGVjdGlv biAoc2hvdWxkIHN0YXkgc2VjcmV0LCBubyBwcm9ibGVtIGlmIGRpc2Nsb3NlZCBidXQgYSBiaWcg ZGVhbCBpZiBtb2RpZmllZCwgZXRjKS48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpIb3cgeW91IHJlY29tbWVuZCBwcm90ZWN0 aW5nIHRoZSBhYm92ZS48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoZSByZWFkZXIgc2hvdWxkIGxlYXJuIHdoYXQgbmV3IHJlcXVpcmVzIHByb3Rl Y3Rpb24sIGlkZWFsbHkgLSB3aHksIGFuZCBwcm9iYWJseSwgaG93LiBCdXQgKElNSE8pIHNheWlu ZyDigJxqdXN0IHVzZSBUTFPigJ0gaXMgbm90IG5lYXJseSBnb29kIGVub3VnaCAtIGl0IGRvZXNu 4oCZdCB0ZWxsIG1lIHdoYXQgSeKAmW0gdHJ5aW5nIHRvIHByb3RlY3QsIGFuZCB3aHkgKHdoYXQg aGFybSBjb3VsZCBjb21lIGlmIGxlZnQgdW5wcm90ZWN0ZWQpLg0KPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cD5leHBsYWluaW5nIHdoeSBh IHNlY3VyaXR5IG1lY2hhbmlzbSBpcyBuZWVkZWQgc2VlbXMgcmVhc29uYWJsZSB0byBtZS48bzpw PjwvbzpwPjwvcD4NCjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87Y2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZh cmlhbnQtY2FwczoNCiAgICAgICAgICAgICAgbm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7LXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O2JhY2tncm91bmQtY29sb3I6cmdiKDI1NSwNCiAgICAg ICAgICAgICAgMjU1LCAyNTUpO3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PkNlcnRhaW5seSBhdXRob3JzIHNob3VsZCByZWZlcmVuY2UgdGhlIHByaW9yIHdvcmsvUkZDcyB0 aGF0IGFyZSBuZWVkZWQgdG8gdW5kZXJzdGFuZCB0aGUgYW5hbHlzaXMsIGJ1dCB0aGV5IG5lZWQg bm90IChldmVuIHNob3VsZCBub3QpIHJlaGFzaCBhbGwgdGhlIG1hdGVyaWFsIGZvcm0gdGhpcyBl eGlzdGluZyB3b3JrIC0tIG9ubHkNCiB3aGF0IGhhcyBjaGFuZ2VkLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29ycmVj dC4gQlRXLCBieSDigJxyZWZlcmVuY2XigJ0gSSBtZWFuIHN0YXRpbmcgd2hhdCBjb25jZXB0cyBm cm9tIHRob3NlIFJGQ3MgYXBwbHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPHA+c28geW91IHdhbnQgdG8gcmVwZWF0IGFsbCB0aGUgY29uY2VwdHMgZnJvbSBwcmlv ciB3b3JrL3JmY3M/Jm5ic3A7IFRoaXMgbWFrZXMgbGl0dGxlIHNlbnNlIHRvIG1lIGFzIGl0IG1l YW5zIHRoZSBsaWtlbHkgaW50cm9kdWN0aW9uIG9mIGRpZmZlcmVuY2VzIGFuZCBlcnJvcnMgZnJv bSB0aGUgb3JpZ2luYWwgd29yay4mbmJzcDsgUG9pbnRlcnMgdG8gdGhlIHJlbGV2YW50IHdvcmsv c2VjdGlvbnMgc2VlbSByaWdodCB0byBtZSBhcyB0aGUgaW1wbGVtZW50YXRpb25zDQogYXJlIGdv aW5nIHRvIGhhdmUgdG8gc3VwcG9ydCB0aGUgcHJpb3Igd29yayBpbiBhbnkgY2FzZS48bzpwPjwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztjYXJldC1j b2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOg0KICAgICAgICAgICAgICBub3Jt YWw7dGV4dC1hbGlnbjpzdGFydDstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7YmFja2dy b3VuZC1jb2xvcjpyZ2IoMjU1LA0KICAgICAgICAgICAgICAyNTUsIDI1NSk7d29yZC1zcGFjaW5n OjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+RG9lcyB0aGlzIG1hdGNoIHlvdXIgZXhwZWN0YXRp b24gb3IgZG8geW91IGV4cGVjdCBzb21ldGhpbmcgZGlmZmVyZW50PyZuYnNwOyBJZiBzbywgd2hh dCBkbyB5b3UgZXhwZWN0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgaXQgZG9lcywgd2l0aCB0 aGUgYWJvdmUgY2F2ZWF0IDspLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5XZSBtYXkgbml0LWFyZ3VlIGFib3V0IHdoYXQg4oCccmVoYXNoaW5n IGV4aXN0aW5nIHdvcmvigJ0gbWVhbnMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZmVycmluZyB0aGUgcmVhZGVyIHRvIGdvIHRv IFJGQyBYWFhYIGZvciBkZXRhaWxzIG9uIHNwZWNpZmljIGNvbmNlcm5zL2lzc3Vlcy9ldGMgaXMg ZmluZS4gV2Ugd291bGRu4oCZdCBiZSBhYmxlIHRvIG9wZXJhdGUgaWYgZXZlcnkgUkZDIGhhZCB0 byBiZSBzZWxmLWNvbnRhaW5lZCwgYW5kIGluY2x1ZGVkDQo8dT5ldmVyeXRoaW5nPC91PiZuYnNw O3JlbGF0ZWQuIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxwPnZlcnkgaGFwcHkgd2UgYWdyZWUgb24gdGhpcyBrZXkgcG9pbnQuPG86cD48L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0IHlvdSBzaG91bGQgdGVs bCB0aGUgcmVhZGVyIHdoeSB5b3XigJlyZSByZWZlcnJpbmcgaGltIHRvIGFuIGV4dGVybmFsIGRv Y3VtZW50LCBhbmQgd2hhdCBpbiBwYXJ0aWN1bGFyIGhl4oCZcyBzdXBwb3NlZCB0byBmaW5kL2xv b2sgZm9yIHRoZXJlLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPHA+U3VyZSwgYnV0IGl0IHNvdW5kcyBsaWtlIHdlIG1heSBkaWZmZXIgb24gZGV0YWls IGxldmVsIG5lZWRlZCBpbiB0aGUgcmVmZXJlbmNlLjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG8ganVzdCBzYXkg4oCcdGhpcyBpcyBNUExT LWJhc2VkLCBzbyB0byBmaWd1cmUgaXTigJlzIHNlY3VyaXR5IHJpc2tzIGdvIHJlYWQgTVBMUyBS RkNz4oCdIElNSE8gaXMgbm90IGdvb2QgZW5vdWdoLiBNYWlubHkgYmVjYXVzZSBJIGRvbuKAmXQg YWdyZWUgdGhhdCAmbmJzcDtubyBuZXcgZXhwb3N1cmVzIGFyZSBpbnRyb2R1Y2VkLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwPkkgZG9uJ3QgdGhpbmsg dGhpcyBpcyBhIHZhbGlkIHNvbHV0aW9uIHRvIHlvdXIgY29uY2Vybi48bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB0aGUgYXV0aG9ycywgaG93 ZXZlciwgYmVsaWV2ZSB0aGlzIC0gdGhlaXIgYW5hbHlzaXMgKHB1dCBpbiB0aGUgU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMgc2VjdGlvbikgc2hvdWxkIHNob3cNCjx1PndoeTwvdT4mbmJzcDt0aGVy ZSBhcmUgbm8gbmV3IGV4cG9zdXJlcy4gSXQgZG9lc27igJl0IGhhdmUgdG8gYmUgbGVuZ3RoeSAt IGJ1dCBpdCBkb2VzIGhhdmUgdG8gbWFrZSBzZW5zZS4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwPlRoaXMgaXMgYSBnb29kIHNvbHV0aW9uIC0tIGlu IG90aGVyIHdvcmRzLCBJIGRvIHRoaW5rIGl0J3MgZmFpciB0byBhZGQgc29tZXRoaW5nIG9uIHRo aXMgdG8gdGhlIHNlY3Rpb24uJm5ic3A7IEkgc3VzcGVjdCBpdCB3aWxsIGJlIGF0IG1vc3QgdHdv IHNlbnRlbmNlcy4mbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPHA+TG91PG86cD48L286cD48L3A+ DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQt c2l6ZS1hZGp1c3Q6DQogICAgICAgICAgICBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gTWFy IDE2LCAyMDIwLCBhdCAxMDoyMiwgTG91IEJlcmdlcjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86bGJlcmdlckBsYWJuLm5ldCI+ Jmx0O2xiZXJnZXJAbGFibi5uZXQmZ3Q7PC9hPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj53cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5k OndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5XYXRzb24sIFVyaSw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+d291bGQgYSByZWZlcmVuY2UgdG88c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtZGV0bmV0LXNlY3VyaXR5LTA4I3NlY3Rpb24tNyI+aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZGV0bmV0LXNlY3VyaXR5LTA4I3NlY3Rpb24tNzwv YT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+aGVscD8N CiBub3RlIHRoYXQgRGV0bmV0IG9wZXJhdGVzL2V4dGVuZHMgdGhlIElQIGFuZCBNUExTIGxheWVy cy4mbmJzcDsgSXQgaXMgbm90IGEgc2VydmljZSB0aGF0IHJpZGVzIG9uIGdlbmVyYWwgSVAgb3Ig c2VwYXJhdGUgZnJvbSB0aGUgTVBMUyBsYXllcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PkxvdTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIDMvMTYvMjAyMCAx MDoxOCBBTSwgV2F0c29uIExhZGQgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gTW9uLCBNYXIgMTYs IDIwMjAsIDc6MDEgQU0gU3Rld2FydCBCcnlhbnQgJmx0OzxhIGhyZWY9Im1haWx0bzpzdGV3YXJ0 LmJyeWFudEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5zdGV3YXJ0LmJyeWFudEBnbWFpbC5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPlRoZSByZXF1aXJlbWVudCBpcyBOT1QgZm9yIGEgZHJhZnQgdG8gcHJvdmlk ZSB0aGUgc2VjdXJpdHkgYW5hbHlzaXMgb2YgYWxsIG9mIGFsbCBvZiB0aGUgdGVjaG5vbG9naWVz IHRoYXQgaXQgY2FsbHMgdXAuIEl0IGlzLCBJIGJlbGlldmUsIHRvIGRlc2NyaWJlDQogdGhlIGRl bHRhcyB0aGF0IGFwcGx5IHRvIHRoZSBuZXcgaWRlYS4gQW55dGhpbmcgZWxzZSBhbmQgdGhlIHRl eHQgd291bGQgYmUgYSBzZWN1cml0eSBhbmFseXNpcyB3aXRoIGEgc2hvcnQgdGVjaG5vbG9neSBw cmVhbWJsZS48YnI+DQo8YnI+DQpXZSBhcmUgZGVzY3JpYmluZyBhIHRlY2hub2xvZ3kgdGhhdCBp cyBvdmVybGFpZCBvbiBNUExTLiBXZSBzaG91bGQgbm90IG5lZWQgdG8gZGVzY3JpYmUgdGhlIHNl Y3VyaXR5IG1vZGVsIG9mIE1QTFMsJm5ic3A7IGJ1dCBpbnN0ZWFkIGNvbmZpbmUgb3VyIHJlbWFy a3MgdG8gaXNzdWVzIHRoYXQgc3BlY2lmaWNhbGx5IGFwcGx5IHRvIHRoZSBhZGRpdGlvbmFsIHRl Y2hub2xvZ3kgd2UgYXJlIGRlc2NyaWJpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+UkZDIDM1NTIgcmVxdWlyZXMgdGhh dCBpbiBhIGNhc2Ugc3VjaCBhcyB0aGlzIHlvdSBleHBsaWNpdGx5IGRlc2NyaWJlIHdoYXQgdGhl IGxvd2VyIGxheWVyIGlzIHByb3ZpZGluZyB0byB0aGUgdG9wIGxheWVyLiBSRkMgMzU1MiBzZWN0 aW9uIDUgYWxzbw0KIGRlbWFuZHMgdGhhdCBhdHRhY2tzIGJlIGVudW1lcmF0ZWQgYW5kIHRob3Nl IG91dCBvZiBzY29wZSBiZSBjYWxsZWQgb3V0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5FLmcgJnF1b3Q7dXNlIFRMUyZxdW90OyBpc24ndCBnb29kIGVub3VnaCBh bmQgaW1obyBuZWl0aGVyIGlzICZxdW90O3VzZSBNUExTJnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5BZ2FpbiwgdGhlIHNlbnRlbmNlcyBpbiB0aGUgc2Vj dXJpdHkgY29uc2lkZXJhdGlvbnMgYXMgaXQgc3RhbmRzIGFyZSBhYm91dCBNUExTIGFuZCBEZXRu ZXQsIGFuZCB0aGV5IGRvbid0IHNlZW0gdG8gY29tZSB0b2dldGhlci4gQXJlIHRoZXJlIHJlYWxs eQ0KIG5vIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHdoZW4gcHV0dGluZyB0aGUgdHdvIHRvZ2V0 aGVyPyBFdmVyeSBNUExTIG5ldHdvcmsgd2lsbCBqdXN0IHdvcmsgd2l0aCBEZXRuZXQgb24gdG9w LCBubyBtYXR0ZXIgaG93IHJ1c2hlZCB0aGUgZGVwbG95IGlzPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPjxicj4NCkVhcmx5IGluIHRoZSBkb2N1bWVudCB3ZSBjYWxsIHVwIFJGQzMwMzEgYW5k IFJGQzMwMzIsIHRoZSBmdW5kYW1lbnRhbCBNUExTIFJGQ3MuIFRoZXkgYXJlIGluIHNlY3Rpb24g My4xIHRoZSBmaXJzdCBwYXJ0IG9mIHRoZSBzZXJpb3VzIHRlY2huaWNhbCBkaXNjdXNzaW9uLiBJ biBteSB2aWV3IHRoZXNlIGVzdGFibGlzaCBhIGJhc2VsaW5lIG9mIHVuZGVyc3RhbmQgdGhhdCB0 aGUgcmVhZGVyIGlzIGV4cGVjdGVkIHRvIGhhdmUuPGJyPg0KPGJyPg0KSXQgaXMgaW1wb3J0YW50 IHRvIHJlYWxpc2UsIGFzIEkgaGF2ZSBzYWlkIGJlZm9yZSwgdGhhdCB3aXRob3V0IHVuZGVyc3Rh bmRpbmcgdGhhdCBiYXNlbGluZSB0aGUgcmVzdCBvZiB0aGUgZG9jdW1lbnQgaXMgbWVhbmluZ2xl c3MuPGJyPg0KPGJyPg0KUmVnYXJkczxicj4NCjxicj4NClN0ZXdhcnQ8YnI+DQo8YnI+DQpCVFc8 YnI+DQo8YnI+DQpJdCBtaWdodCBiZSBhcyB3ZWxsIGlmIHlvdSByZWZyYWluZWQgZnJvbSBpbGx1 c3RyYXRpbmcgdGhlIGxhY2sgb2YgcHJvZmVzc2lvbmFsaXNtIHRoYXQgdGhlIHNlY3VyaXR5IGFy ZWEgYXBwbGllcyB0byBpdHMgcmV2aWV3cyBieSBjb250aW51aW5nIHdpdGggdGhlIGZsaXBwYW5j eS4gVGhlcmUgaXMgYSBzZXJpb3VzIHBvaW50IHRoYXQgbmVlZHMgdG8gYmUgZGViYXRlZCBoZXJl IGFib3V0IHdoYXQgYXNzdW1wdGlvbnMgYXJlIGEgZ2l2ZW4gYW5kDQogd2hhdCBhc3N1bXB0aW9u cyBuZWVkIHRvIGJlIHNwZWxsZWQgb3V0IHdoZW4gbW9kaWZ5aW5nIG9yIGxheWVyaW5nIGEgdGVj aG5vbG9neS48YnI+DQo8YnI+DQo8YnI+DQomZ3Q7IE9uIDE2IE1hciAyMDIwLCBhdCAxMjoyMiwg VXJpIEJsdW1lbnRoYWwgJmx0OzxhIGhyZWY9Im1haWx0bzp1cmlAbWl0LmVkdSIgdGFyZ2V0PSJf YmxhbmsiPnVyaUBtaXQuZWR1PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OzxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQomZ3Q7IElFVEYgcG9zaXRp b24gKGFkZCBmYXQgYXMgSSByZW1lbWJlcikgcmVnYXJkaW5nIFJGQ3MgaGFzIGJlZW4gdGhhdCBS RkNzIHNob3VsZCBwcm92aWRlIHdpdGggZXZlcnl0aGluZyBpbmZvcm1hdGlvbiBmb3IgYSByZWFz b25hYmxlIGRldmVsb3BlciB0byBpbXBsZW1lbnQgY29ycmVjdGx5IGFuZCBzZWN1cmVseSB0aGUg c3RhbmRhcmQgdGhleSBkZWZpbmUsIGFuZCBwcm92aWRlIGVub3VnaCBpbmZvcm1hdGlvbiBmb3Ig dGhlIHBlcnNvbiB3aG8gd2lsbA0KIGRlcGxveSBhIGNvbXBsaWFudCBpbXBsZW1lbnRhdGlvbiB0 byBkbyB0aGF0IGNvcnJlY3RseSBhbmQgc2VjdXJlbHkuPGJyPg0KJmd0OzxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQomZ3Q7IE9uZSBwdXJwb3Nl IG9mIFNlY3VyaXR5IFJldmlldyBpcyB0byBlbnN1cmUgdGhhdCBhIHBlcnNvbiBkb2Vzbid0IGhh dmUgdG8gYmUgYW4gZXhwZXJ0IGluIHRoZSBmaWVsZCB0byBkZWFsIHdpdGggdGhlIHByb3Bvc2Vk IGRvY3VtZW50Ljxicj4NCiZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGJyPg0KJmd0OyBJbiBhIGZsaXBwYW50IHdheSwgaWYgdXNpbmcgeW91ciBz dHVmZiBpcyByZXF1aXJlcyBzcGVjaWFsIGNsYXNzZXMgLSBwZXJoYXBzIGl0IGJlbG9uZ3MgdG8g YSBib29rIHJhdGhlciB0aGFuIGFuIFJGQy48YnI+DQomZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZndDsgSW4gYSBub24tZmxpcHBhbnQg d2F5IC0gd2hhdCdzIHRoZSBwcm9ibGVtIGluIG1lbnRpb25pbmcgdGhlIGlzc3VlcyBhbmQgcHJv dmlkaW5nIHRoZSBhcHByb3ByaWF0ZSByZWZlcmVuY2VzPyBBICZxdW90O25vcm1hbCZxdW90OyBS RkMgY2Fubm90IGJlIHNlbGYtY29udGFpbmVkLCBidXQgaXQncyB1bnJlYXNvbmFibGUgdG8gZXBl Y3QgYSByZWFkZXIgdG8ganVzdCAmcXVvdDtrbm93JnF1b3Q7IHdoZXJlIGFsbCB0aGUgb21pdHRl ZCB0aGluZ3MgYXJlIGRlc2NyaWJlZC48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PGJyPg0KJmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YnI+DQomZ3Q7Jmd0OyBPbiBNYXIgMTYsIDIwMjAsIGF0IDA2OjMz LCBTdGV3YXJ0IEJyeWFudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN0ZXdhcnQuYnJ5YW50QGdtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbTwvYT4mZ3Q7IHdy b3RlOjxicj4NCiZndDsmZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjxicj4NCiZndDsmZ3Q7IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+77u/PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj5VcmksPGJyPg0KJmd0OyZndDs8c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KJmd0OyZndDsgVGhhdCBpcyBhIHJp ZGljdWxvdXMgcG9zaXRpb24sIGFuZCB5b3UgZmxpcHBhbmN5IGRlbW9uc3RyYXRlcyB0aGF0Ljxi cj4NCiZndDsmZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxicj4NCiZndDsmZ3Q7IFRoaXMgdGVjaG5vbG9neSBmdW5kYW1lbnRhbGx5IHJlc3RzIG9u IE1QTFMgYW5kIGl0IGlzIHJlYXNvbmFibGUgdGhhdCB0aGUgcmVhZGVyIG9mIHRoaXMgUkZDIHdp bGwgdW5kZXJzdGFuZCBNUExTIGFuZCB0aGUgc2VjdXJpdHkgbW9kZWwgaXQgdXNlcyBiZWZvcmUg dGhleSBpbXBsZW1lbnQgb3IgZGVwbG95IGl0LiBJbmRlZWQgSSBjYW5ub3QgdGhpbmsgb2YgYW55 IGltcGxlbWVudG9yIG9yIG9wZXJhdG9yIHRoYXQgd291bGQgbm90IGFscmVhZHkNCiBoYXZlIHRo YXQga25vd2xlZGdlIGJlZm9yZSB0YWtpbmcgb24gdGhlIHRhc2sgb2YgYnVpbGRpbmcgb3IgcnVu bmluZyBETiBvdmVyIE1QTFMuPGJyPg0KJmd0OyZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KJmd0OyZndDsgSWYgU2VjRGlyIHJldmlld3Mg YXJlIHRvIHJldGFpbiBhbnkgY3JlZGliaWxpdHkgYXMgZXhwZXJ0IHJldmlld3MgYXMgb3Bwb3Nl ZCB0byBHZW5hcnQgcmFuZG9tIHJlYWRlciByZXZpZXdzIHRoZXkgaGF2ZSB0byBiZSBjYXJyaWVk IG91dCB3aXRoIHNoYXJlZCBrbm93bGVkZ2Ugb2YgYm90aCB0aGUgc2VjdXJpdHkgYXJlYSBhbmQg dGhlIGRyYWZ04oCZcyBob3N0IGFyZWEuPGJyPg0KJmd0OyZndDs8c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KJmd0OyZndDsgSSBoYXZlIGJlZW4g dGhpbmtpbmcgZm9yIHNvbWUgdGltZSB0aGF0IHRoZXJlIG5lZWRzIHRvIGJlIGEgZnVuZGFtZW50 YWwgcmV2aWV3IG9mIHRoZSBzZWN1cml0eSByZXZpZXcgcHJvY2Vzcy48YnI+DQomZ3Q7Jmd0Ozxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQomZ3Q7 Jmd0OyBTdGV3YXJ0PGJyPg0KJmd0OyZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KJmd0OyZndDsmZ3Q7IE9uIDE1IE1hciAyMDIwLCBhdCAy Mjo0NCwgVXJpIEJsdW1lbnRoYWwgJmx0OzxhIGhyZWY9Im1haWx0bzp1cmlAbWl0LmVkdSIgdGFy Z2V0PSJfYmxhbmsiPnVyaUBtaXQuZWR1PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7 PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZn dDsmZ3Q7Jmd0OyBJIHNheSB5ZXMgLSB1bmxlc3MgeW91IGV4cGVjdCBhIHBlcnNvbiB3aG8gd2Fu dHMganVzdCBvbmUgUkZDIHRvIGhhdmUgdG8gcmVhZCBldmVyeSBjcl5oXmggc3R1ZmYgdGhhdCBj YW1lIG91dCBvZiB0aGUgcm91dGluZyBhcmVhLjxicj4NCiZndDsmZ3Q7Jmd0OzxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQomZ3Q7Jmd0OyZndDsg JnF1b3Q7SnVzdCBkbyBpdCZxdW90Ozxicj4NCiZndDsmZ3Q7Jmd0OzxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQomZ3Q7Jmd0OyZndDs8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsgT24gTWFyIDE1LCAyMDIwLCBhdCAxNzozOSwgTG91IEJlcmdlciAmbHQ7PGEg aHJlZj0ibWFpbHRvOmxiZXJnZXJAbGFibi5uZXQiIHRhcmdldD0iX2JsYW5rIj5sYmVyZ2VyQGxh Ym4ubmV0PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OzxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+77u/PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiAzLzE1LzIwMjAgNToyMiBQTSwgV2F0c29uIExhZGQg d3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIFN1biwgTWFyIDE1LCAyMDIw IGF0IDI6MTQgUE0gTG91IEJlcmdlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxiZXJnZXJAbGFibi5u ZXQiIHRhcmdldD0iX2JsYW5rIj5sYmVyZ2VyQGxhYm4ubmV0PC9hPiZndDsgd3JvdGU6PGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEhpIFdhdHNvbiw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwO0kgdGhpbmsgU3Rld2Fy dCdzIHJlc3BvbnNlIHJlYWxseSBjb3ZlcnMgdGhlIG1haW4gcG9pbnRzLiBEZXROZXQgaXM8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVhbGx5IGp1c3QgTVBMUyAoYW5kIElQKSB3aXRo IHNvbWUgc3BlY2lmaWMgZm9yd2FyZGluZyBiZWhhdmlvcnMgYW5kPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IHF1ZXVpbmcuJm5ic3A7IFRoZSBvbmx5IHRoaW5nIEknZCBhZGQsIGlzIEkg c2VlIERldE5ldCBpbiBnZW5lcmFsIGFzIGE8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg c3BlY2lmaWMgZm9ybSBvZiBwb2xpY3kgYmFzZWQgcm91dGluZy4gKFRoZSBnZW5lcmFsIGZvcm0g b2Ygd2hpY2ggaXM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcHJldHR5IG11Y2ggYXMg b2xkIGFzIElQKS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGVuIFN0ZXdhcnQgY2FuIHB1 dCB0aG9zZSBwb2ludHMgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgc2VjdGlvbi4gV2hhdCdzIHRoZSBkaXNhZHZhbnRhZ2Ugb2YgZG9pbmcg c28/PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEF0IG9uZSBsZXZlbCwgaXQg d291bGQgYmUgZWFzaWVzdCBmb3IgdGhlIGF1dGhvcnMgdG8ganVzdCBwdXQgdGhlc2UgaW4uJm5i c3A7IE9uIHRoZSBvdGhlciBoYW5kLCB0aGlzIHdvdWxkIG1lYW4gdGhhdCBldmVyeSBSRkMgcHJv ZHVjZWQgaW4gdGhlIHJvdXRpbmcgYXJlYSB3aWxsIGFjcXVpcmUgc2ltaWxhciBub3RlcywgZS5n Liwgcm91dGluZyBwcm90b2NvbHMgYXJlIGN1cnJlbnRseSBidWlsdCB3aXRoIGEgY2hhaW4gb2Yg dHJ1c3QgbW9kZWwuJm5ic3A7DQogSXMgdGhpcyB3aGF0IHRoZSBzZWMtZGlyIHJlYWxseSBpcyBh c2tpbmcgdGhlIHJvdXRpbmcgYXJlYSB0byBkbz88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsgQURzLDxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyBh bnkgb3BpbmlvbiBvbiB0aGlzPyZuYnNwOyAmbmJzcDsgJm5ic3A7KGZvciBjb250ZXh0LCBTdGV3 YXJ0J3MgcmVzcG9uc2UgY2FuIGJlIGZvdW5kIGF0OjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYu b3JnL2FyY2gvbXNnL2RldG5ldC8tZXBMNUZiNmJGSVVsdE1yakg1M0MyMzE2WkEvIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9kZXRuZXQvLWVw TDVGYjZiRklVbHRNcmpINTNDMjMxNlpBLzwvYT4pPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OzxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgTG91 PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgTG91PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiAzLzEyLzIwMjAg OTozNSBQTSwgV2F0c29uIExhZGQgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBPbiBUaHUsIE1hciAxMiwgMjAyMCBhdCA0OjA3IEFNIExvdSBCZXJnZXIgJmx0OzxhIGhy ZWY9Im1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0IiB0YXJnZXQ9Il9ibGFuayI+bGJlcmdlckBsYWJu Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IFdhdHNvbiw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBDYW4geW91IHByb3ZpZGUgY29udGV4dCBoZXJlPyBDYW4geW91 IGJlIGV4cGxpY2l0IG9uIHdoYXQgeW91IHNlZSBuZWVkcyB0bzxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGJlIGFkZHJlc3NlZCAoYmV5b25kIHdoYXQgaXMgaW4gdGhpcyBk b2N1bWVudCBhcyB3ZWxsIGFzIHJlbGF0ZWQgcmZjcyk/PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBZb3UgaGF2ZSB0byB0YWxrIGFib3V0IGhvdyB0aGUgbGF5ZXJzIGludGVyYWN0 LCBhbmQgY2FuJ3QganVzdCBzYXkgdGhlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBsb3dlciBsZXZlbCBoYW5kbGVzIGFueXRoaW5nIHdpdGhvdXQgYW55IGd1aWRlIGFzIHRvIHdo YXQgbmVlZHMgdG8gYmU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHByb3ZpZGVk IGJ5IHRoYXQgbG93ZXIgbGF5ZXIuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgdGhpbmsgbXkgY29uY2VybnMgYWJvdXQgdGhlIGFz c3VtcHRpb25zIHRoaXMgY291bGQgYmUgZml4ZWQgYnk8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IHNheWluZy4gJnF1b3Q7QWxsIG5vZGVzIGFyZSB0cnVzdGVkIGFuZCBhbnkgb2Yg dGhlbSBjYW4gbWlzYmVoYXZlIGluIHdheXM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IHRoYXQgYWZmZWN0IHRoZSBuZXR3b3JrLiZuYnNwOyBJZiB0aGUgTVBMUyBsYXllciBjYW5u b3QgcHJvdmlkZSBzdWZmaWNpZW50PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBk ZXRlcm1pbmlzbSwgdGhlbiB0aGUgRGV0TmV0IG1lY2hhbmlzbXMgd29uJ3Qgd29yayZxdW90Oy4m bmJzcDsgSSBhZ3JlZSB3ZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2hvdWRu J3QgcmVxdWlyZSBhbiBlbnRpcmUgbWFzc2l2ZSBzZWN1cml0eSBmcmFtZXdvcmsgdG8gYmUgcXVv dGVkPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhZ2FpbiBoZXJlLCBidXQgdGhl cmUgbXVzdCBiZSBzb21lIGRldGFpbHMgb2YgdGhpcyBlbWJlZGRpbmcgdGhhdCBhcmU8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdvcnRoIG5vdGluZywgYW5kIHlldCBJIGRvbid0 IHNlZSB0aGVtIGNhbGxlZCBvdXQgaW4gdGhlIHNlY3VyaXR5PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBjb25zaWRlcmF0aW9ucyBzZWN0aW9uLjxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBcmUgdGhlcmUgcmVhbGx5 IG5vIHNwZWNpZmljIGNvbmNlcm5zIGFib3V0IHRoZSBpbnRlcmFjdGlvbiBiZXR3ZWVuPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBEZXROZXQgYW5kIE1QTFM/PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGFu ayB5b3UsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgTG91PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS0tLS0tLS0tLTxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIE1hcmNoIDExLCAyMDIwIDEwOjMwOjI3IFBNIFdh dHNvbiBMYWRkICZsdDs8YSBocmVmPSJtYWlsdG86d2F0c29uYmxhZGRAZ21haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayI+d2F0c29uYmxhZGRAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IEkgZG9uJ3Qgc2VlIGFueSByZWFzb24gd2h5IFJGQyAzNTUyJ3MgZ3VpZGVsaW5lcyBz aG91ZG4ndCBhcHBseSB0byB0aGlzIGRyYWZ0Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSWYgdGhlcmUg aXMgYSBNUExTIGV4Y2VwdGlvbiBJJ2QgbGlrZSB0byBzZWUgdGhlIHJ1bGVzIHRoYXQgc2hvdWxk IGJlIGFwcGxpZWQuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBcyBpcyBJIGRvbid0IHNlZSBhbnkgcmVh c29uIHdoeSB0aGUgYXNzdW1wdGlvbnMgY2FuJ3QgYmUgZXhwbGljaXRseTxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzcGVsbGVkIG91dCwgZWl0aGVyIGluIHRoZSBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucyBvciBlbHNld2hlcmUuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkZXRuZXQgbWFpbGluZyBsaXN0PGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkZXRuZXRAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5kZXRuZXRAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZGV0bmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9kZXRuZXQ8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgc2VjZGlyIG1haWxpbmcgbGlzdDxicj4NCiZndDsm Z3Q7Jmd0OyZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PGEgaHJlZj0ibWFpbHRvOnNlY2RpckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNlY2Rp ckBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2VjZGlyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZWNkaXI8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyB3 aWtpOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBo cmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvYXJlYS9zZWMvdHJhYy93aWtpL1NlY0RpclJldmll dyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9hcmVhL3NlYy90cmFjL3dp a2kvU2VjRGlyUmV2aWV3PC9hPjxicj4NCiZndDsmZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPmRldG5ldCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGEgaHJlZj0ibWFpbHRvOmRldG5ldEBpZXRm Lm9yZyI+ZGV0bmV0QGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2RldG5ldCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kZXRu ZXQ8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlVyaTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9wPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmRldG5ldCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86ZGV0bmV0QGlldGYub3JnIj5kZXRuZXRAaWV0Zi5v cmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9kZXRuZXQiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZGV0bmV0PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MN2PR19MB404529C87F0765CDA8D202D583F60MN2PR19MB4045namp_-- From nobody Tue Mar 17 08:10:54 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 273293A03EB; Tue, 17 Mar 2020 08:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPjUrHWTnJzC; Tue, 17 Mar 2020 08:10:28 -0700 (PDT) Received: from outgoing-exchange-5.mit.edu (outgoing-exchange-5.mit.edu [18.9.28.59]) (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 6D7B13A0402; Tue, 17 Mar 2020 08:10:22 -0700 (PDT) Received: from w92exedge3.exchange.mit.edu (W92EXEDGE3.EXCHANGE.MIT.EDU [18.7.73.15]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id 02HF7Pqe014630; Tue, 17 Mar 2020 11:07:38 -0400 Received: from w92expo31.exchange.mit.edu (18.7.74.43) by w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 17 Mar 2020 11:07:07 -0400 Received: from oc11expo31.exchange.mit.edu (18.9.4.104) by w92expo31.exchange.mit.edu (18.7.74.43) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 17 Mar 2020 11:07:16 -0400 Received: from oc11expo31.exchange.mit.edu ([18.9.4.104]) by oc11expo31.exchange.mit.edu ([18.9.4.104]) with mapi id 15.00.1365.000; Tue, 17 Mar 2020 11:07:16 -0400 From: Uri Blumenthal To: "Black, David" CC: Lou Berger , secdir , "rtg-ads@ietf.org" , Watson Ladd , "draft-ietf-detnet-mpls.all@ietf.org" , Stewart Bryant , "" , DetNet WG Thread-Topic: [Detnet] [secdir] Secdir last call review of draft-ietf-detnet-mpls-05 Thread-Index: AQHV+8DZP29H4cjJ90qNnu6vrG/xK6hL5XQAgAEYY4CAAB2xgIAAC3EA Date: Tue, 17 Mar 2020 15:07:16 +0000 Message-ID: References: <73942657-B55A-431F-AB55-444C3C587AE1@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [24.62.106.45] Content-Type: multipart/signed; boundary="Apple-Mail=_91212AB3-239E-4D11-8BB2-805D4CFF7CBC"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2020 15:10:48 -0000 --Apple-Mail=_91212AB3-239E-4D11-8BB2-805D4CFF7CBC Content-Type: multipart/alternative; boundary="Apple-Mail=_D1A7D0D8-8AD4-4530-81A4-D829B4447A52" --Apple-Mail=_D1A7D0D8-8AD4-4530-81A4-D829B4447A52 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 17, 2020, at 10:26 , Black, David wrote: >=20 > Hi Lou, > =20 > Weighing in late in the discussion ... trying to make a positive = contribution ... Thank you! And please see below. =20 > >> If the authors, however, believe this - their analysis (put in the = Security Considerations section) should show why there are no new = exposures. > >> It doesn=E2=80=99t have to be lengthy - but it does have to make = sense. > > This is a good solution -- in other words, I do think it's fair to = add something on this to the section. I suspect it will be at most two = sentences.=20 >=20 > Two important differences between DetNet and MPLS are that DetNet uses = a fraction of the resources of the MPLS data plane and DetNet has rather = tight timing requirements. By comparison to ordinary MPLS, that = combination reduces the effort requires to overwhelm the DetNet = forwarding resources and increases the ability to do serious damage (to = DetNet service, not MPLS overall) at relatively low levels of overload. This is the kind of analysis/guidance that belongs to the Draft! > My initial hunch is that Stewart is correct that MPLS=E2=80=99s = existing resistance to denial of service attacks suffices for DetNet = without additional measures, but a brief explanation of why would be a = good thing to add to this draft. I do not know if that hunch is correct, but it should be added = regardless. > [EXTERNAL EMAIL]=20 >=20 > Hi, >=20 > Yes, it should be a *comprehensive* analysis of the possible security = impacts that the *changes* introduce. > =20 > I.e., in general, when you add some capability, you describe > What your security assumptions are - what kind of access you assume = your adversary can or cannot have. > How your added capability impacts/changes the existing security = posture (and what you assume that posture is/was) - new attack = surface(s), etc.=20 > What of the newly-introduced stuff may require protection, and what = kind of protection (should stay secret, no problem if disclosed but a = big deal if modified, etc). > How you recommend protecting the above. > =20 > The reader should learn what new requires protection, ideally - why, = and probably, how. But (IMHO) saying =E2=80=9Cjust use TLS=E2=80=9D is = not nearly good enough - it doesn=E2=80=99t tell me what I=E2=80=99m = trying to protect, and why (what harm could come if left unprotected). > explaining why a security mechanism is needed seems reasonable to me. >=20 Thanks! > Certainly authors should reference the prior work/RFCs that are = needed to understand the analysis, but they need not (even should not) = rehash all the material form this existing work -- only what has = changed. >=20 > Correct. BTW, by =E2=80=9Creference=E2=80=9D I mean stating what = concepts from those RFCs apply.=20 > so you want to repeat all the concepts from prior work/rfcs?=20 >=20 Not =E2=80=9Crepeat=E2=80=9D, i.e., not copy text from what the other = RFCs says). Refer to - i.e., =E2=80=9Cfor general MPLS security = consideration see section X of RFC Y." > Pointers to the relevant work/sections seem right to me as the = implementations are going to have to support the prior work in any case. >=20 That=E2=80=99s exactly what I=E2=80=99m suggesting. > Referring the reader to go to RFC XXXX for details on specific = concerns/issues/etc is fine. We wouldn=E2=80=99t be able to operate if = every RFC had to be self-contained, and included everything related.=20 > very happy we agree on this key point. >=20 :-) > But you should tell the reader why you=E2=80=99re referring him to an = external document, and what in particular he=E2=80=99s supposed to = find/look for there. > Sure, but it sounds like we may differ on detail level needed in the = reference. >=20 My main point is that you tell the reader why you refer him to a given = section of a given RFC, and what he should expect to find there. E.g., = =E2=80=9Csee section X of RFC Y for details of the generic MPLS Threat = Model=E2=80=9D. > To just say =E2=80=9Cthis is MPLS-based, so to figure it=E2=80=99s = security risks go read MPLS RFCs=E2=80=9D IMHO is not good enough. = Mainly because I don=E2=80=99t agree that no new exposures are = introduced. > I don't think this is a valid solution to your concern. >=20 > If the authors, however, believe this - their analysis (put in the = Security Considerations section) should show why there are no new = exposures. It doesn=E2=80=99t have to be lengthy - but it does have to = make sense. > This is a good solution -- in other words, I do think it's fair to add = something on this to the section. I suspect it will be at most two = sentences.=20 >=20 I don=E2=80=99t know how many sentences it should take. All I want is = that it is clear and useful (and if it also manages to stay brief - = that=E2=80=99s an extra bonus ;). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > On Mar 16, 2020, at 10:22, Lou Berger = wrote: > Watson, Uri, > would a reference to = https://tools.ietf.org/html/draft-ietf-detnet-security-08#section-7 = = help? note that Detnet operates/extends the IP and MPLS layers. It is = not a service that rides on general IP or separate from the MPLS layers. > Lou > On 3/16/2020 10:18 AM, Watson Ladd wrote: > =20 >=20 > On Mon, Mar 16, 2020, 7:01 AM Stewart Bryant > wrote: > The requirement is NOT for a draft to provide the security analysis of = all of all of the technologies that it calls up. It is, I believe, to = describe the deltas that apply to the new idea. Anything else and the = text would be a security analysis with a short technology preamble. >=20 > We are describing a technology that is overlaid on MPLS. We should not = need to describe the security model of MPLS, but instead confine our = remarks to issues that specifically apply to the additional technology = we are describing. > =20 > RFC 3552 requires that in a case such as this you explicitly describe = what the lower layer is providing to the top layer. RFC 3552 section 5 = also demands that attacks be enumerated and those out of scope be called = out. > =20 > E.g "use TLS" isn't good enough and imho neither is "use MPLS". > =20 > Again, the sentences in the security considerations as it stands are = about MPLS and Detnet, and they don't seem to come together. Are there = really no security considerations when putting the two together? Every = MPLS network will just work with Detnet on top, no matter how rushed the = deploy is? > =20 >=20 > Early in the document we call up RFC3031 and RFC3032, the fundamental = MPLS RFCs. They are in section 3.1 the first part of the serious = technical discussion. In my view these establish a baseline of = understand that the reader is expected to have. >=20 > It is important to realise, as I have said before, that without = understanding that baseline the rest of the document is meaningless. >=20 > Regards >=20 > Stewart >=20 > BTW >=20 > It might be as well if you refrained from illustrating the lack of = professionalism that the security area applies to its reviews by = continuing with the flippancy. There is a serious point that needs to be = debated here about what assumptions are a given and what assumptions = need to be spelled out when modifying or layering a technology. >=20 >=20 > > On 16 Mar 2020, at 12:22, Uri Blumenthal > wrote: > >=20 > > IETF position (add fat as I remember) regarding RFCs has been that = RFCs should provide with everything information for a reasonable = developer to implement correctly and securely the standard they define, = and provide enough information for the person who will deploy a = compliant implementation to do that correctly and securely. > >=20 > > One purpose of Security Review is to ensure that a person doesn't = have to be an expert in the field to deal with the proposed document. > >=20 > > In a flippant way, if using your stuff is requires special classes - = perhaps it belongs to a book rather than an RFC. > >=20 > > In a non-flippant way - what's the problem in mentioning the issues = and providing the appropriate references? A "normal" RFC cannot be = self-contained, but it's unreasonable to epect a reader to just "know" = where all the omitted things are described.=20 > >=20 > >> On Mar 16, 2020, at 06:33, Stewart Bryant > wrote: > >>=20 > >> =EF=BB=BFUri, > >>=20 > >> That is a ridiculous position, and you flippancy demonstrates that. > >>=20 > >> This technology fundamentally rests on MPLS and it is reasonable = that the reader of this RFC will understand MPLS and the security model = it uses before they implement or deploy it. Indeed I cannot think of any = implementor or operator that would not already have that knowledge = before taking on the task of building or running DN over MPLS. > >>=20 > >> If SecDir reviews are to retain any credibility as expert reviews = as opposed to Genart random reader reviews they have to be carried out = with shared knowledge of both the security area and the draft=E2=80=99s = host area. > >>=20 > >> I have been thinking for some time that there needs to be a = fundamental review of the security review process. > >>=20 > >> Stewart > >>=20 > >>> On 15 Mar 2020, at 22:44, Uri Blumenthal > wrote: > >>>=20 > >>> I say yes - unless you expect a person who wants just one RFC to = have to read every cr^h^h stuff that came out of the routing area. > >>>=20 > >>> "Just do it" > >>>=20 > >>>=20 > >>>>> On Mar 15, 2020, at 17:39, Lou Berger > wrote: > >>>>=20 > >>>> =EF=BB=BF > >>>>> On 3/15/2020 5:22 PM, Watson Ladd wrote: > >>>>>> On Sun, Mar 15, 2020 at 2:14 PM Lou Berger > wrote: > >>>>>> Hi Watson, > >>>>>>=20 > >>>>>> I think Stewart's response really covers the main points. = DetNet is > >>>>>> really just MPLS (and IP) with some specific forwarding = behaviors and > >>>>>> queuing. The only thing I'd add, is I see DetNet in general as = a > >>>>>> specific form of policy based routing. (The general form of = which is > >>>>>> pretty much as old as IP). > >>>>> Then Stewart can put those points in the security considerations > >>>>> section. What's the disadvantage of doing so? > >>>>=20 > >>>> At one level, it would be easiest for the authors to just put = these in. On the other hand, this would mean that every RFC produced in = the routing area will acquire similar notes, e.g., routing protocols are = currently built with a chain of trust model. Is this what the sec-dir = really is asking the routing area to do? > >>>>=20 > >>>> ADs, > >>>>=20 > >>>> any opinion on this? (for context, Stewart's response can be = found at: = https://mailarchive.ietf.org/arch/msg/detnet/-epL5Fb6bFIUltMrjH53C2316ZA/ = ) > >>>>=20 > >>>> Thanks, > >>>>=20 > >>>> Lou > >>>>=20 > >>>>>> Lou > >>>>>>=20 > >>>>>> On 3/12/2020 9:35 PM, Watson Ladd wrote: > >>>>>>> On Thu, Mar 12, 2020 at 4:07 AM Lou Berger > wrote: > >>>>>>>> Watson, > >>>>>>>>=20 > >>>>>>>> Can you provide context here? Can you be explicit on what you = see needs to > >>>>>>>> be addressed (beyond what is in this document as well as = related rfcs)? > >>>>>>> You have to talk about how the layers interact, and can't just = say the > >>>>>>> lower level handles anything without any guide as to what = needs to be > >>>>>>> provided by that lower layer. > >>>>>>>=20 > >>>>>>> I think my concerns about the assumptions this could be fixed = by > >>>>>>> saying. "All nodes are trusted and any of them can misbehave = in ways > >>>>>>> that affect the network. If the MPLS layer cannot provide = sufficient > >>>>>>> determinism, then the DetNet mechanisms won't work". I agree = we > >>>>>>> shoudn't require an entire massive security framework to be = quoted > >>>>>>> again here, but there must be some details of this embedding = that are > >>>>>>> worth noting, and yet I don't see them called out in the = security > >>>>>>> considerations section. > >>>>>>>=20 > >>>>>>> Are there really no specific concerns about the interaction = between > >>>>>>> DetNet and MPLS? > >>>>>>>=20 > >>>>>>>> Thank you, > >>>>>>>> Lou > >>>>>>>>=20 > >>>>>>>>=20 > >>>>>>>> ---------- > >>>>>>>> On March 11, 2020 10:30:27 PM Watson Ladd = > wrote: > >>>>>>>>=20 > >>>>>>>>> I don't see any reason why RFC 3552's guidelines shoudn't = apply to this draft. > >>>>>>>>>=20 > >>>>>>>>> If there is a MPLS exception I'd like to see the rules that = should be applied. > >>>>>>>>>=20 > >>>>>>>>> As is I don't see any reason why the assumptions can't be = explicitly > >>>>>>>>> spelled out, either in the Security Considerations or = elsewhere. > >>>>>>>>>=20 > >>>>>>>>> _______________________________________________ > >>>>>>>>> detnet mailing list > >>>>>>>>> detnet@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/detnet = > >>>>>>>>>=20 > >>>>>=20 > >>>>>=20 > >>>>=20 > >>>> _______________________________________________ > >>>> secdir mailing list > >>>> secdir@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/secdir = > >>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview = > >>=20 >=20 >=20 >=20 > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet = > =20 > Uri >=20 >=20 >=20 > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet = Uri --Apple-Mail=_D1A7D0D8-8AD4-4530-81A4-D829B4447A52 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Mar 17, 2020, at 10:26 , Black, David <David.Black@dell.com> wrote:

Hi Lou,
 
Weighing in late in the discussion ... trying to make = a positive contribution = ...

Thank = you! And please see below.
 
>> = If the authors, however, believe this - their analysis (put in the = Security Considerations section) should show why there are no new exposures.
>> = It doesn=E2=80=99t have to be lengthy - but it does have to make = sense.

> This is a good = solution -- in other words, I do think it's fair to add something on = this to the section.  I suspect it will be at most two = sentences. 

Two = important differences between DetNet and MPLS are that DetNet uses a = fraction of the resources of the MPLS data plane and DetNet has rather = tight timing requirements.  By comparison to ordinary MPLS, that = combination reduces the effort requires to overwhelm the DetNet = forwarding resources and increases the ability to do serious damage (to = DetNet service, not MPLS overall) at relatively low levels of = overload.

This is the kind of analysis/guidance that belongs = to the Draft!

My initial hunch is that = Stewart is correct that MPLS=E2=80=99s existing resistance to denial of = service attacks suffices for DetNet without additional measures, but a = brief explanation of why would be a good thing to add to this = draft.

I = do not know if that hunch is correct, but it should be added = regardless.

[EXTERNAL EMAIL] 

Hi,

Yes, it = should be a *comprehensive* analysis of the possible security impacts = that the *changes* introduce.
 
I.e., in general, when you add some capability, you = describe
  • What your security assumptions are - = what kind of access you assume your adversary can or cannot have.
  • How your = added capability impacts/changes the existing security posture (and what = you assume that posture is/was) - new attack surface(s), etc. 
  • What of = the newly-introduced stuff may require protection, and what kind of = protection (should stay secret, no problem if disclosed but a big deal = if modified, etc).
  • How you recommend protecting the above.
 
The reader should learn what new = requires protection, ideally - why, and probably, how. But (IMHO) saying = =E2=80=9Cjust use TLS=E2=80=9D is not nearly good enough - it doesn=E2=80=99= t tell me what I=E2=80=99m trying to protect, and why (what harm could = come if left unprotected).

explaining why a security mechanism is needed seems = reasonable to me.


Thanks!

 Certainly authors = should reference the prior work/RFCs that are needed to understand the = analysis, but they need not (even should not) rehash all the material = form this existing work -- only what has changed.

Correct. BTW, by = =E2=80=9Creference=E2=80=9D I mean stating what concepts from those RFCs = apply. 

so you = want to repeat all the concepts from prior work/rfcs?  =

Not =E2=80=9Crepeat=E2=80=9D, i.e., not = copy text from what the other RFCs says). Refer to = - i.e., =E2=80=9Cfor general MPLS security consideration see section X = of RFC Y."

 Pointers to the relevant work/sections seem right to me = as the implementations are going to have to support the prior work in = any case.

That=E2=80=99s exactly what = I=E2=80=99m suggesting.

Referring the reader to go to RFC XXXX for details on = specific concerns/issues/etc is fine. We wouldn=E2=80=99t be able to = operate if every RFC had to be self-contained, and = included everything related. 

very happy = we agree on this key = point.

:-)

But you should tell the reader why = you=E2=80=99re referring him to an external document, and what in = particular he=E2=80=99s supposed to find/look for there.

Sure, but = it sounds like we may differ on detail level needed in the = reference.

My main point is that you = tell the reader why you refer him to a given = section of a given RFC, and what he should expect to find there. E.g., = =E2=80=9Csee section X of RFC Y for details of the generic MPLS Threat = Model=E2=80=9D.

 To just say =E2=80=9Cthis is = MPLS-based, so to figure it=E2=80=99s security risks go read MPLS = RFCs=E2=80=9D IMHO is not good enough. Mainly because I don=E2=80=99t = agree that  no new exposures are introduced.

I don't = think this is a valid solution to your concern.

If the authors, however, believe this - = their analysis (put in the Security Considerations section) should = show why there are no new exposures. It doesn=E2=80=99t = have to be lengthy - but it does have to make sense.

This is a = good solution -- in other words, I do think it's fair to add something = on this to the section.  I suspect it will be at most two = sentences. 

I don=E2=80=99t know = how many sentences it should take. All I want is that it is clear and = useful (and if it also manages to stay brief - that=E2=80=99s an extra = bonus ;).


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /div>

On Mar 16, 2020, at 10:22, Lou Berger <lberger@labn.net> wrote:
Watson, Uri,
would a reference to https://tools.ietf.org/html/draft-ietf-detnet-security-08#secti= on-7 help? note = that Detnet operates/extends the IP and MPLS layers.  It is not a = service that rides on general IP or separate from the MPLS layers.
Lou
On 3/16/2020 10:18 AM, = Watson Ladd wrote:

 

On Mon, Mar 16, 2020, 7:01 AM Stewart Bryant <stewart.bryant@gmail.com> wrote:
The requirement is NOT for a draft to = provide the security analysis of all of all of the technologies that it = calls up. It is, I believe, to describe the deltas that apply to the new = idea. Anything else and the text would be a security analysis with a = short technology preamble.

We are = describing a technology that is overlaid on MPLS. We should not need to = describe the security model of MPLS,  but instead confine our = remarks to issues that specifically apply to the additional technology = we are describing.
 
RFC 3552 requires that in a case such as this you explicitly = describe what the lower layer is providing to the top layer. RFC 3552 = section 5 also demands that attacks be enumerated and those out of scope = be called out.
 
E.g "use TLS" isn't good enough and imho neither is "use = MPLS".
 
Again, the sentences in the security = considerations as it stands are about MPLS and Detnet, and they don't = seem to come together. Are there really no security considerations when = putting the two together? Every MPLS network will just work with Detnet = on top, no matter how rushed the deploy is?
 


Early in the document we call up RFC3031 and = RFC3032, the fundamental MPLS RFCs. They are in section 3.1 the first = part of the serious technical discussion. In my view these establish a = baseline of understand that the reader is expected to have.

It is important to realise, as I have said = before, that without understanding that baseline the rest of the = document is meaningless.

Regards

Stewart

BTW

It might be as well if you refrained from = illustrating the lack of professionalism that the security area applies = to its reviews by continuing with the flippancy. There is a serious = point that needs to be debated here about what assumptions are a given = and what assumptions need to be spelled out when modifying or layering a = technology.


> On 16 Mar = 2020, at 12:22, Uri Blumenthal <uri@mit.edu> wrote:
> 
> IETF = position (add fat as I remember) regarding RFCs has been that RFCs = should provide with everything information for a reasonable developer to = implement correctly and securely the standard they define, and provide = enough information for the person who will deploy a compliant = implementation to do that correctly and securely.
> 
> One = purpose of Security Review is to ensure that a person doesn't have to be = an expert in the field to deal with the proposed document.
> 
> In a flippant way, if using your stuff is requires = special classes - perhaps it belongs to a book rather than an RFC.
> 
> In a non-flippant way - what's the problem in mentioning = the issues and providing the appropriate references? A "normal" RFC = cannot be self-contained, but it's unreasonable to epect a reader to = just "know" where all the omitted things are described. 
> 
>> On = Mar 16, 2020, at 06:33, Stewart Bryant <stewart.bryant@gmail.com> wrote:
>> 
>> =EF=BB=BFUri,
>> 
>> That is a ridiculous position, and you flippancy = demonstrates that.
>> 
>> = This technology fundamentally rests on MPLS and it is reasonable that = the reader of this RFC will understand MPLS and the security model it = uses before they implement or deploy it. Indeed I cannot think of any = implementor or operator that would not already have that knowledge = before taking on the task of building or running DN over MPLS.
>> 
>> If SecDir reviews are to retain any credibility as = expert reviews as opposed to Genart random reader reviews they have to = be carried out with shared knowledge of both the security area and the = draft=E2=80=99s host area.
>> 
>> I = have been thinking for some time that there needs to be a fundamental = review of the security review process.
>> 
>> = Stewart
>> 
>>> = On 15 Mar 2020, at 22:44, Uri Blumenthal <uri@mit.edu> wrote:
>>> 
>>> = I say yes - unless you expect a person who wants just one RFC to have to = read every cr^h^h stuff that came out of the routing area.
>>> 
>>> = "Just do it"
>>> 
>>> 
>>>>> On Mar 15, 2020, at 17:39, Lou Berger = <lberger@labn.net> = wrote:
>>>> 
>>>> =EF=BB=BF
>>>>> On 3/15/2020 5:22 PM, Watson Ladd = wrote:
>>>>>> On Sun, Mar 15, 2020 at = 2:14 PM Lou Berger <lberger@labn.net> wrote:
>>>>>> Hi Watson,
>>>>>> 
>>>>>>   I think Stewart's = response really covers the main points. DetNet is
>>>>>> really just MPLS (and IP) with some = specific forwarding behaviors and
>>>>>> = queuing.  The only thing I'd add, is I see DetNet in general as = a
>>>>>> specific form of policy based = routing. (The general form of which is
>>>>>> pretty much as old as IP).
>>>>> Then Stewart can put those points in the = security considerations
>>>>> section. = What's the disadvantage of doing so?
>>>> 
>>>> At one level, it would be easiest for the = authors to just put these in.  On the other hand, this would mean = that every RFC produced in the routing area will acquire similar notes, = e.g., routing protocols are currently built with a chain of trust = model.  Is this what the sec-dir really is asking the routing area = to do?
>>>> 
>>>> ADs,
>>>> 
>>>>  any opinion on this?    =  (for context, Stewart's response can be found at: https://mailarchive.ietf.org/arch/msg/detnet/-epL5Fb6bFIUltMrjH= 53C2316ZA/)
>>>> 
>>>> Thanks,
>>>> 
>>>> Lou
>>>> 
>>>>>> Lou
>>>>>> 
>>>>>> On 3/12/2020 9:35 PM, Watson Ladd = wrote:
>>>>>>> On Thu, Mar 12, 2020 = at 4:07 AM Lou Berger <lberger@labn.net> wrote:
>>>>>>>> Watson,
>>>>>>>> 
>>>>>>>> Can you provide context = here? Can you be explicit on what you see needs to
>>>>>>>> be addressed (beyond what is = in this document as well as related rfcs)?
>>>>>>> You have to talk about how the = layers interact, and can't just say the
>>>>>>> lower level handles anything = without any guide as to what needs to be
>>>>>>> provided by that lower layer.
>>>>>>> 
>>>>>>> I think my concerns about the = assumptions this could be fixed by
>>>>>>> saying. "All nodes are trusted = and any of them can misbehave in ways
>>>>>>> that affect the network.  = If the MPLS layer cannot provide sufficient
>>>>>>> determinism, then the DetNet = mechanisms won't work".  I agree we
>>>>>>> shoudn't require an entire = massive security framework to be quoted
>>>>>>> again here, but there must be = some details of this embedding that are
>>>>>>> worth noting, and yet I don't = see them called out in the security
>>>>>>> considerations section.
>>>>>>> 
>>>>>>> Are there really no specific = concerns about the interaction between
>>>>>>> DetNet and MPLS?
>>>>>>> 
>>>>>>>> Thank you,
>>>>>>>> Lou
>>>>>>>> 
>>>>>>>> 
>>>>>>>> ----------
>>>>>>>> On March 11, 2020 10:30:27 = PM Watson Ladd <watsonbladd@gmail.com> wrote:
>>>>>>>> 
>>>>>>>>> I don't see any reason = why RFC 3552's guidelines shoudn't apply to this draft.
>>>>>>>>> 
>>>>>>>>> If there is a MPLS = exception I'd like to see the rules that should be applied.
>>>>>>>>> 
>>>>>>>>> As is I don't see any = reason why the assumptions can't be explicitly
>>>>>>>>> spelled out, either in = the Security Considerations or elsewhere.
>>>>>>>>> 
>>>>>>>>> = _______________________________________________
>>>>>>>>> detnet mailing list
>>>>>>>>> detnet@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/detnet
>>>>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> = _______________________________________________
>>>> secdir mailing list
>>>> secdir@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/secdir
>>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>> 



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



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

Uri

= --Apple-Mail=_D1A7D0D8-8AD4-4530-81A4-D829B4447A52-- --Apple-Mail=_91212AB3-239E-4D11-8BB2-805D4CFF7CBC Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCA70w ggO5MIIDIqADAgECAhBdZAK63nchU5yFJ3D5ChXkMA0GCSqGSIb3DQEBCwUAMGwxCzAJBgNVBAYT AlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMS4wLAYDVQQKEyVNYXNzYWNodXNldHRzIEluc3Rp dHV0ZSBvZiBUZWNobm9sb2d5MRUwEwYDVQQLEwxDbGllbnQgQ0EgdjEwHhcNMTkwNzMxMDMxMDA3 WhcNMjAwNzMxMDMxMDA3WjCBoTELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMx LjAsBgNVBAoTJU1hc3NhY2h1c2V0dHMgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsT DENsaWVudCBDQSB2MTEXMBUGA1UEAxMOVXJpIEJsdW1lbnRoYWwxGjAYBgkqhkiG9w0BCQEWC3Vy aUBNSVQuRURVMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAn7po/olfBbdflh0fEdQ+ t+I8E1LXvU6codZBlKbB9ITxFCHgFRAoGs5acPBhA9x0nULDag4v/XPgVCqFYbQiH12NTsqC/y6j uRlJEKD3tsgelrG69Rhi/uTX8kX+UWlR3ESgsRrBTlBhdFri3irgFzo8H7jOGfB7i3M6lM+qBDcf hdlFNvYP5gy7yCPWbSqT+vG2Runqs/ZPZbzEjdO0ZIAGY9mXAxJhGRQYGoHv6l7I6YkKJFjaXa+c iGNNEVdRjMglBlzutlKdxwvNjddktt1xFfNK+5RekutIaKM5aiAk0g8p9VwyF30a8E3vaVqiAlCK p8ow80Tf6pCsWzd+3wIDAQABo4GhMIGeMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMB0G A1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjALBgNVHQ8EBAMCBeAwHQYDVR0OBBYEFKfGEmEN xBmzwFf7/C/woTfy2QTnMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jYS5taXQuZWR1L2NhL21p dGNsaWVudC5jcmwwDQYJKoZIhvcNAQELBQADgYEASLiK0bsEYVsX61pV4QHdrtmoxlXRHxGFt2AR OFWBrhYUMvpUgrQXzafRzldyS22lXQP4Zr+nw2drFdUL1K4H+VuNtYsUgZ/jtGl5qd1re8cmgq0o LAy3wLIIoA4g8l9M8GkfbWCKtYPLaa2rqmD2AU6vp7zRgHxbiRee5k1jbEIxggNDMIIDPwIBATCB gDBsMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEuMCwGA1UEChMlTWFzc2Fj aHVzZXR0cyBJbnN0aXR1dGUgb2YgVGVjaG5vbG9neTEVMBMGA1UECxMMQ2xpZW50IENBIHYxAhBd ZAK63nchU5yFJ3D5ChXkMA0GCWCGSAFlAwQCAQUAoIIBkzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAzMTcxNTA3MDJaMC8GCSqGSIb3DQEJBDEiBCAbW7kgtpkz aHMUnzLBP0NsfexbkVFvqJP4N2PSOUn4vzCBkQYJKwYBBAGCNxAEMYGDMIGAMGwxCzAJBgNVBAYT AlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMS4wLAYDVQQKEyVNYXNzYWNodXNldHRzIEluc3Rp dHV0ZSBvZiBUZWNobm9sb2d5MRUwEwYDVQQLEwxDbGllbnQgQ0EgdjECEF1kArredyFTnIUncPkK FeQwgZMGCyqGSIb3DQEJEAILMYGDoIGAMGwxCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNo dXNldHRzMS4wLAYDVQQKEyVNYXNzYWNodXNldHRzIEluc3RpdHV0ZSBvZiBUZWNobm9sb2d5MRUw EwYDVQQLEwxDbGllbnQgQ0EgdjECEF1kArredyFTnIUncPkKFeQwDQYJKoZIhvcNAQEBBQAEggEA DNT2HgLY3Q9DcbisB20t2AGLjk7AN7T9ZfWDIoR5tHckrGd9L/11Ai9nuSUa7lnhDGL+J3GpEC8n ORkYF2XvRFRlQCQlw0g/FVi/B6MoB+n9uyW5tpO//ydhSj234wGLAdcz8zptZDtjFyL/eYF67knb nQjYbRlCpxegBgdBUlT0BUb2Xu7XP4Qhrd9GsQg0IRMo8bIlIS7pIUMl9qC52faKQw/JbxNpHIQ7 d4cWiYN6+QTcPjxvUhC6J798nX83guA+67SG6lJXvDZn2NdPtfeKvls2T8P9AyRAqjgeCM9/8qOp /UNMAHC7kFnPVVfrq37I11m1/OVoLpGev7i1SAAAAAAAAA== --Apple-Mail=_91212AB3-239E-4D11-8BB2-805D4CFF7CBC-- From nobody Tue Mar 17 08:38:17 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CAE73A078B; Tue, 17 Mar 2020 08:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 yNNXcfx8RgzC; Tue, 17 Mar 2020 08:38:10 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2070.outbound.protection.outlook.com [40.107.20.70]) (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 3B8F03A0787; Tue, 17 Mar 2020 08:38:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V1tp8ywYB8JwQiHZEvUY3aUOiAWN4OMgfv4xxUcSVtFV7O7/QZR8tkkDBlzLg/YTsfLg+t5HsTbbUjtq1KT4mqUcF3xmBeaATvCDEdEb2etXqF1p75Idt0sGA2RrBPtXtWr3STGK6tq5Pven/pkPYh2YQ0+NtINYXWj5jZ/9w5Udv7/arQWD6B+lZgcV1Fhqs0xjU9N9YIYr95yCEzOJWc94KZOfBOv+N5MLAKn/R2VTHZ24UiGuWurtinpDzQqlv0flrAZdSKtD00eFVBhFr3BuMNVcunAYbez8AZ3BqPUrhhNh+0Ok5Enr6M7567nYjFOWjta7/yJAaZTnppnT+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eyeAp0BBy6hL+kuijrTdbDbDPGnDPhQUy3QC63ZcgjY=; b=JcdDG28/AJVEmFYCFR3tUFUSNljZkiuvhy3BgTOB2HvzCvimh3GmduszzRGwX/ZV5oezt6tERI61y0Gw5lZJfBkd9jPTIBdJ98Nk6+rDpI0FFiClqFJmpgcoZzfvg6qydg7/ofy0cMfTB6c9QrkBKXtrKMVMev/iDINJfHe7LGhylCTf6IvriEWqVfUeHX11gDQN0PEcw3F+1vecNsJSNQOjwA9zPX7TqEJvCdcQTxNpqb/+LUcFj/E94EbqdxMTXIbX+uOthNcX6vldj712MNGxAX5HMOgLX6Y1YDDgLbwJGpIOe5XjscYDsPnCOxupPyv8X28HZyz4QmYfcSmobw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none 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=eyeAp0BBy6hL+kuijrTdbDbDPGnDPhQUy3QC63ZcgjY=; b=M5JSL3Mt5UeU7rDao/4EWaMXuFpaggH/58teDQnoCOQ3EDrstq8gFCYz/outFlDFvwWvufduuXleulyuiZkJlyV6Njy3UiECcVwOwfpFG1vV9oG2lMxXcbL8RO65ChWTmX3t8Jzt1bEsGa4MeNlydoQ6sOz09DASvflo2qd2L30= Received: from AM7PR07MB6707.eurprd07.prod.outlook.com (20.181.27.203) by AM7PR07MB6360.eurprd07.prod.outlook.com (10.186.168.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.12; Tue, 17 Mar 2020 15:38:07 +0000 Received: from AM7PR07MB6707.eurprd07.prod.outlook.com ([fe80::36:4d0:5e29:8c43]) by AM7PR07MB6707.eurprd07.prod.outlook.com ([fe80::36:4d0:5e29:8c43%3]) with mapi id 15.20.2835.013; Tue, 17 Mar 2020 15:38:07 +0000 From: Klaus Hartke To: David Mandelberg , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-core-stateless.all@ietf.org" CC: "hartke@projectcool.de" Thread-Topic: secdir review of draft-ietf-core-stateless-05 Thread-Index: AQHV+uu9nK6WdknHm0uk+B22lZBRZ6hM6f7g Date: Tue, 17 Mar 2020 15:38:07 +0000 Message-ID: References: <9ea24cd9-e194-9820-a903-9cc09ef19504@mandelberg.org> In-Reply-To: <9ea24cd9-e194-9820-a903-9cc09ef19504@mandelberg.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=klaus.hartke@ericsson.com; x-originating-ip: [145.14.112.90] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e218a92c-0182-4fcd-7b14-08d7ca8930f2 x-ms-traffictypediagnostic: AM7PR07MB6360: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0345CFD558 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(39860400002)(366004)(376002)(136003)(199004)(4326008)(186003)(26005)(66946007)(44832011)(2906002)(110136005)(66476007)(76116006)(66446008)(64756008)(66556008)(478600001)(33656002)(966005)(6506007)(9686003)(7696005)(55016002)(316002)(81166006)(52536014)(71200400001)(5660300002)(8936002)(86362001)(8676002)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:AM7PR07MB6360; H:AM7PR07MB6707.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WfjPjdmQ52TqTSi+nNsyKrGtyax4hoNGHloguBJJ0p46JkErxTh53301OWEyzrDKxdZHiN8AzDe8rsTUXsh25AGGeSi1JvZyaZdHRJPJAfac0DLms9f05QSkJAOEwMiWlNisWGkWnVD21q99uAt9R/HtioT3uzOewB1xxVPJp+F54MItnGFzc1f6oT3kkJqC7CXBCHLWCzWhsfs98N+0VvHJwvNKuH5hMI92P99RHuF74LsbC5K8c+DzAYrr4ZqOx+nLqxVcU8LxNdlM4BJCicPWbAOHamH7Hk+UqvRoGrGirTTZj9VVw5Qfyw2fE+miZKSwTyhRibM9Qk7LktSx8eFy9zJHx0u9mBZ7vWTPYUat1somdWTag8z4xNbHEqaZrCF2LW+UvzM2rc487V1IPHRRmepytCffaoNFjlC00aYkfqdljZEOHk2kPnS17ePbpk6P8UYB/A5MFGsy9UntUMdx/jaGhCr+e5hhcLpTF9nGuv7Dz0Oc0dXytL6ULGIJ1TW3c4dCxQHp4HeAuJ+esw== x-ms-exchange-antispam-messagedata: 09XCC2i6MUBzS+wAdcfGYgruXKFSv5H5YDlQj5DaGOMjaq9DFGbDRRFWQ7FDTeVHA9x9w1NjjfQGxhCHowxeVvMqlieRkplEeUlJktKmdKvi6ioV9BO9AkKbWqMryfZyuCRvAXkNGLW+ga2CZcCBQQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: e218a92c-0182-4fcd-7b14-08d7ca8930f2 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2020 15:38:07.5209 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: GEzD4Cwg3hfe+3gG8hj/Fd5o4oM2wRSq+AnPET3zoFwbAwCimXKnc8CbsGQdDHZPjkk7cfzIUztNZWlO4Qxr5npylkUYGifa3dmvxTDXbIU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6360 Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-core-stateless-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2020 15:38:13 -0000 RGF2aWQgTWFuZGVsYmVyZyB3cm90ZToNCj4gSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQg YXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyBvbmdvaW5nDQo+IGVmZm9ydCB0 byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4N Cg0KVGhhbmtzIGEgbG90IQ0KDQo+IEkgdGhpbmsgdGhpcyBwcm90b2NvbCBjaGFuZ2UgaW5jcmVh c2VzIHRoZSBhbW91bnQgb2YgZGF0YSB0aGF0IGEgQ29BUCBzZXJ2ZXINCj4gd291bGQgcmVmbGVj dCBpbiBhIERvUyBhdHRhY2sgdXNpbmcgc3Bvb2ZlZCBzb3VyY2UgSVAgYWRkcmVzc2VzIHdpdGgg VURQLiBJDQo+IGRvbid0IHNlZSBhbnkgb3Bwb3J0dW5pdHkgZm9yIGFtcGxpZmljYXRpb24gdGhv dWdoLCBqdXN0IHJlZmxlY3Rpb24gb2YgbW9yZQ0KPiBkYXRhIHNlbnQgYnkgYSBtYWxpY2lvdXMg Y2xpZW50LiBJJ20gdmVyeSBtdWNoIG5vdCBhIERvUyBleHBlcnQgdGhvdWdoLCBzbyBJDQo+IGhh dmUgbm8gaWRlYSBpZiB0aGlzIGlzIGFuIGlzc3VlIGF0IGFsbC4NCg0KUmlnaHQsIHRoZSBhbW91 bnQgb2YgZGF0YSB0aGF0IGNhbiBwb3RlbnRpYWxseSBiZSByZWZsZWN0ZWQgaW5jcmVhc2VzLiBU aGUgQ29BUCBSRkMgYWxyZWFkeSBoYXMgYSBzZWN0aW9uIG9uIHJlZmxlY3Rpb24gYW5kIGFtcGxp ZmljYXRpb24gWzFdOyBJIHdpbGwgYWRkIGFuIGV4cGxpY2l0IHJlZmVyZW5jZSB0byB0aGF0IHNl Y3Rpb24gdG8gdGhlIGRyYWZ0Lg0KDQo+IFdoYXQgaGFwcGVucyB3aGVuIGEgY2xpZW50IGNoYW5n ZXMgdGhlIChpbXBsZW1lbnRhdGlvbi1wcml2YXRlKSBmb3JtYXQgb2YNCj4gdGhlIHN0YXRlIGl0 IHB1dHMgaW4gdGhlIHRva2Vucz8gRS5nLiwgd2hhdCBpZiBhIGNsaWVudCBzZW5kcyBhIHJlcXVl c3QsIGFwcGxpZXMgYQ0KPiBzb2Z0d2FyZSB1cGRhdGUsIHRoZW4gcmVjZWl2ZXMgdGhlIHJlc3Bv bnNlPyAoSSdtIGd1ZXNzaW5nIHRoYXQncyBhIG1vcmUNCj4gbGlrZWx5IHNpdHVhdGlvbiB3aXRo IFVEUCwgc2luY2UgdGhlIHNvZnR3YXJlIHVwZGF0ZSB3b3VsZCBwcm9iYWJseSBpbnRlcnJ1cHQN Cj4gYSBUQ1Agc2Vzc2lvbi4pIElmIGFuIGF0dGFja2VyIGNhbiBwcmVkaWN0IHdoZW4gdGhlIHNv ZnR3YXJlIHVwZGF0ZSB3aWxsDQo+IGhhcHBlbiBhbmQgaG93IHRoZSBuZXcgdmVyc2lvbiB3aWxs IGludGVycHJldCB0aGUgb2xkIHZlcnNpb24ncyB0b2tlbnMsIGNhbg0KPiB0aGV5IHJlcGxheSBh bnl0aGluZyBtYWxpY2lvdXNseT8gKEFzc3VtaW5nIHRoZSByZXBsYXkgd2luZG93IGluY2x1ZGVz DQo+IHNvbWUgbWVzc2FnZXMgZnJvbSBqdXN0IGJlZm9yZSB0aGUgc29mdHdhcmUgdXBkYXRlLikN Cg0KUmlnaHQsIGZhbHNlIGludGVyb3BlcmFiaWxpdHkgd2l0aCBwcmV2aW91cyBpbXBsZW1lbnRh dGlvbiB2ZXJzaW9ucyBtaWdodCBjYXVzZSBhIHNlY3VyaXR5IGlzc3VlLiBJIHdpbGwgYWRkIGEg cGFyYWdyYXBoIGFsb25nIHRoZXNlIGxpbmVzIHRvIHRoZSBkcmFmdCAoIi4uLlNIT1VMRCBpbmNs dWRlIGEgdmVyc2lvbiBpbmRpY2F0b3IgaW4gdGhlIHNlcmlhbGl6ZWQgc3RhdGUuLi4iKS4NCg0K S2xhdXMNCg0KWzFdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MjUyI3NlY3Rpb24t MTEuMw0KDQo= From nobody Tue Mar 17 09:17:52 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5A23A0767; Tue, 17 Mar 2020 09:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H03ZAFmWJk1Q; Tue, 17 Mar 2020 09:17:42 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A041C3A073E; Tue, 17 Mar 2020 09:17:41 -0700 (PDT) Received: from [172.16.42.113] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48hdcM58hvzyvv; Tue, 17 Mar 2020 17:17:39 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: Date: Tue, 17 Mar 2020 17:17:39 +0100 Cc: David Mandelberg , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-core-stateless.all@ietf.org" , "hartke@projectcool.de" X-Mao-Original-Outgoing-Id: 606154659.2073621-a3406f6949124b0b6d1be914dd717521 Content-Transfer-Encoding: quoted-printable Message-Id: <580E6593-9240-4A4C-9A14-B9FC1C2F6133@tzi.org> References: <9ea24cd9-e194-9820-a903-9cc09ef19504@mandelberg.org> To: Klaus Hartke X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-core-stateless-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2020 16:17:45 -0000 On 2020-03-17, at 16:38, Klaus Hartke wrote: >=20 > Right, false interoperability with previous implementation versions = might cause a security issue. I will add a paragraph along these lines = to the draft ("...SHOULD include a version indicator in the serialized = state..."). Not sure that a "version indicator=E2=80=9D is a SHOULD, but including = something that changes when the interpretation of the data is changed, = is. (I=E2=80=99m sure anyone familiar with CSRF tokens will have put that = in, already.) Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Mar 20 13:28:28 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D61F3A0DEB for ; Fri, 20 Mar 2020 13:28:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.121.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <158473610636.13531.3460483893017557466@ietfa.amsl.com> Date: Fri, 20 Mar 2020 13:28:26 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 20:28:27 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2020-04-09 Reviewer LC end Draft John Bradley 2020-02-28 draft-ietf-regext-data-escrow-05 Donald Eastlake R2019-11-14 draft-ietf-hip-dex-18 Scott Kelly 2020-03-18 draft-ietf-sidrops-ov-egress-02 Last calls: Reviewer LC end Draft John Bradley 2020-02-28 draft-ietf-regext-data-escrow-05 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-09 Donald Eastlake 2020-02-27 draft-ietf-6tisch-msf-12 Donald Eastlake R2019-11-14 draft-ietf-hip-dex-18 Daniel Franke 2020-03-09 draft-ietf-regext-dnrd-objects-mapping-06 Dan Harkins 2020-03-06 draft-ietf-alto-incr-update-sse-21 Leif Johansson 2020-02-28 draft-ietf-tcpm-converters-18 Charlie Kaufman R2019-09-02 draft-ietf-ecrit-data-only-ea-22 Scott Kelly 2020-03-18 draft-ietf-sidrops-ov-egress-02 Aanchal Malhotra 2020-03-12 draft-ietf-bess-vpls-multihoming-05 Catherine Meadows 2020-04-02 draft-ietf-dnsop-extended-error-14 Daniel Migault 2020-03-31 draft-ietf-dnsop-multi-provider-dnssec-04 Adam Montville 2020-03-31 draft-ietf-core-resource-directory-24 Kathleen Moriarty 2020-03-20 draft-ietf-sidrops-rp-06 Russ Mundy 2020-01-02 draft-ietf-dprive-bcp-op-08 Sandra Murphy 2020-04-08 draft-ietf-dmarc-psd-08 Sandra Murphy 2019-10-04 draft-ietf-mpls-ldp-yang-06 Yoav Nir 2020-04-08 draft-ietf-idr-rfc5575bis-20 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-11 Vincent Roca 2020-01-30 draft-ietf-pim-msdp-yang-16 Takeshi Takahashi 2020-02-06 draft-ietf-mmusic-t140-usage-data-channel-11 Tina Tsou 2020-02-06 draft-ietf-6lo-backbone-router-19 Sean Turner None draft-ietf-opsawg-sdi-02 David Waltermire 2020-02-25 draft-ietf-6man-icmp-limits-08 Dacheng Zhang 2020-03-12 draft-nottingham-how-did-that-get-into-the-repo-01 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Next in the reviewer rotation: Magnus Nystrom Hilarie Orman Radia Perlman Derrell Piper Tirumaleswar Reddy.K Vincent Roca Kyle Rose Joseph Salowey Rich Salz Stefan Santesson From nobody Tue Mar 24 08:46:58 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A96DE3A0CCD; Tue, 24 Mar 2020 08:46:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Montville via Datatracker To: Cc: last-call@ietf.org, core@ietf.org, draft-ietf-core-resource-directory.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.122.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158506479161.11508.17361892799522117506@ietfa.amsl.com> Reply-To: Adam Montville Date: Tue, 24 Mar 2020 08:46:31 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-core-resource-directory-24 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2020 15:46:51 -0000 Reviewer: Adam Montville Review result: Ready I generally feel that this draft is ready. I do think the Security ADs should pay particular attention to some of the security considerations. Most notable is Section 8.3, Denial of Service Attacks. This section describes how a Resource Directory (RD) “…can unknowingly become part of a DDoS amplification attack,” but doesn’t provide any real mitigation or normative language toward that end. It is clear from the draft that the preferred deployment of these capabilities is to leverage TLS or DTLS, but doing so is not mandatory per the draft. There is an assumption, also, that clients are provided a certificate at the time of manufacture, which can then be used by the RD as the endpoint’s name. It seems that, with use of TLS/DTLS, and with certain device characteristics in place, things are pretty well buttoned up. Without these assumptions, however, it seems that the use of an RD could be problematic in more open deployments. Then again, I’m not operating in the space of constrained devices day-to-day. From nobody Fri Mar 27 15:11:33 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC933A0C36; Fri, 27 Mar 2020 15:11:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Daniel Migault via Datatracker To: Cc: draft-ietf-dnsop-multi-provider-dnssec.all@ietf.org, last-call@ietf.org, dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.123.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158534708187.17642.15427344724416293958@ietfa.amsl.com> Reply-To: Daniel Migault Date: Fri, 27 Mar 2020 15:11:21 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-dnsop-multi-provider-dnssec-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 22:11:22 -0000 Reviewer: Daniel Migault Review result: Has Nits Hi, Reviewer: Daniel Migault Review result: Has Nits I reviewed this document as part of the Security Directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Security Area Directors. Document authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. Please find my comments below. Yours, Daniel Multi Signer DNSSEC models draft-ietf-dnsop-multi-provider-dnssec-04 Abstract Many enterprises today employ the service of multiple DNS providers to distribute their authoritative DNS service. Deploying DNSSEC in such an environment may present some challenges depending on the configuration and feature set in use. In particular, when each DNS provider independently signs zone data with their own keys, additional key management mechanisms are necessitated. This document presents deployment models that accommodate this scenario and describe these key management requirements. describes These models do not require any changes to the behavior of validating resolvers, nor do they impose the new key management requirements on authoritative servers not involved in multi signer configurations. I am reading the last sentence as no changes are expected for servers not implementing. Maybe it would be clearer to say that changes are only expected on server implementing the multi signer described in this document. Of course this is only a suggestion. [...] In the models presented, the function of coordinating the DNSKEY or DS RRset does not involve the providers communicating directly with each other. Feedback from several commercial managed DNS providers indicates that they may be unlikely to directly communicate since they typically have a contractual relationship only with the zone owner. However, if the parties involved are agreeable, it may be possible to devise a protocol mechanism by which the providers directly communicate to share keys. The following descriptions consider the case of two DNS providers, but the model is generalizable to any number. The only justification for the use of two is that both is once used. I think this is not really needed with the current text. 2.1.1. Model 1: Common KSK, Unique ZSK per provider The term Unique may not be appropriated as it could be interpreted as one single and not two ZSKs per providers. I think that Unique here means "per provider independent ZSK." One note also, I am also balanced by considering there is always multiple KSKs, ZSKs as this could be the case between the key roll overs. On the other hand, I do not know if it makes the text more complex to read. I am wondering if it makes sense to also consider this model with one provider if the content owner wants to keep the ownership/control of the zone. o Zone owner holds the KSK, manages the DS record, and is responsible for signing the DNSKEY RRset and distributing the signed DNSKEY RRset to the providers. o Each provider has their own ZSK which is used to sign data. o Providers have an API that owner uses to query the ZSK public key, and insert a combined DNSKEY RRset that includes both ZSKs and the KSK, signed by the KSK. I believe the text could be clearer on who generates the DNSKEY RRset and describe the outputs in an uniform way - that is using RRsets for both outputs. The text also seems to indicate the owner directly updates the zone. While this is the resulting outcome, I understood the insertion to the zone as being performed by the provider as in some cases a signature with the ZSK may also be performed. Explanation may actually be more complex then the actual change. The text I would propose would be around the lines (assuming I am not missing anything): Providers have an API to enable the owner to retrieve the ZSKs public key from the providers, generate and return the appropriated DNSKEY and RRSIG RRsets. The DNSKEY RRset contains the ZSKs of the multiple providers and the KSKs. Its associated RRSIG RRset contains the signature of the DNSKEY RRset with the KSKs. o Note that even if the contents of the DNSKEY RRset don't change, the Zone owner of course needs to periodically re-sign it as signature expiration approaches. The provider API is also used to thus periodically redistribute the refreshed DNSKEY RRset. o Key rollovers need coordinated participation of the zone owner to update the DNSKEY RRset (for KSK or ZSK), and the DS RRset (for KSK). Unless I am missing something, I believe that the API operating regularly could proceed to a key roll over in an automated way. The only additional step would consists in the publication of the DS RRSet. I am wondering if one is a specific key roll over or an emergency key roll over was considered there. The reason I am commenting this aspect is that I see the need of manual coordination as a strong reason against the mechanism. 2.1.2. Model 2: Unique KSK and ZSK per provider o Each provider has their own KSK and ZSK. o Each provider offers an API that the Zone Owner uses to import the ZSK of the other provider into their DNSKEY RRset. I think "Zone Owner" was used without capital letter before. In this case I believe that the information is the ZSKs public key (as opposed as the DNSKEY RRset) and that each provider is responsible of publishing ZSKs of other providers and signing those with their own KSKs and eventually their own ZSKs. Maybe this could be detailed a bit more. It might be clarifying to specify: "Each provider offers an API that the zone owner to import the ZSKs public key and export the ZSKs public keys of all providers. Each provider will generate the associated DNSSEY RRset." What is unclear to me is who generates the DNSKEY RRset. I have the impression each provider is generating its own DNSKEY. If that is correct, I am wondering the impact of having different TTLs. At least, the TTL needs to be known by the zone owner to regularly retrieve and updates the ZSK public key values. If the zone owner imposes the TTL value, than it makes this easier. For that reason, I am wondering if that would not be better to have the owner generating the NDSKEY RRset. o DNSKEY RRset is signed independently by each provider using their own KSK. o Zone Owner manages the DS RRset that includes both KSKs. s/Zone Owner/zone owner/ s/both/all/ 3. Validating Resolver Behavior The central requirement for both of the Multiple Signer models (Section 2.1) is to ensure that the ZSKs from all providers are present in each provider's apex DNSKEY RRset, and is vouched for by either the single KSK (in model 1) or each provider's KSK (in model 2.) If this is not done, the following situation can arise (assuming two providers A and B): o The validating resolver follows a referral (delegation) to the zone in question. o It retrieves the zone's DNSKEY RRset from one of provider A's nameservers. o At some point in time, the resolver attempts to resolve a name in the zone, while the DNSKEY RRset received from provider A is still viable in its cache. o It queries one of provider B's nameservers to resolve the name, and obtains a response that is signed by provider B's ZSK, which it cannot authenticate because this ZSK is not present in its cached DNSKEY RRset for the zone that it received from provider A. o The resolver will not accept this response. It may still be able to ultimately authenticate the name by querying other nameservers for the zone until it elicits a response from one of provider A's nameservers. But it has incurred the penalty of additional roundtrips with other nameservers, with the corresponding latency and processing costs. The exact number of additional roundtrips depends on details of the resolver's nameserver selection algorithm and the number of nameservers configured at provider B. With the use of geographic authoritative DNS for example, I have the impression we may also have one provider is only available in from one place and not from the other thus making the resolution possible probably only possible after flushing the cache. o It may also be the case that a resolver is unable to provide an authenticated response because it gave up after a certain number of retries or a certain amount of delay. Or that downstream clients of the resolver that originated the query timed out waiting for a response. Hence, it is important that the DNSKEY RRset at each provider is maintained with the active ZSKs of all participating providers. This ensures that resolvers can validate a response no matter which provider's nameservers it came from. Details of how the DNSKEY RRset itself is validated differs. In model 1 (Section 2.1.1), one unique KSK managed by the Zone Owner signs an identical DNSKEY RRset deployed at each provider, and the signed DS record in the parent zone refers to this KSK. In model 2 (Section 2.1.2), each provider has a distinct KSK and signs the DNSKEY RRset with it. I have the impression that the resolution does not consider the DS. I think that some text needs to be added to mention that all KSK must appropriately delegated. The Zone Owner deploys a DS RRset at the parent zone that contains multiple DS records, each referring to a distinct provider's KSK. Hence it does not matter which provider's nameservers the resolver obtains the DNSKEY RRset from, the signed DS record in each model can authenticate the associated KSK. 4. Signing Algorithm Considerations DNS providers participating in multi-signer models need to use a common DNSSEC signing algorithm. I think the text is saying that providers needs to have a common algorithm which does not seem correct. The text also only mentions the use of a single algorithms which I believe is maybe too restrictive. I would propose something around the following lines: The providers MUST use the same algorithms for signing. This is because the current specifications require that if there are multiple algorithms in the DNSKEY RRset, then RRsets in the zone need to be signed with at least one DNSKEY of each algorithm, as described in RFC 4035 [RFC4035], Section 2.2. If providers employ distinct signing algorithms, then this requirement cannot be satisfied. 5. Authenticated Denial Considerations Authentiated denial of existence enables a resolver to validate that s/Authentiated/Authenticated/ a record does not exist. For this purpose, an authoritative server presents, in a response to the resolver, NSEC (Section 3.1.3 of [RFC4035]) or NSEC3 (Section 7.2 of [RFC5155]) records. The NSEC3 method enhances NSEC by providing opt-out for signing insecure delegations and also adds limited protection against zone enumeration attacks. [...] 5.1. Single Method Usually, the NSEC and NSEC3 methods are used exclusively (i.e. the methods are not used at the same time by different servers). This configuration is prefered because the behavior is well-defined and it's closest to the current operational practice. s/prefered/preferred/ Even though the document is informational, I do not think this prevents using normative language. Here I would think that a RECOMMENDED might be appropriated. 5.2. Mixing Methods Compliant resolvers should be able to validate zone data when different authoritative servers for the same zone respond with different authentiated s/authentiated/authenticated/ denial methods because this is normally observed when NSEC and NSEC3 are being switched or when NSEC3PARAM is updated. Resolver software may be however designed to handle a single transition between two authenticated denial configurations more optimally than permanent setup with mixed authenticated denial methods. This could make caching on the resolver side less efficient and the authoritative servers may observe higher number of queries. This aspect should be considered especially in context of Aggresive Aggressive maybe? The use of mixed method seems to me outside the design of DNSSEC with the publication of one zone. The impact on 8198 as well as the additional burden provided on resolvers seems to me sufficient to at least strongly discourage the mixed method. Use of DNSSEC-Validated Cache [RFC8198]. In case all providers cannot be configured for a matching authentiated denial, it is advised to find lowest number of possible configurations possible across all used providers. Note that NSEC3 configuration on all providers with different NSEC3PARAM values is considered a mixed setup. 6. Key Rollover Considerations The Multiple Signer (Section 2.1) models introduce some new requirements for DNSSEC key rollovers. Since this process necessarily involves coordinated actions on the part of providers and the Zone Owner, one reasonable strategy is for the Zone Owner to initiate key rollover operations. This assumes the zone owner controls the TTL of the DNSKEY. But other operationally plausible models may also suit, such as a DNS provider initiating a key rollover and signaling their intent to the Zone Owner in some manner. The descriptions in this section assume that KSK rollovers employ the commonly used Double Signature KSK Rollover Method, and that ZSK rollovers employ the Pre-Publish ZSK Rollover Method, as described in detail in [RFC6781]. With minor modifications, they can also be easily adapted to other models, such as Double DS KSK Rollover or Double Signature ZSK rollover, if desired. Huque, et al. Expires September 9, 2020 [Page 7] Internet-Draft Multi Signer DNSSEC models March 2020 6.1. Model 1: Common KSK, Unique ZSK per provider o Key Signing Key Rollover: In this model, the two managed DNS providers share a common KSK which is held by the Zone Owner. The text seems confusing as the providers do not actually share the KSK but instead publish a common DNSKEY RRsets with the same public part of the KSK. My understanding of sharing a key means that the private part is shared. To initiate the rollover, the Zone Owner generates a new KSK and obtains the DNSKEY RRset of each DNS provider using their respective APIs. The new KSK is added to each provider's DNSKEY RRset and the RRset is re-signed with both the new and the old KSK. This new DNSKEY RRset is then transferred to each provider. At this point the KSK cannot be used so I am wondering if the DS that corresponds to the new KSK should not need to be added before the new KSK being added to the DNSKEY RRset. The Zone Owner then updates the DS RRset in the parent zone to point to the new KSK, It is not clear what point to the new KSK. Does it means that a new DS RRset has been added and that old and new KSK co-exist? I think I am reading it as the DS RRset of the old KSK has been removed. I think clarifying text may be needed. and after the necessary DS record TTL period has expired, proceeds with updating the DNSKEY RRSet to remove the old KSK. [...] 12. Security Considerations The Zone key import APIs required by these models need to be strongly authenticated to prevent tampering of key material by malicious third parties. Many providers today offer REST/HTTPS APIs that utilize a number of authentication mechanisms (username/password, API keys etc). If DNS protocol mechanisms like UPDATE are being used for key insertion and deletion, they should similarly be strongly authenticated, e.g. by employing Transaction Signatures (TSIG) [RFC2845]. I believe that some words should be provided on the security implied by the two models. For the two models the providers signs and so is able to modify and alter the zone. The content is actually under the responsibility of the provider not the zone owner. In addition, the zone owner has little mean to check the appropriated content is being delivered. The fact that TTL are controlled by the provider and not the zone owner keeps the control of the provider to to TTL s after it is being revoked at least for cached data. In the second model, the zone maintainer is given up any control. If it is choosing to remove a KSK and the provider continue serving the zone, he is affecting the resolution of its zone at - least until the NS expires. In the first model the zone owner keeps the control of the KSK which enables to revoke a provider for any new request. In other words, keep a technical mean to revoke a provider. This will not work on cached RRSet, which means that if a long TTL has been provided and cached, this RRset will stay in cache even though the DNSKEY expires. It is one reason we may recommend the resolver to limit the TTL of the RRsets to not be larger than those of the DNSKEY RRset. I am wondering if any indication for KSK TTL could be recommended. At least I would expect to have TTL shorter than in a non delegated case. The link between the zone owner and the provider also represent an potential vector of attack, though limited, but I think that would need more text. From nobody Tue Mar 31 08:00:14 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE1A3A2288; Tue, 31 Mar 2020 07:59:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Catherine Meadows via Datatracker To: Cc: draft-ietf-dnsop-extended-error.all@ietf.org, dnsop@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.123.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158566679527.28397.11447221654478370153@ietfa.amsl.com> Reply-To: Catherine Meadows Date: Tue, 31 Mar 2020 07:59:55 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-dnsop-extended-error-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2020 14:59:55 -0000 Reviewer: Catherine Meadows Review result: Has Issues This ID defines an extensible method to return information about the cause of DNS errors. It extends both the type of response that can contain error messages and the type of messages that can be returned, and includes mechanisms that can be used to add more as needed. The Security Considerations section mentions some valid points, but it is not made clear how they apply to extended DNS error messages (as opposed to DNS error messages in general). It first makes the non-obvious point that a significant number of clients, when receiving a failure message about a DNS validation issue from a validated resolver, will seek out an unvalidated server instead. It is not clear to me though whether you think that extending the types of DNS error messages available (thus giving more information to the client) would help address this problem. You should say something about this. Secondly, it discusses the security implications of the fact that DNS error messages are unauthenticated. In addition, in the paragraph about the security implications of DNS error messages being unauthenticated, you should say whether or not extending the types of DNS error messages would improve the situation, make it worse, have no effect, or is unclear.