From nobody Thu Aug 3 07:47:25 2017 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 9FF6F132027 for ; Thu, 3 Aug 2017 07:47:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Reply-to: secdir-secretary@mit.edu Message-ID: <150177164352.9690.16415777608282420568.idtracker@ietfa.amsl.com> Date: Thu, 03 Aug 2017 07:47:23 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 14:47:24 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2017-08-03 Reviewer LC end Draft Derek Atkins 2017-07-18 draft-ietf-httpbis-immutable-03 Alan DeKok R2017-05-26 draft-nottingham-rfc5988bis-07 Klaas Wierenga 2017-07-12 draft-ietf-mpls-rfc3107bis-02 For telechat 2017-08-17 Reviewer LC end Draft Alan DeKok 2017-05-14 draft-ietf-calext-caldav-attachments-03 Dan Harkins 2017-08-09 draft-ietf-bess-evpn-etree-12 Paul Hoffman 2017-08-08 draft-ietf-slim-multilangcontent-10 Rich Salz R2017-07-24 draft-ietf-mmusic-dtls-sdp-27 For telechat 2017-08-31 Reviewer LC end Draft Ólafur Guðmundsson 2017-08-15 draft-ietf-sidr-rpki-validation-reconsidered-08 Last calls: Reviewer LC end Draft Donald Eastlake 2017-07-30 draft-ietf-curdle-ssh-modp-dh-sha2-07 Shawn Emery 2017-07-30 draft-ietf-curdle-ssh-ext-info-11 Daniel Franke 2017-07-30 draft-ietf-curdle-ssh-dh-group-exchange-05 Daniel Gillmor 2017-07-30 draft-ietf-curdle-des-des-des-die-die-die-04 Phillip Hallam-Baker 2017-08-11 draft-ietf-rtcweb-jsep-21 Steve Hanna 2017-08-09 draft-ietf-codec-opus-update-08 Christian Huitema None draft-ietf-sfc-nsh-18 Yaron Sheffer 2017-07-17 draft-weis-gdoi-rekey-ack-05 Tom Yu 2017-07-25 draft-ietf-lamps-rfc5280-i18n-update-02 Tom Yu 2017-02-20 draft-ietf-slim-negotiating-human-language-13 Early review requests: Reviewer Due Draft Daniel Gillmor 2016-02-01 draft-ietf-rtcweb-security-08 Leif Johansson 2017-08-09 draft-ietf-homenet-babel-profile-02 Catherine Meadows R2017-06-29 draft-ietf-opsawg-capwap-alt-tunnel-09 Next in the reviewer rotation: Benjamin Kaduk Charlie Kaufman Scott Kelly Stephen Kent Tero Kivinen Watson Ladd Ben Laurie Barry Leiba Chris Lonvick David Mandelberg From nobody Fri Aug 4 01:16:50 2017 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 3D58B128A32 for ; Fri, 4 Aug 2017 01:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sunet-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtMaiemh6HHP for ; Fri, 4 Aug 2017 01:16:43 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43A65126B6D for ; Fri, 4 Aug 2017 01:16:42 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id t128so3978987lff.2 for ; Fri, 04 Aug 2017 01:16:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet-se.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=eQNiwCHzVkx/2JlKPyYepFkgKmMsqbTut9WuVzCc0dw=; b=uUljhbQ3Fcpu4zG5s5VzTUDhg87izxtij7W/WFTt9iTrGRK2UfOxMeiWNI3QZdBxtk ijTpeBCZSGCol/K2IumyPXQ60Qa29ZQybaIWbZs7SdOUxn+hc+8mKMoch+DqWX4RhRdS /ZakwkfdJjv0mQqybtxmA5DIGhKVW6OzcpEeXkQu+23At85dAJvPRKW9jBAo3tYBULdA a95pnkazfC4iSku60QmrVUYg5lfsOLIN0vihEx0c4ZnD0IL1XgwEpojdgF5J/WEAibmz E4+4Z+qQhQVQLXLkVGAgRqGJoEGFrvEnpf1R8eGZylzzsRFWQiDwJiBJEAH/dynvD2wT lrNA== 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-language:content-transfer-encoding; bh=eQNiwCHzVkx/2JlKPyYepFkgKmMsqbTut9WuVzCc0dw=; b=jcGFfv53EOAxUI0C7Xh4pWH8GyuaGccNyzZqmgkdviDpiGuFuJzWHy6lO26J0hsyfN 8fAQG1S4J8YPLTo4rpT3RHVRrL0z9piyXkwCwzH8UNHWZH8NzGpiolRpTnrs/mkFqSzZ Fz4SpYZvd3HB/1a9hUy/MH4TKcLBfdCvAD40iWfgk4TbXaph8NbioZwKlBv9u+sTfW4b Ws5by2nWefRcmIClmk6gdtCZ8qlCf5aVYyzCtK4NM+yrvuqErDwx+5CZMHYax+NeAjMS Lcm7jLUV34cnEzdKYAvSeXm1VZLfOb8vRwbKKq2Ul41pxXUXO6YN243lq/EBqqbvYgd8 i4ZQ== X-Gm-Message-State: AHYfb5hvY9x7yYlPcNLbH/VDl5VKASzsYJAbaw7T6Phnccy2jFPOK1+P B4n7RCWt6FI/LKV4cOzX+g== X-Received: by 10.46.32.80 with SMTP id g77mr662113ljg.55.1501834601208; Fri, 04 Aug 2017 01:16:41 -0700 (PDT) Received: from [192.168.1.72] (81-230-12-165-no206.tbcn.telia.com. [81.230.12.165]) by smtp.gmail.com with ESMTPSA id n72sm838094lje.51.2017.08.04.01.16.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 01:16:40 -0700 (PDT) To: "secdir@ietf.org" , draft-ietf-homenet-babel-profile.all@ietf.org, "iesg@ietf.org" From: Leif Johansson Message-ID: Date: Fri, 4 Aug 2017 10:16:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [secdir] secdir review of draft-ietf-homenet-babel-profile-02 (early review, not ready) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 08:16:46 -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 early review requested by Ray Bellis and so it is to be expected that the document isn't quite ready. The document is clearly written and although I'm not an expert on routing I can follow the requirements with little difficulty. I have primarily reviewed the document with a security focus and I have not gone looking for "nits" to fix. My main problem with the document is the trust model which is based on the notion of "internal" links. In general I think this will turn out to be harder to do in practice. As home networks grow in complexity I suspect this "binary" trust model will fail to accurately map to reality. In fact, RFC7788 lists several other categories (eg Hybrid) and although I suspect this is still a simplistic model, these other categories should be covered in this document. Finally REQ6 sais that implementations SHOULD distinguish between wired and wireless links. It seems to me that this should be a MUST given how important link classification is to the security model and also given that border classification defaults to the internal category. Cheers Leif From nobody Fri Aug 4 16:46:49 2017 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 CE8DE129ADA; Fri, 4 Aug 2017 16:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9r6kNVU4j9w; Fri, 4 Aug 2017 16:46:47 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB72C129ADD; Fri, 4 Aug 2017 16:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5880; q=dns/txt; s=iport; t=1501890407; x=1503100007; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=z4c/octoPDHa9tzmFKr4XGxiYKrcd39RyOCdSWG7lU0=; b=NnApbHBe7JcjDRk6+ghWM0VqkzWzmMRAmeBv0r531yJy7DWaZzDkqMmy KDMwHpN+r9iG8U0PTe7Wy4o/d6sHEQopAHUmgjLo1IzAadVry5CygbWIR zBo9IJNSvL+5DHtAFh+TWu68PLZZsYMy35Wro9UDGBJIhDJAH8xxllIzR g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DLAAAnBoVZ/51dJa1TBgMZAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDWoF4B44IkAeBbpYVDoIEhUcCGoQxPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQEBAQIBIxEzEgULAgEIGAICJgICAjAVEAIEDgWKJwivMIImi0YBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEdgQuCHYICgy8rgnyEQAEIAwcBHxcKJoJMMIIxBaAFApQ?= =?us-ascii?q?tkkmWAQEfOH8LdxVbAYUEARuBZ3aHJw8XgQyBDwEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,322,1498521600"; d="scan'208";a="466709863" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Aug 2017 23:46:46 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v74NkjX1019156 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Aug 2017 23:46:45 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 4 Aug 2017 19:46:45 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1210.000; Fri, 4 Aug 2017 19:46:44 -0400 From: "Brian Weis (bew)" To: stefano previdi CC: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-idr-bgp-prefix-sid.all@ietf.org" Thread-Topic: Secdir early review of draft-ietf-idr-bgp-prefix-sid-06 Thread-Index: AQHTBhG4pVaqk4yamk2QE/uj/S+OEKJ1LtWA Date: Fri, 4 Aug 2017 23:46:44 +0000 Message-ID: References: <150071889993.20425.5273428383173596948@ietfa.amsl.com> <6A05B578-F8DE-4197-97B8-82886089782B@previdi.net> In-Reply-To: <6A05B578-F8DE-4197-97B8-82886089782B@previdi.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.172.43] Content-Type: text/plain; charset="utf-8" Content-ID: <43C5CD1F64D62A44BF1CF20874C0D685@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir early review of draft-ietf-idr-bgp-prefix-sid-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 23:46:49 -0000 SGkgU3RlZmFubywNCg0KVGhhbmtzIGZvciB5b3VyIG5vdGVzIGJlbG93LCB3aGljaCBtYWtlIHNl bnNlIHRvIG1lLiBJIGRvbuKAmXQgaGF2ZSBhbnkgbW9yZSBjb21tZW50cy4gDQoNCkJyaWFuDQoN Cj4gT24gSnVsIDI2LCAyMDE3LCBhdCA2OjE4IEFNLCBzdGVmYW5vIHByZXZpZGkgPHN0ZWZhbm9A cHJldmlkaS5uZXQ+IHdyb3RlOg0KPiANCj4gSGkgQnJpYW4sDQo+IA0KPiB0aGFua3MgZm9yIHRo ZSByZXZpZXcuIFNvbWUgY29tbWVudHMgaGVyZSBiZWxvdy4NCj4gDQo+IA0KPj4gT24gSnVsIDIy LCAyMDE3LCBhdCAxMjoyMSBQTSwgQnJpYW4gV2VpcyA8YmV3QGNpc2NvLmNvbT4gd3JvdGU6DQo+ PiANCj4+IFJldmlld2VyOiBCcmlhbiBXZWlzDQo+PiBSZXZpZXcgcmVzdWx0OiBIYXMgTml0cw0K Pj4gDQo+PiBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1 cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcNCj4+IGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYg ZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gVGhlc2UgY29tbWVudHMNCj4+ IHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBh cmVhIGRpcmVjdG9ycy4gRG9jdW1lbnQNCj4+IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQg dHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwNCj4+IGNv bW1lbnRzLg0KPj4gDQo+PiBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIEJHUCBleHRlbnNpb24g dG8gc2lnbmFsIHRoZSBCR1AgUHJlZml4LVNJRCB1c2Ugd2l0aA0KPj4gU2VnbWVudCBSb3V0aW5n LiAgYXMgd2VsbCBhcyB0aGUgcnVsZXMgdG8gb3JpZ2luYXRlLCByZWNlaXZlIGFuZCBoYW5kbGUg ZXJyb3INCj4+IGNvbmRpdGlvbnMuIFRoZSBCR1AgZXh0ZW5zaW9uIGRlZmluZXMgYSBuZXcgdHlw ZSBvZiBCR1AgcGF0aCBhdHRyaWJ1dGUgcGFzc2VkDQo+PiB3aXRoaW4gQkdQLCBhbmQgZG9lcyBu b3QgY2hhbmdlIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBvZiB0aGUgQkdQIHByb3RvY29s DQo+PiBpdHNlbGYuDQo+PiANCj4+IEkgY29uc2lkZXIgdGhpcyBkb2N1bWVudCDigJxyZWFkeSB3 aXRoIG5pdHPigJ0uDQo+PiANCj4+IFRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9u IHJlYXNvbmFibHkgc3RhdGVzIHRoYXQgdGhlIHVzZSBvZiB0aGlzIEJHUA0KPj4gYXR0cmlidXRl IOKAnGluaGVyaXRzIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9uc+KAnSBvZiB0aGUgQkdQLTQg UkZDIGFzIHdlbGwgYXMNCj4+IHRoZSBSRkMgZGVmaW5pbmcgaG93IGxhYmVscyBhcmUgY2Fycmll ZCBpbiBCR1AtNC4gQXMgYW4gYXNpZGUsIHRob3NlIGRvY3VtZW50cw0KPj4gYXJlIHF1aXRlIG9s ZC4gRm9yIGV4YW1wbGUsIFJGQyA0MjcxIHNheXMgdGhhdCB0aGUgVENQLU1ENSBvcHRpb24gaXMg cmVxdWlyZWQNCj4+IHRvIGltcGxlbWVudCBmb3IgYXV0aGVudGljYXRpb24sIGJ1dCB0aGlzIGhh cyBiZWVuIHJlcGxhY2VkIGJ5IGEgbXVjaCBzdHJvbmdlcg0KPj4gYXV0aGVudGljYXRpb24gbWV0 aG9kIChUQ1AtQU8pLiBJdCB3b3VsZCBiZSBuaWNlIGlmIHdlIGhhZCBuZXdlciBzZWN1cml0eQ0K Pj4gY29uc2lkZXJhdGlvbnMgZm9yIEJHUC00IGJ1dCB0aGF0IGFkdmljZSBkb2VzbuKAmXQgYmVs b25nIGluIHRoaXMgZG9jdW1lbnQuDQo+PiANCj4+IFRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9u cyBtaWdodCBoYXZlIHNhaWQgc29tZXRoaW5nIGFib3V0IHRoZSBob3cgYW4gQVMgd291bGQNCj4+ IHByb3RlY3QgaXRzZWxmIGFnYWluc3QgYSBwZWVyIHNlbmRpbmcgdGhlIFByZWZpeC1TSUQgYXR0 cmlidXRlIGFjcm9zcyBBUw0KPj4gYm91bmRhcmllcywgYnV0IHRoYXQgdGV4dCBpcyBjb250YWlu ZWQgaW4gdXNlZnVsIHBsYWNlcyBlbHNld2hlcmUgaW4gdGhlDQo+PiBkb2N1bWVudCBhbmQgc2Vl bXMgc3VmZmljaWVudC4NCj4+IA0KPj4gSSBoYXZlIG9ubHkgb25lIG5pdCwgd2hpY2ggaXMgc29t ZSBjb25mdXNpb24gcmVnYXJkaW5nIHNjb3Bpbmcgb2YgdGhlIFNJRC4gVGhlDQo+PiBkb2N1bWVu dCBjbGVhcmx5IHN0YXRlcyB0aGF0IGEgU0lEIGhhcyBhIGxpbWl0ZWQgc2NvcGUgd2l0aGluIHRo ZSBuZXR3b3JrLCANCj4+IHdoaWNoIGlzIGltcG9ydGFudCBiZWNhdXNlIG91dHNpZGUgb2YgdGhh dCBzY29wZSBhbiBTSUQgdmFsdWUgd291bGQgaGF2ZSBhDQo+PiBkaWZmZXJlbnQgbWVhbmluZy4g VGhpcyBpcyBhIHNlY3VyaXR5ICBjb25zaWRlcmF0aW9uLCBiZWNhdXNlIGFjY2VwdGluZyBhIFNJ RA0KPj4gaW4gdGhlIHdyb25nIHNjb3BlIGNvdWxkIHBvc3NpYmx5IGNhdXNlIGEgc2VjdXJpdHkg aXNzdWUgaWYgcGFja2V0cyBhcmUNCj4+IGZvcndhcmRlZCB0byB0aGUgd3JvbmcgaWRlbnRpdHkg KGUuZywgdGhlIHBhY2tldHMgd2VyZSBpbnRlbmRlZCBmb3IgYSBmaXJld2FsbA0KPj4gd2l0aGlu IHRoZSBBUywgbm90IGEgc2VydmljZSBvdXRzaWRlIG9mIHRoZSBBUykuDQo+PiANCj4+IChhKSBT ZWN0aW9uIDUuMSBzYXlzIGl0IHNob3VsZCBub3QgYmUgYWR2ZXJ0aXNlZCBvdXRzaWRlIG9mIGFu IEFTIHVubGVzcw0KPj4g4oCcZXhwbGljaXRseSBjb25maWd1cmVkIHRvIGRvIHNv4oCdLiBJdCB3 b3VsZCBiZSBuaWNlIGlmIHRoZSBjb25kaXRpb25zIGZvcg0KPj4gZXhwbGljaXRseSBjb25maWd1 cmluZyB0aGUgU0lEIHRvIGJlIGFkdmVydGlzZWQgb3V0c2lkZSBvZiB0aGUgQVMgd2VyZQ0KPj4g bWVudGlvbmVkIGhlcmUuDQo+IA0KPiANCj4gdXN1YWxseSB3ZSBkb27igJl0IGRlZmluZSB0aGVz ZSBjb25kaXRpb24gYmVjYXVzZSB0aGV5IGFyZSByZWxhdGVkIHRvIGVhY2ggaW5kaXZpZHVhbCBv cGVyYXRvciBwb2xpY3kuIFdoYXQgd2Ugd2FudCB0byBiZSBzdXJlIG9mIGlzIHRoYXQgYW55IGNv bXBsaWFudCBpbXBsZW1lbnRhdGlvbiwgYnkgZGVmYXVsdCwgd2lsbCBub3QgcHJvcGFnYXRlIHRo ZSBhdHRyaWJ1dGUgb3V0c2lkZSB0aGUgQVMuDQo+IA0KPiBVbmRlciB3aGljaCBjb25kaXRpb25z IHByb3BhZ2F0aW9uIGlzIGFsbG93ZWQgaXMgYSBsb2NhbCBtYXR0ZXIgb2YgdGhlIG9wZXJhdG9y IGFuZCBob3cgaXQgaXMgZWZmZWN0aXZlbHkgYWNoaWV2ZWQgaXMgYSBtYXR0ZXIgb2YgbG9jYWwg aW1wbGVtZW50YXRpb24uDQo+IA0KPiANCj4+IChiKSBUaGUgbGFzdCBwYXJhZ3JhcGggb2YgU2Vj dGlvbiA4IHNheXMgaXQgaXMgYXBwbGljYWJsZSB3aXRoaW4gYW4gU1IgRG9tYWluDQo+PiAoaS5l LiwgbW9yZSB0aGFuIGFuIEFTKSwgYW5kIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNheXMgc29t ZXRoaW5nIHNpbWlsYXIuDQo+PiANCj4+IChjKSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzcGVh a3Mgb2YgbGltaXRpbmcgQkdQIFByZWZpeC1TSUQgd2l0aGluIGENCj4+IOKAnGRvbWFpbuKAnS4g SXMgdGhhdCBpbnRlbmRpbmcgdG8gc2F5IGFuIOKAnFNSIGRvbWFpbuKAnT8NCj4gDQo+IA0KPiBN b3JlIGdlbmVyYWxseSwgYnkgZG9tYWluIHdlIGludGVuZCB0aGUgc2V0IG9mIEFTIHVuZGVyIGNv bnRyb2wgb2YgdGhlIHNhbWUgb3JnYW5pemF0aW9uL29wZXJhdG9yLg0KPiANCj4+IEkgc3VzcGVj dCB3aGV0aGVyIGFuIFNJRCBzaG91bGQgYmUgYWR2ZXJ0aXNlZCBvdXRzaWRlIG9mIHRoZSBBUyBk ZXBlbmRzIG9uDQo+PiB3aGV0aGVyIGFuIEFTIGlzIHBhcnQgb2YgYW4g4oCcU1IgZG9tYWlu4oCd IG9yIG5vdCwgYW5kIHRoYXQgdGhlcmUncyBsaWtlbHkgbmV2ZXIgYQ0KPj4gZ29vZCBjYXNlIHRv IGFkdmVydGlzZSBpdCBvdXRzaWRlIG9mIGFuIEFTIHVubGVzcyBpdCBpcyBwYXJ0IG9mIGFuICJT UiBkb21haW4iLg0KPj4gQnV0IGl0IHdvdWxkIGJlIGdvb2QgaWYgdGhlcmUgd2FzIHNvbWUgdGV4 dCBjbGFyaWZ5aW5nICB0aGUgY29uZGl0aW9ucyB3aGVuIGl0DQo+PiBpcyByZWFzb25hYmxlIHRv IHNoYXJlIGFuIFNJRCBiZXR3ZWVuIEFTZXMuDQo+IA0KPiANCj4gV2VsbCwgSeKAmW0gbm90IHN1 cmUgdGhhdCB3b3VsZCBiZSBhIGdvb2QgaWRlYSBiZWNhdXNlIHRoZSBjb25kaXRpb25zIG1heSB2 YXJ5IG92ZXIgdGltZSBhbmQgd2Ugd2lsbCBuZXZlciBiZSBleGhhdXN0aXZlIGFueXdheS4NCj4g VGhhbmtzLg0KPiBzLg0KPiANCj4gDQo+PiANCj4gDQoNCi0tIA0KQnJpYW4gV2Vpcw0KU2VjdXJp dHksIENTRywgQ2lzY28gU3lzdGVtcw0KVGVsZXBob25lOiArMSA0MDggNTI2IDQ3OTYNCkVtYWls OiBiZXdAY2lzY28uY29tDQoNCg== From nobody Sat Aug 5 08:49:14 2017 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 095C0131D32; Sat, 5 Aug 2017 08:49:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yaron Sheffer To: Cc: draft-weis-gdoi-rekey-ack.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150194814585.18635.3104789196001873381@ietfa.amsl.com> Date: Sat, 05 Aug 2017 08:49:05 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-weis-gdoi-rekey-ack-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2017 15:49:06 -0000 Reviewer: Yaron Sheffer Review result: Has Issues Summary: this reviewer is not clear about the value of the push-ack (compared to a pull) and about the strategy that was chosen. * "For example, a GCKS policy can use the acknowledgements to determine [...] which members may no longer be members of the group." This sentence is very confusing: when are members not members? * The new protocol capability is defined as optional, but really isn't. "A GM receiving the KEK_ACK_REQUESTED attribute can choose to ignore it, thus appearing as if it does not support the KEK_ACK_REQUESTED attribute. However, GCKS policy may consider a non-responsive GM to no longer desire to be a member of the group." So if you want to play the game, you MUST support the new attribute. * I'm puzzled at the overall protocol. Being able to send ACKs is a GM software capability. Why not have the GM announce this capability when it initially registers to the GCKS? Then the GCKS would know what to expect, whereas with the current protocol it is left waiting for an ACK that may never come, either because the GM is dead or because it just doesn't feel like responding. Add the long waits (jitter of "a few seconds" and potential retries), and this looks like a far from optimal management experience. * 2.2: "This is a private key" - to avoid confusion, I suggest: "This is a secret symmetric key" (if this is indeed the case). Obviously using the same key for encryption and for HMAC is not a best practice. * Sec. 5: ACK messages can also be duplicated in the network. I suggest to add a sentence describing what the GCKS should do in this case. * Sec. 6: I am confused about the notion of "jitter" here. If the PUSH messages are sent as multicast (the recommended alternative AFAICT), I'm not sure about the benefit of using multicast, given that each recipient responds with a unicast ACK. And if the PUSH is unicast, there should be no reason for a jitter as the sender can throttle the PUSH messages as necessary. * Moreover, everything would be much more predictable if the GCKS could indicate if a jitter is expected and how much of a jitter (based on size of the group, network throughput, and queue length). Specifically, this would allow the GCKS to tell how long it should wait for an ACK. * Cryptographic agility: this document specifies only one algorithm for the HASH value, and says that if a new algorithm is needed, there will be a new KEK_ACK_REQUESTED payload defined. However to make sure that this really "works", we need to define whether multiple such payloads can be sent simultaneously (if e.g. some GMs still support the old algorithm) and what's the expected behavior. I would suggest to define an additional SHA-512 payload just to make for a concrete example. From nobody Mon Aug 7 13:42:05 2017 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 35C5D132474; Mon, 7 Aug 2017 13:41:57 -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, HTML_MESSAGE=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 9T2nxBMN11gJ; Mon, 7 Aug 2017 13:41:55 -0700 (PDT) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [IPv6:2001:480:20:118:118::211]) (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 D7EB2132405; Mon, 7 Aug 2017 13:41:51 -0700 (PDT) Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id v77KfnMp024580 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 7 Aug 2017 16:41:49 -0400 From: Catherine Meadows Content-Type: multipart/alternative; boundary="Apple-Mail=_8C757580-2841-4AF9-91B3-60A2F86A6ABA" Date: Mon, 7 Aug 2017 16:41:49 -0400 Message-Id: <1EC75ACD-C8A2-4B64-B2D9-7BE44E47FCEB@nrl.navy.mil> To: iesg@ietf.org, secdir@ietf.org, draft-ietf-opsawg-capwap-alt-tunnel.all@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Archived-At: Subject: [secdir] review of draft-ietf-opsawg-capwap-alt-tunnel=09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 20:41:57 -0000 --Apple-Mail=_8C757580-2841-4AF9-91B3-60A2F86A6ABA Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii 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 authors have fully addressed all the concerns I had in my last review. I consider this draft Ready. Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil --Apple-Mail=_8C757580-2841-4AF9-91B3-60A2F86A6ABA Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
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 authors have fully addressed all the concerns I had in my last review.
I consider this draft Ready.


Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942
email: catherine.meadows@nrl.navy.mil

--Apple-Mail=_8C757580-2841-4AF9-91B3-60A2F86A6ABA-- From nobody Tue Aug 8 13:10:34 2017 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 B39591329AF; Tue, 8 Aug 2017 13:10:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rich Salz To: Cc: draft-ietf-mmusic-dtls-sdp.all@ietf.org, ietf@ietf.org, mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150222302662.12343.4196075098931297625@ietfa.amsl.com> Date: Tue, 08 Aug 2017 13:10:26 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-mmusic-dtls-sdp-28 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 20:10:27 -0000 Reviewer: Rich Salz Review result: Ready Issues I raised in the -22 review have been addressed, and a quick read showed nothing new to complain about :) From nobody Tue Aug 8 14:11:56 2017 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 6D9661325CD; Tue, 8 Aug 2017 14:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Ja05cenR89oE; Tue, 8 Aug 2017 14:11:39 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E36241325EB; Tue, 8 Aug 2017 14:11:38 -0700 (PDT) X-AuditID: c1b4fb3a-81bff70000001b2f-a1-598a2908b63a Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A8.A2.06959.8092A895; Tue, 8 Aug 2017 23:11:36 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.91]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0352.000; Tue, 8 Aug 2017 23:11:36 +0200 From: Christer Holmberg To: Rich Salz , "secdir@ietf.org" CC: "draft-ietf-mmusic-dtls-sdp.all@ietf.org" , "ietf@ietf.org" , "mmusic@ietf.org" Thread-Topic: Secdir telechat review of draft-ietf-mmusic-dtls-sdp-28 Thread-Index: AQHTEIJhHC/9q3fc0USxdaOFO/icVqJ69OJg Date: Tue, 8 Aug 2017 21:11:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CCB48D9@ESESSMB109.ericsson.se> References: <150222302662.12343.4196075098931297625@ietfa.amsl.com> In-Reply-To: <150222302662.12343.4196075098931297625@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZGbHdQ5dDsyvS4EmjvsWOuzvYLJ5tnM9i MXX5YxaL/1s6WSw+LHzI4sDqMfnIAmaPJUt+MgUwRXHZpKTmZJalFunbJXBlnFxdWdDFWjH/ yRLGBsYfLF2MnBwSAiYSD7d/ZOpi5OIQEjjCKLHq1zdWCGcRo8T3XRfZuxg5ONgELCS6/2mD NIgIuEps6/3MDFLDLLAQqObsJ0aQhLCAi8SF22eZYIr+bnvKCGEbSWxYeA3MZhFQkVjwdSHY Zl4BX4lzD1aAxYUEnCXu3t3OCmJzAs15snwRWA2jgJjE91NrwGYyC4hL3HoynwniagGJJXvO M0PYohIvH/9jhbCVJBbd/swEcjOzgKbE+l36EK2KElO6H7JDrBWUODnzCcsERtFZSKbOQuiY haRjFpKOBYwsqxhFi1OLi3PTjYz0Uosyk4uL8/P08lJLNjECI+jglt9WOxgPPnc8xCjAwajE w3tmSWekEGtiWXFl7iFGCQ5mJRFeM42uSCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8DvsuRAgJ pCeWpGanphakFsFkmTg4pRoYtR/M5lqew9SXYXpO2cYzNfOMyneOuua0V/q+ffLqpa/FP7PO vfF7Vv22fPna/GV61/cetD9WcWPvL6tVfs+YCha0MXpdv20vtOkQ94+3obPf7BKborZyr2ut u5CDyppoXkvZO/1Tkhc+X7lazlmv0Pn7u5jrp2bJGM2qLbhq1JNxsFK70FlViaU4I9FQi7mo OBEAdNkJaJwCAAA= Archived-At: Subject: Re: [secdir] Secdir telechat review of draft-ietf-mmusic-dtls-sdp-28 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 21:11:42 -0000 VGhhbmtzLCBSaWNoISA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogUmljaCBTYWx6IFttYWlsdG86cnNhbHpAYWthbWFpLmNvbV0g DQpTZW50OiAwOCBBdWd1c3QgMjAxNyAyMjoxMA0KVG86IHNlY2RpckBpZXRmLm9yZw0KQ2M6IGRy YWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwLmFsbEBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsgbW11 c2ljQGlldGYub3JnDQpTdWJqZWN0OiBTZWNkaXIgdGVsZWNoYXQgcmV2aWV3IG9mIGRyYWZ0LWll dGYtbW11c2ljLWR0bHMtc2RwLTI4DQoNClJldmlld2VyOiBSaWNoIFNhbHoNClJldmlldyByZXN1 bHQ6IFJlYWR5DQoNCklzc3VlcyBJIHJhaXNlZCBpbiB0aGUgLTIyIHJldmlldyBoYXZlIGJlZW4g YWRkcmVzc2VkLCBhbmQgYSBxdWljayByZWFkIHNob3dlZCBub3RoaW5nIG5ldyB0byBjb21wbGFp biBhYm91dCA6KQ0KDQoNCg== From nobody Tue Aug 8 18:56:49 2017 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 E8AD6131CEC; Tue, 8 Aug 2017 18:56:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Paul Hoffman To: Cc: slim@ietf.org, draft-ietf-slim-multilangcontent.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150224380784.3639.13154779501460690796@ietfa.amsl.com> Date: Tue, 08 Aug 2017 18:56:47 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-slim-multilangcontent-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 01:56:48 -0000 Reviewer: Paul Hoffman Review result: Ready This document simply allows a MIME message to say that it contains more than one (human) language. It follows the MIME spec closely and makes a completely obvious addition to the MIME spec. The two security considerations listed are both far stretches; this protocol extension does not create any significant security issues. From nobody Wed Aug 9 03:04:44 2017 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 B7E82126C22; Wed, 9 Aug 2017 03:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 L_sWiKomw-AW; Wed, 9 Aug 2017 03:04:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8049F124234; Wed, 9 Aug 2017 03:04:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DTA49082; Wed, 09 Aug 2017 10:04:38 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 9 Aug 2017 11:04:37 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Wed, 9 Aug 2017 18:04:33 +0800 From: Duzongpeng To: Catherine Meadows CC: "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-opsawg-capwap-alt-tunnel.all@ietf.org" Thread-Topic: review of draft-ietf-opsawg-capwap-alt-tunnel=09 Thread-Index: AQHTD72lXBdCSIgEJU2TSkPXzcrmhaJ7zieQ Date: Wed, 9 Aug 2017 10:04:32 +0000 Message-ID: References: <1EC75ACD-C8A2-4B64-B2D9-7BE44E47FCEB@nrl.navy.mil> In-Reply-To: <1EC75ACD-C8A2-4B64-B2D9-7BE44E47FCEB@nrl.navy.mil> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.149.226] Content-Type: multipart/alternative; boundary="_000_BAFEC9523F57BC48A51C20226A5589575FF1BB13nkgeml514mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.598ADE36.003A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: dcfb160462930bb374adc5f7815b8164 Archived-At: Subject: Re: [secdir] review of draft-ietf-opsawg-capwap-alt-tunnel=09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 10:04:43 -0000 --_000_BAFEC9523F57BC48A51C20226A5589575FF1BB13nkgeml514mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you very much for the review. From: Catherine Meadows [mailto:catherine.meadows@nrl.navy.mil] Sent: Tuesday, August 08, 2017 4:42 AM To: iesg@ietf.org; secdir@ietf.org; draft-ietf-opsawg-capwap-alt-tunnel.all= @ietf.org Cc: Catherine Meadows Subject: review of draft-ietf-opsawg-capwap-alt-tunnel=3D09 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 authors have fully addressed all the concerns I had in my last review. I consider this draft Ready. Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil --_000_BAFEC9523F57BC48A51C20226A5589575FF1BB13nkgeml514mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank you = very much for the review.

 = ;

From: Catherine Meadows [mailto:catherine.meadows@nrl.navy.= mil]
Sent: Tuesday, August 08, 2017 4:42 AM
To: iesg@ietf.org; secdir@ietf.org; draft-ietf-opsawg-capwap-alt-tun= nel.all@ietf.org
Cc: Catherine Meadows
Subject: review of draft-ietf-opsawg-capwap-alt-tunnel=3D09

 

I have reviewed this document a= s part of the security directorate's 

ongoing effort to review all IE= TF 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 ot= her last call comments.

 

The authors have fully addresse= d all the concerns I had in my last review.

I consider this draft Ready.

 

 

Cathe= rine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942
email: catherine.mea= dows@nrl.navy.mil

 

--_000_BAFEC9523F57BC48A51C20226A5589575FF1BB13nkgeml514mbxchi_-- From nobody Thu Aug 10 13:06:56 2017 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 82FDB13243C for ; Thu, 10 Aug 2017 13:06:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Reply-to: secdir-secretary@mit.edu Message-ID: <150239561553.11871.16120629316326837799.idtracker@ietfa.amsl.com> Date: Thu, 10 Aug 2017 13:06:55 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 20:06:55 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2017-08-17 Reviewer LC end Draft Alan DeKok 2017-05-14 draft-ietf-calext-caldav-attachments-03 Steve Hanna 2017-08-09 draft-ietf-codec-opus-update-08 Dan Harkins 2017-08-09 draft-ietf-bess-evpn-etree-12 For telechat 2017-08-31 Reviewer LC end Draft Ólafur Guðmundsson 2017-08-15 draft-ietf-sidr-rpki-validation-reconsidered-08 Benjamin Kaduk None draft-ietf-teas-lsp-diversity-08 Charlie Kaufman None draft-ietf-pce-rfc6006bis-03 Tero Kivinen 2017-08-24 draft-ietf-pals-p2mp-pw-03 Ben Laurie 2017-08-23 draft-ietf-pce-pce-initiated-lsp-10 Last calls: Reviewer LC end Draft Alan DeKok R2017-05-26 draft-nottingham-rfc5988bis-07 Donald Eastlake 2017-07-30 draft-ietf-curdle-ssh-modp-dh-sha2-07 Shawn Emery 2017-07-30 draft-ietf-curdle-ssh-ext-info-11 Daniel Franke 2017-07-30 draft-ietf-curdle-ssh-dh-group-exchange-05 Daniel Gillmor 2017-07-30 draft-ietf-curdle-des-des-des-die-die-die-04 Phillip Hallam-Baker 2017-08-11 draft-ietf-rtcweb-jsep-21 Christian Huitema None draft-ietf-sfc-nsh-18 Scott Kelly 2017-08-25 draft-ietf-tsvwg-sctp-ndata-12 Watson Ladd 2017-08-24 draft-ietf-nfsv4-rfc5667bis-13 Barry Leiba 2017-08-23 draft-ietf-mboned-interdomain-peering-bcp-10 Klaas Wierenga 2017-07-12 draft-ietf-mpls-rfc3107bis-03 Tom Yu 2017-07-25 draft-ietf-lamps-rfc5280-i18n-update-02 Tom Yu 2017-02-20 draft-ietf-slim-negotiating-human-language-13 Early review requests: Reviewer Due Draft Daniel Gillmor 2016-02-01 draft-ietf-rtcweb-security-08 Next in the reviewer rotation: Chris Lonvick David Mandelberg Catherine Meadows Alexey Melnikov Daniel Migault Matthew Miller Adam Montville Russ Mundy Sandra Murphy Yoav Nir From nobody Fri Aug 11 06:38:55 2017 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 3D7F913244B; Fri, 11 Aug 2017 06:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=infineon.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 jpcrshbPodRj; Fri, 11 Aug 2017 06:38:52 -0700 (PDT) Received: from smtp11.infineon.com (smtp11.infineon.com [IPv6:2a00:18f0:1e00:4::5]) (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 C6D3A13214D; Fri, 11 Aug 2017 06:38:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=infineon.com; i=@infineon.com; q=dns/txt; s=IFXMAIL; t=1502458732; x=1533994732; h=from:to:subject:date:message-id:mime-version; bh=hP2Iu/sE03bhrWTpPyTtSyD3IDomvkfvIs3tFruJdWE=; b=Mw21JpyOin/6c+TMxtyGgSGxAgE96clsI518aN6vC3A6hsWNwMpIe9uD ddvQNHYHzD7tETn+yADTtLQnMxRJrxBkEa7NDaFFU7TXBeE5m86i3PZgm T5cnKk3wPQTlWZytJkHTUfEl42bid64E/yVEe6yTs11BEx6pVWxmapm+0 I=; X-SBRS: None Received: from unknown (HELO mucxv002.muc.infineon.com) ([172.23.11.17]) by smtp11.infineon.com with ESMTP/TLS/AES256-GCM-SHA384; 11 Aug 2017 15:38:49 +0200 Received: from MUCSE607.infineon.com (mucse607.infineon.com [172.23.7.108]) by mucxv002.muc.infineon.com (Postfix) with ESMTPS; Fri, 11 Aug 2017 15:38:48 +0200 (CEST) Received: from MUCSE610.infineon.com (172.23.7.111) by MUCSE607.infineon.com (172.23.7.108) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 11 Aug 2017 15:38:48 +0200 Received: from MUCSE609.infineon.com (172.23.7.110) by MUCSE610.infineon.com (172.23.7.111) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 11 Aug 2017 15:38:47 +0200 Received: from MUCSE609.infineon.com ([172.23.103.71]) by MUCSE609.infineon.com ([172.23.103.71]) with mapi id 15.00.1263.000; Fri, 11 Aug 2017 15:38:47 +0200 From: To: , , Thread-Topic: SecDir Last Call Review of draft-ietf-codec-opus-update-08 Thread-Index: AdMSlVHlzvP1oT9WQReYKDkXHAsw4g== Date: Fri, 11 Aug 2017 13:38:46 +0000 Message-ID: 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.23.8.247] Content-Type: multipart/alternative; boundary="_000_d86f35424f95417d8298e4a5fdf9fef7MUCSE609infineoncom_" MIME-Version: 1.0 Archived-At: Subject: [secdir] SecDir Last Call Review of draft-ietf-codec-opus-update-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 13:38:54 -0000 --_000_d86f35424f95417d8298e4a5fdf9fef7MUCSE609infineoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoin= g effort to review all IETF documents being processed by the IESG. These c= omments were written primarily for the benefit of the security area directo= rs. Document editors and WG chairs should treat these comments just like a= ny other last call comments. I am not an expert in codecs but I do have con= siderable experience with C coding and with security, both of which are rel= evant topics for this review. The summary of the review is Ready with Issues. This draft fixes bugs in the reference implementation of the Opus codec (de= fined in RFC 6716). Some of the bugs fixed have previously been identified = as security vulnerabilities (CVE-2013-0899 and CVE-2017-0381). RFC 6716 def= ines the source code of the reference implementation to be normative, rathe= r than the English text in the RFC. This means that the code in RFC 6716 mi= ght well be copied by implementers, thus exposing them to these vulnerabili= ties. Here are the substantive issues: 1) In section 5, the third problem with the SILK resampler involves a possi= ble buffer overrun. This bug looks like to me like it could result in unaut= horized writes to the stack beyond the end of the buffer. These writes coul= d be used for return-oriented programming, to modify variables stored in th= e stack, or even to execute arbitrary code. The draft says that "the code n= ever produced any error in testing" and "suggests that in practice [...] no= ne of the issues above was ever a problem." Many security vulnerabilities d= o not produce any errors in testing but lead to serious security problems. = Unless the authors can prove that the bug is harmless, they should not mini= mize its potential impact. Therefore, I suggest that this language in the d= raft be changed to avoid minimizing the impact of the bug in any way. Rathe= r, the draft should warn that a buffer overrun permitting writes into the s= tack is a dangerous vulnerability that can in some cases lead to arbitrary = code execution, although the authors are not aware at this time of any succ= essful exploits. Minimizing the impact of the bug may discourage readers fr= om rapidly deploying the fix or adopting other countermeasures. 2) Section 7 discusses and fixes the CVE-2017-0381 vulnerability. Although = the CVE description says that "A remote code execution vulnerability in sil= k/NLSF_stabilize.c in libopus in Mediaserver could enable an attacker using= a specially crafted file to cause memory corruption during media file and = data processing.", subsequent analysis by many parties (e.g., https://bugs.= debian.org/cgi-bin/bugreport.cgi?bug=3D851612#10) indicates that this vulne= rability cannot lead to remote code execution. Rather, it can only result i= n an illegal read access to the stack. That's not good but it's not nearly = as bad as remote code execution. The draft correctly states that "The end r= esult of the wrap-around is an illegal read access on the stack". The text = in the CVE description should be corrected, if possible. 3) Section 12 says that "CVE-2017-0381 [...] could not be exploited in any = way (despite the claims in the CVE), unless the read-only table was somehow= placed very close to sensitive data, which is highly unlikely." Those who = write library code don't control the placement of input parameters such as = buffers. That's especially true for open source reference code that may be = adapted in almost any way. Therefore, the statement that the CVE could not = be exploited in any way seems to be a stretch. Rather, it would be better t= o warn about the worst possible risks of the bug than to minimize its impac= t. Still, there would be some benefit in explaining that community analysis= of this vulnerability has not supported the claim in the CVE that it enabl= es remote code execution. Also, here are a few nits: * At the end of section 1, the text "has a SHA1" should be "has a SHA-1 has= h of". * In section 10 at the end of the first paragraph, "artefacts" should be "a= rtifacts". * In section 11 just before the hexadecimal values, "SHA1 hash" should be "= SHA-1 hashes". * In section 12, "theoretically cause information leak" should be "theoreti= cally cause an information leak". This text is split by a line break so sea= rch for "information leak". --_000_d86f35424f95417d8298e4a5fdf9fef7MUCSE609infineoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have reviewed this doc= ument as part of the security directorate's  ongoing effort to review = all IETF documents being processed by the IESG.  These comments were w= ritten primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these co= mments just like any other last call comments. I am not an expert in codecs= but I do have considerable experience with C coding and with security, bot= h of which are relevant topics for this review.

 =

The summary of the revie= w is Ready with Issues.

 =

This draft fixes bugs in= the reference implementation of the Opus codec (defined in RFC 6716). Some= of the bugs fixed have previously been identified as security vulnerabilit= ies (CVE-2013-0899 and CVE-2017-0381). RFC 6716 defines the source code of the reference implementation to be nor= mative, rather than the English text in the RFC. This means that the code i= n RFC 6716 might well be copied by implementers, thus exposing them to thes= e vulnerabilities.

 =

Here are the substantive= issues:

 =

1) In section 5, the thi= rd problem with the SILK resampler involves a possible buffer overrun. This= bug looks like to me like it could result in unauthorized writes to the st= ack beyond the end of the buffer. These writes could be used for return-oriented programming, to modify variables = stored in the stack, or even to execute arbitrary code. The draft says that= “the code never produced any error in testing” and “sugg= ests that in practice […] none of the issues above was ever a problem.” Many security vulnerabilities do not produce an= y errors in testing but lead to serious security problems. Unless the autho= rs can prove that the bug is harmless, they should not minimize its potenti= al impact. Therefore, I suggest that this language in the draft be changed to avoid minimizing the impact of the bug= in any way. Rather, the draft should warn that a buffer overrun permitting= writes into the stack is a dangerous vulnerability that can in some cases = lead to arbitrary code execution, although the authors are not aware at this time of any successful exploits= . Minimizing the impact of the bug may discourage readers from rapidly depl= oying the fix or adopting other countermeasures.

 =

2) Section 7 discusses a= nd fixes the CVE-2017-0381 vulnerability. Although the CVE description says= that “A remote code execution vulnerability in silk/NLSF_stabilize.c= in libopus in Mediaserver could enable an attacker using a specially crafted file to cause memory corruption during = media file and data processing.”, subsequent analysis by many parties= (e.g., h= ttps://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D851612#10) indicates= that this vulnerability cannot lead to remote code execution. Rather, it c= an only result in an illegal read access to the stack. That’s not good but it’s not nearly as bad as re= mote code execution. The draft correctly states that “The end result = of the wrap-around is an illegal read access on the stack”. The text = in the CVE description should be corrected, if possible.<= /p>

 =

3) Section 12 says that = “CVE-2017-0381 […] could not be exploited in any way (despite t= he claims in the CVE), unless the read-only table was somehow placed very c= lose to sensitive data, which is highly unlikely.” Those who write library code don’t control the placement of input pa= rameters such as buffers. That’s especially true for open source refe= rence code that may be adapted in almost any way. Therefore, the statement = that the CVE could not be exploited in any way seems to be a stretch. Rather, it would be better to warn about the worst = possible risks of the bug than to minimize its impact. Still, there would b= e some benefit in explaining that community analysis of this vulnerability = has not supported the claim in the CVE that it enables remote code execution.

 =

Also, here are a few nit= s:

 =

* At the end of section = 1, the text “has a SHA1” should be “has a SHA-1 hash of&#= 8221;.

* In section 10 at the e= nd of the first paragraph, “artefacts” should be “artifac= ts”.

* In section 11 just bef= ore the hexadecimal values, “SHA1 hash” should be “SHA-1 = hashes”.

* In section 12, “= theoretically cause information leak” should be “theoretically = cause an information leak”. This text is split by a line break so sea= rch for “information leak”.

 =

--_000_d86f35424f95417d8298e4a5fdf9fef7MUCSE609infineoncom_-- From nobody Fri Aug 11 15:21:30 2017 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 8A7BE1326AC for ; Fri, 11 Aug 2017 15:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 U79_JwbdOZCW for ; Fri, 11 Aug 2017 15:21:12 -0700 (PDT) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 E99CA1326AE for ; Fri, 11 Aug 2017 15:21:10 -0700 (PDT) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx3.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1dgIIh-0003Gf-3m for secdir@ietf.org; Sat, 12 Aug 2017 00:21:09 +0200 Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1dgIIc-0008Is-U8 for secdir@ietf.org; Fri, 11 Aug 2017 18:21:00 -0400 Received: (qmail 14990 invoked from network); 11 Aug 2017 22:20:57 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.186]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 11 Aug 2017 22:20:57 -0000 From: Christian Huitema To: The IESG , secdir@ietf.org, draft-ietf-sfc-nsh.all@ietf.org Cc: IETF Discussion Mailing List Message-ID: <2ad0274f-3385-136d-794b-082192393ebf@huitema.net> Date: Fri, 11 Aug 2017 15:20:53 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: 168.144.250.232 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.19) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJackVDEeh/s63C3hq8BP19aND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23Et8EmwAEDHt/bpQlSQ4WzenAK+xr92ZGK1ua sQ+8Dmh3cwQzo/7QWl8r4aborZJuYOEkjsX7F8KmpUaZQHV+ST61TfxIvi8LwOTvVrRIhaC2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpIuW2VxLnS94njDgTNmyTXH6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGyb5pE1hv2y98CU17gG3OzcHeNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj237jnExji3pN9ZwHGBHd3j58WezJa7xDQcOg5ET5/LmCvakjSWDcjZyDseb0cBFM1p7J 0ZI2Cud2W8ULqpclZpX6+ln3SmdyWNNJvR4I+Hp8ZTqmtKYOlQxywq7X9AiLTGikfdoogjfTpZPs zrPFazX6bpsmzT5sWVD4sfkDnyejRRklgDtVC2Xqa4QCRhTuoCmXPUJkXUk8tGhJsBnmMDbaKcNO SCytRyeT1c4b6jF7f/DKzfOCXnJQjcl9DhaIFtwGXh1z3jjhvha4XAPJdhEh0i13zjCiwPgdt77s k1WBMw== X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: [secdir] SECDIR review of draft-ietf-sfc-nsh-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 22:21:13 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. The summary of this review is a puzzled reviewer. Why was I asked to=20 review this? Why is the IETF even working on such specifications? What does this have to do with the Internet? And why such disregard for privacy and security? In any case, this document has significant issues. It does not explaining where exactly the proposed Network Service Header would be inserted (MPLS or IPv6?). The security provisions boil down to lip-service mentions of IPSEC, and that's way insufficient given the nature of the protocol. Sometimes you read a document and it gives you a glimpse of an alternate universe in which the Internet has been replaced by a mad pile-up of middle boxes. Of course, they will not be called that. Instead, we will speak of "service functions" providing such essential features as NAT and deep packet inspection. I suppose that censorship and surveillance are not desirable key words in marketing brochures, and that metadata collection and the insertion of adverts are better described in yet to be published extensions. As far as I can tell, the so called "Service Function Chaining Architecture" tries to standardize this pile-up of middleboxes, so that service providers can procure them from multiple vendors. The draft that I am reviewing, draft-ietf-sfc-nsh-18, defines a clear-text "network service header" (NSH) that would inserted between the "transport" used in the domain and the IPv4 or IPv6 packet itself. Boxes could look at this header, add metadata to it, and forward it to other boxes along a "service path". I mentioned IPv4 or IPv6, but there are also provisions for passing pure NSH information, probably for maintaining the "service path", or passing Ethernet, MPLS or experimental frames, because why not.= The specification itself is appropriately baroque, with the header composed of three components and multiple options, but the basic idea is to allow different boxes to see the packet so they can read, update and process the metadata. As far as I can tell, there are no serious attempt to provide any kind of security or privacy protection except maybe some basic ingress filtering, which means that the metadata can be observed by any entity able to tap the path, or can be spoofed by any system inserted on the path, such as for example a virus infected box. The only security reference is a short note that deployments "could use IPSEC", through a token reference to RFC 6071. When first reading the document, I was under the impression that the "transport" used in the domain would be some kind of close layer 2 system, MPLS or maybe Ethernet. That would give some assurance that the collection of middle boxes would be part of a somewhat controlled domain. It was only the reference to IPSEC that enlightened me. If IPSEC is plausible, it probably means that the packet would be composed of an IP header, the SFH, and the original IP payload. So the proposed usage implies carrying metadata like subscriber information and identification of content in clear text over long distance paths. What could possibly go wrong? And if that was not enough, imagine what an adversary could achieve by spoofing the service packets. Of course, the same threats would still apply if the protocol was strictly carried over layer 2, as several adversaries are quite capable of snooping and spoofing layer 2 traffic. Coming at the end of this review, I hesitate between two options. One would be to just express my disgust, wash my hands, and hope that the effort will fail under its own weight, maybe after a couple of catastrophic security failures. The other option is to provide some advice on how to solve the most blatant issues. In a spirit of cooperation, I choose the latter, and here is the two steps advice: The first step to better security and privacy there would be to present the practical deployment conditions. I could only make guesses, and that's silly. There should be some kind of diagram explaining how the SFH is inserted in packets, and where it sits between Ethernet, MPLS and IP. The next step is to develop a protection model. Given that the goal of the architecture is to decorate the packets with sensitive metadata, there need to be some thinking about who should be able to see it. How would path encryption like IPSEC be deployed? Should all elements on path really be able to access all metadata, or should some of it be further protected? Please fix that before the document is published. --=20 Christian Huitema From nobody Mon Aug 14 13:45:43 2017 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 A22A0132427 for ; Mon, 14 Aug 2017 13:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jmvalin-ca.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSnSCNOKmTUm for ; Mon, 14 Aug 2017 13:45:38 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 02B90126E64 for ; Mon, 14 Aug 2017 13:45:37 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id 76so1331210ith.0 for ; Mon, 14 Aug 2017 13:45:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jmvalin-ca.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=SuSAttQ1xG8GwF2Et0dPekxFxNYUIxqw0jxlLyjkL/0=; b=MKZEgKLSRLv7VT4t/kRlsBSBwKXbrQQTdHquFuvD2EQnWyxvJ+XJzrfmR8zR5nSI2c 3zSzEowa8CiEaWvtxxfYqEolFoKDVuXW5G0tXIRyZYrKj4Lfl5PACIa3HBBVq5Rh+t2P pWxqcGsw8PX4tqkqB0ABAGJGGLKdaOMpC8KuljIiQOb43FWkZF93ehEd9KRO4yiuOjkt fCxodlUQ2QUbH78S28mv2LbIK+5p2D3xi0pYFoLCe62/Ji5yirRkTja7WL9ynarHirPb lDge0uDuJyHePosJANPHqxHXmHnAF/ewQCjFjl/yjjQFralnMiLx9HARZh8PFwKU39PA 8TOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=SuSAttQ1xG8GwF2Et0dPekxFxNYUIxqw0jxlLyjkL/0=; b=Bv013RUo38V7Q+y6A4p8XMqnIeMz7Gh0apn6rutlIW1VHf0s4lWFPafd1OuWMMEr1g NQ8tkFsiEza+oEZkn+Mlyvh6TCRT+jSCKZQH4DDR3h/qZVuauCZqFPFb0TKsmK9cVFJS V0E9YEassVgVUbMpnlmecYuHwi+4GMGcJfZf01db/dEYJIJrE8GpSNomt8WDjATvobYp 27VvHKvC6ypB6gp89qLXF2PKJel3GJhmz4QQif/Vu3pTYlyg1ZeMMsd1wDZw04J0GRcN 1q8h238Wy2y7HqJ5UV6W1qMLh3c9AV9L4/6aIBmlAZ8lWcjhomo0k0JI47El9qF7++YS sRBw== X-Gm-Message-State: AHYfb5jeLXLK5pnA3a5WrM5p7nZobqKgrDAL8TjNE2GyZxfogIzyiBLE NxuGi3Z1Uft3d3iW X-Received: by 10.36.77.134 with SMTP id l128mr221978itb.44.1502743537218; Mon, 14 Aug 2017 13:45:37 -0700 (PDT) Received: from panoramix.jmvalin.ca (modemcable067.31-56-74.mc.videotron.ca. [74.56.31.67]) by smtp.gmail.com with ESMTPSA id h76sm3944894ioe.28.2017.08.14.13.45.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Aug 2017 13:45:36 -0700 (PDT) To: Steve.Hanna@infineon.com, iesg@ietf.org, secdir@ietf.org, draft-ietf-codec-opus-update.all@ietf.org References: From: Jean-Marc Valin Message-ID: Date: Mon, 14 Aug 2017 16:45:34 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [secdir] SecDir Last Call Review of draft-ietf-codec-opus-update-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 20:45:41 -0000 Hi Steve, Thanks for the review and useful comments. See below. On 11/08/17 09:38 AM, Steve.Hanna@infineon.com wrote: > 1) In section 5, the third problem with the SILK resampler involves a > possible buffer overrun. This bug looks like to me like it could result > in unauthorized writes to the stack beyond the end of the buffer. These > writes could be used for return-oriented programming, to modify > variables stored in the stack, or even to execute arbitrary code. The > draft says that the code never produced any error in testing and > suggests that in practice [] none of the issues above was ever a > problem. Many security vulnerabilities do not produce any errors in > testing but lead to serious security problems. Unless the authors can > prove that the bug is harmless, they should not minimize its potential > impact. Therefore, I suggest that this language in the draft be changed > to avoid minimizing the impact of the bug in any way. Rather, the draft > should warn that a buffer overrun permitting writes into the stack is a > dangerous vulnerability that can in some cases lead to arbitrary code > execution, although the authors are not aware at this time of any > successful exploits. Minimizing the impact of the bug may discourage > readers from rapidly deploying the fix or adopting other countermeasures. So I spent some time to evaluate the consequences of the problem and came to the conclusion that no out-of-bounds read or write is possible. That's because the buffers involved (buf and S->sFIR) are actually larger than they needed to be for the code to work. So the extra bytes copied do not overrun any of the buffers. I'll update the text to state to make it clear that the bug is harmless. It's still good to fix it because it *does* look a bit scary until you've done the full analysis. > 2) Section 7 discusses and fixes the CVE-2017-0381 vulnerability. > Although the CVE description says that A remote code execution > vulnerability in silk/NLSF_stabilize.c in libopus in Mediaserver could > enable an attacker using a specially crafted file to cause memory > corruption during media file and data processing., subsequent analysis > by many parties (e.g., > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851612#10) indicates > that this vulnerability cannot lead to remote code execution. Rather, it > can only result in an illegal read access to the stack. Thats not good > but its not nearly as bad as remote code execution. The draft correctly > states that The end result of the wrap-around is an illegal read access > on the stack. The text in the CVE description should be corrected, if > possible. I tried getting the CVE corrected at the time, but didn't get far aside from having the severity lowered slightly. It's worth noting that the CVE came in about 6 months after the bug was fixed. > 3) Section 12 says that CVE-2017-0381 [] could not be exploited in any > way (despite the claims in the CVE), unless the read-only table was > somehow placed very close to sensitive data, which is highly unlikely. > Those who write library code dont control the placement of input > parameters such as buffers. Thats especially true for open source > reference code that may be adapted in almost any way. Therefore, the > statement that the CVE could not be exploited in any way seems to be a > stretch. Rather, it would be better to warn about the worst possible > risks of the bug than to minimize its impact. Still, there would be some > benefit in explaining that community analysis of this vulnerability has > not supported the claim in the CVE that it enables remote code execution. Here's the revised text I would suggest: "CVE-2017-0381 is fixed by Section 7 and can only result in a 16-bit out-of-bounds read to a fixed location 256 bytes before a constant table. That location would normally be part of an executable's read-only data segment, but if that is not the case, the bug could at worst results in either a crash or the leakage of 16 bits of information from that fixed memory location (if the attacker has access to the decoded output). Despite the claims of the CVE, the bug cannot results in arbitrary code execution." > Also, here are a few nits: > > * At the end of section 1, the text has a SHA1 should be has a SHA-1 > hash of. > > * In section 10 at the end of the first paragraph, artefacts should be > artifacts. > > * In section 11 just before the hexadecimal values, SHA1 hash should > be SHA-1 hashes. > > * In section 12, theoretically cause information leak should be > theoretically cause an information leak. This text is split by a line > break so search for information leak. Will fix as suggested. Cheers, Jean-Marc From nobody Thu Aug 17 07:19:38 2017 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 5570F1200C5 for ; Thu, 17 Aug 2017 07:19:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Reply-to: secdir-secratary@mit.edu Message-ID: <150297957734.12346.9756912865118445014.idtracker@ietfa.amsl.com> Date: Thu, 17 Aug 2017 07:19:37 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 14:19:37 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2017-08-17 Reviewer LC end Draft Alan DeKok 2017-05-14 draft-ietf-calext-caldav-attachments-03 For telechat 2017-08-31 Reviewer LC end Draft Ólafur Guðmundsson 2017-08-15 draft-ietf-sidr-rpki-validation-reconsidered-08 Dan Harkins 2017-08-09 draft-ietf-bess-evpn-etree-12 Benjamin Kaduk 2017-08-24 draft-ietf-teas-lsp-diversity-08 Charlie Kaufman 2017-08-24 draft-ietf-pce-rfc6006bis-03 Scott Kelly 2017-08-25 draft-ietf-tsvwg-sctp-ndata-12 Tero Kivinen 2017-08-24 draft-ietf-pals-p2mp-pw-03 Watson Ladd 2017-08-24 draft-ietf-nfsv4-rfc5667bis-13 Ben Laurie 2017-08-23 draft-ietf-pce-pce-initiated-lsp-10 David Mandelberg 2017-08-28 draft-ietf-ospf-encapsulation-cap-06 Catherine Meadows 2017-08-25 draft-ietf-mile-iodef-guidance-10 Daniel Migault 2017-08-25 draft-ietf-homenet-dot-12 Matthew Miller 2017-08-24 draft-ietf-teas-pce-central-control-03 For telechat 2017-09-14 Reviewer LC end Draft Chris Lonvick 2017-08-28 draft-ietf-rmcat-coupled-cc-06 Last calls: Reviewer LC end Draft Alan DeKok R2017-05-26 draft-nottingham-rfc5988bis-08 Donald Eastlake 2017-07-30 draft-ietf-curdle-ssh-modp-dh-sha2-07 Shawn Emery 2017-07-30 draft-ietf-curdle-ssh-ext-info-11 Daniel Franke 2017-07-30 draft-ietf-curdle-ssh-dh-group-exchange-05 Daniel Gillmor 2017-07-30 draft-ietf-curdle-des-des-des-die-die-die-04 Phillip Hallam-Baker 2017-08-11 draft-ietf-rtcweb-jsep-21 Barry Leiba 2017-08-23 draft-ietf-mboned-interdomain-peering-bcp-10 Klaas Wierenga 2017-07-12 draft-ietf-mpls-rfc3107bis-03 Tom Yu 2017-07-25 draft-ietf-lamps-rfc5280-i18n-update-02 Tom Yu 2017-02-20 draft-ietf-slim-negotiating-human-language-13 Early review requests: Reviewer Due Draft Daniel Gillmor 2016-02-01 draft-ietf-rtcweb-security-08 Adam Montville 2017-08-29 draft-ietf-opsawg-mud-08 Next in the reviewer rotation: Russ Mundy Sandra Murphy Yoav Nir Magnus Nystrom Hilarie Orman Radia Perlman Derrell Piper Tim Polk Vincent Roca Joseph Salowey From nobody Thu Aug 17 12:26:29 2017 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 AD101132349; Fri, 4 Aug 2017 10:57:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1501869422; bh=Ie0jxB+TGv86/nH2dsICVSsMnO4xPGf6iIzEIrJTytY=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=KuIAjAYdPTD8B5ebR10MEGyjDSDCYhngqkkU94T8WE9tiH3AVe17SjCeO6Zi42AVu 5STaWjBdY7CIYaLQjkEEAanlmWLX/nKmVf1DgtGCOlzSV4qJ74q3BgQkzdbiFLdtoD mkirSTPzFwrz9Qf7Oquhcg1WXv9ssfI3fCJaNkdE= 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 C2B88132331 for ; Fri, 4 Aug 2017 10:56:55 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Reply_to: Message-ID: <150186941579.18640.9480856989970030173.idtracker@ietfa.amsl.com> Date: Fri, 04 Aug 2017 10:56:55 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 17 Aug 2017 12:26:28 -0700 Subject: [secdir] [new-work] WG Review: Email mailstore and eXtensions To Revise or Amend (extra) 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, 04 Aug 2017 17:57:03 -0000 A new IETF WG has been proposed in the Applications and Real-Time Area. 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 2017-08-14. Email mailstore and eXtensions To Revise or Amend (extra) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: TBD Assigned Area Director: Alexey Melnikov Applications and Real-Time Area Directors: Adam Roach Ben Campbell Alexey Melnikov Mailing list: TBD Group page: https://datatracker.ietf.org/group/extra/ Charter: https://datatracker.ietf.org/doc/charter-ietf-extra/ The IETF maintains several key email related protocols that relate to message delivery to mailstores and mailstore access. These include in the following: IMAP (RFC3501) SIEVE (RFC5228) ManageSieve (RFC5804) >From time to time, there are bursts of work to do and the motivation and critical mass to do it. When such bursts coincide, it's important to give them a home. This working group provides such a venue. The WG will work on updates, extensions, and revisions to the above email protocols. Upon formation, the working group will consider any existing Internet Drafts that could be appropriate for its processing. While an interest poll for a new related idea is fine, the WG should avoid detailed discussion of work items lacking an Internet-Draft. The working group may also elect to turn its attention and energy to review and possible revision of these base protocols directly. In some cases, there may be appropriate corrections, clarifications, or amplifications to reflect existing practice or to address problems that have been identified through experience with Internet mail protocols as currently specified. Also eligible for consideration is the incorporation of accumulated errata or consolidation with newer documents that have updated the base specifications. However, any new functionality is expected to be pursued via extensions rather than changes to the base protocols wherever possible. Expressly excluded from this charter is work on any protocol for which a dedicated working group already exists, such as DMARC, DCRUP or JMAP, as well as any work on SMTP/LMTP and email format/MIME. However, each working group should endeavor to remain aware of the activities of the other and collaborate as needed. Milestones: _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Thu Aug 17 12:26:35 2017 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 830E013239C; Wed, 16 Aug 2017 11:01:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1502906466; bh=HiymTTiofnLwvBOILhjvkJa+wyghRSZskUL44/iSGos=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=TrI31u5bSTyhwpFo7F1XIROa6W2Rr105FnHI8wMjkCf/fT0MP0+O3LKhRnXlq5WiF D+C6FF7T3YgycAoMC0sRbG/Lc69K6O5MifooNalG8lvcKnw4EBobZo1T+ly2E6E4tt 3XspBXa2v58obqtavN95kkU0HlVNXDBHH1agXeTg= 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 37F2713239A for ; Wed, 16 Aug 2017 11:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O_IHSMg3mLKm for ; Wed, 16 Aug 2017 11:01:00 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 80C8F13237B for ; Wed, 16 Aug 2017 11:01:00 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id a18so25320635qta.0 for ; Wed, 16 Aug 2017 11:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version:thread-index :content-language; bh=iEKsLMMiaHXqmwZ3KKYbian2/8rK29DhMuFiE3J3pIc=; b=ClEhnGGikZkKsZYTwk8SZ9gHGDc9ctH8+znlHYkli8KEHMhHxNYgnyA9RfyTEfvrtI a+E5GsK9qHj99bc6xpM0S4fXeN28o+sMqXuFbX6iw56nJ6TOEsjuvpNGQ4wcHrFQMGlm WdOk1mn7JzZH10p0eN+8TNpNE/9Qfe0g8lLqqm4R0ahooCJCWwS8nCR8fWXL+IR0LxWx tfTkB8A72KcyRfsMSCBTYh9reZgqfyYjY7Uvda7IWwVakx2Y3iFZCVSkZXq3II02evtl LehKlHfDZZboIZJdDDR15PI/6LZ1+G+rdZeS73FiPpu7Yxt8f+ajTLRkEVTKY2yNfKsQ 6wAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :thread-index:content-language; bh=iEKsLMMiaHXqmwZ3KKYbian2/8rK29DhMuFiE3J3pIc=; b=NVXhSbSPRyWxCicMxEkclLc5iJMRod+EQ1Ddr+jMBF5rMKb0mmyHtR6Y7pgAIpfzM/ JohjEri4Tdz04nXcBFU5J8q7o0rCT7bZbdKyT+HREE6++GssYSkczUgf1N/8Ji4ql5/J bs/IMpn4+VJQNqwtetSCeqK/hSVKJ9XH/iD/Zz34JyujgZJXfIVAobQQFaJA1SQxf8Ps XXlZVbrw/csMzFC3fiYHywdRQ8JicxVTgq7PxACYpgBAN6FL/q3p+3A6jmtS/juhHC4Q K+05TCNtpPGREpzBFvMgg17nL4ghiE9sSrRmIbqHGY3wn9yQEHBMkYtath8IhWjpMqPq ztvA== X-Gm-Message-State: AHYfb5jfCdpDVBlk0NFg0sdnkpe4s+xWgEzHdW2qjzO9sVkdNb3TEjsy yVSDqrSPnU93wGL1 X-Received: by 10.200.45.3 with SMTP id n3mr3398696qta.15.1502906458544; Wed, 16 Aug 2017 11:00:58 -0700 (PDT) Received: from DESKTOPGUNUVB7 ([152.208.100.53]) by smtp.gmail.com with ESMTPSA id p126sm867178qka.47.2017.08.16.11.00.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Aug 2017 11:00:57 -0700 (PDT) From: "John D'Ambrosia" To: Date: Wed, 16 Aug 2017 14:00:56 -0400 Message-ID: <040701d316b9$9d938d10$d8baa730$@gmail.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdMWuYhx5ZaPWaPQTRGuxjBnYz0wQw== Content-Language: en-us Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.22 Precedence: list Content-Type: multipart/mixed; boundary="===============3998260549525811911==" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Thu, 17 Aug 2017 12:26:28 -0700 Subject: [secdir] [new-work] IEEE 802 July 2017 Plenary - New Study Groups X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 18:01:07 -0000 This is a multipart message in MIME format. --===============3998260549525811911== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0408_01D31698.16848520" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_0408_01D31698.16848520 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Members of the IETF; In the spirit of continuing cooperation between IEEE 802 and the IETF, the following letter addresses new work items for information and potential coordination with the respective IEEE 802 WG. One of the first steps in the IEEE Standards Association's standards development process is the creation of a Study Group. Study groups are chartered to create a formal Project Authorization Request (PAR) document that includes a description of the project's scope and purpose. At the March 2017 IEEE 802 Plenary, no study groups were approved. The following Study Group were approved at the July 2017 IEEE 802 Plenary - * IEEE 802.3 Beyond 10km Optical PHYs for 50 Gb/s, 200 Gb/s, 400Gb/s Ethernet * IEEE 802.11 Light Communications Study Group Further information about Study Groups may be found at http://www.ieee802.org/StudyGroups.shtml. Please note, per the IEEE 802 Policies and Procedures that a Study Group is chartered to operate until the next plenary session, a period of four months and, if it wishes to continue, must request a charter extension. Study Groups may also terminate between plenary sessions if their proposed project is approved by the IEEE Standards Association Standards Board. Additionally, within the IEEE 802 family of standards, there is a requirement that each new project proposal attaches additional documentation that describes its engineering feasibility, market potential, assurance of coexistence and distinct identity relative to previous standards (referred to as the "CSD" in 802, which also includes the "5 criteria"). The "Criteria for Standards Development (CSD)" used by IEEE 802 can be found in document: https://mentor.ieee.org/802-ec/dcn/14/ec-14-0028-00-00EC-csd-informative-ext ract.pdf Also, please note that IEEE meetings are open and may be attended by any individuals who register and fulfill any registration fees. Details regarding future IEEE 802 plenary meeting schedules may be found at http://802world.org/plenary/future-plenary-sessions/. Please refer to individual working groups for their interim meeting schedules. A listing of all working groups may be found at http://www.ieee802.org/. Sincerely, John D'Ambrosia Recording Secretary, IEEE 802 LMSC jdambrosia@ieee.org ------=_NextPart_000_0408_01D31698.16848520 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Members of the = IETF;

In the = spirit of continuing cooperation between IEEE 802 and the IETF, the = following letter addresses new work items for information and potential = coordination with the respective IEEE 802 WG.

One of the first steps in the IEEE Standards = Association’s standards development process is the creation of a = Study Group. Study groups are chartered to create a formal Project = Authorization Request (PAR) document that includes a description of the = project’s scope and purpose.

At the March 2017 IEEE 802 Plenary, no study = groups were approved.

The = following Study Group were approved at the July 2017 IEEE 802 Plenary = –

Further information about Study Groups may be = found at http://www.ieee802.org/StudyGroups.shtml.   =

Please note, = per the IEEE 802 Policies and Procedures that a Study Group is chartered = to operate until the next plenary session, a period of four months and, = if it wishes to continue, must request a charter extension. Study Groups = may also terminate between plenary sessions if their proposed project is = approved by the IEEE Standards Association Standards = Board.

Additionally, within the IEEE 802 family of = standards, there is a requirement that each new project proposal = attaches additional documentation that describes its engineering = feasibility, market potential, assurance of coexistence and distinct = identity relative to previous standards (referred to as the = “CSD” in 802, which also includes the “5 = criteria”). The “Criteria for Standards Development = (CSD)” used by IEEE 802 can be found in document: =

 https://mentor.ieee.org/802-ec/dcn/14/ec-14-00= 28-00-00EC-csd-informative-extract.pdf

Also, please = note that IEEE meetings are open and may be attended by any individuals = who register and fulfill any registration fees. Details regarding future = IEEE 802 plenary meeting schedules may be found at http://802world.org/plenary/future-plenary-ses= sions/.   Please = refer to individual working groups for their interim meeting schedules. = A listing of all working groups may be found at http://www.ieee802.org/. 

Sincerely, =

 

John = D’Ambrosia

Recording Secretary, IEEE 802 = LMSC

jdambrosia@ieee.org

 

------=_NextPart_000_0408_01D31698.16848520-- --===============3998260549525811911== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --===============3998260549525811911==-- From nobody Fri Aug 18 07:19:41 2017 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 7CCAD13218C for ; Fri, 18 Aug 2017 07:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrL_DBkMiFM2 for ; Fri, 18 Aug 2017 07:19:38 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFDE013218E for ; Fri, 18 Aug 2017 07:19:36 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id q42so15642611uad.2; Fri, 18 Aug 2017 07:19:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=0/PEQozFpuBIHhJKbxLEQ8qCQLaXKkR6hnr8X7f9Mio=; b=G+mHw2OWJtrZ1oZN1EacCgTZLUUqm8OTAWLyOmDEweRPHKUsnttVfm9W8Byyykui/7 bQTsddoz0csxApkBpVFhzsAqTBU/4grNNhEc2s48nGgzwGVO/6HPUQzVdSMqpJIlyV0T XydUQQ4GtsAdnAKymKPEJzkdTk9BldBu1GmPBrYLExRWa0t+nYpF26+ss3OIcwZp5hl7 F2NgZGyrvC/bxx8Cx6CDubqsd3BrEAvu6WDi4m538rPAhJjwDMSuRlgamdRqhb3IlAxL 6cTRf14L1FXDC5DfGlV7E1MIIztvfC4PfsTannOzj/ikytDwV7vcNi8AShaYC+e0g1qZ yFKA== 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; bh=0/PEQozFpuBIHhJKbxLEQ8qCQLaXKkR6hnr8X7f9Mio=; b=XtHxBTHvcgCxz8WEftPAx6HbnPDJcDP0miaijTXumEpHMNWtrE/m4B4P2kAkv8vS3P 4Xth8xm2bD2ZAKMWBpA/CumULr2HDY6Fvok5o+SGX2+T1KjQhHMznuXkqo60WbIqntyv KKU3bM3xP83zBcn+Z8Az6QtCsBsYw98tj5+pLTflKiyiR3U3HEX24K29qSs+CJyx5XjJ OqddyOoN/ZMXCghM6Gpm4yG/bw/wkQ+lCM5aqE/ArCUGY7HQ0KWz7O/PlkkrNoQAQLeQ Xe0utn6oqcxJzPPpWZs3Fz9FD0BODks6yR3Db0MgbUmGiSMSabIM3evFVvabmxH9bmA7 +ZsA== X-Gm-Message-State: AHYfb5hpPyZcM887IIDhJ+qZfAkY5J4zD0ADKWSpSHFG26bp0airHFi+ HujTFQ0oT83ZJTGjvXTe+fjeFA8lAE6+ X-Received: by 10.176.83.14 with SMTP id x14mr6161350uax.101.1503065975638; Fri, 18 Aug 2017 07:19:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.2.108 with HTTP; Fri, 18 Aug 2017 07:19:34 -0700 (PDT) From: Watson Ladd Date: Fri, 18 Aug 2017 07:19:34 -0700 Message-ID: To: iseg@ietf.org, secdir@ietf.org, draft-ietf-nfsv4-rfc5667bis-13.all@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [secdir] Review of draft-ietf-nfsv-rfc5667-bis X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 14:19:39 -0000 Dear all, I have reviewed this as part of the Security Directorates effort to review all drafts. I think the document is ready and have no comments on it. Sincerley, Watson From nobody Fri Aug 18 09:44:12 2017 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 CB1CB132A13; Fri, 18 Aug 2017 09:43:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Daniel Migault To: Cc: draft-ietf-homenet-dot.all@ietf.org, homenet@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150307463977.14156.2178189421671973906@ietfa.amsl.com> Date: Fri, 18 Aug 2017 09:43:59 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-homenet-dot-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 16:44:00 -0000 Reviewer: Daniel Migault Review result: Has Nits Thank you for writing the draft. Please find my comments. I hope there are helpful. Yours, Daniel Special Use Domain 'home.arpa.' draft-ietf-homenet-dot-12 Abstract This document specifies the behavior that is expected from the Domain Name System with regard to DNS queries for names ending with '.home.arpa.', and designates this domain as a special-use domain name. 'home.arpa.' is designated for non-unique use in residential home networks. Home Networking Control Protocol (HNCP) is updated to use the 'home.arpa.' domain instead of '.home'. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MGLT: I would personally start by saying the document defines a special-use domain name and then defines the behavior. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 11, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Pfister & Lemon Expires February 11, 2018 [Page 1] Internet-Draft dot homenet August 2017 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. General Guidance . . . . . . . . . . . . . . . . . . . . . . 3 4. Domain Name Reservation Considerations . . . . . . . . . . . 3 5. Updates to Home Networking Control Protocol . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Delegation of 'home.arpa.' . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Users and devices within a home network (hereafter "homenet") require devices and services to be identified by names that are unique within the boundaries of the homenet [RFC7368]. The naming mechanism needs to function without configuration from the user. While it may be possible for a name to be delegated by an ISP, homenets must also function in the absence of such a delegation. A default name with a scope limited to each individual homenet needs to be used. This document corrects an error in [RFC7788], replacing '.home' with 'home.arpa.' as the default domain-name for homenets. '.home' had been selected as the most user-friendly option. However, there are existing uses of '.home' that may be in conflict with this use: evidence indicates that '.home' queries frequently leak out and reach the root name servers [ICANN1] [ICANN2]. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MGLT: I believe that more important than the leak is that the introduction of .home in the root zone has been identified as highly risky. Another reason for not adopting it are also some uncertainty about its introduction into the root zone. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% In addition, it's necessary, for compatibility with DNSSEC (Section 6), that an insecure delegation ([RFC4035] section 4.3) be present for the name. There is an existing process for allocating names under '.arpa' [RFC3172]. No such process is available for requesting a similar delegation in the root at the request of the IETF, which does not administer that zone. As a result, the use of '.home' is deprecated. This document registers the domain '.home.arpa.' as a special-use domain name [RFC6761] and specifies the behavior that is expected from the Domain Name System with regard to DNS queries for names whose rightmost non-terminal labels are 'home.arpa.'. Queries for Pfister & Lemon Expires February 11, 2018 [Page 2] Internet-Draft dot homenet August 2017 names ending with '.home.arpa.' are of local significance within the scope of a homenet, meaning that identical queries will result in different results from one homenet to another. In other words, a name ending in 'home.arpa.' is not globally unique. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MGLT: I think the text mentioned in the beginning of the paragraph above should be in the abstract. That was the sense of my previous comment. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Although this document makes specific reference to RFC7788, it is not intended that the use of 'home.arpa.' be restricted solely to networks where HNCP is deployed; it is rather the case that 'home.arpa.' is the correct domain for uses like the one described for '.home' in RFC7788: local name service in residential homenets. 2. Requirements Language 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. 3. General Guidance The domain name '.home.arpa.' is to be used for naming within residential homenets. Names ending with '.home.arpa.' reference a locally-served zone, the contents of which are unique only to a particular homenet, and are not globally unique. Such names refer to nodes and/or services that are located within a homenet (e.g., a printer, or a toaster). DNS queries for names ending with '.home.arpa.' are resolved using local resolvers on the homenet. Such queries MUST NOT be recursively forwarded to servers outside the logical boundaries of the homenet. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MGLT: "local resolvers" seems to me mis-leading. Your resolver may be local but still forward the query to the Global Internet. I do not see better ways to say it other than inside the boundaries of the homenet. Maybe we could say: DNS queries for names ending with '.home.arpa.' are resolved using homenet specific resolution mechanisms. Eventually an informational reference to the simple naming architecture may be added so the reader can refer to the doc for further information. For full disclosure Ted and I are co-authors. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Some service discovery user interfaces that are expected to be used on homenets conceal information such as domain names from end users. However, it is still expected that in some cases, users will need to see, remember, and even type, names ending with 'home.arpa.'. It is therefore desirable that users identify the domain and understand that using it expresses the intention to connect to a service that is specific to the homenet to which they are connected. Enforcing the fulfillment of this intention is out of scope for this document. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MGLT: I have difficulties understanding the paragraph above. If the idea is to say home.arpa has special meaning that should be considered by GUIs I would propose the following ordering. It is therefore desirable that users identify the domain and understand that using it expresses the intention to connect to a service that is specific to the homenet to which they are connected. Some service discovery user interfaces that are expected to be used on homenets conceal information such as domain names from end users. However, it is still expected that in some cases, users will need to see, remember, and even type, names ending with 'home.arpa.'. Enforcing the fulfillment of this intention is out of scope for this document. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 4. Domain Name Reservation Considerations This section defines the behavior of systems involved in domain name resolution when resolving queries for names ending with '.home.arpa.' (as per [RFC6761]). Pfister & Lemon Expires February 11, 2018 [Page 3] Internet-Draft dot homenet August 2017 1. Users can use names ending with '.home.arpa.' just as they would use any other domain name. The 'home.arpa.' name is chosen to be readily recognized by users as signifying that the name is addressing a service on the homenet to which the user's device is connected. 2. Application software SHOULD NOT treat names ending in 'home.arpa.' differently than other names. In particular, there is no basis for trusting names that are subdomains of 'home.arpa.' (see Section 6). %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MGLT: a domain name ending in home.arpa may be resolved differently that a regular domain name. As a result a different treatment is applied. I think that "treat" means that no special meaning - other that the domain name is inside the homenet boundaries - should be associated to a home.arpa. If I am correct I would limit the consideration to the name rather then the application. I would suggest the text below: names ending in home.arpa SHOULD NOT be associated any other properties than the affiliation to the homenet. In particular, there is no basis for trusting names that are subdomains of 'home.arpa.' (see Section 6). %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 3. Name resolution APIs and libraries MUST NOT recognize names that end in '.home.arpa.' as special and MUST NOT treat them differently. Name resolution APIs MUST send queries for such names to a recursive DNS server that is configured to be authoritative for the 'home.arpa.' zone appropriate to the homenet. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MGLT: I believe the text below does not concern the library but the resolver. It is different to say libraries MUST NOT have specific considerations for home.arpa than a resolution service that may use different libraries MUST NOT consider the home.arpa differently. My understanding of the text below is that the resolver and the authoritative server for the home.arpa MUST be co-located. The reasons I think this is not exact is that resolution for home.arpa can also be provided by other mechanisms than an authoritative server. Typically, resolution can be done by requesting Authoritative Servers, Advertising Proxies, Hybrid Proxies (now called Discovery Proxies).... The other reason is do not see the text below accurate is that you may have a DNS Proxy that transparently to the end user split the resolution between homenet specific resolutions when home.arpa is encountered while other names are sent to the ISP resolver. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% One or more IP addresses for recursive DNS servers will usually be supplied to the client through router advertisements or DHCP. If a host is configured to use a resolver other than one that is authoritative for the appropriate 'home.arpa.' zone, the client may be unable to resolve, or may receive incorrect results for, names in sub domains of 'home.arpa.'. 4. Caching resolvers conforming to this specification MUST support DNSSEC queries. While validation is not required, it is strongly encouraged; a caching resolver that does not validate answers that can be validated may cache invalid data; this will prevent validating stub resolvers from successfully validating answers. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MGLT: I see the text above as a recommendation for caching resolvers in the homenet, but the relation to the home.arpa is unclear to me. Was the intention to say that names under the home.arpa zone SHOULD be secured with DNSSEC so caching resolvers MUST support DNSSEC validation. In addition, these caching resolvers MUST also be able to be configured with a Trust Anchor for the home.arpa. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Unless configured otherwise, recursive resolvers and DNS proxies MUST behave as described in Locally Served Zones ([RFC6303] Section 3). That is, queries for domains that are subdomains of 'home.arpa.' MUST NOT be forwarded, with one important exception: a query for a DS record when the DO bit ([RFC4035] section 3.2.1) set MUST return the correct answer for that question, including correct information in the authority section that proves that the record is nonexistent. So for example a query for the NS record for 'home.arpa.' MUST NOT result in that query being forwarded to an upstream cache nor to the authoritative DNS server for '.arpa.'. However, as necessary to provide accurate authority information, a query for the DS record MUST result in whatever queries are necessary being forwarded; typically, this will just be a query for the DS record, since the necessary authority information will be included in the authority section of the response if the DO bit is set. Pfister & Lemon Expires February 11, 2018 [Page 4] Internet-Draft dot homenet August 2017 In addition to the behavior specified above, recursive resolvers that can be used in a homenet MUST be configurable with a delegation to an authoritative server for that particular homenet's instance of the domain 'home.arpa.'. It is permissible to combine the recursive resolver function for general DNS lookups with an authoritative resolver for 'home.arpa.'; in this case, rather than forwarding queries for subdomains of 'home.arpa.' to an authoritative server, the caching resolver answers them authoritatively. The behavior with respect to forwarding queries specifically for 'home.arpa.' remains the same. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MGLT: The full consideration seems to me to be conformance to RFC6303. In particular the recommendations for DNSSEC in RFC 6303 seems to me accurated and are not specifically mentioned here. Maybe that should be clearly stated that all considerations of RFC6303 should be considered as home.arpa is of local scope. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 5. No special processing of 'home.arpa.' is required for authoritative DNS server implementations. It is possible that an authoritative DNS server might attempt to check the authoritative servers for 'home.arpa.' for a delegation beneath that name before answering authoritatively for such a delegated name. In such a case, because the name always has only local significance there will be no such delegation in the 'home.arpa.' zone, and so the server would refuse to answer authoritatively for such a zone. A server that implements this sort of check MUST be configurable so that either it does not do this check for the 'home.arpa.' domain, or it ignores the results of the check. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MGLT: I understand this as being incorrect. The resolver can also be configured with a trust anchor. I would refer to the RFC6303: As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA namespaces, the zones listed above will need to be delegated as insecure delegations, or be within insecure zones. This will allow DNSSEC validation to succeed for queries in these spaces despite not being answered from the delegated servers. It is recommended that sites actively using these namespaces secure them using DNSSEC [RFC4035] by publishing and using DNSSEC trust anchors. This will protect the clients from accidental import of unsigned responses from the Internet. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 6. DNS server operators MAY configure an authoritative server for 'home.arpa.' for use in homenets and other home networks. The operator for the DNS servers authoritative for 'home.arpa.' in the global DNS will configure any such servers as described in Section 7. 7. 'home.arpa.' is a subdomain of the 'arpa' top-level domain, which is operated by IANA under the authority of the Internet Architecture Board according to the rules established in [RFC3172]. There are no other registrars for .arpa. 5. Updates to Home Networking Control Protocol The final paragraph of Home Networking Control Protocol [RFC7788], section 8, is updated as follows: OLD: Names and unqualified zones are used in an HNCP network to provide naming and service discovery with local significance. A network- wide zone is appended to all single labels or unqualified zones in order to qualify them. ".home" is the default; however, an administrator MAY configure the announcement of a Domain-Name TLV Pfister & Lemon Expires February 11, 2018 [Page 5] Internet-Draft dot homenet August 2017 (Section 10.6) for the network to use a different one. In case multiple are announced, the domain of the node with the greatest node identifier takes precedence. NEW: Names and unqualified zones are used in an HNCP network to provide naming and service discovery with local significance. A network- wide zone is appended to all single labels or unqualified zones in order to qualify them. 'home.arpa.' is the default; however, an administrator MAY configure the announcement of a Domain-Name TLV (Section 10.6) for the network to use a different one. In case multiple are announced, the domain of the node with the greatest node identifier takes precedence. The 'home.arpa.' special-use name does not require a special resolution protocol. Names for which the rightmost two labels are 'home.arpa.' are resolved using the DNS protocol [RFC1035]. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MGLT: If home.arpa are no different than other resolutions and we start from the root zone responses are likely to be NXDOMAIN. I think we should clarify that DNS is used as a transport protocol, but that resolution may be handled differently. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 6. Security Considerations A DNS record that is returned as a response to a query for an FQDN in the domain '.home.arpa.' is expected to have local significance. It is expected to be returned by a server involved in name resolution for the homenet the device is connected in. However, such response MUST NOT be considered more trustworthy than would be a similar response for any other DNS query. Because 'home.arpa.' is not globally scoped and cannot be secured using DNSSEC based on the root domain's trust anchor, there is no way to tell, using a standard DNS query, in which homenet scope an answer belongs. Consequently, users may experience surprising results with such names when roaming to different homenets. To prevent this from happening, it may be useful for the resolver to identify different homenets on which it has resolved names, but this is out of scope for this document. It is not possible to install a trust anchor for this zone in the '.arpa' zone. The reason for this is that in order to do so, it would be necessary to have the key-signing key for the zone ([RFC4034] Section 5). Since the zone is not globally unique, no one key would work. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MGLT: I think that DS is meant rather than trust anchor. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% An alternative would be to install a authenticated denial of existence ([RFC4033] Section 3.2). %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MGLT: This is unclear where the denial of existence is set. Is that in the home.arpa zone or the arpa zone. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% However, this assumes that validation is being done on a caching resolver that is aware of the special local meaning of 'home.arpa.'. If a host stub resolver attempts to validate a name in 'home.arpa.', an authenticated denial Pfister & Lemon Expires February 11, 2018 [Page 6] Internet-Draft dot homenet August 2017 of existence of 'home' as a subdomain of 'arpa.' would cause the validation to fail. Therefore, the only delegation that will allow names under 'home.arpa.' to be resolved is an insecure delegation, as in [RFC6303] section 7. Consequently, unless a trust anchor for the particular instance of the 'home.arpa.' zone being validated is manually configured on the validating resolver, DNSSEC signing of names within the 'home.arpa.' zone is not possible. Although in principle it might be useful to install a trust anchor for a particular instance of 'home.arpa.', it's reasonable to expect that a host with such a trust anchor might from time to time connect to more than one network with its own instance of 'home.arpa.'. Such a host would be unable to access services on any instance of 'home.arpa.' other than the one for which a trust anchor was configured. It is in principle possible to attach an identifier to an instance of 'home.arpa.' that could be used to identify which trust anchor to rely on for validating names in that particular instance. However, the security implications of this are complicated, and such a mechanism, as well as a discussion of those implications, is out of scope for this document. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MGLT: There are also some privacy issues associated to leaking names outside the homenet boundaries. For example daniel_smith.home.arpa reveal the identity of the member of the homenet, my_ipad.home.arpa reveals the devices you own, the application. home.arpa may also used in larger environment such as corporate / private. going from one to the other may also leak such information. The leak can be from the homenet to the outside world in which case one neeed to control the queries sent. But in intruder (or guest) may also access the homenet and proceed to discovery of the names. As a result even though homenet is believe to be a trusted environment, care should be considered while publishing under the home.arpa. as well as whose the information is accessible to. They might be collision as well. myprinter.home.arpa may be found in various environments, and upon discovery you may also - in this example - print confidential information to that printer. In some case you may not even be aware, for example, if your printing information failed home, and is re-activated once you are in another environment. As information may be sensitive it may be encrypted using IPsec DTLS as described by dprive for both authentication and confidentiality. When the trust anchor is configured in the resolver, these must be able to roll-over the key and should follows the requirements for DNSSEC validators. if it is impossible for a resolver to see the difference between an attack and a re-key we are in trouble. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 7. Delegation of 'home.arpa.' In order to be fully functional, there must be a delegation of 'home.arpa.' in the '.arpa.' zone [RFC3172]. This delegation MUST NOT include a DS record, and MUST point to one or more black hole servers, for example 'blackhole-1.iana.org.' and 'blackhole- 2.iana.org.'. The reason that this delegation must not be signed is that not signing the delegation breaks the DNSSEC chain of trust, which prevents a validating stub resolver from rejecting names published under 'home.arpa.' on a homenet name server. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MGLT: The zone home.arpa MUST NOT be seen as belonging to the homenet. As a result, NS and DS records for home.arpa does not have meanings outside a specific domain. A Public server outside the boundaries of the homenet MUST consider this traffic as irrelevant and sink. Redirection to as112 without coordination with as112 operator may rather be performed using DNAME. I believe more text should document the two alternative. With the proposed configuration, the query will be directed to a server that is not authoritative for the zone. The response is likely to be REFUSED, while in the other case it is likely to be NXDOMAIN. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 8. IANA Considerations IANA is requested to record the domain name 'home.arpa.' in the Special-Use Domain Names registry [SUDN]. IANA is requested, with the approval of IAB, to implement the delegation requested in Section 7. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MGLT: OK if IANA may make the direct way work. In that case is there any need to update a registry for zone served by as112? %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From nobody Fri Aug 18 09:52:27 2017 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 50DFD132A0A; Fri, 18 Aug 2017 09:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 twuFlkV1sb21; Fri, 18 Aug 2017 09:52:11 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 5CAFD13219F; Fri, 18 Aug 2017 09:52:08 -0700 (PDT) X-AuditID: c618062d-b7bff70000004f0a-ed-5997323043f0 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 94.E8.20234.03237995; Fri, 18 Aug 2017 20:30:08 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0352.000; Fri, 18 Aug 2017 12:52:06 -0400 From: Daniel Migault To: Daniel Migault , "secdir@ietf.org" CC: "draft-ietf-homenet-dot.all@ietf.org" , "homenet@ietf.org" , "ietf@ietf.org" Thread-Topic: [secdir] Secdir last call review of draft-ietf-homenet-dot-12 Thread-Index: AQHTGEFPNcIi2xMGa0+hL4jWilNTs6KKUyPA Date: Fri, 18 Aug 2017 16:52:06 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118CD0C08@eusaamb107.ericsson.se> References: <150307463977.14156.2178189421671973906@ietfa.amsl.com> In-Reply-To: <150307463977.14156.2178189421671973906@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyuXRPuK6B0fRIg2nrtCwef5zCZvF+0SEW i2cb57NYfFj4kMWBxWPJkp9MAYxRXDYpqTmZZalF+nYJXBk3f2xmL7j2krHiX5NhA+O5LYxd jJwcEgImEvff7mTrYuTiEBI4yihxcskXVghnOaNE69J2NpAqNgEjibZD/ewgtohAuMSjHWcZ QYqYBWYzSizuWMYCkhAW8JJYuGgWG0SRt0RHz3co20ji9oE/YOtYBFQljny5xwRi8wr4Shzf eQusV0jAWWLa0adgcU4BF4lZO7czg9iMAmIS30+tAYszC4hL3HoynwnibAGJJXvOM0PYohIv H/9jhbCVJD7+ns8OUa8jsWD3JzYIW1ti2cLXzBB7BSVOznzCMoFRdBaSsbOQtMxC0jILScsC RpZVjBylxQU5uelGBpsYgdFxTIJNdwfj/emehxgFOBiVeHgT1aZHCrEmlhVX5h5ilOBgVhLh FXg2LVKINyWxsiq1KD++qDQntfgQozQHi5I474TzFyKEBNITS1KzU1MLUotgskwcnFINjF39 ayqWb4ybJPt3pnhCcPv9m9LyatcXbLjq++D6jKv2UhsfrzqfvjFhoaWs0e095hMk5NrnZJZt f3mjUds7ucnK9f0P8Sfdy/OSzT4++CXzdpnyq27Jtp0P7u5hFGY0Tn0q+NExlPGsbcu1zU1v HvP831pygV2RZ+sBlWcxxxecdNDacS3VM0uJpTgj0VCLuag4EQDRky9wigIAAA== Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-homenet-dot-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 16:52:15 -0000 Hi,=20 I used the web form and expected that the boilerplate would automatically b= e added. This explains why the introduction may look a bit directive or dry= . To clarify the scope of my reviews, I am adding the boilerplate below. I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. Yours,=20 Daniel -----Original Message----- From: secdir [mailto:secdir-bounces@ietf.org] On Behalf Of Daniel Migault Sent: Friday, August 18, 2017 12:44 PM To: secdir@ietf.org Cc: draft-ietf-homenet-dot.all@ietf.org; homenet@ietf.org; ietf@ietf.org Subject: [secdir] Secdir last call review of draft-ietf-homenet-dot-12 Reviewer: Daniel Migault Review result: Has Nits Thank you for writing the draft. Please find my comments. I hope they are h= elpful.=20 Yours, Daniel =20 Special Use Domain 'home.arpa.' draft-ietf-homenet-dot-12 Abstract This document specifies the behavior that is expected from the Domain Name System with regard to DNS queries for names ending with '.home.arpa.', and designates this domain as a special-use domain name. 'home.arpa.' is designated for non-unique use in residential home networks. Home Networking Control Protocol (HNCP) is updated to use the 'home.arpa.' domain instead of '.home'. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 MGLT: I would personally start by saying the document defines a special-us= e domain name and then defines the behavior.=20 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 =20 Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 11, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Pfister & Lemon Expires February 11, 2018 [Page 1] Internet-Draft dot homenet August 2017 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. General Guidance . . . . . . . . . . . . . . . . . . . . . . 3 4. Domain Name Reservation Considerations . . . . . . . . . . . 3 5. Updates to Home Networking Control Protocol . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Delegation of 'home.arpa.' . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Users and devices within a home network (hereafter "homenet") require devices and services to be identified by names that are unique within the boundaries of the homenet [RFC7368]. The naming mechanism needs to function without configuration from the user. While it may be possible for a name to be delegated by an ISP, homenets must also function in the absence of such a delegation. A default name with a scope limited to each individual homenet needs to be used. This document corrects an error in [RFC7788], replacing '.home' with 'home.arpa.' as the default domain-name for homenets. '.home' had been selected as the most user-friendly option. However, there are existing uses of '.home' that may be in conflict with this use: evidence indicates that '.home' queries frequently leak out and reach the root name servers [ICANN1] [ICANN2]. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 MGLT: I believe that more important than the leak is that the introductio= n of .home in the root zone has been identified as highly risky. Another r= eason for not adopting it are also some uncertainty about its introduction into the root zone. =20 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 In addition, it's necessary, for compatibility with DNSSEC (Section 6), that an insecure delegation ([RFC4035] section 4.3) be present for the name. There is an existing process for allocating names under '.arpa' [RFC3172]. No such process is available for requesting a similar delegation in the root at the request of the IETF, which does not administer that zone. As a result, the use of '.home' is deprecated. This document registers the domain '.home.arpa.' as a special-use domain name [RFC6761] and specifies the behavior that is expected from the Domain Name System with regard to DNS queries for names whose rightmost non-terminal labels are 'home.arpa.'. Queries for Pfister & Lemon Expires February 11, 2018 [Page 2] Internet-Draft dot homenet August 2017 names ending with '.home.arpa.' are of local significance within the scope of a homenet, meaning that identical queries will result in different results from one homenet to another. In other words, a name ending in 'home.arpa.' is not globally unique. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 MGLT: I think the text mentioned in the beginning of the paragraph above sh= ould be in the abstract. That was the sense of my previous comment.=20 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 Although this document makes specific reference to RFC7788, it is not intended that the use of 'home.arpa.' be restricted solely to networks where HNCP is deployed; it is rather the case that 'home.arpa.' is the correct domain for uses like the one described for '.home' in RFC7788: local name service in residential homenets. 2. Requirements Language 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. 3. General Guidance The domain name '.home.arpa.' is to be used for naming within residential homenets. Names ending with '.home.arpa.' reference a locally-served zone, the contents of which are unique only to a particular homenet, and are not globally unique. Such names refer to nodes and/or services that are located within a homenet (e.g., a printer, or a toaster). DNS queries for names ending with '.home.arpa.' are resolved using local resolvers on the homenet. Such queries MUST NOT be recursively forwarded to servers outside the logical boundaries of the homenet. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 MGLT: "local resolvers" seems to me mis-leading. Your resolver may be local= but still forward the query to the Global Internet. I do not see better wa= ys to say it other than inside the boundaries of the homenet. Maybe we could say: =20 =20 DNS queries for names ending with '.home.arpa.' are resolved using homenet specific resolution mechanisms.=20 Eventually an informational reference to the simple naming architecture may= be added so the reader can refer to the doc for further information. For f= ull disclosure Ted and I are co-authors. =20 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 =20 Some service discovery user interfaces that are expected to be used on homenets conceal information such as domain names from end users. However, it is still expected that in some cases, users will need to see, remember, and even type, names ending with 'home.arpa.'. It is therefore desirable that users identify the domain and understand that using it expresses the intention to connect to a service that is specific to the homenet to which they are connected. Enforcing the fulfillment of this intention is out of scope for this document. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 MGLT: I have difficulties understanding the paragraph above. If the idea is= to say home.arpa has special meaning that should be considered by GUIs I w= ould propose the following ordering. It is therefore desirable that users identify the domain and understand that using it expresses the intention to connect to a service that is specific to the homenet to which they are connected.=20 Some service discovery user interfaces that are expected to be used on homenets conceal information such as domain names from end users. However, it is still expected that in some cases, users will need to see, remember, and even type, names ending with 'home.arpa.'. =20 Enforcing the fulfillment of this intention is out of scope for this document. =20 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 =20 4. Domain Name Reservation Considerations This section defines the behavior of systems involved in domain name resolution when resolving queries for names ending with '.home.arpa.' (as per [RFC6761]). Pfister & Lemon Expires February 11, 2018 [Page 3] Internet-Draft dot homenet August 2017 1. Users can use names ending with '.home.arpa.' just as they would use any other domain name. The 'home.arpa.' name is chosen to be readily recognized by users as signifying that the name is addressing a service on the homenet to which the user's device is connected. 2. Application software SHOULD NOT treat names ending in 'home.arpa.' differently than other names. In particular, there is no basis for trusting names that are subdomains of 'home.arpa.' (see Section 6). %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 MGLT: a domain name ending in home.arpa may be resolved differently that a = regular domain name. As a result a different treatment is applied. I think = that "treat" means that no special meaning - other that the domain name is = inside the homenet boundaries - should be associated to a home.arpa. If I a= m correct I would limit the consideration to the name rather then the appli= cation.=20 I would suggest the text below: =09 names ending in home.arpa SHOULD NOT be associated any other properties tha= n the affiliation to the homenet. In particular, there is no basis for trusting names that are subdomains of 'home.arpa.' (see Section 6). %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 =09 =20 3. Name resolution APIs and libraries MUST NOT recognize names that end in '.home.arpa.' as special and MUST NOT treat them differently. Name resolution APIs MUST send queries for such names to a recursive DNS server that is configured to be authoritative for the 'home.arpa.' zone appropriate to the homenet. =20 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 MGLT: I believe the text below does not concern the library but the resolve= r. It is different to say libraries MUST NOT have specific considerations f= or home.arpa than a resolution service that may use different libraries MUS= T NOT consider the home.arpa differently.=20 My understanding of the text below is that the resolver and the authoritati= ve server for the home.arpa MUST be co-located. The reasons I think this is= not exact is that resolution for home.arpa can also be provided by other m= echanisms than an authoritative server. Typically, resolution can be done b= y requesting Authoritative Servers, Advertising Proxies, Hybrid Proxies (no= w called Discovery Proxies).... The other reason is do not see the text below accurate is that you may have= a DNS Proxy that transparently to the end user split the resolution betwee= n homenet specific resolutions when home.arpa is encountered while other na= mes are sent to the ISP resolver. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 =20 =20 One or more IP addresses for recursive DNS servers will usually be supplied to the client through router advertisements or DHCP. If a host is configured to use a resolver other than one that is authoritative for the appropriate 'home.arpa.' zone, the client may be unable to resolve, or may receive incorrect results for, names in sub domains of 'home.arpa.'. 4. Caching resolvers conforming to this specification MUST support DNSSEC queries. While validation is not required, it is strongly encouraged; a caching resolver that does not validate answers that can be validated may cache invalid data; this will prevent validating stub resolvers from successfully validating answers. =20 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 MGLT: I see the text above as a recommendation for caching resolvers in the= homenet, but the relation to the home.arpa is unclear to me.=20 Was the intention to say that names under the home.arpa zone SHOULD be secu= red with DNSSEC so caching resolvers MUST support DNSSEC validation. In add= ition, these caching resolvers MUST also be able=20 to be configured with a Trust Anchor for the home.arpa. =20 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 Unless configured otherwise, recursive resolvers and DNS proxies MUST behave as described in Locally Served Zones ([RFC6303] Section 3). That is, queries for domains that are subdomains of 'home.arpa.' MUST NOT be forwarded, with one important exception: a query for a DS record when the DO bit ([RFC4035] section 3.2.1) set MUST return the correct answer for that question, including correct information in the authority section that proves that the record is nonexistent. So for example a query for the NS record for 'home.arpa.' MUST NOT result in that query being forwarded to an upstream cache nor to the authoritative DNS server for '.arpa.'. However, as necessary to provide accurate authority information, a query for the DS record MUST result in whatever queries are necessary being forwarded; typically, this will just be a query for the DS record, since the necessary authority information will be included in the authority section of the response if the DO bit is set. Pfister & Lemon Expires February 11, 2018 [Page 4] Internet-Draft dot homenet August 2017 In addition to the behavior specified above, recursive resolvers that can be used in a homenet MUST be configurable with a delegation to an authoritative server for that particular homenet's instance of the domain 'home.arpa.'. It is permissible to combine the recursive resolver function for general DNS lookups with an authoritative resolver for 'home.arpa.'; in this case, rather than forwarding queries for subdomains of 'home.arpa.' to an authoritative server, the caching resolver answers them authoritatively. The behavior with respect to forwarding queries specifically for 'home.arpa.' remains the same. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 MGLT: The full consideration seems to me to be conformance to RFC6303. In particular the recommendations for DNSSEC in RFC 6303 seems to me accura= ted and are not specifically mentioned here. Maybe that should be clearly s= tated that all considerations of RFC6303 should be considered as home.arpa = is of local scope.=20 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 =20 5. No special processing of 'home.arpa.' is required for authoritative DNS server implementations. It is possible that an authoritative DNS server might attempt to check the authoritative servers for 'home.arpa.' for a delegation beneath that name before answering authoritatively for such a delegated name. In such a case, because the name always has only local significance there will be no such delegation in the 'home.arpa.' zone, and so the server would refuse to answer authoritatively for such a zone. A server that implements this sort of check MUST be configurable so that either it does not do this check for the 'home.arpa.' domain, or it ignores the results of the check. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 MGLT: I understand this as being incorrect. The resolver can also be config= ured with a trust anchor. I would refer to the RFC6303: As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA namespaces, the zones listed above will need to be delegated as insecure delegations, or be within insecure zones. This will allow DNSSEC validation to succeed for queries in these spaces despite not being answered from the delegated servers. It is recommended that sites actively using these namespaces secure them using DNSSEC [RFC4035] by publishing and using DNSSEC trust anchors. This will protect the clients from accidental import of unsigned responses from the Internet. =20 =20 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 =20 =20 6. DNS server operators MAY configure an authoritative server for 'home.arpa.' for use in homenets and other home networks. The operator for the DNS servers authoritative for 'home.arpa.' in the global DNS will configure any such servers as described in Section 7. =20 7. 'home.arpa.' is a subdomain of the 'arpa' top-level domain, which is operated by IANA under the authority of the Internet Architecture Board according to the rules established in [RFC3172]. There are no other registrars for .arpa. 5. Updates to Home Networking Control Protocol The final paragraph of Home Networking Control Protocol [RFC7788], section 8, is updated as follows: OLD: Names and unqualified zones are used in an HNCP network to provide naming and service discovery with local significance. A network- wide zone is appended to all single labels or unqualified zones in order to qualify them. ".home" is the default; however, an administrator MAY configure the announcement of a Domain-Name TLV Pfister & Lemon Expires February 11, 2018 [Page 5] Internet-Draft dot homenet August 2017 (Section 10.6) for the network to use a different one. In case multiple are announced, the domain of the node with the greatest node identifier takes precedence. NEW: Names and unqualified zones are used in an HNCP network to provide naming and service discovery with local significance. A network- wide zone is appended to all single labels or unqualified zones in order to qualify them. 'home.arpa.' is the default; however, an administrator MAY configure the announcement of a Domain-Name TLV (Section 10.6) for the network to use a different one. In case multiple are announced, the domain of the node with the greatest node identifier takes precedence. The 'home.arpa.' special-use name does not require a special resolution protocol. Names for which the rightmost two labels are 'home.arpa.' are resolved using the DNS protocol [RFC1035]. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 MGLT: If home.arpa are no different than other resolutions and we start fro= m the root zone responses are likely to be NXDOMAIN. I think we should clar= ify that DNS is used as a transport protocol, but that resolution may be ha= ndled differently. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 =20 =20 6. Security Considerations A DNS record that is returned as a response to a query for an FQDN in the domain '.home.arpa.' is expected to have local significance. It is expected to be returned by a server involved in name resolution for the homenet the device is connected in. However, such response MUST NOT be considered more trustworthy than would be a similar response for any other DNS query. Because 'home.arpa.' is not globally scoped and cannot be secured using DNSSEC based on the root domain's trust anchor, there is no way to tell, using a standard DNS query, in which homenet scope an answer belongs. Consequently, users may experience surprising results with such names when roaming to different homenets. To prevent this from happening, it may be useful for the resolver to identify different homenets on which it has resolved names, but this is out of scope for this document. It is not possible to install a trust anchor for this zone in the '.arpa' zone. The reason for this is that in order to do so, it would be necessary to have the key-signing key for the zone ([RFC4034] Section 5). Since the zone is not globally unique, no one key would work. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 MGLT: I think that DS is meant rather than trust anchor. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 =20 An alternative would be to install a authenticated denial of existence ([RFC4033] Section 3.2). =20 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 MGLT: This is unclear where the denial of existence is set. Is that in the = home.arpa zone or the arpa zone.=20 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 =20 However, this assumes that validation is being done on a caching resolver that is aware of the special local meaning of 'home.arpa.'. If a host stub resolver attempts to validate a name in 'home.arpa.', an authenticated denial Pfister & Lemon Expires February 11, 2018 [Page 6] Internet-Draft dot homenet August 2017 of existence of 'home' as a subdomain of 'arpa.' would cause the validation to fail. Therefore, the only delegation that will allow names under 'home.arpa.' to be resolved is an insecure delegation, as in [RFC6303] section 7. Consequently, unless a trust anchor for the particular instance of the 'home.arpa.' zone being validated is manually configured on the validating resolver, DNSSEC signing of names within the 'home.arpa.' zone is not possible. Although in principle it might be useful to install a trust anchor for a particular instance of 'home.arpa.', it's reasonable to expect that a host with such a trust anchor might from time to time connect to more than one network with its own instance of 'home.arpa.'. Such a host would be unable to access services on any instance of 'home.arpa.' other than the one for which a trust anchor was configured. It is in principle possible to attach an identifier to an instance of 'home.arpa.' that could be used to identify which trust anchor to rely on for validating names in that particular instance. However, the security implications of this are complicated, and such a mechanism, as well as a discussion of those implications, is out of scope for this document. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 MGLT: There are also some privacy issues associated to leaking names outsid= e the homenet boundaries. For example daniel_smith.home.arpa reveal the ide= ntity of the member of the homenet, my_ipad.home.arpa reveals the devices y= ou own, the application.=20 home.arpa may also used in larger environment such as corporate / private. = going from one to the other may also leak such information.=20 The leak can be from the homenet to the outside world in which case one nee= ed to control the queries sent. But in intruder (or guest) may also access = the homenet and proceed to discovery of the names.=20 As a result even though homenet is believe to be a trusted environment, car= e should be considered while publishing under the home.arpa. as well as whose the information is accessible to. =20 They might be collision as well. myprinter.home.arpa may be found in variou= s environments, and upon discovery you may also - in this example - print c= onfidential information to that printer.=20 In some case you may not even be aware, for example, if your printing infor= mation failed home, and is re-activated once you are in another environment= . =20 As information may be sensitive it may be encrypted using IPsec DTLS as des= cribed by dprive for both authentication and confidentiality.=20 When the trust anchor is configured in the resolver, these must be able to = roll-over the key and should follows the requirements for DNSSEC validators= . if it is impossible for a resolver to see the difference between an attac= k and a re-key we are in trouble.=20 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% =20 =20 =20 =20 7. Delegation of 'home.arpa.' In order to be fully functional, there must be a delegation of 'home.arpa.' in the '.arpa.' zone [RFC3172]. This delegation MUST NOT include a DS record, and MUST point to one or more black hole servers, for example 'blackhole-1.iana.org.' and 'blackhole- 2.iana.org.'. The reason that this delegation must not be signed is that not signing the delegation breaks the DNSSEC chain of trust, which prevents a validating stub resolver from rejecting names published under 'home.arpa.' on a homenet name server. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 MGLT: The zone home.arpa MUST NOT be seen as belonging to the homenet. As a= result, NS and DS records for home.arpa does not have meanings outside a s= pecific domain. A Public server outside the boundaries of the homenet MUST = consider this traffic as=20 irrelevant and sink. =20 Redirection to as112 without coordination with as112 operator may rather be= performed using DNAME. I believe more text should document the two alterna= tive. With the proposed configuration, the query will be directed to a serv= er that is not authoritative for the zone. The response is likely to be REF= USED, while in the other case it is likely to be NXDOMAIN. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 =20 =20 8. IANA Considerations IANA is requested to record the domain name 'home.arpa.' in the Special-Use Domain Names registry [SUDN]. IANA is requested, with the approval of IAB, to implement the delegation requested in Section 7. =20 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 MGLT: OK if IANA may make the direct way work. In that case is there any n= eed to update a registry for zone served by as112?=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 Tue Aug 22 23:01:11 2017 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 16160132334 for ; Tue, 22 Aug 2017 23:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 bAd6_NWdlZaK for ; Tue, 22 Aug 2017 23:01:08 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6299E1321ED for ; Tue, 22 Aug 2017 23:01:08 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id s187so4155744ywf.2 for ; Tue, 22 Aug 2017 23:01:08 -0700 (PDT) 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=wD6u6oxbJy7b/Cp5/tPB2xjYKYQgWQbD60ayVXEhyhE=; b=GxnrY3mOG1dUr29lmID+eo8SJLjwINBDosVJ+/pUDs0kmIJg7+1KgwpufrFcTUepWC k3zKsRm2Du3NMcFVjkBoQ1OOgR+ELmucdyTW6Bjdtabvd3YkZTkaOWpx89vBRlcvAImq Kt2r4EokuybVp9ObPpbv/dqMqxKE49CTRzg9wXPSEjK2JuXl+h8JfB9QsTZSDRFkQY6r 0HE+L4n5BWGdzsVMPZGgigfnlrF4d0IeLT4/WBD7B4xgqz6IC+SQi5bFg3TiplpdS5Fs iePr0N98kGOiKxKuVyGLlPTn18ysUqq+XNNc3SvzdLOz8d0V7m3EMoUwKgDcfndbh01y KRxw== 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=wD6u6oxbJy7b/Cp5/tPB2xjYKYQgWQbD60ayVXEhyhE=; b=SM/eq6oJpx/zBtJFo0n1O4ZOktJTCQBfM5woy7U00MIFbRvYvPkKiaB9IPV6opNlsb iXq8zgejZwJM1hEMr1yG2Ct9qE2172v2iyYIxwDyvchgBzZz8D6jwztVQyiCWf5MTzli r8KHgShbX2AedwBVXkMt2uSxsxMB7A+8TMWUvi1gD9gVWYh/9aodv0E76SRFIEaAO5n7 PX87RUCFK9H//oIWwcXOBdjrI1Jt6FSiQV8dId7IZZINM8/8muqFZsFO8XY17ORd2z1J EeN9MJzjVF/JAuvW4XoeuEZK+GKuKbpJ0vKuRfJw/1oL7Ts7HKgznOdHzIlQOw4wjU8C W9tg== X-Gm-Message-State: AHYfb5jrTp7Tm7cDKM1VxV5A3PAhyShEbzXHdu2oRKUz5O9RqBHsNFVy XNTkb46vxALdddAPXNL19V1wQbRtaC5z X-Received: by 10.37.94.136 with SMTP id s130mr49237ybb.79.1503468067403; Tue, 22 Aug 2017 23:01:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.174.79 with HTTP; Tue, 22 Aug 2017 23:01:06 -0700 (PDT) From: Shawn Emery Date: Wed, 23 Aug 2017 00:01:06 -0600 Message-ID: To: secdir@ietf.org, draft-ietf-curdle-ssh-ext-info.all@tools.ietf.org Content-Type: multipart/alternative; boundary="001a1140efde16bbf20557657059" Archived-At: Subject: [secdir] Review of draft-ietf-curdle-ssh-ext-info-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 06:01:10 -0000 --001a1140efde16bbf20557657059 Content-Type: text/plain; charset="UTF-8" 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 discusses protocol extension negotiation for SSH and specifies several of these extensions in practice. The security considerations section does exist and refers to SSH's base protocol specification (RFC 4251) for security aspects of this draft. I agree with this assessment, though it would be helpful to state that the extension negotiation between the client and server is performed after key exchange with confidentiality. General comments: None. Editorial comments: Table of contents is missing. Shawn. -- --001a1140efde16bbf20557657059 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have reviewed this docu= ment as part of the security directorate's
ongoing effort to review all=C2= =A0IETF=C2=A0document= s being processed by the IESG.
These comments were written primarily for the ben= efit of the security
area directors. Document editors and WG chairs should treat= these
comments just like any other last call comments.

This draft discusses protocol extension negotiation for SSH and s= pecifies
several of these extensions in practice.

The security = considerations section does exist and refers to SSH's base
=
protocol s= pecification (RFC 4251) for security aspects of this draft. =C2=A0I<= /div>
agree= with this assessment, though it would be helpful to=C2=A0state that
the extension negotiation between the c= lient and server is=C2=A0performed<= /span>
after key exch= ange with confidentiality.

General comments:

None.=

=
Editorial comments:

Table of contents is missing.=

=
Shawn.
--
--001a1140efde16bbf20557657059-- From nobody Wed Aug 23 09:37:40 2017 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 7781B132025; Wed, 23 Aug 2017 09:37:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Barry Leiba To: Cc: mboned@ietf.org, draft-ietf-mboned-interdomain-peering-bcp.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150350625436.19506.508612463163381728@ietfa.amsl.com> Date: Wed, 23 Aug 2017 09:37:34 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-mboned-interdomain-peering-bcp-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 16:37:35 -0000 Reviewer: Barry Leiba Review result: Ready This document seems ready, and seems to cover security concerns adequately. Carry on... From nobody Wed Aug 23 12:08:07 2017 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 D0249132935; Wed, 23 Aug 2017 12:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRXycAXZm2EV; Wed, 23 Aug 2017 12:08:04 -0700 (PDT) Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) (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 22D501323B8; Wed, 23 Aug 2017 12:08:04 -0700 (PDT) Received: by mail-it0-x243.google.com with SMTP id l200so275568itl.2; Wed, 23 Aug 2017 12:08:04 -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; bh=HiRzoXsCA4mrL/BmtrSG/1zBTSdOAvb7nmQhw4vZQcA=; b=swI1CCQJg03JQdbpdT4GDkZ3fFoPRvem69Amg+Gaw9RmeJCgc+fTFGx7o1gYAdwihF Hei27X5iJOWUCbhk039I4ztYHdELywjavBXWQZID5JsBwFG/EJ55D4xVpLqV2IkowZIj Bf3smMmi5VQAidGfc4wqIVhN6MVEUyYSgV7nB9KQai92J14fjDaWlSOInUkN+I8dExvM XCY9nkFR3pPLJLBJXx1E3zSkQ4I4HjZiNFZ60trOTIwTIVXfEjWcaw5KQmwfHx4UYJ/C MTv0Rz2YjIaiKVvDrbanCppLf+OKHdOkLHdZiJs9IKcKFfKobUY7AdxFtz0mSGtbhdNF GlEA== 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; bh=HiRzoXsCA4mrL/BmtrSG/1zBTSdOAvb7nmQhw4vZQcA=; b=NEybkenw1tehJVCoK/8FDcIVryCGBq2cmkKfYmfYyUGtKcgY3v4w4jgy7gnqjMIqsu w+LFw6JjSxEPYF/Lf6UqMNXj/MBMvVVaMDPbH3Y4vjhtcVXpkDXeWfyzno/7dFpmqFJU 82N4WIV7uSzVG3uIvfOrX+9iczhTQ8btPFc06R5/Il/TAyNo6N82dAO7GcZf2w8dA1w7 aFbQ9TeF9CHORzq3sCHXL+uhFjXIhUFlwX1ZxGunlP2wVhI+id/7eh6Ch7tMAkhmvR0c XudXUF6cRQq4onR3FNm74aCimdwCEQny8j7OSPN2zUuD7qbc0EWY2QA2GNkvnUS/QuXg USQw== X-Gm-Message-State: AHYfb5iSjaIhrVLyMI0ZQFqLWOwkxmU2RLonYfE/beM3AWjt5RcCK3UT Y3xWhIhIl0BC/CiX X-Received: by 10.36.103.201 with SMTP id u192mr4160781itc.46.1503515283234; Wed, 23 Aug 2017 12:08:03 -0700 (PDT) Received: from chriss-air.smd.local ([216.201.230.154]) by smtp.googlemail.com with ESMTPSA id 193sm1039528ioo.84.2017.08.23.12.08.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Aug 2017 12:08:02 -0700 (PDT) To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-rmcat-coupled-cc.all@ietf.org From: Chris Lonvick Message-ID: <599DD291.4080906@gmail.com> Date: Wed, 23 Aug 2017 14:08:01 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------070309090604060109040901" Archived-At: Subject: [secdir] SECDIR review of draft-ietf-rmcat-coupled-cc X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 19:08:06 -0000 This is a multi-part message in MIME format. --------------070309090604060109040901 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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 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 that the ID is ready with nits. This INFORMATIONAL draft discusses an experimental protocol. The Security Considerations section is adequate, but I would suggest including a brief statement that implementers should also be aware of the Security Considerations sections of RFC 3124 (normatively referenced), and RFCs 5348 and 7478 (both informatively referenced). Each of of these RFCs is discussed within the draft. I also agree with Section 5 of the Shepherd Writeup, and nothing need be done to the draft about that. This is a heavily transport related draft, being focussed entirely on details of congestion control. Security considerations are adequate, although they will likely need elaboration for a future standards-track revision of this work in the light of operational experience. The draft says little about operational complexity, and the risks of cheating and poor quality implementations, but this will depend on the experiences with the protocol, and cannot effectively be done without experimentation and controlled deployment experience. Regards, Chris --------------070309090604060109040901 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit 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 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 that the ID is ready with nits.

This INFORMATIONAL draft discusses an experimental protocol. The Security Considerations section is adequate, but I would suggest including a brief statement that implementers should also be aware of the Security Considerations sections of RFC 3124 (normatively referenced), and RFCs 5348 and 7478 (both informatively referenced). Each of of these RFCs is discussed within the draft.

I also agree with Section 5 of the Shepherd Writeup, and nothing need be done to the draft about that.
  This is a heavily transport related draft, being focussed entirely
  on details of congestion control. Security considerations are adequate,
  although they will likely need elaboration for a future standards-track
  revision of this work in the light of operational experience. The draft
  says little about operational complexity, and the risks of cheating and
  poor quality implementations, but this will depend on the experiences
  with the protocol, and cannot effectively be done without experimentation
  and controlled deployment experience.

Regards,
Chris
--------------070309090604060109040901-- From nobody Thu Aug 24 00:16:47 2017 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 23755132BE7; Thu, 24 Aug 2017 00:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 D5m4MQO3ct0S; Thu, 24 Aug 2017 00:16:45 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 ED8DC132B9C; Thu, 24 Aug 2017 00:16:44 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v7O7GgE1004496 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 24 Aug 2017 10:16:42 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v7O7GfOp027226; Thu, 24 Aug 2017 10:16:41 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22942.32089.500600.506465@fireball.acr.fi> Date: Thu, 24 Aug 2017 10:16:41 +0300 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org, draft-ietf-pals-p2mp-pw.all@tools.ietf.org X-Edit-Time: 11 min X-Total-Time: 13 min Archived-At: Subject: [secdir] Secdir review of draft-ietf-pals-p2mp-pw-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 07:16:47 -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 document describes the mechanims to signal point-to-multipoint pseudowires using LDP. The security considerations section simply points to the RFC4447bis (i.e., RFC8077) saying that security mechanisms described there are adequate. On the other hand RFC8077, says that LDP MD5 authentication key option as described in the section 2.9 of RFC5036 MUST be implemented. The section 2.9 of RFC5036 describes TCP MD5 signature option for LDP. This might have been adequate security for some protocol in 2007 (when RFC5036 was published, altought MD5 was already then known to be broken), but it IS NOT adequate security in 2017. I understand that this document is not really the one supposed to update the security option for the LDP, but there is draft-ijln-mpls-rfc5036bis which is moving LDP to internet standard still trying to keep the same broken MD5 based security in it. I think this document should include note saying, that security of the RFC5036 is no longer adequate for any use because it uses broken security protocol, but there is nothing better out there yet (or is there, I do not know enough of the LDP to know that), and perhaps point to the rfc5036bis also in hopes that it might some day fix the security of the LDP. I think this document (or whole PW and LDP system) has issues that needs to be fixed before it can be published. -- kivinen@iki.fi From nobody Thu Aug 24 00:24:24 2017 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 A2D38132B9F for ; Thu, 24 Aug 2017 00:24:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Reply-to: secdir-secretary@mit.edu Message-ID: <150355946266.24283.10598728074797578576.idtracker@ietfa.amsl.com> Date: Thu, 24 Aug 2017 00:24:22 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 07:24:22 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2017-08-31 Reviewer LC end Draft Ólafur Guðmundsson 2017-08-15 draft-ietf-sidr-rpki-validation-reconsidered-08 Dan Harkins 2017-08-09 draft-ietf-bess-evpn-etree-12 Benjamin Kaduk 2017-08-24 draft-ietf-teas-lsp-diversity-08 Charlie Kaufman 2017-08-24 draft-ietf-pce-rfc6006bis-03 Scott Kelly 2017-08-25 draft-ietf-tsvwg-sctp-ndata-12 Ben Laurie 2017-08-23 draft-ietf-pce-pce-initiated-lsp-10 David Mandelberg 2017-08-28 draft-ietf-ospf-encapsulation-cap-06 Catherine Meadows 2017-08-25 draft-ietf-mile-iodef-guidance-10 Matthew Miller 2017-08-24 draft-ietf-teas-pce-central-control-03 For telechat 2017-09-14 Reviewer LC end Draft Daniel Franke 2017-07-30 draft-ietf-curdle-ssh-dh-group-exchange-05 Daniel Gillmor 2017-07-30 draft-ietf-curdle-des-des-des-die-die-die-04 Sandra Murphy 2017-09-01 draft-ietf-mpls-ldp-mrt-06 Last calls: Reviewer LC end Draft Donald Eastlake 2017-07-30 draft-ietf-curdle-ssh-modp-dh-sha2-07 Phillip Hallam-Baker 2017-08-11 draft-ietf-rtcweb-jsep-21 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-11 Tom Yu 2017-07-25 draft-ietf-lamps-rfc5280-i18n-update-02 Tom Yu 2017-02-20 draft-ietf-slim-negotiating-human-language-13 Early review requests: Reviewer Due Draft Daniel Gillmor 2016-02-01 draft-ietf-rtcweb-security-08 Adam Montville 2017-08-29 draft-ietf-opsawg-mud-08 Next in the reviewer rotation: Yoav Nir Magnus Nystrom Hilarie Orman Radia Perlman Derrell Piper Tim Polk Vincent Roca Joseph Salowey Rich Salz Stefan Santesson From nobody Thu Aug 24 09:49:00 2017 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 528FE1321E6; Thu, 24 Aug 2017 09:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snEwJxGAH0UH; Thu, 24 Aug 2017 09:48:49 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F1511320DC; Thu, 24 Aug 2017 09:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23668; q=dns/txt; s=iport; t=1503593329; x=1504802929; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BERowRZUQNpkCHnjy9j3ZLnmRKUygJmU5eJ59Bj8LTY=; b=VYpqSA2QB2meyqaZay+c4daSgYh1mQF179WjkKHsymOPT758A2aRZAuM ou7vedVDtEdcrP5g35QVzLbEWRaMIUrPgb0EGR1re8mLM10FDX9S1XGTx UOZnNrragDBAk0AloNZNO5tKqAAlOIE+KFtDsipjQY0P4C5yc3ioI62Lw 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BjAQDlAZ9Z/4UNJK1TBwMaAQEBAQIBA?= =?us-ascii?q?QEBCAEBAQGCb2tkgRUHgy1Dih2QFoFOiFuIL4U9DoIELIFggzsCGoQ2PxgBAgE?= =?us-ascii?q?BAQEBAQFrKIUZBgwXVhACAQYCPwMCAgIfERQRAgQOBYlNTAMVEJEenWaCJ4c4D?= =?us-ascii?q?YQRAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWDKoICgy8rC4FlgQyCV4FpAQcLAQk?= =?us-ascii?q?tChURgkwwgjEFoB08AodUh3mEdgyCBoVjim+JcIJRiW4BHzh/C3cVWwGFAwEcg?= =?us-ascii?q?Wd2iGEGAQgXgQyBDwEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,422,1498521600"; d="scan'208,217";a="286941280" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Aug 2017 16:48:48 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v7OGmlqC005783 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 24 Aug 2017 16:48:47 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 24 Aug 2017 12:48:46 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1210.000; Thu, 24 Aug 2017 12:48:46 -0400 From: "Brian Weis (bew)" To: Yaron Sheffer CC: "secdir@ietf.org" , "draft-weis-gdoi-rekey-ack.all@ietf.org" , "ietf@ietf.org" Thread-Topic: Secdir last call review of draft-weis-gdoi-rekey-ack-05 Thread-Index: AQHTDgJglUgJl63bZkSkx0TnTx/5x6KUGN4A Date: Thu, 24 Aug 2017 16:48:46 +0000 Message-ID: References: <150194814585.18635.3104789196001873381@ietfa.amsl.com> In-Reply-To: <150194814585.18635.3104789196001873381@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.191.173] Content-Type: multipart/alternative; boundary="_000_E61F05DBEEB04140A2D4DB11163C4E13ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-weis-gdoi-rekey-ack-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 16:48:52 -0000 --_000_E61F05DBEEB04140A2D4DB11163C4E13ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWWFyb24sDQoNClRoYW5rcyBmb3IgdGhlIHJldmlldy4gV2XigJl2ZSBhZGRlZCBzb21lIGNs YXJpZmljYXRpb24gYmVsb3csIGFuZCBtYWRlIHNvbWUgY2hhbmdlcyBpbiAtMDYgdG8gYWRkcmVz cyB5b3VyIGNvbW1lbnRzLiBQbGVhc2UgbGV0IHVzIGtub3cgaWYgd2UgZGlkIG5vdCBhZGRyZXNz IHRoZW0gc2F0aXNmYWN0b3JpbHkuDQoNCk9uIEF1ZyA1LCAyMDE3LCBhdCA4OjQ5IEFNLCBZYXJv biBTaGVmZmVyIDx5YXJvbmYuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnlhcm9uZi5pZXRmQGdtYWls LmNvbT4+IHdyb3RlOg0KDQpSZXZpZXdlcjogWWFyb24gU2hlZmZlcg0KUmV2aWV3IHJlc3VsdDog SGFzIElzc3Vlcw0KDQpTdW1tYXJ5OiB0aGlzIHJldmlld2VyIGlzIG5vdCBjbGVhciBhYm91dCB0 aGUgdmFsdWUgb2YgdGhlIHB1c2gtYWNrIChjb21wYXJlZA0KdG8gYSBwdWxsKSBhbmQgYWJvdXQg dGhlIHN0cmF0ZWd5IHRoYXQgd2FzIGNob3Nlbi4NCg0KSW4gYSBncm91cCBrZXkgbWFuYWdlbWVu dCBzeXN0ZW0gZWl0aGVyIGEg4oCccHVsbOKAnSAodHJpZ2dlcmVkIGJ5IGEgZ3JvdXAgbWVtYmVy KSBvciBhIOKAnHB1c2jigJ0gKGJ5IHRoZSBrZXkgc2VydmVyKSIgY291bGQgYmUgdXNlZCB0byBw cm92aWRlIHVwZGF0ZXMgdG8gdGhlIGdyb3VwLiBIb3dldmVyLCBhIOKAnHB1bGzigJ0gYnkgdGhl IGdyb3VwIG1lbWJlciBpbXBsaWVzIGEgcG9sbGluZyBtZXRob2QsIHdoaWNoIGhhcyB0aGUgZGVm aWNpZW5jeSB0aGF0IHRoZSBrZXkgc2VydmVyIGNhbm5vdCBjYXVzZSBhIHBvbGljeSByZXBsYWNl bWVudCBhbnkgc29vbmVyIHRoYW4gdGhlIHBvbGxpbmcgbWV0aG9kIGJ5IHRoZSBncm91cCBtZW1i ZXJzLiBBbHNvIOKAnHBvbGxpbmfigJ0gY2FuIGNhdXNlIGFkZGl0aW9uYWwgdW5uZWNlc3Nhcnkg dHJhZmZpYy4gU28gaXMgaXMgYmV0dGVyIGZvciBhbnkgdXBkYXRlIG9uIHRoZSBncm91cCBwb2xp Y3kgb3IgcmVuZXdhbCBvZiBncm91cCBrZXlzIHRvIGJlIGRpc3RyaWJ1dGVkIGJ5IHRoZSBHQ0tT IHVzaW5nIGEgUFVTSCBtZXNzYWdlLiBUaGUgQUNLLW1lc3NhZ2UgaXMgdXNlZCB0byBvZmZlciBh IGZlZWRiYWNrIG1lY2hhbmlzbSB0byBhIHBvbGljeSB1cGRhdGUgZm9yIHRoZSBQVVNIIGV4Y2hh bmdlLg0KKiAiRm9yIGV4YW1wbGUsIGEgR0NLUyBwb2xpY3kgY2FuIHVzZSB0aGUgYWNrbm93bGVk Z2VtZW50cyB0byBkZXRlcm1pbmUgWy4uLl0NCndoaWNoIG1lbWJlcnMgbWF5IG5vIGxvbmdlciBi ZSBtZW1iZXJzIG9mIHRoZSBncm91cC4iIFRoaXMgc2VudGVuY2UgaXMgdmVyeQ0KY29uZnVzaW5n OiB3aGVuIGFyZSBtZW1iZXJzIG5vdCBtZW1iZXJzPw0KDQpXZeKAmXZlIHJld29yZGVkIHRoaXMg dGV4dC4gSXTigJlzIHRyeWluZyB0byBjb252ZXkgdGhhdCBhIG1pc3NpbmcgQUNLIG1lc3NhZ2Ug KG9yIGEgY2VydGFpbiBudW1iZXIgb2YgaXQpIGNhbiBiZSB1c2VkIHRvIGlkZW50aWZ5IHRoYXQg YSBncm91cCBtZW1iZXIgaXMgbm8gbG9uZ2VyIHJlY2VpdmluZyBncm91cCB0cmFmZmljLCBhbmQg aXMgbm93IG1heSBiZSBjb25zaWRlcmVkIGFuIGV4LWdyb3VwIG1lbWJlci4gRm9yIGV4YW1wbGUs IGl0IGNvdWxkIGJlIGEgbXVsdGljYXN0IHJlY2VpdmVyIHRoYXQgaXMgbm8gbG9uZ2VyIGludGVy ZXN0ZWQgaW4gYmVpbmcgYSByZWNlaXZlciBmb3IgdGhlIGdyb3VwLiBCdXQgaXQgY291bGQgYWxz byBiZSB0aGF0IGEgbmV0d29yayBldmVudCBoYXMgY2F1c2VkIGl0IHRvIGJlIHVuYXZhaWxhYmxl IGZvciBhIHN1ZmZpY2llbnQgbGVuZ3RoIG9mIHRpbWUgc3VjaCB0aGF0IGl0IGRvZXNu4oCZdCBo YXZlIGN1cnJlbnQga2V5aW5nIG1hdGVyaWFsIGFuZCB0aGVyZWZvcmUgY2Fu4oCZdCBiZSBjb25z aWRlcmVkIGEgY3VycmVudCBncm91cCBtZW1iZXIuIFRoZXJlIGlzIG5vIHJlbGlhYmxlIOKAnEni gJltIGxlYXZpbmcgdGhlIGdyb3Vw4oCdIG1lc3NhZ2UgZmxvdywgYW5kIG9mIGNvdXJzZSBpbiBt eSBzZWNvbmQgZXhhbXBsZSBubyBzdWNoIG1lc3NhZ2VzIHdvdWxkIGhhdmUgYmVlbiBpbnRlbmRl ZCBieSB0aGUgZ3JvdXAgbWVtYmVyLg0KDQoqIFRoZSBuZXcgcHJvdG9jb2wgY2FwYWJpbGl0eSBp cyBkZWZpbmVkIGFzIG9wdGlvbmFsLCBidXQgcmVhbGx5IGlzbid0LiAiQSBHTQ0KcmVjZWl2aW5n IHRoZSBLRUtfQUNLX1JFUVVFU1RFRCBhdHRyaWJ1dGUgY2FuIGNob29zZSB0byBpZ25vcmUgaXQs IHRodXMNCmFwcGVhcmluZyBhcyBpZiBpdCBkb2VzIG5vdCBzdXBwb3J0IHRoZSBLRUtfQUNLX1JF UVVFU1RFRCBhdHRyaWJ1dGUuIEhvd2V2ZXIsDQpHQ0tTIHBvbGljeSBtYXkgY29uc2lkZXIgYSBu b24tcmVzcG9uc2l2ZSBHTSB0byBubyBsb25nZXIgZGVzaXJlIHRvIGJlIGEgbWVtYmVyDQpvZiB0 aGUgZ3JvdXAuIiBTbyBpZiB5b3Ugd2FudCB0byBwbGF5IHRoZSBnYW1lLCB5b3UgTVVTVCBzdXBw b3J0IHRoZSBuZXcNCmF0dHJpYnV0ZS4NCg0KUG9pbnQgdGFrZW4uIFdl4oCZdmUgY2hhbmdlZCB0 aGUgdGV4dCB0byByZWZsZWN0IHRoaXMuDQoNCiogSSdtIHB1enpsZWQgYXQgdGhlIG92ZXJhbGwg cHJvdG9jb2wuIEJlaW5nIGFibGUgdG8gc2VuZCBBQ0tzIGlzIGEgR00gc29mdHdhcmUNCmNhcGFi aWxpdHkuIFdoeSBub3QgaGF2ZSB0aGUgR00gYW5ub3VuY2UgdGhpcyBjYXBhYmlsaXR5IHdoZW4g aXQgaW5pdGlhbGx5DQpyZWdpc3RlcnMgdG8gdGhlIEdDS1M/IFRoZW4gdGhlIEdDS1Mgd291bGQg a25vdyB3aGF0IHRvIGV4cGVjdCwgd2hlcmVhcyB3aXRoDQp0aGUgY3VycmVudCBwcm90b2NvbCBp dCBpcyBsZWZ0IHdhaXRpbmcgZm9yIGFuIEFDSyB0aGF0IG1heSBuZXZlciBjb21lLCBlaXRoZXIN CmJlY2F1c2UgdGhlIEdNIGlzIGRlYWQgb3IgYmVjYXVzZSBpdCBqdXN0IGRvZXNuJ3QgZmVlbCBs aWtlIHJlc3BvbmRpbmcuIEFkZCB0aGUNCmxvbmcgd2FpdHMgKGppdHRlciBvZiAiYSBmZXcgc2Vj b25kcyIgYW5kIHBvdGVudGlhbCByZXRyaWVzKSwgYW5kIHRoaXMgbG9va3MNCmxpa2UgYSBmYXIg ZnJvbSBvcHRpbWFsIG1hbmFnZW1lbnQgZXhwZXJpZW5jZS4NCg0KSW5kZWVkIGEgR00gY291bGQg YW5ub3VuY2UgaXRzIGNhcGFiaWxpdHksIGJ1dCB3aGV0aGVyIG9yIG5vdCBBQ0tzIGFyZSBkZXNp cmVkIGlzIGEgY29tcG9uZW50IG9mIHRoZSBncm91cCBwb2xpY3kuIEluIHRoZSBjb250ZXh0IG9m IEdET0kgdGhlIEdDS1MgaXMgdGhlIGVudGl0eSB0aGF0IGRlZmluZXMgdGhlIGdyb3VwIHBvbGlj eS4gVGhlcmUgY2FuIGJlIGdyb3VwcyB3aGVyZSB0aGUgQUNLIGlzIHVzZWQsIHdoZXJlYXMgb3Ro ZXJzIGRvIG5vdC4gIFRoZSBjYXBhYmlsaXRpZXMgYW5ub3VuY2VtZW50IHlvdSBzdWdnZXN0IGNv dWxkIGNlcnRhaW5seSBoZWxwIHRoZSBLUyB0byBrbm93IHdoZXRoZXIgb3Igbm90IHRvIGV4cGVj dCB0aGUgQUNLIGZyb20gYSBwYXJ0aWN1bGFyIEdNLCBidXQgdGhlIGZvY3VzIG9mIHRoaXMgSS1E IGlzIG9uIHRoZSB0aGUgZGVjbGFyYXRpb24gb2YgdGhlIHJlcXVlc3QgZm9yIEFDS3MgYnkgdGhl IEdDS1MgYW5kIHRoZSBmb3JtYXQgb2YgdGhlIEFDSy4NCg0KKiAyLjI6ICJUaGlzIGlzIGEgcHJp dmF0ZSBrZXkiIC0gdG8gYXZvaWQgY29uZnVzaW9uLCBJIHN1Z2dlc3Q6ICJUaGlzIGlzIGENCnNl Y3JldCBzeW1tZXRyaWMga2V5IiAoaWYgdGhpcyBpcyBpbmRlZWQgdGhlIGNhc2UpLiBPYnZpb3Vz bHkgdXNpbmcgdGhlIHNhbWUNCmtleSBmb3IgZW5jcnlwdGlvbiBhbmQgZm9yIEhNQUMgaXMgbm90 IGEgYmVzdCBwcmFjdGljZS4NCg0KV2XigJl2ZSBtYWRlIHRoaXMgY2hhbmdlLg0KDQoqIFNlYy4g NTogQUNLIG1lc3NhZ2VzIGNhbiBhbHNvIGJlIGR1cGxpY2F0ZWQgaW4gdGhlIG5ldHdvcmsuIEkg c3VnZ2VzdCB0byBhZGQNCmEgc2VudGVuY2UgZGVzY3JpYmluZyB3aGF0IHRoZSBHQ0tTIHNob3Vs ZCBkbyBpbiB0aGlzIGNhc2UuDQoNClRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAoc2VjdGlv biA3LjMpIGRlc2NyaWJlcyBhIG1ldGhvZCBmb3IgdGhlIEdDS1MgdG8gZGV0ZWN0IHJlcGxheXMu IFRoaXMgaXMgYXJndWFibHkgYmV0dGVyIHBsYWNlZCBpbiB0aGlzIHNlY3Rpb24sIHNvIHdl4oCZ dmUgbW92ZWQgaXQgaGVyZS4uDQoNCiogU2VjLiA2OiBJIGFtIGNvbmZ1c2VkIGFib3V0IHRoZSBu b3Rpb24gb2YgImppdHRlciIgaGVyZS4gSWYgdGhlIFBVU0ggbWVzc2FnZXMNCmFyZSBzZW50IGFz IG11bHRpY2FzdCAodGhlIHJlY29tbWVuZGVkIGFsdGVybmF0aXZlIEFGQUlDVCksIEknbSBub3Qg c3VyZSBhYm91dA0KdGhlIGJlbmVmaXQgb2YgdXNpbmcgbXVsdGljYXN0LCBnaXZlbiB0aGF0IGVh Y2ggcmVjaXBpZW50IHJlc3BvbmRzIHdpdGggYQ0KdW5pY2FzdCBBQ0suIEFuZCBpZiB0aGUgUFVT SCBpcyB1bmljYXN0LCB0aGVyZSBzaG91bGQgYmUgbm8gcmVhc29uIGZvciBhIGppdHRlcg0KYXMg dGhlIHNlbmRlciBjYW4gdGhyb3R0bGUgdGhlIFBVU0ggbWVzc2FnZXMgYXMgbmVjZXNzYXJ5Lg0K DQpUaGUgY29uY2VwdCBvZiDigJxqaXR0ZXLigJ0gaXMgbW9zdCB2YWx1YWJsZSBmb3IgcmVzcG9u c2VzIHRvIGEgbXVsdGljYXN0IFBVU0ggbWVzc2FnZS4gVGhlIHVzZSBvZiBhIG11bHRpY2FzdCBQ VVNIIG1lc3NhZ2UgbG93ZXIgcHJvY2Vzc2luZyBvbiB0aGUgR0NLUy4gU2luY2UgZWFjaCBHTSBj YW4gZSBnaXZlbiB0aGUgZXhhY3Qgc2FtZSBwb2xpY3ksIHRoZXJl4oCZcyBubyBjYWxsIHRvIHNl bmQgaXQgb3V0IGFzIGEgdW5pY2FzdCBtZXNzYWdlLiBUaGUgaml0dGVyIGhlbHBzIHNwcmVhZCBv dXQgdGhlIHJlcGxpZXMgYSBiaXQgdG8gYXZvaWQgaW51bmRhdGluZyB0aGUgR0NLUy4NCg0KKiBN b3Jlb3ZlciwgZXZlcnl0aGluZyB3b3VsZCBiZSBtdWNoIG1vcmUgcHJlZGljdGFibGUgaWYgdGhl IEdDS1MgY291bGQNCmluZGljYXRlIGlmIGEgaml0dGVyIGlzIGV4cGVjdGVkIGFuZCBob3cgbXVj aCBvZiBhIGppdHRlciAoYmFzZWQgb24gc2l6ZSBvZiB0aGUNCmdyb3VwLCBuZXR3b3JrIHRocm91 Z2hwdXQsIGFuZCBxdWV1ZSBsZW5ndGgpLiBTcGVjaWZpY2FsbHksIHRoaXMgd291bGQgYWxsb3cN CnRoZSBHQ0tTIHRvIHRlbGwgaG93IGxvbmcgaXQgc2hvdWxkIHdhaXQgZm9yIGFuIEFDSy4NCg0K VGhpcyB3b3VsZCBiZSBzb21ld2hhdCB1c2VmdWwsIGJ1dCBpbiBwcmFjdGljZSBtaWdodCBub3Qg aGVscCB0aGUgR0NLUyBhcyBtdWNoIGFzIGl0IHNlZW1zLiBUaGUgaml0dGVyIHZhbHVlIHByb3Zp ZGVkIHdvdWxkIGFsc28gYmUgZGVwZW5kZW50IG9uIHNldmVyYWwgbmV0d29yayBwYXJhbWV0ZXJz IHRoYXQgYXJlbuKAmXQgdW5kZXIgdGhlIGNvbnRyb2wgb2YgdGhlIEdDS1Mgb3IgdGhlIEdNLiBF dmVuIHdoZW4gdGhlIEdNIGRvZXMgbm90IGFkZCBhbnkgaml0dGVyIHRvIHRoZSBBQ0ssIHRoZSB1 bmRlcmx5aW5nIG5ldHdvcmsgbWF5IGRlbGF5IHRoZSBQVVNIIGFuZC9vciBmb3IgdGhlIEFDSy4g QW5kIGFzIHN0YXRlZCBpbiBTZWN0aW9uIDYsIHRoZSBHQ0tTIG1heSBiZSBjb25maWd1cmVkIHdp dGggYWRkaXRpb25hbCBwb2xpY3kgYWN0aW9ucyBsaWtlIHJldHJhbnNtaXNzaW9ucyB0byBvdmVy Y29tZSBsb3N0IEFDS3MuIEFsdG9nZXRoZXIgdG8gYWRkIGppdHRlciB0byB0aGUgQUNLIGlzIG5v dCBhIG11c3QsIGl0IGlzIGEgd2F5IHRvIGhlbHAgdGhlIEdDS1MgZGVhbCB3aXRoIGEgaHVnZSBu dW1iZXIgb2YgR01zLiBJbiBwcmFjdGljZSwgd2XigJl2ZSBmb3VuZCB0aGF0IGhhdmluZyB0aGUg R01zIGNob29zZSB0aGUgaml0dGVyIGhhcyB3b3JrZWQgd2VsbCwgZXZlbiB3aGVuIHRoZSBHTXMg YXJlIGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMuDQoNCiogQ3J5cHRvZ3JhcGhpYyBhZ2lsaXR5 OiB0aGlzIGRvY3VtZW50IHNwZWNpZmllcyBvbmx5IG9uZSBhbGdvcml0aG0gZm9yIHRoZQ0KSEFT SCB2YWx1ZSwgYW5kIHNheXMgdGhhdCBpZiBhIG5ldyBhbGdvcml0aG0gaXMgbmVlZGVkLCB0aGVy ZSB3aWxsIGJlIGEgbmV3DQpLRUtfQUNLX1JFUVVFU1RFRCBwYXlsb2FkIGRlZmluZWQuIEhvd2V2 ZXIgdG8gbWFrZSBzdXJlIHRoYXQgdGhpcyByZWFsbHkNCiJ3b3JrcyIsIHdlIG5lZWQgdG8gZGVm aW5lIHdoZXRoZXIgbXVsdGlwbGUgc3VjaCBwYXlsb2FkcyBjYW4gYmUgc2VudA0Kc2ltdWx0YW5l b3VzbHkgKGlmIGUuZy4gc29tZSBHTXMgc3RpbGwgc3VwcG9ydCB0aGUgb2xkIGFsZ29yaXRobSkg YW5kIHdoYXQncw0KdGhlIGV4cGVjdGVkIGJlaGF2aW9yLiBJIHdvdWxkIHN1Z2dlc3QgdG8gZGVm aW5lIGFuIGFkZGl0aW9uYWwgU0hBLTUxMiBwYXlsb2FkDQpqdXN0IHRvIG1ha2UgZm9yIGEgY29u Y3JldGUgZXhhbXBsZS4NCg0KVGhpcyBpcyBhIGdvb2Qgc3VnZ2VzdGlvbi4gV2XigJl2ZSBhZGRl ZCBTSEEtNTEyIHZlcnNpb25zIG9mIHRoZSBleGlzdGluZyBLRUtfQUNLX1JFUVVFU1RFRCB2YWx1 ZXMuDQoNClNlZSA8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdlaXMtZ2RvaS1y ZWtleS1hY2stMDY+DQoNClRoYW5rcywNCkJyaWFuDQoNCi0tDQpCcmlhbiBXZWlzDQpTZWN1cml0 eSwgQ1NHLCBDaXNjbyBTeXN0ZW1zDQpUZWxlcGhvbmU6ICsxIDQwOCA1MjYgNDc5Ng0KRW1haWw6 IGJld0BjaXNjby5jb208bWFpbHRvOmJld0BjaXNjby5jb20+DQoNCg== --_000_E61F05DBEEB04140A2D4DB11163C4E13ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgWWFyb24sDQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGFua3MgZm9yIHRoZSBy ZXZpZXcuIFdl4oCZdmUgYWRkZWQgc29tZSBjbGFyaWZpY2F0aW9uIGJlbG93LCBhbmQgbWFkZSBz b21lIGNoYW5nZXMgaW4gLTA2IHRvIGFkZHJlc3MgeW91ciBjb21tZW50cy4gUGxlYXNlIGxldCB1 cyBrbm93IGlmIHdlIGRpZCBub3QgYWRkcmVzcyB0aGVtIHNhdGlzZmFjdG9yaWx5LjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+T24gQXVnIDUsIDIwMTcsIGF0IDg6NDkgQU0sIFlhcm9uIFNoZWZmZXIgJmx0OzxhIGhyZWY9 Im1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20iIGNsYXNzPSIiPnlhcm9uZi5pZXRmQGdtYWls LmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1u ZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPlJldmlld2VyOiBZYXJvbiBT aGVmZmVyPGJyIGNsYXNzPSIiPg0KUmV2aWV3IHJlc3VsdDogSGFzIElzc3VlczxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NClN1bW1hcnk6IHRoaXMgcmV2aWV3ZXIgaXMgbm90IGNsZWFyIGFi b3V0IHRoZSB2YWx1ZSBvZiB0aGUgcHVzaC1hY2sgKGNvbXBhcmVkPGJyIGNsYXNzPSIiPg0KdG8g YSBwdWxsKSBhbmQgYWJvdXQgdGhlIHN0cmF0ZWd5IHRoYXQgd2FzIGNob3Nlbi48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCkluIGEgZ3JvdXAga2V5IG1hbmFnZW1lbnQgc3lzdGVtIGVpdGhlciBhIOKAnHB1bGzi gJ0gKHRyaWdnZXJlZCBieSBhIGdyb3VwIG1lbWJlcikgb3IgYSDigJxwdXNo4oCdIChieSB0aGUg a2V5IHNlcnZlcikmcXVvdDsgY291bGQgYmUgdXNlZCB0byBwcm92aWRlIHVwZGF0ZXMgdG8gdGhl IGdyb3VwLiBIb3dldmVyLCBhIOKAnHB1bGzigJ0gYnkgdGhlIGdyb3VwIG1lbWJlciBpbXBsaWVz IGEgcG9sbGluZyBtZXRob2QsIHdoaWNoIGhhcyB0aGUgZGVmaWNpZW5jeSB0aGF0IHRoZQ0KIGtl eSBzZXJ2ZXIgY2Fubm90IGNhdXNlIGEgcG9saWN5IHJlcGxhY2VtZW50IGFueSBzb29uZXIgdGhh biB0aGUgcG9sbGluZyBtZXRob2QgYnkgdGhlIGdyb3VwIG1lbWJlcnMuIEFsc28g4oCccG9sbGlu Z+KAnSBjYW4gY2F1c2UgYWRkaXRpb25hbCB1bm5lY2Vzc2FyeSB0cmFmZmljLiBTbyBpcyBpcyBi ZXR0ZXIgZm9yIGFueSB1cGRhdGUgb24gdGhlIGdyb3VwIHBvbGljeSBvciByZW5ld2FsIG9mIGdy b3VwIGtleXMgdG8gYmUgZGlzdHJpYnV0ZWQgYnkNCiB0aGUgR0NLUyB1c2luZyBhIFBVU0ggbWVz c2FnZS4mbmJzcDtUaGUgQUNLLW1lc3NhZ2UgaXMgdXNlZCB0byBvZmZlciBhIGZlZWRiYWNrIG1l Y2hhbmlzbSB0byBhIHBvbGljeSB1cGRhdGUgZm9yIHRoZSBQVVNIIGV4Y2hhbmdlLjxiciBjbGFz cz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdvcmRTZWN0aW9uMTsiPg0K PGRpdiBjbGFzcz0iIiBzdHlsZT0iYm9yZGVyLXN0eWxlOiBub25lIG5vbmUgbm9uZSBzb2xpZDsg Ym9yZGVyLWxlZnQtd2lkdGg6IDEuNXB0OyBib3JkZXItbGVmdC1jb2xvcjogYmx1ZTsgcGFkZGlu ZzogMGNtIDBjbSAwY20gNHB0OyI+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJib3JkZXItc3R5bGU6 IG5vbmUgbm9uZSBub25lIHNvbGlkOyBib3JkZXItbGVmdC13aWR0aDogMS41cHQ7IGJvcmRlci1s ZWZ0LWNvbG9yOiBibHVlOyBwYWRkaW5nOiAwY20gMGNtIDBjbSA0cHQ7Ij4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDEycHQ7IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KPGIgY2xhc3M9 IiI+PGkgY2xhc3M9IiI+PHNwYW4gbGFuZz0iRU4tVVMiIGNsYXNzPSIiIHN0eWxlPSJmb250LXNp emU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMx LCA3MywgMTI1KTsiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+KiAmcXVvdDtGb3IgZXhhbXBsZSwgYSBHQ0tTIHBv bGljeSBjYW4gdXNlIHRoZSBhY2tub3dsZWRnZW1lbnRzIHRvIGRldGVybWluZSBbLi4uXTxiciBj bGFzcz0iIj4NCndoaWNoIG1lbWJlcnMgbWF5IG5vIGxvbmdlciBiZSBtZW1iZXJzIG9mIHRoZSBn cm91cC4mcXVvdDsgVGhpcyBzZW50ZW5jZSBpcyB2ZXJ5PGJyIGNsYXNzPSIiPg0KY29uZnVzaW5n OiB3aGVuIGFyZSBtZW1iZXJzIG5vdCBtZW1iZXJzPzxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXYgY2xhc3M9IiI+V2XigJl2ZSByZXdvcmRlZCB0aGlzIHRleHQuIEl04oCZcyB0cnlpbmcgdG8g Y29udmV5IHRoYXQgYSBtaXNzaW5nIEFDSyBtZXNzYWdlIChvciBhIGNlcnRhaW4gbnVtYmVyIG9m IGl0KSBjYW4gYmUgdXNlZCB0byBpZGVudGlmeSB0aGF0IGEgZ3JvdXAgbWVtYmVyIGlzIG5vIGxv bmdlciByZWNlaXZpbmcgZ3JvdXAgdHJhZmZpYywgYW5kIGlzIG5vdyBtYXkgYmUgY29uc2lkZXJl ZCBhbiBleC1ncm91cCBtZW1iZXIuIEZvciBleGFtcGxlLA0KIGl0IGNvdWxkIGJlIGEgbXVsdGlj YXN0IHJlY2VpdmVyIHRoYXQgaXMgbm8gbG9uZ2VyIGludGVyZXN0ZWQgaW4gYmVpbmcgYSByZWNl aXZlciBmb3IgdGhlIGdyb3VwLiBCdXQgaXQgY291bGQgYWxzbyBiZSB0aGF0IGEgbmV0d29yayBl dmVudCBoYXMgY2F1c2VkIGl0IHRvIGJlIHVuYXZhaWxhYmxlIGZvciBhIHN1ZmZpY2llbnQgbGVu Z3RoIG9mIHRpbWUgc3VjaCB0aGF0IGl0IGRvZXNu4oCZdCBoYXZlIGN1cnJlbnQga2V5aW5nIG1h dGVyaWFsIGFuZA0KIHRoZXJlZm9yZSBjYW7igJl0IGJlIGNvbnNpZGVyZWQgYSBjdXJyZW50IGdy b3VwIG1lbWJlci4gVGhlcmUgaXMgbm8gcmVsaWFibGUg4oCcSeKAmW0gbGVhdmluZyB0aGUgZ3Jv dXDigJ0gbWVzc2FnZSBmbG93LCBhbmQgb2YgY291cnNlIGluIG15IHNlY29uZCBleGFtcGxlIG5v IHN1Y2ggbWVzc2FnZXMgd291bGQgaGF2ZSBiZWVuIGludGVuZGVkIGJ5IHRoZSBncm91cCBtZW1i ZXIuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPiogVGhlIG5ldyBwcm90b2NvbCBjYXBhYmlsaXR5IGlzIGRlZmluZWQgYXMgb3B0aW9u YWwsIGJ1dCByZWFsbHkgaXNuJ3QuICZxdW90O0EgR008YnIgY2xhc3M9IiI+DQpyZWNlaXZpbmcg dGhlIEtFS19BQ0tfUkVRVUVTVEVEIGF0dHJpYnV0ZSBjYW4gY2hvb3NlIHRvIGlnbm9yZSBpdCwg dGh1czxiciBjbGFzcz0iIj4NCmFwcGVhcmluZyBhcyBpZiBpdCBkb2VzIG5vdCBzdXBwb3J0IHRo ZSBLRUtfQUNLX1JFUVVFU1RFRCBhdHRyaWJ1dGUuIEhvd2V2ZXIsPGJyIGNsYXNzPSIiPg0KR0NL UyBwb2xpY3kgbWF5IGNvbnNpZGVyIGEgbm9uLXJlc3BvbnNpdmUgR00gdG8gbm8gbG9uZ2VyIGRl c2lyZSB0byBiZSBhIG1lbWJlcjxiciBjbGFzcz0iIj4NCm9mIHRoZSBncm91cC4mcXVvdDsgU28g aWYgeW91IHdhbnQgdG8gcGxheSB0aGUgZ2FtZSwgeW91IE1VU1Qgc3VwcG9ydCB0aGUgbmV3PGJy IGNsYXNzPSIiPg0KYXR0cmlidXRlLjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5Qb2ludCB0YWtlbi4g V2XigJl2ZSBjaGFuZ2VkIHRoZSB0ZXh0IHRvIHJlZmxlY3QgdGhpcy48L2Rpdj4NCjxkaXY+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPiogSSdtIHB1enpsZWQgYXQgdGhlIG92ZXJhbGwg cHJvdG9jb2wuIEJlaW5nIGFibGUgdG8gc2VuZCBBQ0tzIGlzIGEgR00gc29mdHdhcmU8YnIgY2xh c3M9IiI+DQpjYXBhYmlsaXR5LiBXaHkgbm90IGhhdmUgdGhlIEdNIGFubm91bmNlIHRoaXMgY2Fw YWJpbGl0eSB3aGVuIGl0IGluaXRpYWxseTxiciBjbGFzcz0iIj4NCnJlZ2lzdGVycyB0byB0aGUg R0NLUz8gVGhlbiB0aGUgR0NLUyB3b3VsZCBrbm93IHdoYXQgdG8gZXhwZWN0LCB3aGVyZWFzIHdp dGg8YnIgY2xhc3M9IiI+DQp0aGUgY3VycmVudCBwcm90b2NvbCBpdCBpcyBsZWZ0IHdhaXRpbmcg Zm9yIGFuIEFDSyB0aGF0IG1heSBuZXZlciBjb21lLCBlaXRoZXI8YnIgY2xhc3M9IiI+DQpiZWNh dXNlIHRoZSBHTSBpcyBkZWFkIG9yIGJlY2F1c2UgaXQganVzdCBkb2Vzbid0IGZlZWwgbGlrZSBy ZXNwb25kaW5nLiBBZGQgdGhlPGJyIGNsYXNzPSIiPg0KbG9uZyB3YWl0cyAoaml0dGVyIG9mICZx dW90O2EgZmV3IHNlY29uZHMmcXVvdDsgYW5kIHBvdGVudGlhbCByZXRyaWVzKSwgYW5kIHRoaXMg bG9va3M8YnIgY2xhc3M9IiI+DQpsaWtlIGEgZmFyIGZyb20gb3B0aW1hbCBtYW5hZ2VtZW50IGV4 cGVyaWVuY2UuPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkluZGVlZCBhIEdNIGNvdWxk IGFubm91bmNlIGl0cyBjYXBhYmlsaXR5LCBidXQgd2hldGhlciBvciBub3QgQUNLcyBhcmUgZGVz aXJlZCBpcyBhIGNvbXBvbmVudCBvZiB0aGUgZ3JvdXAgcG9saWN5LiBJbiB0aGUgY29udGV4dCBv ZiBHRE9JIHRoZSBHQ0tTIGlzIHRoZSBlbnRpdHkgdGhhdCBkZWZpbmVzIHRoZSBncm91cCBwb2xp Y3kuIFRoZXJlIGNhbiBiZSBncm91cHMgd2hlcmUgdGhlIEFDSyBpcyB1c2VkLCB3aGVyZWFzDQog b3RoZXJzIGRvIG5vdC4gJm5ic3A7VGhlIGNhcGFiaWxpdGllcyBhbm5vdW5jZW1lbnQgeW91IHN1 Z2dlc3QgY291bGQgY2VydGFpbmx5IGhlbHAgdGhlIEtTIHRvIGtub3cgd2hldGhlciBvciBub3Qg dG8gZXhwZWN0IHRoZSBBQ0sgZnJvbSBhIHBhcnRpY3VsYXIgR00sIGJ1dCB0aGUgZm9jdXMgb2Yg dGhpcyBJLUQgaXMgb24gdGhlIHRoZSBkZWNsYXJhdGlvbiBvZiB0aGUgcmVxdWVzdCBmb3IgQUNL cyBieSB0aGUgR0NLUyBhbmQgdGhlIGZvcm1hdCBvZiB0aGUNCiBBQ0suPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4qIDIuMjogJnF1b3Q7VGhpcyBp cyBhIHByaXZhdGUga2V5JnF1b3Q7IC0gdG8gYXZvaWQgY29uZnVzaW9uLCBJIHN1Z2dlc3Q6ICZx dW90O1RoaXMgaXMgYTxiciBjbGFzcz0iIj4NCnNlY3JldCBzeW1tZXRyaWMga2V5JnF1b3Q7IChp ZiB0aGlzIGlzIGluZGVlZCB0aGUgY2FzZSkuIE9idmlvdXNseSB1c2luZyB0aGUgc2FtZTxiciBj bGFzcz0iIj4NCmtleSBmb3IgZW5jcnlwdGlvbiBhbmQgZm9yIEhNQUMgaXMgbm90IGEgYmVzdCBw cmFjdGljZS48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSIiPldl4oCZdmUgbWFk ZSB0aGlzIGNoYW5nZS48L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4qIFNl Yy4gNTogQUNLIG1lc3NhZ2VzIGNhbiBhbHNvIGJlIGR1cGxpY2F0ZWQgaW4gdGhlIG5ldHdvcmsu IEkgc3VnZ2VzdCB0byBhZGQ8YnIgY2xhc3M9IiI+DQphIHNlbnRlbmNlIGRlc2NyaWJpbmcgd2hh dCB0aGUgR0NLUyBzaG91bGQgZG8gaW4gdGhpcyBjYXNlLjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5U aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgKHNlY3Rpb24gNy4zKSBkZXNjcmliZXMgYSBtZXRo b2QgZm9yIHRoZSBHQ0tTIHRvIGRldGVjdCByZXBsYXlzLiBUaGlzIGlzIGFyZ3VhYmx5IGJldHRl ciBwbGFjZWQgaW4gdGhpcyBzZWN0aW9uLCBzbyB3ZeKAmXZlIG1vdmVkIGl0IGhlcmUuLjwvZGl2 Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4qIFNlYy4gNjogSSBhbSBjb25mdXNlZCBhYm91dCB0 aGUgbm90aW9uIG9mICZxdW90O2ppdHRlciZxdW90OyBoZXJlLiBJZiB0aGUgUFVTSCBtZXNzYWdl czxiciBjbGFzcz0iIj4NCmFyZSBzZW50IGFzIG11bHRpY2FzdCAodGhlIHJlY29tbWVuZGVkIGFs dGVybmF0aXZlIEFGQUlDVCksIEknbSBub3Qgc3VyZSBhYm91dDxiciBjbGFzcz0iIj4NCnRoZSBi ZW5lZml0IG9mIHVzaW5nIG11bHRpY2FzdCwgZ2l2ZW4gdGhhdCBlYWNoIHJlY2lwaWVudCByZXNw b25kcyB3aXRoIGE8YnIgY2xhc3M9IiI+DQp1bmljYXN0IEFDSy4gQW5kIGlmIHRoZSBQVVNIIGlz IHVuaWNhc3QsIHRoZXJlIHNob3VsZCBiZSBubyByZWFzb24gZm9yIGEgaml0dGVyPGJyIGNsYXNz PSIiPg0KYXMgdGhlIHNlbmRlciBjYW4gdGhyb3R0bGUgdGhlIFBVU0ggbWVzc2FnZXMgYXMgbmVj ZXNzYXJ5LjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5UaGUgY29uY2VwdCBvZiDigJxqaXR0ZXLigJ0g aXMgbW9zdCB2YWx1YWJsZSBmb3IgcmVzcG9uc2VzIHRvIGEgbXVsdGljYXN0IFBVU0ggbWVzc2Fn ZS4gVGhlIHVzZSBvZiBhIG11bHRpY2FzdCBQVVNIIG1lc3NhZ2UgbG93ZXIgcHJvY2Vzc2luZyBv biB0aGUgR0NLUy4gU2luY2UgZWFjaCBHTSBjYW4gZSBnaXZlbiB0aGUgZXhhY3Qgc2FtZSBwb2xp Y3ksIHRoZXJl4oCZcyBubyBjYWxsIHRvIHNlbmQgaXQgb3V0IGFzIGEgdW5pY2FzdCBtZXNzYWdl Lg0KIFRoZSBqaXR0ZXIgaGVscHMgc3ByZWFkIG91dCB0aGUgcmVwbGllcyBhIGJpdCB0byBhdm9p ZCBpbnVuZGF0aW5nIHRoZSBHQ0tTLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+KiBNb3Jlb3ZlciwgZXZlcnl0aGluZyB3b3VsZCBiZSBtdWNoIG1vcmUgcHJlZGlj dGFibGUgaWYgdGhlIEdDS1MgY291bGQ8YnIgY2xhc3M9IiI+DQppbmRpY2F0ZSBpZiBhIGppdHRl ciBpcyBleHBlY3RlZCBhbmQgaG93IG11Y2ggb2YgYSBqaXR0ZXIgKGJhc2VkIG9uIHNpemUgb2Yg dGhlPGJyIGNsYXNzPSIiPg0KZ3JvdXAsIG5ldHdvcmsgdGhyb3VnaHB1dCwgYW5kIHF1ZXVlIGxl bmd0aCkuIFNwZWNpZmljYWxseSwgdGhpcyB3b3VsZCBhbGxvdzxiciBjbGFzcz0iIj4NCnRoZSBH Q0tTIHRvIHRlbGwgaG93IGxvbmcgaXQgc2hvdWxkIHdhaXQgZm9yIGFuIEFDSy48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXY+VGhpcyB3b3VsZCBiZSBzb21ld2hhdCB1c2VmdWwsIGJ1dCBpbiBwcmFjdGlj ZSBtaWdodCBub3QgaGVscCB0aGUgR0NLUyBhcyBtdWNoIGFzIGl0IHNlZW1zLiBUaGUgaml0dGVy IHZhbHVlIHByb3ZpZGVkIHdvdWxkIGFsc28gYmUgZGVwZW5kZW50IG9uIHNldmVyYWwmbmJzcDtu ZXR3b3JrIHBhcmFtZXRlcnMgdGhhdCBhcmVu4oCZdCB1bmRlciB0aGUgY29udHJvbCBvZiB0aGUg R0NLUyBvciB0aGUgR00uIEV2ZW4gd2hlbiB0aGUgR00gZG9lcyBub3QgYWRkDQogYW55IGppdHRl ciB0byB0aGUgQUNLLCB0aGUgdW5kZXJseWluZyBuZXR3b3JrIG1heSZuYnNwO2RlbGF5IHRoZSBQ VVNIIGFuZC9vciBmb3IgdGhlIEFDSy4gQW5kIGFzIHN0YXRlZCBpbiBTZWN0aW9uIDYsIHRoZSBH Q0tTIG1heSBiZSBjb25maWd1cmVkIHdpdGggYWRkaXRpb25hbCBwb2xpY3kgYWN0aW9ucyBsaWtl IHJldHJhbnNtaXNzaW9ucyB0byBvdmVyY29tZSZuYnNwO2xvc3QgQUNLcy4gQWx0b2dldGhlciB0 byBhZGQgaml0dGVyIHRvIHRoZSBBQ0sgaXMgbm90DQogYSBtdXN0LCBpdCBpcyBhIHdheSB0byBo ZWxwIHRoZSBHQ0tTIGRlYWwgd2l0aCBhIGh1Z2UgbnVtYmVyIG9mIEdNcy4gSW4gcHJhY3RpY2Us IHdl4oCZdmUgZm91bmQgdGhhdCBoYXZpbmcgdGhlIEdNcyBjaG9vc2UgdGhlIGppdHRlciBoYXMg d29ya2VkIHdlbGwsIGV2ZW4gd2hlbiB0aGUgR01zIGFyZSBkaWZmZXJlbnQgaW1wbGVtZW50YXRp b25zLjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4qIENyeXB0b2dyYXBoaWMgYWdpbGl0 eTogdGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgb25seSBvbmUgYWxnb3JpdGhtIGZvciB0aGU8YnIg Y2xhc3M9IiI+DQpIQVNIIHZhbHVlLCBhbmQgc2F5cyB0aGF0IGlmIGEgbmV3IGFsZ29yaXRobSBp cyBuZWVkZWQsIHRoZXJlIHdpbGwgYmUgYSBuZXc8YnIgY2xhc3M9IiI+DQpLRUtfQUNLX1JFUVVF U1RFRCBwYXlsb2FkIGRlZmluZWQuIEhvd2V2ZXIgdG8gbWFrZSBzdXJlIHRoYXQgdGhpcyByZWFs bHk8YnIgY2xhc3M9IiI+DQomcXVvdDt3b3JrcyZxdW90Oywgd2UgbmVlZCB0byBkZWZpbmUgd2hl dGhlciBtdWx0aXBsZSBzdWNoIHBheWxvYWRzIGNhbiBiZSBzZW50PGJyIGNsYXNzPSIiPg0Kc2lt dWx0YW5lb3VzbHkgKGlmIGUuZy4gc29tZSBHTXMgc3RpbGwgc3VwcG9ydCB0aGUgb2xkIGFsZ29y aXRobSkgYW5kIHdoYXQnczxiciBjbGFzcz0iIj4NCnRoZSBleHBlY3RlZCBiZWhhdmlvci4gSSB3 b3VsZCBzdWdnZXN0IHRvIGRlZmluZSBhbiBhZGRpdGlvbmFsIFNIQS01MTIgcGF5bG9hZDxiciBj bGFzcz0iIj4NCmp1c3QgdG8gbWFrZSBmb3IgYSBjb25jcmV0ZSBleGFtcGxlLjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2IGNsYXNzPSIiPlRoaXMgaXMgYSBnb29kIHN1Z2dlc3Rpb24uIFdl4oCZdmUg YWRkZWQgU0hBLTUxMiB2ZXJzaW9ucyBvZiB0aGUgZXhpc3RpbmcgS0VLX0FDS19SRVFVRVNURUQg dmFsdWVzLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+U2VlICZsdDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtd2Vpcy1nZG9pLXJla2V5LWFjay0wNiIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXdlaXMtZ2RvaS1yZWtleS1hY2stMDY8L2E+Jmd0OzwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhhbmtzLDwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj5CcmlhbjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPi0tJm5ic3A7PGJyIGNsYXNzPSIiPg0KQnJpYW4gV2VpczxiciBjbGFzcz0iIj4N ClNlY3VyaXR5LCBDU0csIENpc2NvIFN5c3RlbXM8YnIgY2xhc3M9IiI+DQpUZWxlcGhvbmU6ICYj NDM7MSA0MDggNTI2IDQ3OTY8YnIgY2xhc3M9IiI+DQpFbWFpbDogPGEgaHJlZj0ibWFpbHRvOmJl d0BjaXNjby5jb20iIGNsYXNzPSIiPmJld0BjaXNjby5jb208L2E+IDwvZGl2Pg0KPGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E61F05DBEEB04140A2D4DB11163C4E13ciscocom_-- From nobody Thu Aug 24 10:39:26 2017 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 BB5AA13247A for ; Thu, 24 Aug 2017 10:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=unavailable 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 3vqksfvey8PM for ; Thu, 24 Aug 2017 10:39:19 -0700 (PDT) Received: from smtp90.iad3a.emailsrvr.com (smtp90.iad3a.emailsrvr.com [173.203.187.90]) (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 94CD41329BE for ; Thu, 24 Aug 2017 10:39:18 -0700 (PDT) Received: from smtp36.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp36.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 9E88E571D; Thu, 24 Aug 2017 13:39:17 -0400 (EDT) Received: from app31.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp36.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 84E885B67; Thu, 24 Aug 2017 13:39:17 -0400 (EDT) X-Sender-Id: scott@hyperthought.com Received: from app31.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Thu, 24 Aug 2017 13:39:17 -0400 Received: from hyperthought.com (localhost.localdomain [127.0.0.1]) by app31.wa-webapps.iad3a (Postfix) with ESMTP id 729ECC0067; Thu, 24 Aug 2017 13:39:17 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Thu, 24 Aug 2017 10:39:17 -0700 (PDT) X-Auth-ID: scott@hyperthought.com Date: Thu, 24 Aug 2017 10:39:17 -0700 (PDT) From: "Scott G. Kelly" To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-tsvwg-sctp-ndata.all@ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain Message-ID: <1503596357.467129961@apps.rackspace.com> X-Mailer: webmail/12.9.5-RC Archived-At: Subject: [secdir] secdir review of draft-ietf-tsvwg-sctp-ndata-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 17:39:22 -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 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.=0A=0AThe summary of the review is ready with (m= aybe) issues. I'm not sure if there is an issue or not. Maybe this can be q= uickly resolved.=0A=0AParaphrasing from the abstract, the document adds a n= ew chunk to SCTP for carrying payload data, allowing a sender to interleave= different user messages that would otherwise result in head of line blocki= ng at the sender. =0A=0AAn example usage: a client (or server) is sending a= large message over SCTP, so it fragments the message and sends the fragmen= ts one after the other; each fragment is assigned a Transmission Sequence N= umber (TSN). If that client has a higher priority message to send during th= e transmission of the fragments, that message must go to the end of the lin= e. This document defines a "stream", and allows interleaving streams, so th= at the higher priority message can be transmitted immediately (on its own s= tream), and the receiver will understand that this is not part of the lower= priority message's TSN chain (stream).=0A =0AThe security considerations s= ection says=0A=0A This document does not add any additional security cons= iderations in=0A addition to the ones given in [RFC4960] and [RFC6458].= =0A=0A It should be noted that the application has to consent that it is= =0A willing to do the more complex reassembly support required for user= =0A message interleaving. When doing so, an application has to provide= =0A up to two reassembly buffers (one for ordered messages, one for=0A = unordered messages) for each incoming stream. It has to protect=0A itsel= f against these buffers taking too many resources. If user=0A message in= terleaving is not used, only a single reassembly buffer=0A needs to be pr= ovided for each association. But the application has=0A to protect itsel= f for excessive resource usages there too.=0A=0AThe security considerations= of 4960 are very thorough, but they never mention anything about fragment = reassembly issues. I don't know much about SCTP, so maybe this is not a con= cern, but I wondered: could a hostile endpoint attack the reassembly scheme= (which must be reimplemented for each application) by sending malicious fr= agments?=0A=0A--Scott=0A From nobody Thu Aug 24 15:26:38 2017 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 71BE3132710; Thu, 24 Aug 2017 15:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 mukSb6JI0xef; Thu, 24 Aug 2017 15:26:30 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E00BA1326FE; Thu, 24 Aug 2017 15:26:29 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id r9so7507302oie.3; Thu, 24 Aug 2017 15:26:29 -0700 (PDT) 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=Ph11YgcVWe4c/xb9lGD8rSlQbmDuKhry+0wzDVASaQ8=; b=omUS1O/U0U0ClFXglPL2nM0YuXD/1cUNNGO8RmatggITwhzYDoV1KmhQFn7u4U1wRu Rgeo9FIAgfH0S8NOHgPFV/u65PS+aEs+rhOrqG5gvuPc3LKF0QCFM7aVTZToM7wveNUN /gKLxBhC+zvkXMQWlw1kcNuVSMEUKa2d5Le0WJjylMiV61EezggNy+DT1WGf8OGxbWI0 8iqwmvbFgXL2AXuJELpdlsFgAwwJuHoPLUABVj4RXuNpa6Sh4rECvsP/SlhLSiSSettS j+7mAMN43hG/XMtRRTMFYwxURGa1NbLEmT5qzyY0Ud3vrFC3ZiKXpslT18QHzbz8Vvpa S2Zw== 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=Ph11YgcVWe4c/xb9lGD8rSlQbmDuKhry+0wzDVASaQ8=; b=QEUsiXlJBqYL8338TvefUIQu1Xcb/qkEfGIiLOYatEzYPZ9YjDWMO7Y6CILeoKKiW8 WZt/mYca+1TqPAdhVLJcL24NcWyIhGOJ9l6BmbzdejfcN15MNLsRUp48g9TvUnD+KSBn +FP7AK1B0nTxO6K2NHkF84jAvlpU2hOLN5l48UmlcMSXGF1qeFy2DYyEgHXFq7K3W1v0 cZ4as5GWm153C+SkaUBlYfSP905nYhxY1JskzJgD4wZ9kgQTcW0MigtqM+9o+ML7j2HC REFgQdBQmupeht3IwirWF89U2t12vlbhSDnKlv14QM7PFtXknG5Hed0hD4wzwSWnLzBs +w7Q== X-Gm-Message-State: AHYfb5h/TMLQlWdwzNvFJ5V/St0lARslLaUHQWj7Jr1oxbdoThUqQjPu vlS6B7n2zKpH36Xff044dCthxgMPqJ1DrHM= X-Received: by 10.202.242.2 with SMTP id q2mr9544118oih.71.1503613589167; Thu, 24 Aug 2017 15:26:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.168.183.10 with HTTP; Thu, 24 Aug 2017 15:26:13 -0700 (PDT) From: Donald Eastlake Date: Thu, 24 Aug 2017 18:26:13 -0400 Message-ID: To: "iesg@ietf.org" , draft-ietf-curdle-ssh-modp-dh-sha2@ietf.org Cc: "secdir@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [secdir] draft-ietf-curdle-ssh-modp-dh-sha2 SECDIR review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 22:26:31 -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. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready. I am not an expert on MODP groups or the like but this document looks good to me. I would comment that I am used to information about where comments on the draft should be sent being on the title page rather than on page 3 at the end of Section 1. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Fri Aug 25 03:44:21 2017 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 8B1421321BB; Fri, 25 Aug 2017 03:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 zP4k6ohjR9fr; Fri, 25 Aug 2017 03:44:10 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22BB8132A97; Fri, 25 Aug 2017 03:44:09 -0700 (PDT) Received: from [192.168.1.204] (p57BB53DA.dip0.t-ipconnect.de [87.187.83.218]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 8EBF1721E281A; Fri, 25 Aug 2017 12:44:04 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_8108BCB0-8311-4314-8518-A391AC480DB7"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Tuexen X-Priority: 3 (Normal) In-Reply-To: <1503596357.467129961@apps.rackspace.com> Date: Fri, 25 Aug 2017 12:44:02 +0200 Cc: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-tsvwg-sctp-ndata.all@ietf.org Message-Id: References: <1503596357.467129961@apps.rackspace.com> To: "Scott G. Kelly" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-sctp-ndata-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 10:44:13 -0000 --Apple-Mail=_8108BCB0-8311-4314-8518-A391AC480DB7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 24. Aug 2017, at 19:39, Scott G. Kelly = wrote: Hi Scott, thank you very much for the review. See my comments in-line. Best regards Michael >=20 > 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. >=20 > The summary of the review is ready with (maybe) issues. I'm not sure = if there is an issue or not. Maybe this can be quickly resolved. >=20 > Paraphrasing from the abstract, the document adds a new chunk to SCTP = for carrying payload data, allowing a sender to interleave different = user messages that would otherwise result in head of line blocking at = the sender.=20 >=20 > An example usage: a client (or server) is sending a large message over = SCTP, so it fragments the message and sends the fragments one after the = other; each fragment is assigned a Transmission Sequence Number (TSN). = If that client has a higher priority message=20 Actually, each fragment is assigned a fragment sequence number (FSN) to = reassemble the fragments in the correct order. A TSN is assigned to each chunk just to ensure all chunks sent are = received by the receiver (in whatever order). > to send during the transmission of the fragments, that message must go = to the end of the line. This document defines a "stream", and allows = interleaving streams, so that the higher priority message can be = transmitted immediately (on its own stream), and the receiver will = understand that this is not part of the lower priority message's TSN = chain (stream). The stream is not a TSN chain. A stream is a concept allowing user = messages to be ordered. Ordered user messages sent on the same stream are received in the order they are sent. This = messages sequence preservation is only guaranteed within each stream, but not across streams. >=20 > The security considerations section says >=20 > This document does not add any additional security considerations in > addition to the ones given in [RFC4960] and [RFC6458]. >=20 > It should be noted that the application has to consent that it is > willing to do the more complex reassembly support required for user > message interleaving. When doing so, an application has to provide > up to two reassembly buffers (one for ordered messages, one for > unordered messages) for each incoming stream. It has to protect > itself against these buffers taking too many resources. If user > message interleaving is not used, only a single reassembly buffer > needs to be provided for each association. But the application has > to protect itself for excessive resource usages there too. >=20 > The security considerations of 4960 are very thorough, but they never = mention anything about fragment reassembly issues. I don't know much = about SCTP, so maybe this is not a concern, but I wondered: could a = hostile endpoint attack the reassembly scheme (which must be = reimplemented for each application) by sending malicious fragments? To send malicious fragments, the attacker must bypass the SCTP stack, = which is possible. That way a receiver has to deal with the case that it received arbitrary = TSN/SID/FSN/MID/PPID combinations. This is already true for RFC 4960 stacks, just with = arbitrary TSN/SID/PPID combinations. Using the I-DATA chunk makes it easier to detect illegal combinations, = since some dependencies are removed. So therefore I don't see a big change for SCTP implementations here. = There is a change for applications using and SCTP stack and that difference is described = above. Best regards Michael >=20 > --Scott >=20 >=20 --Apple-Mail=_8108BCB0-8311-4314-8518-A391AC480DB7 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQkDCCBNUw ggO9oAMCAQICCFBOxvU9EbRkMA0GCSqGSIb3DQEBCwUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMw IQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0xNDA3MjIxMjA4MjZaFw0xOTA3 MDkyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdE Rk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAx BAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84Ik Q4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVg Te3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sW VlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjggGG MIIBgjAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1Ud IwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMBIGA1UdEwEB/wQIMAYBAf8CAQIwYgYDVR0gBFsw WTARBg8rBgEEAYGtIYIsAQEEAgIwEQYPKwYBBAGBrSGCLAEBBAMAMBEGDysGAQQBga0hgiwBAQQD ATAPBg0rBgEEAYGtIYIsAQEEMA0GCysGAQQBga0hgiweMD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6 Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvRFRfUk9PVF9DQV8yLmNybDB4BggrBgEFBQcBAQRsMGow LAYIKwYBBQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMDoGCCsGAQUFBzAC hi5odHRwOi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9EVF9ST09UX0NBXzIuY2VyMA0GCSqGSIb3 DQEBCwUAA4IBAQBjICj9nCGGcr45Rlk5MiW8qQGbDczKfUGchm0KbiyzE1l1sTOSG2EnFv/DstU1 gvuEKgFJvWa7Zi+ywgZdbj9u4wFaW8pDY1yVtuExpx/VB19N5mWCTjL5w3x6S81NXHTuIfJ1AuxS PtLJatOQI25JZzW+f01WpOzML8+3oZeocj7JvEDWWqQIPda8gsO3tzKOsSyOam23NQIZz/U5RFhj pyQAELC7/E6vbi84u6VXST/YblBvLJeW3B1GmmWJz67M8uXZn1OzPqEvkqnYC8aEHwTG6x7on321 e6UC8STFJGMRNMxakyAqeYg6JUKQqWU7fIbTEhUjKfws2sw5W1QXMIIFojCCBIqgAwIBAgIHF6Qk oQlIMzANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTE0MDUyNzE0NTQwOVoXDTE5MDcwOTIzNTkwMFowgcYxCzAJBgNVBAYTAkRFMRwwGgYDVQQIExNO b3JkcmhlaW4tV2VzdGZhbGVuMREwDwYDVQQHEwhNdWVuc3RlcjEgMB4GA1UEChMXRmFjaGhvY2hz Y2h1bGUgTXVlbnN0ZXIxIzAhBgNVBAsTGkRhdGVudmVyYXJiZWl0dW5nc3plbnRyYWxlMR0wGwYD VQQDExRGSCBNdWVuc3RlciBDQSAtIEcwMTEgMB4GCSqGSIb3DQEJARYRY2FAZmgtbXVlbnN0ZXIu ZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4eWyu8GzsIv0iowf2v/9BT0SmCFNX /eyQe5BncOk1j6XIlY5bnNu1S5uBe3uVgekgTh3gJyVNlaoIfCgAjqCrNJIaNQq5fr/S6L8uFeaU O8IF/C4RH5P7f9Hn2GUueEjmJhg9CI3LBAhrfAmEEtNmuVfDycN2MjngwDNxUNRfuXbWxuhkgDqJ 0ztJeayHGhFDrGx88eyStx40xy+0c0OFWdWxzBFQlBRHnl+zRftj3c9qy6BY+/fGaA2vV1oKr3h5 X6eyU1T8YlpP1NDe4bylqAteX01sM2Qciu8UAPnNc7Sb93TQjhCFRVDIS3CdN6AOpwz5YWEld6ey CdmFZ7pvAgMBAAGjggH+MIIB+jASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjAR BgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFArzW7zkMYDWNUKJptPDzzfe0d/XMB8GA1UdIwQY MBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBwGA1UdEQQVMBOBEWNhQGZoLW11ZW5zdGVyLmRlMIGI BgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1jYS9wdWIvY3JsL2NhY3JsLmNybDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0 dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDov L2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYI KwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQDeRwM11kpvuRIPuzWXLapr/ZBtB76V3cuF l45x/Kx0u03yjB4GaBPcxihn4P1z5KhRYkDBMo8HXkOgbL59aF6VdOlCurEgZvghKvUkKOCyWeYx S9rTGPBkbGiNn2ATVuLXzF8rDf50ynAIu3otstOOv+3Ifqi1pzCva1nO64khQA5Gd5/BNyu+YHbW f8ERAf9leu5a7yVI7cv1gCZAHpWJpkUKmfawyY4sAJ2hbGZRBvdACOxrfbuMdSOzPneT2rlmvH+D 7M6DmzVabLYk6UtAxQhldd/T/qsHkWvaWXHt0Eb9STs2Fl03Ls7M3NyLQLhaeR3ysNURYcaEfaB+ lxN+MIIGDTCCBPWgAwIBAgIHG5mIdDexozANBgkqhkiG9w0BAQsFADCBxjELMAkGA1UEBhMCREUx HDAaBgNVBAgTE05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQK ExdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVu dHJhbGUxHTAbBgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBm aC1tdWVuc3Rlci5kZTAeFw0xNjA3MDQwNzA2MTNaFw0xOTA3MDQwNzA2MTNaMHwxCzAJBgNVBAYT AkRFMSAwHgYDVQQKDBdGYWNoaG9jaHNjaHVsZSBNdWVuc3RlcjEyMDAGA1UECwwpRmFjaGJlcmVp Y2ggRWxla3Ryb3RlY2huaWsgdW5kIEluZm9ybWF0aWsxFzAVBgNVBAMMDk1pY2hhZWwgVHVleGVu MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzJoaUG3Zm24XxA/zNg2sbFcL56w8xqMg +X6G7UsYec3YEncnlkw3jgE5nDefos7UVoCA7wPjFTj8AQt5xfpXElnbM45IPy5Ng7g6dS7biGSM VRACPXe1PrjgApRAwwGmCPvALnZXkmKP6Zlf+3VLfz9YWIIaeKu3jFM2Lk6Y3gr5U1l8bjHSawOo WMlfvSsXXLT38zKW7Uz9jS278j0OqHANBPgsE6/LJoCWFInwlvybxhO3nGU7OteUGaPikqzvjLsL YgpHDi0WjMZfVx/UtUSzZ4EJvmJTBeuVwyKnCbrawnfwYPTQQ6VE1OkAzmsMByBbEwJ996RtG//T XCG06QIDAQABo4ICRzCCAkMwQAYDVR0gBDkwNzARBg8rBgEEAYGtIYIsAQEEAwUwEQYPKwYBBAGB rSGCLAIBBAMBMA8GDSsGAQQBga0hgiwBAQQwCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTQHa9qhKgSZgCCAPThZkXaEaJ/ dTAfBgNVHSMEGDAWgBQK81u85DGA1jVCiabTw8833tHf1zAgBgNVHREEGTAXgRV0dWV4ZW5AZmgt bXVlbnN0ZXIuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2Zo LW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZu LmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAz BggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsG AQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2ZoLW11ZW5zdGVyLWNhL3B1Yi9jYWNlcnQv Y2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9maC1tdWVuc3Rl ci1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBAEj2/6x4kzoCVIiu aaminPrOHxACyoYsmSRjYPQpgW5xRj/FlolO1nG+ZZ11sqTb3TdCGD69ko5/zs8eGKnv/i0VLCHF g1JLfpaxElN5RrR/cqRJrbzKshF9aUkBODF8vlf9BCeimMK3fifjbbWRyxHssfEECffujD7/Yvta NYMO46Roz39lIK2s37IVFq3V5RWzUeTuwpP9t8lOxirOi9eK2OYI/dh0HjR2S5Dr9nMR1dNulrhz jlFxGc+opefGScrRR9Ec0eqTXlbt1Q9UzNIYVS+OGZY8/bBbprwXVTmwSp8dygEULkIaMbLsaTaW 6TehuL8ousPJkL52SOENgSkxggQpMIIEJQIBATCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozAJBgUrDgMCGgUAoIICKzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNzA4MjUxMDQ0MDNaMCMGCSqGSIb3DQEJBDEWBBQfQh0Z6fchWNOxdcCS ThovHN4WgzCB4wYJKwYBBAGCNxAEMYHVMIHSMIHGMQswCQYDVQQGEwJERTEcMBoGA1UECBMTTm9y ZHJoZWluLVdlc3RmYWxlbjERMA8GA1UEBxMITXVlbnN0ZXIxIDAeBgNVBAoTF0ZhY2hob2Noc2No dWxlIE11ZW5zdGVyMSMwIQYDVQQLExpEYXRlbnZlcmFyYmVpdHVuZ3N6ZW50cmFsZTEdMBsGA1UE AxMURkggTXVlbnN0ZXIgQ0EgLSBHMDExIDAeBgkqhkiG9w0BCQEWEWNhQGZoLW11ZW5zdGVyLmRl AgcbmYh0N7GjMIHlBgsqhkiG9w0BCRACCzGB1aCB0jCBxjELMAkGA1UEBhMCREUxHDAaBgNVBAgT E05vcmRyaGVpbi1XZXN0ZmFsZW4xETAPBgNVBAcTCE11ZW5zdGVyMSAwHgYDVQQKExdGYWNoaG9j aHNjaHVsZSBNdWVuc3RlcjEjMCEGA1UECxMaRGF0ZW52ZXJhcmJlaXR1bmdzemVudHJhbGUxHTAb BgNVBAMTFEZIIE11ZW5zdGVyIENBIC0gRzAxMSAwHgYJKoZIhvcNAQkBFhFjYUBmaC1tdWVuc3Rl ci5kZQIHG5mIdDexozANBgkqhkiG9w0BAQEFAASCAQBC+8z1lSKWB4f2VF/iDPVDYXvPAxQULkzc aSMKZ1/AO3dgVEelV+wSbxOuMjwN5YM3ADECX0dwAHr86x/SRXgE9zCJY/PmdZRDa4djbfLDNBEE lmWot3wwjymcsnnVijxzadD9/BSbULioufMWsxsiUlSIL5wLEULMAVmD48syDdV4Y6zddG6ETPrU vomkyQUuB2AxIvcybWE1qcL+fwBEUeEWmNxnTp+bcx1rGtoTA3DguNkJOiosnvVwB83TbD+E4KNG EAc6QCa/W6d3I07wuSgVnFHZr12Gb/0tX2Jgig3CwDnmWwkV9TVJ+01ugvRPXvN+FslA9jFK1MTx IO8sAAAAAAAA --Apple-Mail=_8108BCB0-8311-4314-8518-A391AC480DB7-- From nobody Sat Aug 26 08:06:40 2017 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 AF370132951 for ; Sat, 26 Aug 2017 08:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] 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 j20ib-yZOOSJ for ; Sat, 26 Aug 2017 08:06:38 -0700 (PDT) Received: from smtp98.iad3a.emailsrvr.com (smtp98.iad3a.emailsrvr.com [173.203.187.98]) (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 E4658132949 for ; Sat, 26 Aug 2017 08:06:37 -0700 (PDT) Received: from smtp37.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp37.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 9BA5C5E32; Sat, 26 Aug 2017 11:06:32 -0400 (EDT) Received: from app54.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp37.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 837F85D96; Sat, 26 Aug 2017 11:06:32 -0400 (EDT) X-Sender-Id: scott@hyperthought.com Received: from app54.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Sat, 26 Aug 2017 11:06:32 -0400 Received: from hyperthought.com (localhost.localdomain [127.0.0.1]) by app54.wa-webapps.iad3a (Postfix) with ESMTP id 73EE1A0045; Sat, 26 Aug 2017 11:06:32 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Sat, 26 Aug 2017 08:06:32 -0700 (PDT) X-Auth-ID: scott@hyperthought.com Date: Sat, 26 Aug 2017 08:06:32 -0700 (PDT) From: "Scott G. Kelly" To: "Michael Tuexen" Cc: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-tsvwg-sctp-ndata.all@ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain In-Reply-To: References: <1503596357.467129961@apps.rackspace.com> Message-ID: <1503759992.472429533@apps.rackspace.com> X-Mailer: webmail/12.9.5-RC Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-sctp-ndata-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2017 15:06:39 -0000 Hi Michael,=0A=0AThanks for the clarifications. I re-read the fragment hand= ling text in 4960, and looked again through the draft, and I have a better = understanding now. I also looked again at known attacks on fragmentation. I= don't know of any specific attacks via malicious SCTP fragment constructio= n, and I don't want to suggest chasing after ghosts. =0A=0AIt wouldn't hurt= to have someone with security expertise who also understands SCTP to think= more about this, but I think it's the working group's call. I have no othe= r concerns with the draft.=0A=0AThanks,=0A=0AScott=0A=0A=0AOn Friday, Augus= t 25, 2017 3:44am, "Michael Tuexen" said:=0A=0A>> O= n 24. Aug 2017, at 19:39, Scott G. Kelly wrote:=0A= > Hi Scott,=0A> =0A> thank you very much for the review. See my comments in= -line.=0A> =0A> Best regards=0A> Michael=0A>>=0A>> I have reviewed this doc= ument as part of the security directorate's ongoing=0A>> effort to review a= ll IETF documents being processed by the IESG. These comments=0A>> were wr= itten primarily for the benefit of the security area directors. Document= =0A>> editors and WG chairs should treat these comments just like any other= last call=0A>> comments.=0A>>=0A>> The summary of the review is ready with= (maybe) issues. I'm not sure if there is=0A>> an issue or not. Maybe this = can be quickly resolved.=0A>>=0A>> Paraphrasing from the abstract, the docu= ment adds a new chunk to SCTP for=0A>> carrying payload data, allowing a se= nder to interleave different user messages=0A>> that would otherwise result= in head of line blocking at the sender.=0A>>=0A>> An example usage: a clie= nt (or server) is sending a large message over SCTP, so=0A>> it fragments t= he message and sends the fragments one after the other; each=0A>> fragment = is assigned a Transmission Sequence Number (TSN). If that client has a=0A>>= higher priority message=0A> Actually, each fragment is assigned a fragment= sequence number (FSN) to reassemble=0A> the fragments in the correct order= .=0A> A TSN is assigned to each chunk just to ensure all chunks sent are re= ceived by the=0A> receiver (in whatever order).=0A>> to send during the tra= nsmission of the fragments, that message must go to the end=0A>> of the lin= e. This document defines a "stream", and allows interleaving streams,=0A>> = so that the higher priority message can be transmitted immediately (on its = own=0A>> stream), and the receiver will understand that this is not part of= the lower=0A>> priority message's TSN chain (stream).=0A> The stream is no= t a TSN chain. A stream is a concept allowing user messages to be=0A> order= ed. Ordered user messages=0A> sent on the same stream are received in the o= rder they are sent. This messages=0A> sequence preservation is only=0A> gua= ranteed within each stream, but not across streams.=0A>>=0A>> The security = considerations section says=0A>>=0A>> This document does not add any addi= tional security considerations in=0A>> addition to the ones given in [RFC= 4960] and [RFC6458].=0A>>=0A>> It should be noted that the application ha= s to consent that it is=0A>> willing to do the more complex reassembly su= pport required for user=0A>> message interleaving. When doing so, an app= lication has to provide=0A>> up to two reassembly buffers (one for ordere= d messages, one for=0A>> unordered messages) for each incoming stream. I= t has to protect=0A>> itself against these buffers taking too many resour= ces. If user=0A>> message interleaving is not used, only a single reasse= mbly buffer=0A>> needs to be provided for each association. But the appl= ication has=0A>> to protect itself for excessive resource usages there to= o.=0A>>=0A>> The security considerations of 4960 are very thorough, but the= y never mention=0A>> anything about fragment reassembly issues. I don't kno= w much about SCTP, so maybe=0A>> this is not a concern, but I wondered: cou= ld a hostile endpoint attack the=0A>> reassembly scheme (which must be reim= plemented for each application) by sending=0A>> malicious fragments?=0A> To= send malicious fragments, the attacker must bypass the SCTP stack, which i= s=0A> possible.=0A> That way a receiver has to deal with the case that it r= eceived arbitrary=0A> TSN/SID/FSN/MID/PPID=0A> combinations. This is alread= y true for RFC 4960 stacks, just with arbitrary=0A> TSN/SID/PPID combinatio= ns.=0A> Using the I-DATA chunk makes it easier to detect illegal combinatio= ns, since some=0A> dependencies are=0A> removed.=0A> =0A> So therefore I do= n't see a big change for SCTP implementations here. There is a=0A> change f= or=0A> applications using and SCTP stack and that difference is described a= bove.=0A> =0A> Best regards=0A> Michael=0A>>=0A>> --Scott=0A>>=0A>>=0A> =0A= > =0A From nobody Sat Aug 26 08:34:56 2017 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 E952613234B; Sat, 26 Aug 2017 08:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 WU83E-tSM5k0; Sat, 26 Aug 2017 08:34:53 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE74C132328; Sat, 26 Aug 2017 08:34:49 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id z132so10828225wmg.1; Sat, 26 Aug 2017 08:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=+1ycyli6gJov2aWsTXJ/uYpEg5xLm1LJk9PHltLjdqE=; b=MbZ70t8FomQOYBo45BZoAAMb3wHlQsGlutlUfwNhbHewrSOrX3gq5Ck5Eh4VtbkP88 ArJcobV2szxGaGhfBR5IUzWBIUew1qp3Q3/y4sOjDy8xJ8aIW8Hf49FOMgraFzyMBRas vXHF5cX/Jn7C2IdfRPScbU2xaeoZjywo0hV0uD5iMoR8y4jDU3pNKlDgZWafBdOTs3SW 5Bnu+rbFXNSWExOOGPW07X1T3mCln90Fk0cHsQJnu+YADFEU+gIv7leXoczHkBndQkw4 M4X9q5l8WIdYSHCNeyNIpX0Ji9I3xwnWA/gW4lPb+JOYiakNG7n0elZ9uaKeq9vRZNbT JoWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+1ycyli6gJov2aWsTXJ/uYpEg5xLm1LJk9PHltLjdqE=; b=giCKZYFe6E/2DBgXqtzTB9Wrl1za3rU7AlEU9C7Ad+TQvhvTEw7TViqUCchBbpNNOG 6gAE3ys0LeMEfTgTTQ2weoGN3NObip7qdBwPit4ENBg9oksNLVR/krNH9Xc+DnCIHsM/ BLq6P8EXksifemPzzCkt0g5vIetyr3p9P96Mk2Aedd0TuWk+Y4mJy4XlCpeSqpxaL9e/ 9BOff9E9Mn3fp6Z/hF4GINkVzKBlwZLjiEWyr3UXAD/ItmLLyjT1RyIyCI4uWLxyjxC/ q6na4dqwjFRML8v4MasDgs5lfcOBMr+fXw9lrZlF/WQR5IPYSpSakx09qjxhuot7PIxR kAfg== X-Gm-Message-State: AHYfb5jz6ohzPBBg97YZjGge7pc5VznETHOVOHQAVPfj31oCX7mtWuD4 CXZhPFN29VQkPS41tbA= X-Received: by 10.28.67.1 with SMTP id q1mr970670wma.162.1503761687829; Sat, 26 Aug 2017 08:34:47 -0700 (PDT) Received: from [10.0.0.10] (bzq-109-67-55-26.red.bezeqint.net. [109.67.55.26]) by smtp.gmail.com with ESMTPSA id h190sm2955727wmd.4.2017.08.26.08.34.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 26 Aug 2017 08:34:46 -0700 (PDT) To: "Brian Weis (bew)" Cc: "secdir@ietf.org" , "draft-weis-gdoi-rekey-ack.all@ietf.org" , "ietf@ietf.org" References: <150194814585.18635.3104789196001873381@ietfa.amsl.com> From: Yaron Sheffer Message-ID: Date: Sat, 26 Aug 2017 18:34:44 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [secdir] Secdir last call review of draft-weis-gdoi-rekey-ack-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2017 15:34:56 -0000 Hi Brian, Thank you for addressing most of my comments in the new version, and for clarifying points where I was off the mark. The only remaining comment that's only partly addressed is the one on crypto agility. Quoting myself: we need to define whether multiple such payloads can be sent simultaneously (if e.g. some GMs still support the old algorithm) and what's the expected behavior. In other words, supporting more algorithms in not sufficient. The question is whether we support incremental deployment of a new algorithm to a large group of GMs. Thanks, Yaron On 24/08/17 19:48, Brian Weis (bew) wrote: > Hi Yaron, > > Thanks for the review. We’ve added some clarification below, and made > some changes in -06 to address your comments. Please let us know if we > did not address them satisfactorily. > >> On Aug 5, 2017, at 8:49 AM, Yaron Sheffer > > wrote: >> >> Reviewer: Yaron Sheffer >> Review result: Has Issues >> >> Summary: this reviewer is not clear about the value of the push-ack >> (compared >> to a pull) and about the strategy that was chosen. > > In a group key management system either a “pull” (triggered by a group > member) or a “push” (by the key server)" could be used to provide > updates to the group. However, a “pull” by the group member implies a > polling method, which has the deficiency that the key server cannot > cause a policy replacement any sooner than the polling method by the > group members. Also “polling” can cause additional unnecessary traffic. > So is is better for any update on the group policy or renewal of group > keys to be distributed by the GCKS using a PUSH message. The ACK-message > is used to offer a feedback mechanism to a policy update for the PUSH > exchange. >> >> *//* >> >> * "For example, a GCKS policy can use the acknowledgements to >> determine [...] >> which members may no longer be members of the group." This sentence is >> very >> confusing: when are members not members? > > We’ve reworded this text. It’s trying to convey that a missing ACK > message (or a certain number of it) can be used to identify that a group > member is no longer receiving group traffic, and is now may be > considered an ex-group member. For example, it could be a multicast > receiver that is no longer interested in being a receiver for the group. > But it could also be that a network event has caused it to be > unavailable for a sufficient length of time such that it doesn’t have > current keying material and therefore can’t be considered a current > group member. There is no reliable “I’m leaving the group” message flow, > and of course in my second example no such messages would have been > intended by the group member. > >> * The new protocol capability is defined as optional, but really >> isn't. "A GM >> receiving the KEK_ACK_REQUESTED attribute can choose to ignore it, thus >> appearing as if it does not support the KEK_ACK_REQUESTED attribute. >> However, >> GCKS policy may consider a non-responsive GM to no longer desire to be >> a member >> of the group." So if you want to play the game, you MUST support the new >> attribute. > > Point taken. We’ve changed the text to reflect this. > >> * I'm puzzled at the overall protocol. Being able to send ACKs is a GM >> software >> capability. Why not have the GM announce this capability when it initially >> registers to the GCKS? Then the GCKS would know what to expect, >> whereas with >> the current protocol it is left waiting for an ACK that may never >> come, either >> because the GM is dead or because it just doesn't feel like >> responding. Add the >> long waits (jitter of "a few seconds" and potential retries), and this >> looks >> like a far from optimal management experience. > > Indeed a GM could announce its capability, but whether or not ACKs are > desired is a component of the group policy. In the context of GDOI the > GCKS is the entity that defines the group policy. There can be groups > where the ACK is used, whereas others do not. The capabilities > announcement you suggest could certainly help the KS to know whether or > not to expect the ACK from a particular GM, but the focus of this I-D is > on the the declaration of the request for ACKs by the GCKS and the > format of the ACK. > >> * 2.2: "This is a private key" - to avoid confusion, I suggest: "This is a >> secret symmetric key" (if this is indeed the case). Obviously using >> the same >> key for encryption and for HMAC is not a best practice. > > We’ve made this change. > >> * Sec. 5: ACK messages can also be duplicated in the network. I >> suggest to add >> a sentence describing what the GCKS should do in this case. > > The Security Considerations (section 7.3) describes a method for the > GCKS to detect replays. This is arguably better placed in this section, > so we’ve moved it here.. > >> * Sec. 6: I am confused about the notion of "jitter" here. If the PUSH >> messages >> are sent as multicast (the recommended alternative AFAICT), I'm not >> sure about >> the benefit of using multicast, given that each recipient responds with a >> unicast ACK. And if the PUSH is unicast, there should be no reason for >> a jitter >> as the sender can throttle the PUSH messages as necessary. > > The concept of “jitter” is most valuable for responses to a multicast > PUSH message. The use of a multicast PUSH message lower processing on > the GCKS. Since each GM can e given the exact same policy, there’s no > call to send it out as a unicast message. The jitter helps spread out > the replies a bit to avoid inundating the GCKS. > >> * Moreover, everything would be much more predictable if the GCKS could >> indicate if a jitter is expected and how much of a jitter (based on >> size of the >> group, network throughput, and queue length). Specifically, this would >> allow >> the GCKS to tell how long it should wait for an ACK. > > This would be somewhat useful, but in practice might not help the GCKS > as much as it seems. The jitter value provided would also be dependent > on several network parameters that aren’t under the control of the GCKS > or the GM. Even when the GM does not add any jitter to the ACK, the > underlying network may delay the PUSH and/or for the ACK. And as stated > in Section 6, the GCKS may be configured with additional policy actions > like retransmissions to overcome lost ACKs. Altogether to add jitter to > the ACK is not a must, it is a way to help the GCKS deal with a huge > number of GMs. In practice, we’ve found that having the GMs choose the > jitter has worked well, even when the GMs are different implementations. > >> * Cryptographic agility: this document specifies only one algorithm >> for the >> HASH value, and says that if a new algorithm is needed, there will be >> a new >> KEK_ACK_REQUESTED payload defined. However to make sure that this really >> "works", we need to define whether multiple such payloads can be sent >> simultaneously (if e.g. some GMs still support the old algorithm) and >> what's >> the expected behavior. I would suggest to define an additional SHA-512 >> payload >> just to make for a concrete example. > > This is a good suggestion. We’ve added SHA-512 versions of the existing > KEK_ACK_REQUESTED values. > > See > > Thanks, > Brian > > -- > Brian Weis > Security, CSG, Cisco Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com > From nobody Sat Aug 26 11:49:07 2017 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 9AA0B132981 for ; Sat, 26 Aug 2017 11:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 zgaZGsHzeqta for ; Sat, 26 Aug 2017 11:49:04 -0700 (PDT) Received: from nm24-vm6.access.bullet.mail.gq1.yahoo.com (nm24-vm6.access.bullet.mail.gq1.yahoo.com [216.39.63.172]) (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 5E17E132977 for ; Sat, 26 Aug 2017 11:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1503773342; bh=cyQT23u/xOJ3LS43PbkPXzD2lGWlj05JLh3Oys+f+NA=; h=To:From:Subject:Date:From:Subject; b=X+NZZqq1xFle8lwvh7HlsK+pEcPyhKhPKSkapoqxKmXXyZKOW9u7TQp9OXEO9xa3dunSaMTUrb3SqztynLdC6nkIvAVEB+42lEV0nvaQJDWZORRWbVf3fFjqexHPJ6/c0soUP9Pf3lt9YcrmpIhAMosEwMc5Ze0PDknx4Brlz0Q16hD47w72y4WOh8R25/xYFSvqwoxrfMauL7IlsbIBXtuela0Mot0W2xR4wjsCHLuEa7ctJhRUVa1stPcOzbdEwLN32x4UveqD+LJ+A24cklypm+bJWTtVP8cY8CM2wfaABnyay6j+yX4t5OxD8uQstkqlTO0EctPby93i9kipdw== Received: from [216.39.60.167] by nm24.access.bullet.mail.gq1.yahoo.com with NNFMP; 26 Aug 2017 18:49:02 -0000 Received: from [98.138.226.244] by tm3.access.bullet.mail.gq1.yahoo.com with NNFMP; 26 Aug 2017 18:49:02 -0000 Received: from [127.0.0.1] by smtp115.sbc.mail.ne1.yahoo.com with NNFMP; 26 Aug 2017 18:49:02 -0000 X-Yahoo-Newman-Id: 321512.62011.bm@smtp115.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: vXBA5nUVM1laMUWilzSRvJmFj0HzJHaTmUUFAvcqx7RtR15 EqfuWu39s7NwANcOj4VCUs9MLKHshRxyRTS1eu2u8D_aAJZbZ6p5BSA6nf7N DqJtTeSaJha0Lv5ZzADr.ohMB9ePlZZoRySR68pisHMQAwkVl0xi4zZnLSVq VAQLuiHUCLUQnzRGwzXE.kzJ8r7wDIVFdW3264qkrwdCkGk_dVhY4Btsk.w9 9ieMAcal_bSeMz_AIJ0ftDUuEoPHvGjhj5aUBkZyTICLXc.vv7IFSwNVyq4P HCiOw7F6vhQUfyJ6fkSmYkAfLgNEBf1pxLCC1txRg_xB2UyAH2PEAd9b2ToF 3ttANePW2mhzA3juzAdplgnfL886ZC2oTTxtzHrDEh0ryTLMki_z3ahvwEP7 j67Zjgx9BPzHvwloRIhxstWPyaN9Yz0CZyi9BnxFP9D0etx3_DtmIfF7k3kt HSCJ_INYbWlpBa3m6Vs1FanrnvZwy7RwHNPRcW3e1KTfM0hcZBvaQ5ppZwjc Wsbtpe0O3ywgG X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from [192.168.1.127] (DD-WRT [192.168.1.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 3B44E1C60A1; Sat, 26 Aug 2017 14:49:01 -0400 (EDT) To: iesg@ietf.org, secdir@ietf.org, draft-ietf-ospf-encapsulation-cap.all@ietf.org From: David Mandelberg Message-ID: <475c78dc-c872-8795-2d99-81b28df97aed@mandelberg.org> Date: Sat, 26 Aug 2017 14:49:00 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 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-ospf-encapsulation-cap-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2017 18:49:06 -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 nits. This document extends OSPF for use with tunnels. As mentioned in the security considerations, an attacker who can modify routing information can cause packets to be misdirected or dropped. However, that seems to be the general nature of routing attacks. I don't know if this document makes such attacks any more likely or more severe, but it would be nice to see a bit more discussion of that in the security considerations. E.g., are OSPF attacks without tunneling less severe because of some limitation on where packets can be forwarded, while tunneling makes it easier to forward packets to anywhere on the Internet? Or is that not the case? (I'm not very familiar with OSPF or with the environments it's typically used in.) From nobody Sun Aug 27 02:30:44 2017 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 38FA11323B4; Sun, 27 Aug 2017 02:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZUu_umtrzX8; Sun, 27 Aug 2017 02:30:34 -0700 (PDT) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 6E83413202D; Sun, 27 Aug 2017 02:30:34 -0700 (PDT) Received: by mail-wm0-x243.google.com with SMTP id i76so4061085wme.1; Sun, 27 Aug 2017 02:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=6zoyhywnGDLDbzVZPJtAAFRd8G9A/YzJHocmYuhVN3o=; b=I6XwZVSn+Q1rUxU+UcLC1IXhv3gfofjABdmQouRwCKbIMvUQzJzqXHR2lKyLaYAtVY Erhe13bIAbr9WTgrN76rP0CFTuJch+Sh2JD5B8rA/skD1HO4HsNd3lQHfq8m0O/zsbAm EiMJm3Db1VV7ZnNE6Qdiw9FhLpX7swzKDmF9+x1Ovy5fbrqDfQQeHK9EnuFnCOf/X94u PQJP/axN+nKqG+tv7Fv/KeD7SCtisEmKPpKCtZabNtdDrWBjs/r0kDhOVqZBou8/a+PL kyzYd37YGhNZQbHCnw3EYPZnLw9GQhkB0HWlcS2eEEsFAHKL/9t9iey8svRphsEsm0R2 zdAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=6zoyhywnGDLDbzVZPJtAAFRd8G9A/YzJHocmYuhVN3o=; b=tK6Y4emyDyvX7gw48WdFg0Z9VbuYoz6F0+se/9V9un5seQ+O4tz1uZGPVcg6ze4ir2 h88YAUIHSX1i6ifDI61djs+uhW6R4Kyz3eXGgmIG9yEh69tEyuTM9lcFjUTe94Q8Wn6w P/Mp3Cxfgc2W9p1bG7/jSZ0EDdFYw+ca3FrxmoJEOf+Nb/T1GPL0leIlQCb/p2yLoNXd J49PcT66CSD1LnCeMhvU6G4rxpC3MC0XHVOTtQyLUg7f51hiDeOUU5Deq7ENmxpn+/Rn Bjx+9mHMCO9rU4pbKfQYnYn793g0ePXgwJnD02/0DBc7ChUL/2uWI3NcJnrIPtXji7TK RLhQ== X-Gm-Message-State: AHYfb5jMWg6axvDgo2jD2D5d5oGZhJX9weHyT8UkuMETDHquR6RZQNUe 7OMSwsxdlpIfcS7l5dI= X-Received: by 10.28.57.135 with SMTP id g129mr1863349wma.186.1503826232569; Sun, 27 Aug 2017 02:30:32 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id q45sm23086285wrb.3.2017.08.27.02.30.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 27 Aug 2017 02:30:32 -0700 (PDT) To: Tero Kivinen , iesg@ietf.org, secdir@ietf.org, draft-ietf-pals-p2mp-pw.all@tools.ietf.org, "mpls-chairs@ietf.org" References: <201708270627.v7R6RLjk004141@fireball.acr.fi> From: Stewart Bryant Message-ID: Date: Sun, 27 Aug 2017 10:30:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <201708270627.v7R6RLjk004141@fireball.acr.fi> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-pals-p2mp-pw-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Aug 2017 09:30:36 -0000 Tero Thank you for your comment. I believe that it if wrong to hold this document hostage to a security issue that applies to a major MPLS protocol widely used throughout the Internet. The right way to address the problem is via an update to the security of LDP (in the MPLS WG) and have that specification update the RFCs that use LDP. If an attacker were able to use the vulnerability in MD5 as a vector to attack LDP, I doubt that this relatively low key aspect of pseudowires would be their first priority. Regards - Stewart On 27/08/2017 07:27, Tero Kivinen 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 describes the mechanims to signal point-to-multipoint > pseudowires using LDP. The security considerations section simply > points to the RFC4447bis (i.e., RFC8077) saying that security > mechanisms described there are adequate. > > On the other hand RFC8077, says that LDP MD5 authentication key option > as described in the section 2.9 of RFC5036 MUST be implemented. The > section 2.9 of RFC5036 describes TCP MD5 signature option for LDP. > This might have been adequate security for some protocol in 2007 (when > RFC5036 was published, altought MD5 was already then known to be > broken), but it IS NOT adequate security in 2017. > > I understand that this document is not really the one supposed to > update the security option for the LDP, but there is > draft-ijln-mpls-rfc5036bis which is moving LDP to internet standard > still trying to keep the same broken MD5 based security in it. I think > this document should include note saying, that security of the RFC5036 > is no longer adequate for any use because it uses broken security > protocol, but there is nothing better out there yet (or is there, I do > not know enough of the LDP to know that), and perhaps point to the > rfc5036bis also in hopes that it might some day fix the security of > the LDP. > > I think this document (or whole PW and LDP system) has issues that > needs to be fixed before it can be published. From nobody Sun Aug 27 06:29:39 2017 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 03E0A13219E; Sun, 27 Aug 2017 06:29:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Montville To: Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150384057895.866.9675653302394719026@ietfa.amsl.com> Date: Sun, 27 Aug 2017 06:29:39 -0700 Archived-At: Subject: [secdir] Secdir early review of draft-ietf-opsawg-mud-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Aug 2017 13:29:39 -0000 Reviewer: Adam Montville Review result: Has Issues Hi. I am the assigned SECDIR reviewer for this document's early review reuqest. What follows is what I would write if this were a last call review, more or less. The summary of the review is ready with (potential) issues and nits. The draft is interesting in that it seeks to define a mechanism for devices to self-identify in a trusted manner, so that the infrastructure in which the devices operate may appropriately manage security-related configurations pertaining to those devices. The examples provided are exclusively network flow realted, but extension points are provided for future capabilities. The mechanism is defined as a Manufacturer Usage Description, as expressed in a file containing a YANG-based JSON serialization. This file is obtained from a device-provided URL, which is trusted to varying degrees and communitacted to the infrastructure in one of several different ways (i.e. via DHCP, 802.1AR, 802.1AB). Thus, the device emits a URL via one of the identified methods, and the URL is used to obtain the MUD, which can then be interpreted and appropriate action taken. The security consideraitons appear well-thought and is worth a read. This seems like a solution intended to take time to reach full potential, given that there are devices deployed in the real world that know nothing about this, and that there are different trust mechanisms at play. The intent seems less about perfection and more about moving the needle, which seems to be the right approach. Finally, I found myself wondering if this type of appraoch - communicating intended use - could be extended to software installed on general purpose devices. For example, it would be interesting to consider how a given installed software package could communicate not only its intended use, but it's preferred configuration. Some questions to consider (these are potential issues): At the top of page 9, the draft describes controller behavior for mobile devices - configurations should be removed when the device is removed. Does this apply also to intermittent devices? When would a device be considered "removed" instead of simply powered down? Also, when reading that paragraph I began wondering about the load on Web servers serving MUD files - not that this draft should say anything about it, but that it's something manufacturers are going to have to consider and account for. Is a stronger statement needed on the first bullet of section 4? Should it read: Anything not explicitly permitted MUST be denied? Similarly for other requirements in MUD file processing. At about this point, I began wondering if additional security considerations may be required for the controller. Section 9.2 describes DHCP server behavior, and is written in a manner presuming the DHCP server knows what's happening with these building blocks. I am not a DHCP expert, so there may be something in DHCP instructing a server to ignore everything it doesn't understand, but if that is not the case, then what is expected to happen when DHCP is not expecting these options and is not going to ignore them? Nits follow: First paragraph of section 1.5: s/another example might to follow/another example might be to follow/ Recommend the following for definition of Thing: the device emitting a MUD URL. Suggest striking last two sentences of Manufacturer definition, as irrelevant. Is there a way to make the ASCII art in section 1.7 a little cleaner? One possibility is to move the right side of the bounding box to the left by two or three places. Also, the arrows to the line text isn't necessary (e.g. "----->get URL->" is cleaner as "---get URL--->"). Second bullet on page 11: s/other otherwise/otherwise/ Should there be a newline after "" at the start of section 6? On page 17: s/end(ed)/end(s\/ed)/ Basically, the sentence without "ended" should read, "Information about when support ends, and when to refresh." Vertial spacing could be improved for the first bit in section 9, so that the look/feel surrounding OPTION_MUD_URL_V4 matches that of OPTION_MUD_URL_v6 Section 11, first sentence: s/link layer protocols/link layer protocol/ From nobody Mon Aug 28 00:32:29 2017 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 2BF8913271E; Mon, 28 Aug 2017 00:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 kygT1ahWuv1Q; Mon, 28 Aug 2017 00:32:19 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 5D0A81326BB; Mon, 28 Aug 2017 00:32:19 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v7S7WDK4027159 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 28 Aug 2017 10:32:13 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v7S7WCN5013086; Mon, 28 Aug 2017 10:32:12 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22947.50940.679445.270481@fireball.acr.fi> Date: Mon, 28 Aug 2017 10:32:12 +0300 From: Tero Kivinen To: Stewart Bryant Cc: iesg@ietf.org, secdir@ietf.org, draft-ietf-pals-p2mp-pw.all@tools.ietf.org, "mpls-chairs\@ietf.org" In-Reply-To: References: <201708270627.v7R6RLjk004141@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 2 min Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-pals-p2mp-pw-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 07:32:22 -0000 Stewart Bryant writes: > Tero > > Thank you for your comment. > > I believe that it if wrong to hold this document hostage to a security > issue that applies to a major MPLS protocol widely used throughout the > Internet. I agree on that, but I think the text claiming "security is adequate" in the security considerations section is also wrong, so it should be fixed to include note explaining what you explained below: > The right way to address the problem is via an update to the security of > LDP (in the MPLS WG) and have that specification update the RFCs that > use LDP. > > If an attacker were able to use the vulnerability in MD5 as a vector to > attack LDP, I doubt that this relatively low key aspect of pseudowires > would be their first priority. I.e., current security is using MD5, which is not considered safe, but this document will be able to use the better security mechanisms when they are defined, and there are better targets to attack if attacker is able to break MD5 based security... > Regards > > - Stewart > > > On 27/08/2017 07:27, Tero Kivinen 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 describes the mechanims to signal point-to-multipoint > > pseudowires using LDP. The security considerations section simply > > points to the RFC4447bis (i.e., RFC8077) saying that security > > mechanisms described there are adequate. > > > > On the other hand RFC8077, says that LDP MD5 authentication key option > > as described in the section 2.9 of RFC5036 MUST be implemented. The > > section 2.9 of RFC5036 describes TCP MD5 signature option for LDP. > > This might have been adequate security for some protocol in 2007 (when > > RFC5036 was published, altought MD5 was already then known to be > > broken), but it IS NOT adequate security in 2017. > > > > I understand that this document is not really the one supposed to > > update the security option for the LDP, but there is > > draft-ijln-mpls-rfc5036bis which is moving LDP to internet standard > > still trying to keep the same broken MD5 based security in it. I think > > this document should include note saying, that security of the RFC5036 > > is no longer adequate for any use because it uses broken security > > protocol, but there is nothing better out there yet (or is there, I do > > not know enough of the LDP to know that), and perhaps point to the > > rfc5036bis also in hopes that it might some day fix the security of > > the LDP. > > > > I think this document (or whole PW and LDP system) has issues that > > needs to be fixed before it can be published. -- kivinen@iki.fi From nobody Tue Aug 29 08:52:39 2017 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 404F7132C3E; Tue, 29 Aug 2017 08:52:33 -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, HTML_MESSAGE=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 cj8-kudPXHeZ; Tue, 29 Aug 2017 08:52:31 -0700 (PDT) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [IPv6:2001:480:20:118:118::211]) (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 D9445132962; Tue, 29 Aug 2017 08:52:29 -0700 (PDT) Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id v7TFqRAP016679 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 29 Aug 2017 11:52:28 -0400 From: Catherine Meadows Content-Type: multipart/alternative; boundary="Apple-Mail=_499AD170-6653-4144-9917-DC886748D4A6" Date: Tue, 29 Aug 2017 11:52:27 -0400 Message-Id: <93C424C0-EEF5-4A1B-B322-0C3C60519DA7@nrl.navy.mil> To: secdir@ietf.org, iesg@ietf.org, draft-ietf-mile-iodef-guidance.all@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Archived-At: Subject: [secdir] Sector Review of draft-ietf-mile-iodef-guidance-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 15:52:33 -0000 --Apple-Mail=_499AD170-6653-4144-9917-DC886748D4A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. The summary of the review is Ready With Nits. This document contains advice on using the Incident Object Description = Exchange Format (IODEF) to describe incident reports. In contains = general guidelines. No security-related issues are addressed; in particular = guidance on setting restrictions is avoided. In the security = considerations section, the authors point out that this document introduces no new security = concerns other than those already addressed in RFC7870 (the IODEF RFC), = and reader is referred to RFC7970=20 for any security questions. I agree with this, and I don=E2=80=99t see any need for making = substantive changes. There are a couple of nits though: 1. The sentence at the bottom of page 6, beginning =E2=80=9CIODEF = implementations SHOULD not consider using their own IODEF extensions unless =E2=80=A6=E2=80=9D doesn=E2=80=99t parse. I = think you can get the meaning you intended by removing the words =E2=80=9C=E2=80=9Dis not a suitable option=E2=80=9D at the end. 2. The =E2=80=9CNevertheless=E2=80=9D at the beginning of the second = sentence of the Security Considerations section is confusing. The = second sentence doesn=E2=80=99t contradict the first; it merely elaborates on it. I=E2=80= =99d suggest removing the word =E2=80=9CNevertheless.=E2=80=9D Cathy Meadows Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil = --Apple-Mail=_499AD170-6653-4144-9917-DC886748D4A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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 Nits.

This document contains advice on using = the Incident Object Description Exchange Format (IODEF) to describe = incident reports.  In contains general
guidelines.  No security-related issues are addressed; = in particular guidance on setting restrictions is avoided. In the = security considerations section,
the authors point = out that this document  introduces no new security concerns other = than those already addressed in RFC7870 (the IODEF RFC), and reader is = referred to  RFC7970 
for any security = questions.

I = agree with this, and I don=E2=80=99t see any need for making substantive = changes.  There are a couple of nits though:
1.  The sentence at the bottom of = page 6, beginning =E2=80=9CIODEF implementations SHOULD not consider = using their own
IODEF extensions unless =E2=80=A6=E2=80= =9D doesn=E2=80=99t parse.  I think you can get the meaning you = intended by removing the
words =E2=80=9C=E2=80=9Dis = not a suitable option=E2=80=9D at the end.

2.  The =E2=80=9CNevertheless=E2=80=9D= at the beginning of the second sentence of the Security Considerations = section is confusing.  The second sentence
doesn=E2=80=99t contradict the first; it merely elaborates on = it.  I=E2=80=99d suggest removing the word = =E2=80=9CNevertheless.=E2=80=9D

Cathy Meadows


Catherine Meadows
Naval Research = Laboratory
Code 5543
4555 Overlook Ave., = S.W.
Washington DC, 20375
phone: = 202-767-3490
fax: 202-404-7942
email: catherine.meadows@nrl.navy.mil

= --Apple-Mail=_499AD170-6653-4144-9917-DC886748D4A6-- From nobody Tue Aug 29 11:31:54 2017 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 13F29132941; Tue, 29 Aug 2017 11:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0tHFZpSSE_u; Tue, 29 Aug 2017 11:31:51 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7A70132951; Tue, 29 Aug 2017 11:31:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7095; q=dns/txt; s=iport; t=1504031510; x=1505241110; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=VZG6339rYaHJSnvJ6LZ61yhcCRf6ogtZlbY8zvBrtw8=; b=fsuioizn9Lrtr85g2uOm5Px4o+mUtyCD8+vPZMGKccig0qCSGDkVNlYQ rk31AifWh8/+J47cVn8fnZI8fRiMtjMMykcKS10iEiko04jpoG1BKNgde DGrPToJeQY8Khzge5/KR+w7HNybEZ/Xkqz3sznAM+A1nnmopLUOP6T/UV E=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CeAgD5saVZ/xbLJq1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBiUqLEZB2IpY1ggQHggWDOwKEWBUBAgEBAQEBAQFrKIUYAQEBAQIBIwR?= =?us-ascii?q?EDgULCxgVFQICVwYBDAgBAYolCK5+gW06i18BAQEBAQEBAwEBAQEBAQEBEQ+DK?= =?us-ascii?q?oUzKwuCcoQwLQJVglSCYQEEiXcWiH2FIog8hDeCIY10ghKFZ4NZJIZ1lkI1IoE?= =?us-ascii?q?NMiEIHBVJhROCCj6MCgEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,445,1498521600"; d="asc'?scan'208";a="696830849" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Aug 2017 18:31:47 +0000 Received: from [10.61.82.247] (ams3-vpn-dhcp4856.cisco.com [10.61.82.247]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v7TIVlPu007306; Tue, 29 Aug 2017 18:31:47 GMT To: Adam Montville , secdir@ietf.org Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org References: <150384057895.866.9675653302394719026@ietfa.amsl.com> From: Eliot Lear Message-ID: Date: Tue, 29 Aug 2017 20:31:46 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150384057895.866.9675653302394719026@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jmgMsA6Cn433PtjGGFebCXJVwkOsEDnT7" Archived-At: Subject: Re: [secdir] Secdir early review of draft-ietf-opsawg-mud-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 18:31:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jmgMsA6Cn433PtjGGFebCXJVwkOsEDnT7 Content-Type: multipart/mixed; boundary="ek3fMXD6SSlRctE5dK75NveXHsREUe6Fs"; protected-headers="v1" From: Eliot Lear To: Adam Montville , secdir@ietf.org Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org Message-ID: Subject: Re: Secdir early review of draft-ietf-opsawg-mud-08 References: <150384057895.866.9675653302394719026@ietfa.amsl.com> In-Reply-To: <150384057895.866.9675653302394719026@ietfa.amsl.com> --ek3fMXD6SSlRctE5dK75NveXHsREUe6Fs Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Adam, Thanks very much for your review.=C2=A0 I'm pleased you like the general approach.=C2=A0 You hit the nail on the head: this is NOT intended to be = a panacea, but a means by which the device (and its manufacturer) can enlist the network's protection. Indeed as I mentioned the first time I presented to SAAG, I will say now again (with feeling): NOTHING in that draft nor anywhere ELSE should excuse a manufacturer/developer from best coding practices and updating software.=C2=A0 The best form of protection will ALWAYS ALWAYS be a well secured device to begin with. MUD is simply there to add an additional layer for when the hacker gets there first... Please now see below. On 8/27/17 3:29 PM, Adam Montville wrote: > > Finally, I found myself wondering if this type of appraoch - communicat= ing > intended use - could be extended to software installed on general purpo= se > devices. For example, it would be interesting to consider how a given i= nstalled > software package could communicate not only its intended use, but it's > preferred configuration. I'd very much like to pursue this concept, but it seems to me it has to be rooted in some sort of hardware trust. > > Some questions to consider (these are potential issues): > > At the top of page 9, the draft describes controller behavior for mobil= e > devices - configurations should be removed when the device is removed. = Does > this apply also to intermittent devices?=20 Well indeed so.=C2=A0 I think the discussion around mobility is confusing= =2E=C2=A0 I've cleaned that up. > When would a device be considered > "removed" instead of simply powered down? I think the best way to look at this is to view the configuration information as ephemeral, and since the device provides the information on connect, or otherwise periodically (eg LLDP), you can regenerate the state. > Also, when reading that paragraph I > began wondering about the load on Web servers serving MUD files - not t= hat this > draft should say anything about it, but that it's something manufacture= rs are > going to have to consider and account for. Right. > > Is a stronger statement needed on the first bullet of section 4? Should= it > read: Anything not explicitly permitted MUST be denied? Similarly for o= ther > requirements in MUD file processing. At about this point, I began wonde= ring if > additional security considerations may be required for the controller. One of the principles we try to observe is that the administrator owns the network.=C2=A0 As such we should be somewhat cautious about how we ph= rase such things.=C2=A0 From a MUD perspective, what you end up with is an access-list that an administrator might choose to augment.=C2=A0 For instance, if he or she is running a special load on a Thing using 802.1AR certificates, he might want to augment the access to accommodate a new feature. In fact, it may be possible that a manufacturer writes such a complex MUD file that the network administrator desires an optimization.=C2=A0 We= do not yet have enough experience to know what sort of normative statement would cover that ;-) > > Section 9.2 describes DHCP server behavior, and is written in a manner > presuming the DHCP server knows what's happening with these building bl= ocks. I > am not a DHCP expert, so there may be something in DHCP instructing a s= erver to > ignore everything it doesn't understand, but if that is not the case, t= hen what > is expected to happen when DHCP is not expecting these options and is n= ot going > to ignore them? This is not a worry.=C2=A0 DHCP servers are very capable of ignoring unkn= own options, and they have to be well bullet proofed today or we have FAR FAR bigger fish to fry ;-) > > Nits follow: > > First paragraph of section 1.5: s/another example might to follow/anoth= er > example might be to follow/ Right! > > Recommend the following for definition of Thing: the device emitting a = MUD URL. Ok. > > Suggest striking last two sentences of Manufacturer definition, as irre= levant. Ahhh but this actually is a big deal to system integrators ;-)=C2=A0 They= want to know what their role in the ecosystem is. > > Is there a way to make the ASCII art in section 1.7 a little cleaner? O= ne > possibility is to move the right side of the bounding box to the left b= y two or > three places. Sure.=C2=A0 Done. > Also, the arrows to the line text isn't necessary (e.g. > "----->get URL->" is cleaner as "---get URL--->"). Done. > > Second bullet on page 11: s/other otherwise/otherwise/ right. > Should there be a newline after "" at the start of section= 6? I'm going to leave that one to the YANG doctors... > > On page 17: s/end(ed)/end(s\/ed)/ Basically, the sentence without "end= ed" > should read, "Information about when support ends, and when to refresh.= " This will change with the updating of the model, based on YANG doctor feedback.=C2=A0 That very container is likely to be consolidated away. > > Vertial spacing could be improved for the first bit in section 9, so th= at the > look/feel surrounding OPTION_MUD_URL_V4 matches that of OPTION_MUD_URL_= v6 Ok.=C2=A0 I think I addressed what you're talking about. > > Section 11, first sentence: s/link layer protocols/link layer protocol/= > > Good catch. Best regards and thanks again for your review. Eliot --ek3fMXD6SSlRctE5dK75NveXHsREUe6Fs-- --jmgMsA6Cn433PtjGGFebCXJVwkOsEDnT7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJZpbMSAAoJEIe2a0bZ0nozLGEH/j1kGQfBV3gOCuIk+flybdTr GwCxvRmezsLCe4BnMCnA6NJWC0iC+HshNjFqoYG1IAuS5L1K8Kk30CDFAD6yULlo /kPFgl0M0ftYEuFc3CRniB9G0SBK1ivs6X9gWJwqK+0KqgvLhn0ddPWM7I0F5rL2 ni4fe1pr1bUdErQ8lcXwk0fHcru9y+4C/4FtaJNyhzUaiyNTmlMzTIp2RikZnLbb RZDzWh77lTeiPzw1J2Qbc3wCZapbCFpc6ovht30gdT3F92NjdqUVEKqSvIN7THQV GzQeZkdwPXDSh5YUWhgHxrZxOjI6Fv64O4kRo/GPcJ1RP5AvwJ8sHPUFFSHLEPw= =ueu9 -----END PGP SIGNATURE----- --jmgMsA6Cn433PtjGGFebCXJVwkOsEDnT7-- From nobody Tue Aug 29 11:50:43 2017 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 CEFCF1326EC; Tue, 29 Aug 2017 11:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Q0eZNgiQBKDd; Tue, 29 Aug 2017 11:50:28 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15AC013248B; Tue, 29 Aug 2017 11:50:28 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id o132so4502536itc.1; Tue, 29 Aug 2017 11:50:28 -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=1L15XunAXfD0LcRaF4p9Zt64Uw3nYwWAboSpb1hQCJo=; b=uh9eidmszsQMfP4IQQex37GLSKejdH547DSjbsRWfnwcMvaKh8dvZIwD9WyrNvy9vP YrszY1c1tA+dUIFTibEh77xhciBeGS3tfT5rGK4o3DTKC7+/oDR3p18VmAaYhlU7VE0p Di5boZ422Nd3K5Ox6BkXXi+7aY520O4020AOKzGLUvODLlsEoffit7R2NHFbuNpHiaH7 H1i5uwDtt6o3qLWsivL4/j880D3fB3yR7TkuQyneNQFGuT9g4Ess1mHqno+SiUpyJ3lj P+kKJ0hCUnsML1lFdZ2xs0IBS1sTpm2RJvlnFIdqcs2TovemyC6eCiksTS8UOH5aZgzF s3hw== 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=1L15XunAXfD0LcRaF4p9Zt64Uw3nYwWAboSpb1hQCJo=; b=FmgJrh6aqe3V4CGOMPZg63lpSzyCCTOtAD4tlSgA0VKTT99NMAXNaKlF013mkBR4HB ZxT9tehB+SrMrNomMyK9jGi1TuEp125f34yxbm+6YWjna+Smsa6fZwhsjnzn4N/CPbHN 1Sdj3Xp42TAMM+SCO3V5HeEQ/3hQcWnn0DCL9AS5uSlX0kMo5+yG/yeHy/Y8iKv+DzaE J+flKyCEVwBVn7FnpZywKdV5pd4uEM0eJ6eF35LcjFzN7b67FaG53e+vtcLhh5LDjv4R VgMuIePFX6oHB7s51PdrjwBEZ5pHSbPLJ2ErRyxoxqYGWfizFV5pynvTlsJFwgc3LvZ+ q1/w== X-Gm-Message-State: AHYfb5gHXL032zM6vT+TfG3VT9PeR2t4hIZ3EE0va1DBvnIFiYHgu33z yENV5CRBRdrgCi+Q6AoJ5ONSBZLwMw== X-Received: by 10.36.249.67 with SMTP id l64mr3371819ith.66.1504032627122; Tue, 29 Aug 2017 11:50:27 -0700 (PDT) MIME-Version: 1.0 References: <150384057895.866.9675653302394719026@ietfa.amsl.com> In-Reply-To: From: Adam Montville Date: Tue, 29 Aug 2017 18:50:15 +0000 Message-ID: To: Eliot Lear , secdir@ietf.org Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0475707864dc0557e8e2c4" Archived-At: Subject: Re: [secdir] Secdir early review of draft-ietf-opsawg-mud-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 18:50:31 -0000 --94eb2c0475707864dc0557e8e2c4 Content-Type: text/plain; charset="UTF-8" Hi Eliot, You're welcome. Thanks for taking the time to consider, and even implement some of, my feedback. I agree on the hardware rooted trust for software intended use. Seems plausible, given work coming out of TCG. I'm sure there are others who may find this train of thought interesting. Kind regards, Adam On Tue, Aug 29, 2017 at 1:31 PM Eliot Lear wrote: > Hi Adam, > > Thanks very much for your review. I'm pleased you like the general > approach. You hit the nail on the head: this is NOT intended to be a > panacea, but a means by which the device (and its manufacturer) can > enlist the network's protection. Indeed as I mentioned the first time I > presented to SAAG, I will say now again (with feeling): > > NOTHING in that draft nor anywhere ELSE should excuse a > manufacturer/developer from best coding practices and updating > software. The best form of protection will ALWAYS ALWAYS be a well > secured device to begin with. > > MUD is simply there to add an additional layer for when the hacker gets > there first... > > Please now see below. > > > On 8/27/17 3:29 PM, Adam Montville wrote: > > > > Finally, I found myself wondering if this type of appraoch - > communicating > > intended use - could be extended to software installed on general purpose > > devices. For example, it would be interesting to consider how a given > installed > > software package could communicate not only its intended use, but it's > > preferred configuration. > > I'd very much like to pursue this concept, but it seems to me it has to > be rooted in some sort of hardware trust. > > > > > Some questions to consider (these are potential issues): > > > > At the top of page 9, the draft describes controller behavior for mobile > > devices - configurations should be removed when the device is removed. > Does > > this apply also to intermittent devices? > Well indeed so. I think the discussion around mobility is confusing. > I've cleaned that up. > > > When would a device be considered > > "removed" instead of simply powered down? > > I think the best way to look at this is to view the configuration > information as ephemeral, and since the device provides the information > on connect, or otherwise periodically (eg LLDP), you can regenerate the > state. > > > Also, when reading that paragraph I > > began wondering about the load on Web servers serving MUD files - not > that this > > draft should say anything about it, but that it's something > manufacturers are > > going to have to consider and account for. > Right. > > > > Is a stronger statement needed on the first bullet of section 4? Should > it > > read: Anything not explicitly permitted MUST be denied? Similarly for > other > > requirements in MUD file processing. At about this point, I began > wondering if > > additional security considerations may be required for the controller. > > One of the principles we try to observe is that the administrator owns > the network. As such we should be somewhat cautious about how we phrase > such things. From a MUD perspective, what you end up with is an > access-list that an administrator might choose to augment. For > instance, if he or she is running a special load on a Thing using > 802.1AR certificates, he might want to augment the access to accommodate > a new feature. > > In fact, it may be possible that a manufacturer writes such a complex > MUD file that the network administrator desires an optimization. We do > not yet have enough experience to know what sort of normative statement > would cover that ;-) > > > > > Section 9.2 describes DHCP server behavior, and is written in a manner > > presuming the DHCP server knows what's happening with these building > blocks. I > > am not a DHCP expert, so there may be something in DHCP instructing a > server to > > ignore everything it doesn't understand, but if that is not the case, > then what > > is expected to happen when DHCP is not expecting these options and is > not going > > to ignore them? > > This is not a worry. DHCP servers are very capable of ignoring unknown > options, and they have to be well bullet proofed today or we have FAR > FAR bigger fish to fry ;-) > > > > Nits follow: > > > > First paragraph of section 1.5: s/another example might to follow/another > > example might be to follow/ > Right! > > > > Recommend the following for definition of Thing: the device emitting a > MUD URL. > > Ok. > > > > Suggest striking last two sentences of Manufacturer definition, as > irrelevant. > > Ahhh but this actually is a big deal to system integrators ;-) They > want to know what their role in the ecosystem is. > > > > > Is there a way to make the ASCII art in section 1.7 a little cleaner? One > > possibility is to move the right side of the bounding box to the left by > two or > > three places. > > Sure. Done. > > Also, the arrows to the line text isn't necessary (e.g. > > "----->get URL->" is cleaner as "---get URL--->"). > > Done. > > > > Second bullet on page 11: s/other otherwise/otherwise/ > > right. > > Should there be a newline after "" at the start of section > 6? > > I'm going to leave that one to the YANG doctors... > > > > On page 17: s/end(ed)/end(s\/ed)/ Basically, the sentence without > "ended" > > should read, "Information about when support ends, and when to refresh." > > This will change with the updating of the model, based on YANG doctor > feedback. That very container is likely to be consolidated away. > > > > Vertial spacing could be improved for the first bit in section 9, so > that the > > look/feel surrounding OPTION_MUD_URL_V4 matches that of OPTION_MUD_URL_v6 > > Ok. I think I addressed what you're talking about. > > > > Section 11, first sentence: s/link layer protocols/link layer protocol/ > > > > > > Good catch. > > Best regards and thanks again for your review. > > Eliot > > --94eb2c0475707864dc0557e8e2c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Eliot,

You're welcome. Thanks fo= r taking the time to consider, and even implement some of, my feedback.

I agree on the hardware rooted trust for software int= ended use. Seems plausible, given work coming out of TCG. I'm sure ther= e are others who may find this train of thought interesting.

=
Kind regards,

Adam

On Tue, Aug 29, 2017 at 1:31 PM Eliot Lea= r <lear@cisco.com> wrote:
Hi Adam,

Thanks very much for your review.=C2=A0 I'm pleased you like the genera= l
approach.=C2=A0 You hit the nail on the head: this is NOT intended to be a<= br> panacea, but a means by which the device (and its manufacturer) can
enlist the network's protection. Indeed as I mentioned the first time I=
presented to SAAG, I will say now again (with feeling):

NOTHING in that draft nor anywhere ELSE should excuse a
manufacturer/developer from best coding practices and updating
software.=C2=A0 The best form of protection will ALWAYS ALWAYS be a well secured device to begin with.

MUD is simply there to add an additional layer for when the hacker gets
there first...

Please now see below.


On 8/27/17 3:29 PM, Adam Montville wrote:
>
> Finally, I found myself wondering if this type of appraoch - communica= ting
> intended use - could be extended to software installed on general purp= ose
> devices. For example, it would be interesting to consider how a given = installed
> software package could communicate not only its intended use, but it&#= 39;s
> preferred configuration.

I'd very much like to pursue this concept, but it seems to me it has to=
be rooted in some sort of hardware trust.

>
> Some questions to consider (these are potential issues):
>
> At the top of page 9, the draft describes controller behavior for mobi= le
> devices - configurations should be removed when the device is removed.= Does
> this apply also to intermittent devices?
Well indeed so.=C2=A0 I think the discussion around mobility is confusing.= =C2=A0
I've cleaned that up.

> When would a device be considered
> "removed" instead of simply powered down?

I think the best way to look at this is to view the configuration
information as ephemeral, and since the device provides the information
on connect, or otherwise periodically (eg LLDP), you can regenerate the
state.

>=C2=A0 Also, when reading that paragraph I
> began wondering about the load on Web servers serving MUD files - not = that this
> draft should say anything about it, but that it's something manufa= cturers are
> going to have to consider and account for.
Right.
>
> Is a stronger statement needed on the first bullet of section 4? Shoul= d it
> read: Anything not explicitly permitted MUST be denied? Similarly for = other
> requirements in MUD file processing. At about this point, I began wond= ering if
> additional security considerations may be required for the controller.=

One of the principles we try to observe is that the administrator owns
the network.=C2=A0 As such we should be somewhat cautious about how we phra= se
such things.=C2=A0 From a MUD perspective, what you end up with is an
access-list that an administrator might choose to augment.=C2=A0 For
instance, if he or she is running a special load on a Thing using
802.1AR certificates, he might want to augment the access to accommodate a new feature.

In fact, it may be possible that a manufacturer writes such a complex
MUD file that the network administrator desires an optimization.=C2=A0 We d= o
not yet have enough experience to know what sort of normative statement
would cover that ;-)

>
> Section 9.2 describes DHCP server behavior, and is written in a manner=
> presuming the DHCP server knows what's happening with these buildi= ng blocks. I
> am not a DHCP expert, so there may be something in DHCP instructing a = server to
> ignore everything it doesn't understand, but if that is not the ca= se, then what
> is expected to happen when DHCP is not expecting these options and is = not going
> to ignore them?

This is not a worry.=C2=A0 DHCP servers are very capable of ignoring unknow= n
options, and they have to be well bullet proofed today or we have FAR
FAR bigger fish to fry ;-)
>
> Nits follow:
>
> First paragraph of section 1.5: s/another example might to follow/anot= her
> example might be to follow/
Right!
>
> Recommend the following for definition of Thing: the device emitting a= MUD URL.

Ok.
>
> Suggest striking last two sentences of Manufacturer definition, as irr= elevant.

Ahhh but this actually is a big deal to system integrators ;-)=C2=A0 They want to know what their role in the ecosystem is.

>
> Is there a way to make the ASCII art in section 1.7 a little cleaner? = One
> possibility is to move the right side of the bounding box to the left = by two or
> three places.

Sure.=C2=A0 Done.
> Also, the arrows to the line text isn't necessary (e.g.
> "----->get URL->" is cleaner as "---get URL--->= ;").

Done.
>
> Second bullet on page 11: s/other otherwise/otherwise/

right.
> Should there be a newline after "<CODE BEGINS>" at the= start of section 6?

I'm going to leave that one to the YANG doctors...
>
> On page 17: s/end(ed)/end(s\/ed)/=C2=A0 Basically, the sentence withou= t "ended"
> should read, "Information about when support ends, and when to re= fresh."

This will change with the updating of the model, based on YANG doctor
feedback.=C2=A0 That very container is likely to be consolidated away.
>
> Vertial spacing could be improved for the first bit in section 9, so t= hat the
> look/feel surrounding OPTION_MUD_URL_V4 matches that of OPTION_MUD_URL= _v6

Ok.=C2=A0 I think I addressed what you're talking about.
>
> Section 11, first sentence: s/link layer protocols/link layer protocol= /
>
>

Good catch.

Best regards and thanks again for your review.

Eliot

--94eb2c0475707864dc0557e8e2c4-- From nobody Tue Aug 29 13:48:33 2017 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 50ECA1320CC; Tue, 29 Aug 2017 13:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TBEBDEBspig; Tue, 29 Aug 2017 13:48:21 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90745124E15; Tue, 29 Aug 2017 13:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=48306; q=dns/txt; s=iport; t=1504039701; x=1505249301; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/VU45vNSS6vq9tQx0WXLj7/iEvkXzKBNyuRka6BkRZw=; b=bGyeKhE8IsKzkPM5SHwKONt0bVL0XmKQj7TU8RaGR8JrCUDP8NC1pAvn Arpxb4po92HL0noieF08hPWltp8JuFoSYMpj1w76s8asxdfwRGUbwKtTk C/TkbgeZ6ni8X010yWx5CDIjO+ZadT1F/9a2HdXKcZDX31+u4DYLM38FZ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ARAQBp0qVZ/4YNJK1TBwMZAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDWmSBFQeDLUOKHpAbgU+IW41uDoIELIFggzsCGoN7PxgBAgE?= =?us-ascii?q?BAQEBAQFrKIUZBgwOCVYQAgEGAjgHAwICAh8RFBECBA4FiU1MAxUQkSSdZoInh?= =?us-ascii?q?zYNhAYBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYMqgQt3gzErC4FlgQ2CV4FrAQc?= =?us-ascii?q?LAQkJJAomgkwwgjEFoCw8AodXh32EdoIShWeKcol3glWJdQEfOIECC3cVWwGFB?= =?us-ascii?q?AEcgWd2iRECBAEIF4EMgQ8BAQE?= X-IronPort-AV: E=Sophos;i="5.41,445,1498521600"; d="scan'208,217";a="473673296" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Aug 2017 20:48:19 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v7TKmJsq020337 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 29 Aug 2017 20:48:19 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 29 Aug 2017 16:48:18 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1263.000; Tue, 29 Aug 2017 16:48:18 -0400 From: "Brian Weis (bew)" To: Yaron Sheffer CC: "secdir@ietf.org" , "draft-weis-gdoi-rekey-ack.all@ietf.org" , "ietf@ietf.org" Thread-Topic: Secdir last call review of draft-weis-gdoi-rekey-ack-05 Thread-Index: AQHTDgJglUgJl63bZkSkx0TnTx/5x6KUGN4AgAMP2QCABQ6cgA== Date: Tue, 29 Aug 2017 20:48:18 +0000 Message-ID: References: <150194814585.18635.3104789196001873381@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.174.41] Content-Type: multipart/alternative; boundary="_000_DE62366A03774DE19ED0A14E44A7EC05ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-weis-gdoi-rekey-ack-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 20:48:25 -0000 --_000_DE62366A03774DE19ED0A14E44A7EC05ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWWFyb24sDQoNCk9uIEF1ZyAyNiwgMjAxNywgYXQgODozNCBBTSwgWWFyb24gU2hlZmZlciA8 eWFyb25mLmlldGZAZ21haWwuY29tPG1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20+PiB3cm90 ZToNCg0KSGkgQnJpYW4sDQoNClRoYW5rIHlvdSBmb3IgYWRkcmVzc2luZyBtb3N0IG9mIG15IGNv bW1lbnRzIGluIHRoZSBuZXcgdmVyc2lvbiwgYW5kIGZvciBjbGFyaWZ5aW5nIHBvaW50cyB3aGVy ZSBJIHdhcyBvZmYgdGhlIG1hcmsuDQoNClRoZSBvbmx5IHJlbWFpbmluZyBjb21tZW50IHRoYXQn cyBvbmx5IHBhcnRseSBhZGRyZXNzZWQgaXMgdGhlIG9uZSBvbiBjcnlwdG8gYWdpbGl0eS4gUXVv dGluZyBteXNlbGY6DQoNCndlIG5lZWQgdG8gZGVmaW5lIHdoZXRoZXIgbXVsdGlwbGUgc3VjaCBw YXlsb2FkcyBjYW4gYmUgc2VudCBzaW11bHRhbmVvdXNseSAoaWYgZS5nLiBzb21lIEdNcyBzdGls bCBzdXBwb3J0IHRoZSBvbGQgYWxnb3JpdGhtKSBhbmQgd2hhdCdzIHRoZSBleHBlY3RlZCBiZWhh dmlvci4NCg0KSW4gb3RoZXIgd29yZHMsIHN1cHBvcnRpbmcgbW9yZSBhbGdvcml0aG1zIGluIG5v dCBzdWZmaWNpZW50LiBUaGUgcXVlc3Rpb24gaXMgd2hldGhlciB3ZSBzdXBwb3J0IGluY3JlbWVu dGFsIGRlcGxveW1lbnQgb2YgYSBuZXcgYWxnb3JpdGhtIHRvIGEgbGFyZ2UgZ3JvdXAgb2YgR01z Lg0KDQpTb3JyeSwgd2UgbWlzc2VkIHRoaXMuIEluY3JlbWVudGFsIGRlcGxveW1lbnQgb2YgYW55 IG5ldyBwb2xpY3kgKGFsZ29yaXRobSBvciBvdGhlcndpc2UpIHdpdGhpbiBhIGdyb3VwIGlzIG5v dCBzbyBzdHJhaWdodGZvcndhcmQuIFRoZXJlIGNhbiByZWFsbHkgb25seSBiZSBvbmUgc2V0IG9m IHBvbGljeSB1c2VkIGJ5IHRoZSBlbnRpcmUgZ3JvdXAgYmVjYXVzZSBpZiBhIHNlbmRlciBoYXMg YmVlbiB1cGRhdGVkIHRvIGEgbmV3IHNldCBvZiBwb2xpY3kgaXQgY2Fu4oCZdCByZWFsbHkgdXNl IGl0IHVudGlsIGFsbCByZWNlaXZlcnMgYXJlIHNpbWlsYXJseSB1cGdyYWRlZC4gVGhpcyBpcyBh IHBsYWNlIHdoZXJlIGEgY2FwYWJpbGl0aWVzIGV4Y2hhbmdlIGNhbiBiZSB1c2VmdWwgZm9yIGEg a2V5IHNlcnZlciB0byBkZWNsYXJlIGEgc3dpdGNoIHRvIGEgbmV3IGFsZ29yaXRobSBhZnRlciBh bGwgbWVtYmVycyBjbGFpbSB0byBzdXBwb3J0IGl0LCBidXQgdGhhdCBtaWdodCBuZXZlciBoYXBw ZW4gaW4gYSBsYXJnZSBncm91cC4gUHJhY3RpY2FsbHkgc3BlYWtpbmcgaW5jcmVtZW50YWwgdXBk YXRlcyBpbiBhIGxhcmdlIGdyb3VwIG1pZ2h0IHJlcXVpcmUgdHdvIGRpZmZlcmVudCBncm91cHMg d2l0aCBhIGJyaWRnZSBiZXR3ZWVuLCBvciBzb21lIG90aGVyIGRlcGxveW1lbnQgc3RydWN0dXJl LiBTaW5jZSBpdOKAmXMgYSBicm9hZGVyIHByb2JsZW0sIEnigJltIG5vdCBzdXJlIHdoYXQgZWxz ZSB3ZSBjYW4gZG8gaW4gdGhpcyBkb2N1bWVudCB0byBhZGRyZXNzIGluY3JlbWVudGFsIGRlcGxv eW1lbnQuDQoNClRoYW5rcywNCkJyaWFuDQoNCg0KVGhhbmtzLA0KWWFyb24NCg0KT24gMjQvMDgv MTcgMTk6NDgsIEJyaWFuIFdlaXMgKGJldykgd3JvdGU6DQpIaSBZYXJvbiwNClRoYW5rcyBmb3Ig dGhlIHJldmlldy4gV2XigJl2ZSBhZGRlZCBzb21lIGNsYXJpZmljYXRpb24gYmVsb3csIGFuZCBt YWRlIHNvbWUgY2hhbmdlcyBpbiAtMDYgdG8gYWRkcmVzcyB5b3VyIGNvbW1lbnRzLiBQbGVhc2Ug bGV0IHVzIGtub3cgaWYgd2UgZGlkIG5vdCBhZGRyZXNzIHRoZW0gc2F0aXNmYWN0b3JpbHkuDQpP biBBdWcgNSwgMjAxNywgYXQgODo0OSBBTSwgWWFyb24gU2hlZmZlciA8eWFyb25mLmlldGZAZ21h aWwuY29tPG1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20+IDxtYWlsdG86eWFyb25mLmlldGZA Z21haWwuY29tPj4gd3JvdGU6DQoNClJldmlld2VyOiBZYXJvbiBTaGVmZmVyDQpSZXZpZXcgcmVz dWx0OiBIYXMgSXNzdWVzDQoNClN1bW1hcnk6IHRoaXMgcmV2aWV3ZXIgaXMgbm90IGNsZWFyIGFi b3V0IHRoZSB2YWx1ZSBvZiB0aGUgcHVzaC1hY2sgKGNvbXBhcmVkDQp0byBhIHB1bGwpIGFuZCBh Ym91dCB0aGUgc3RyYXRlZ3kgdGhhdCB3YXMgY2hvc2VuLg0KSW4gYSBncm91cCBrZXkgbWFuYWdl bWVudCBzeXN0ZW0gZWl0aGVyIGEg4oCccHVsbOKAnSAodHJpZ2dlcmVkIGJ5IGEgZ3JvdXAgbWVt YmVyKSBvciBhIOKAnHB1c2jigJ0gKGJ5IHRoZSBrZXkgc2VydmVyKSIgY291bGQgYmUgdXNlZCB0 byBwcm92aWRlIHVwZGF0ZXMgdG8gdGhlIGdyb3VwLiBIb3dldmVyLCBhIOKAnHB1bGzigJ0gYnkg dGhlIGdyb3VwIG1lbWJlciBpbXBsaWVzIGEgcG9sbGluZyBtZXRob2QsIHdoaWNoIGhhcyB0aGUg ZGVmaWNpZW5jeSB0aGF0IHRoZSBrZXkgc2VydmVyIGNhbm5vdCBjYXVzZSBhIHBvbGljeSByZXBs YWNlbWVudCBhbnkgc29vbmVyIHRoYW4gdGhlIHBvbGxpbmcgbWV0aG9kIGJ5IHRoZSBncm91cCBt ZW1iZXJzLiBBbHNvIOKAnHBvbGxpbmfigJ0gY2FuIGNhdXNlIGFkZGl0aW9uYWwgdW5uZWNlc3Nh cnkgdHJhZmZpYy4gU28gaXMgaXMgYmV0dGVyIGZvciBhbnkgdXBkYXRlIG9uIHRoZSBncm91cCBw b2xpY3kgb3IgcmVuZXdhbCBvZiBncm91cCBrZXlzIHRvIGJlIGRpc3RyaWJ1dGVkIGJ5IHRoZSBH Q0tTIHVzaW5nIGEgUFVTSCBtZXNzYWdlLiBUaGUgQUNLLW1lc3NhZ2UgaXMgdXNlZCB0byBvZmZl ciBhIGZlZWRiYWNrIG1lY2hhbmlzbSB0byBhIHBvbGljeSB1cGRhdGUgZm9yIHRoZSBQVVNIIGV4 Y2hhbmdlLg0KDQoqLy8qDQoNCiogIkZvciBleGFtcGxlLCBhIEdDS1MgcG9saWN5IGNhbiB1c2Ug dGhlIGFja25vd2xlZGdlbWVudHMgdG8gZGV0ZXJtaW5lIFsuLi5dDQp3aGljaCBtZW1iZXJzIG1h eSBubyBsb25nZXIgYmUgbWVtYmVycyBvZiB0aGUgZ3JvdXAuIiBUaGlzIHNlbnRlbmNlIGlzIHZl cnkNCmNvbmZ1c2luZzogd2hlbiBhcmUgbWVtYmVycyBub3QgbWVtYmVycz8NCldl4oCZdmUgcmV3 b3JkZWQgdGhpcyB0ZXh0LiBJdOKAmXMgdHJ5aW5nIHRvIGNvbnZleSB0aGF0IGEgbWlzc2luZyBB Q0sgbWVzc2FnZSAob3IgYSBjZXJ0YWluIG51bWJlciBvZiBpdCkgY2FuIGJlIHVzZWQgdG8gaWRl bnRpZnkgdGhhdCBhIGdyb3VwIG1lbWJlciBpcyBubyBsb25nZXIgcmVjZWl2aW5nIGdyb3VwIHRy YWZmaWMsIGFuZCBpcyBub3cgbWF5IGJlIGNvbnNpZGVyZWQgYW4gZXgtZ3JvdXAgbWVtYmVyLiBG b3IgZXhhbXBsZSwgaXQgY291bGQgYmUgYSBtdWx0aWNhc3QgcmVjZWl2ZXIgdGhhdCBpcyBubyBs b25nZXIgaW50ZXJlc3RlZCBpbiBiZWluZyBhIHJlY2VpdmVyIGZvciB0aGUgZ3JvdXAuIEJ1dCBp dCBjb3VsZCBhbHNvIGJlIHRoYXQgYSBuZXR3b3JrIGV2ZW50IGhhcyBjYXVzZWQgaXQgdG8gYmUg dW5hdmFpbGFibGUgZm9yIGEgc3VmZmljaWVudCBsZW5ndGggb2YgdGltZSBzdWNoIHRoYXQgaXQg ZG9lc27igJl0IGhhdmUgY3VycmVudCBrZXlpbmcgbWF0ZXJpYWwgYW5kIHRoZXJlZm9yZSBjYW7i gJl0IGJlIGNvbnNpZGVyZWQgYSBjdXJyZW50IGdyb3VwIG1lbWJlci4gVGhlcmUgaXMgbm8gcmVs aWFibGUg4oCcSeKAmW0gbGVhdmluZyB0aGUgZ3JvdXDigJ0gbWVzc2FnZSBmbG93LCBhbmQgb2Yg Y291cnNlIGluIG15IHNlY29uZCBleGFtcGxlIG5vIHN1Y2ggbWVzc2FnZXMgd291bGQgaGF2ZSBi ZWVuIGludGVuZGVkIGJ5IHRoZSBncm91cCBtZW1iZXIuDQoqIFRoZSBuZXcgcHJvdG9jb2wgY2Fw YWJpbGl0eSBpcyBkZWZpbmVkIGFzIG9wdGlvbmFsLCBidXQgcmVhbGx5IGlzbid0LiAiQSBHTQ0K cmVjZWl2aW5nIHRoZSBLRUtfQUNLX1JFUVVFU1RFRCBhdHRyaWJ1dGUgY2FuIGNob29zZSB0byBp Z25vcmUgaXQsIHRodXMNCmFwcGVhcmluZyBhcyBpZiBpdCBkb2VzIG5vdCBzdXBwb3J0IHRoZSBL RUtfQUNLX1JFUVVFU1RFRCBhdHRyaWJ1dGUuIEhvd2V2ZXIsDQpHQ0tTIHBvbGljeSBtYXkgY29u c2lkZXIgYSBub24tcmVzcG9uc2l2ZSBHTSB0byBubyBsb25nZXIgZGVzaXJlIHRvIGJlIGEgbWVt YmVyDQpvZiB0aGUgZ3JvdXAuIiBTbyBpZiB5b3Ugd2FudCB0byBwbGF5IHRoZSBnYW1lLCB5b3Ug TVVTVCBzdXBwb3J0IHRoZSBuZXcNCmF0dHJpYnV0ZS4NClBvaW50IHRha2VuLiBXZeKAmXZlIGNo YW5nZWQgdGhlIHRleHQgdG8gcmVmbGVjdCB0aGlzLg0KKiBJJ20gcHV6emxlZCBhdCB0aGUgb3Zl cmFsbCBwcm90b2NvbC4gQmVpbmcgYWJsZSB0byBzZW5kIEFDS3MgaXMgYSBHTSBzb2Z0d2FyZQ0K Y2FwYWJpbGl0eS4gV2h5IG5vdCBoYXZlIHRoZSBHTSBhbm5vdW5jZSB0aGlzIGNhcGFiaWxpdHkg d2hlbiBpdCBpbml0aWFsbHkNCnJlZ2lzdGVycyB0byB0aGUgR0NLUz8gVGhlbiB0aGUgR0NLUyB3 b3VsZCBrbm93IHdoYXQgdG8gZXhwZWN0LCB3aGVyZWFzIHdpdGgNCnRoZSBjdXJyZW50IHByb3Rv Y29sIGl0IGlzIGxlZnQgd2FpdGluZyBmb3IgYW4gQUNLIHRoYXQgbWF5IG5ldmVyIGNvbWUsIGVp dGhlcg0KYmVjYXVzZSB0aGUgR00gaXMgZGVhZCBvciBiZWNhdXNlIGl0IGp1c3QgZG9lc24ndCBm ZWVsIGxpa2UgcmVzcG9uZGluZy4gQWRkIHRoZQ0KbG9uZyB3YWl0cyAoaml0dGVyIG9mICJhIGZl dyBzZWNvbmRzIiBhbmQgcG90ZW50aWFsIHJldHJpZXMpLCBhbmQgdGhpcyBsb29rcw0KbGlrZSBh IGZhciBmcm9tIG9wdGltYWwgbWFuYWdlbWVudCBleHBlcmllbmNlLg0KSW5kZWVkIGEgR00gY291 bGQgYW5ub3VuY2UgaXRzIGNhcGFiaWxpdHksIGJ1dCB3aGV0aGVyIG9yIG5vdCBBQ0tzIGFyZSBk ZXNpcmVkIGlzIGEgY29tcG9uZW50IG9mIHRoZSBncm91cCBwb2xpY3kuIEluIHRoZSBjb250ZXh0 IG9mIEdET0kgdGhlIEdDS1MgaXMgdGhlIGVudGl0eSB0aGF0IGRlZmluZXMgdGhlIGdyb3VwIHBv bGljeS4gVGhlcmUgY2FuIGJlIGdyb3VwcyB3aGVyZSB0aGUgQUNLIGlzIHVzZWQsIHdoZXJlYXMg b3RoZXJzIGRvIG5vdC4gIFRoZSBjYXBhYmlsaXRpZXMgYW5ub3VuY2VtZW50IHlvdSBzdWdnZXN0 IGNvdWxkIGNlcnRhaW5seSBoZWxwIHRoZSBLUyB0byBrbm93IHdoZXRoZXIgb3Igbm90IHRvIGV4 cGVjdCB0aGUgQUNLIGZyb20gYSBwYXJ0aWN1bGFyIEdNLCBidXQgdGhlIGZvY3VzIG9mIHRoaXMg SS1EIGlzIG9uIHRoZSB0aGUgZGVjbGFyYXRpb24gb2YgdGhlIHJlcXVlc3QgZm9yIEFDS3MgYnkg dGhlIEdDS1MgYW5kIHRoZSBmb3JtYXQgb2YgdGhlIEFDSy4NCiogMi4yOiAiVGhpcyBpcyBhIHBy aXZhdGUga2V5IiAtIHRvIGF2b2lkIGNvbmZ1c2lvbiwgSSBzdWdnZXN0OiAiVGhpcyBpcyBhDQpz ZWNyZXQgc3ltbWV0cmljIGtleSIgKGlmIHRoaXMgaXMgaW5kZWVkIHRoZSBjYXNlKS4gT2J2aW91 c2x5IHVzaW5nIHRoZSBzYW1lDQprZXkgZm9yIGVuY3J5cHRpb24gYW5kIGZvciBITUFDIGlzIG5v dCBhIGJlc3QgcHJhY3RpY2UuDQpXZeKAmXZlIG1hZGUgdGhpcyBjaGFuZ2UuDQoqIFNlYy4gNTog QUNLIG1lc3NhZ2VzIGNhbiBhbHNvIGJlIGR1cGxpY2F0ZWQgaW4gdGhlIG5ldHdvcmsuIEkgc3Vn Z2VzdCB0byBhZGQNCmEgc2VudGVuY2UgZGVzY3JpYmluZyB3aGF0IHRoZSBHQ0tTIHNob3VsZCBk byBpbiB0aGlzIGNhc2UuDQpUaGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgKHNlY3Rpb24gNy4z KSBkZXNjcmliZXMgYSBtZXRob2QgZm9yIHRoZSBHQ0tTIHRvIGRldGVjdCByZXBsYXlzLiBUaGlz IGlzIGFyZ3VhYmx5IGJldHRlciBwbGFjZWQgaW4gdGhpcyBzZWN0aW9uLCBzbyB3ZeKAmXZlIG1v dmVkIGl0IGhlcmUuLg0KKiBTZWMuIDY6IEkgYW0gY29uZnVzZWQgYWJvdXQgdGhlIG5vdGlvbiBv ZiAiaml0dGVyIiBoZXJlLiBJZiB0aGUgUFVTSCBtZXNzYWdlcw0KYXJlIHNlbnQgYXMgbXVsdGlj YXN0ICh0aGUgcmVjb21tZW5kZWQgYWx0ZXJuYXRpdmUgQUZBSUNUKSwgSSdtIG5vdCBzdXJlIGFi b3V0DQp0aGUgYmVuZWZpdCBvZiB1c2luZyBtdWx0aWNhc3QsIGdpdmVuIHRoYXQgZWFjaCByZWNp cGllbnQgcmVzcG9uZHMgd2l0aCBhDQp1bmljYXN0IEFDSy4gQW5kIGlmIHRoZSBQVVNIIGlzIHVu aWNhc3QsIHRoZXJlIHNob3VsZCBiZSBubyByZWFzb24gZm9yIGEgaml0dGVyDQphcyB0aGUgc2Vu ZGVyIGNhbiB0aHJvdHRsZSB0aGUgUFVTSCBtZXNzYWdlcyBhcyBuZWNlc3NhcnkuDQpUaGUgY29u Y2VwdCBvZiDigJxqaXR0ZXLigJ0gaXMgbW9zdCB2YWx1YWJsZSBmb3IgcmVzcG9uc2VzIHRvIGEg bXVsdGljYXN0IFBVU0ggbWVzc2FnZS4gVGhlIHVzZSBvZiBhIG11bHRpY2FzdCBQVVNIIG1lc3Nh Z2UgbG93ZXIgcHJvY2Vzc2luZyBvbiB0aGUgR0NLUy4gU2luY2UgZWFjaCBHTSBjYW4gZSBnaXZl biB0aGUgZXhhY3Qgc2FtZSBwb2xpY3ksIHRoZXJl4oCZcyBubyBjYWxsIHRvIHNlbmQgaXQgb3V0 IGFzIGEgdW5pY2FzdCBtZXNzYWdlLiBUaGUgaml0dGVyIGhlbHBzIHNwcmVhZCBvdXQgdGhlIHJl cGxpZXMgYSBiaXQgdG8gYXZvaWQgaW51bmRhdGluZyB0aGUgR0NLUy4NCiogTW9yZW92ZXIsIGV2 ZXJ5dGhpbmcgd291bGQgYmUgbXVjaCBtb3JlIHByZWRpY3RhYmxlIGlmIHRoZSBHQ0tTIGNvdWxk DQppbmRpY2F0ZSBpZiBhIGppdHRlciBpcyBleHBlY3RlZCBhbmQgaG93IG11Y2ggb2YgYSBqaXR0 ZXIgKGJhc2VkIG9uIHNpemUgb2YgdGhlDQpncm91cCwgbmV0d29yayB0aHJvdWdocHV0LCBhbmQg cXVldWUgbGVuZ3RoKS4gU3BlY2lmaWNhbGx5LCB0aGlzIHdvdWxkIGFsbG93DQp0aGUgR0NLUyB0 byB0ZWxsIGhvdyBsb25nIGl0IHNob3VsZCB3YWl0IGZvciBhbiBBQ0suDQpUaGlzIHdvdWxkIGJl IHNvbWV3aGF0IHVzZWZ1bCwgYnV0IGluIHByYWN0aWNlIG1pZ2h0IG5vdCBoZWxwIHRoZSBHQ0tT IGFzIG11Y2ggYXMgaXQgc2VlbXMuIFRoZSBqaXR0ZXIgdmFsdWUgcHJvdmlkZWQgd291bGQgYWxz byBiZSBkZXBlbmRlbnQgb24gc2V2ZXJhbCBuZXR3b3JrIHBhcmFtZXRlcnMgdGhhdCBhcmVu4oCZ dCB1bmRlciB0aGUgY29udHJvbCBvZiB0aGUgR0NLUyBvciB0aGUgR00uIEV2ZW4gd2hlbiB0aGUg R00gZG9lcyBub3QgYWRkIGFueSBqaXR0ZXIgdG8gdGhlIEFDSywgdGhlIHVuZGVybHlpbmcgbmV0 d29yayBtYXkgZGVsYXkgdGhlIFBVU0ggYW5kL29yIGZvciB0aGUgQUNLLiBBbmQgYXMgc3RhdGVk IGluIFNlY3Rpb24gNiwgdGhlIEdDS1MgbWF5IGJlIGNvbmZpZ3VyZWQgd2l0aCBhZGRpdGlvbmFs IHBvbGljeSBhY3Rpb25zIGxpa2UgcmV0cmFuc21pc3Npb25zIHRvIG92ZXJjb21lIGxvc3QgQUNL cy4gQWx0b2dldGhlciB0byBhZGQgaml0dGVyIHRvIHRoZSBBQ0sgaXMgbm90IGEgbXVzdCwgaXQg aXMgYSB3YXkgdG8gaGVscCB0aGUgR0NLUyBkZWFsIHdpdGggYSBodWdlIG51bWJlciBvZiBHTXMu IEluIHByYWN0aWNlLCB3ZeKAmXZlIGZvdW5kIHRoYXQgaGF2aW5nIHRoZSBHTXMgY2hvb3NlIHRo ZSBqaXR0ZXIgaGFzIHdvcmtlZCB3ZWxsLCBldmVuIHdoZW4gdGhlIEdNcyBhcmUgZGlmZmVyZW50 IGltcGxlbWVudGF0aW9ucy4NCiogQ3J5cHRvZ3JhcGhpYyBhZ2lsaXR5OiB0aGlzIGRvY3VtZW50 IHNwZWNpZmllcyBvbmx5IG9uZSBhbGdvcml0aG0gZm9yIHRoZQ0KSEFTSCB2YWx1ZSwgYW5kIHNh eXMgdGhhdCBpZiBhIG5ldyBhbGdvcml0aG0gaXMgbmVlZGVkLCB0aGVyZSB3aWxsIGJlIGEgbmV3 DQpLRUtfQUNLX1JFUVVFU1RFRCBwYXlsb2FkIGRlZmluZWQuIEhvd2V2ZXIgdG8gbWFrZSBzdXJl IHRoYXQgdGhpcyByZWFsbHkNCiJ3b3JrcyIsIHdlIG5lZWQgdG8gZGVmaW5lIHdoZXRoZXIgbXVs dGlwbGUgc3VjaCBwYXlsb2FkcyBjYW4gYmUgc2VudA0Kc2ltdWx0YW5lb3VzbHkgKGlmIGUuZy4g c29tZSBHTXMgc3RpbGwgc3VwcG9ydCB0aGUgb2xkIGFsZ29yaXRobSkgYW5kIHdoYXQncw0KdGhl IGV4cGVjdGVkIGJlaGF2aW9yLiBJIHdvdWxkIHN1Z2dlc3QgdG8gZGVmaW5lIGFuIGFkZGl0aW9u YWwgU0hBLTUxMiBwYXlsb2FkDQpqdXN0IHRvIG1ha2UgZm9yIGEgY29uY3JldGUgZXhhbXBsZS4N ClRoaXMgaXMgYSBnb29kIHN1Z2dlc3Rpb24uIFdl4oCZdmUgYWRkZWQgU0hBLTUxMiB2ZXJzaW9u cyBvZiB0aGUgZXhpc3RpbmcgS0VLX0FDS19SRVFVRVNURUQgdmFsdWVzLg0KU2VlIDxodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2Vpcy1nZG9pLXJla2V5LWFjay0wNj4NClRoYW5r cywNCkJyaWFuDQotLQ0KQnJpYW4gV2Vpcw0KU2VjdXJpdHksIENTRywgQ2lzY28gU3lzdGVtcw0K VGVsZXBob25lOiArMSA0MDggNTI2IDQ3OTYNCkVtYWlsOiBiZXdAY2lzY28uY29tPG1haWx0bzpi ZXdAY2lzY28uY29tPiA8bWFpbHRvOmJld0BjaXNjby5jb20+DQoNCg0KVGhhbmtzLA0KWWFyb24N Cg0KT24gMjQvMDgvMTcgMTk6NDgsIEJyaWFuIFdlaXMgKGJldykgd3JvdGU6DQpIaSBZYXJvbiwN ClRoYW5rcyBmb3IgdGhlIHJldmlldy4gV2XigJl2ZSBhZGRlZCBzb21lIGNsYXJpZmljYXRpb24g YmVsb3csIGFuZCBtYWRlIHNvbWUgY2hhbmdlcyBpbiAtMDYgdG8gYWRkcmVzcyB5b3VyIGNvbW1l bnRzLiBQbGVhc2UgbGV0IHVzIGtub3cgaWYgd2UgZGlkIG5vdCBhZGRyZXNzIHRoZW0gc2F0aXNm YWN0b3JpbHkuDQpPbiBBdWcgNSwgMjAxNywgYXQgODo0OSBBTSwgWWFyb24gU2hlZmZlciA8eWFy b25mLmlldGZAZ21haWwuY29tPG1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20+IDxtYWlsdG86 eWFyb25mLmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQoNClJldmlld2VyOiBZYXJvbiBTaGVmZmVy DQpSZXZpZXcgcmVzdWx0OiBIYXMgSXNzdWVzDQoNClN1bW1hcnk6IHRoaXMgcmV2aWV3ZXIgaXMg bm90IGNsZWFyIGFib3V0IHRoZSB2YWx1ZSBvZiB0aGUgcHVzaC1hY2sgKGNvbXBhcmVkDQp0byBh IHB1bGwpIGFuZCBhYm91dCB0aGUgc3RyYXRlZ3kgdGhhdCB3YXMgY2hvc2VuLg0KSW4gYSBncm91 cCBrZXkgbWFuYWdlbWVudCBzeXN0ZW0gZWl0aGVyIGEg4oCccHVsbOKAnSAodHJpZ2dlcmVkIGJ5 IGEgZ3JvdXAgbWVtYmVyKSBvciBhIOKAnHB1c2jigJ0gKGJ5IHRoZSBrZXkgc2VydmVyKSIgY291 bGQgYmUgdXNlZCB0byBwcm92aWRlIHVwZGF0ZXMgdG8gdGhlIGdyb3VwLiBIb3dldmVyLCBhIOKA nHB1bGzigJ0gYnkgdGhlIGdyb3VwIG1lbWJlciBpbXBsaWVzIGEgcG9sbGluZyBtZXRob2QsIHdo aWNoIGhhcyB0aGUgZGVmaWNpZW5jeSB0aGF0IHRoZSBrZXkgc2VydmVyIGNhbm5vdCBjYXVzZSBh IHBvbGljeSByZXBsYWNlbWVudCBhbnkgc29vbmVyIHRoYW4gdGhlIHBvbGxpbmcgbWV0aG9kIGJ5 IHRoZSBncm91cCBtZW1iZXJzLiBBbHNvIOKAnHBvbGxpbmfigJ0gY2FuIGNhdXNlIGFkZGl0aW9u YWwgdW5uZWNlc3NhcnkgdHJhZmZpYy4gU28gaXMgaXMgYmV0dGVyIGZvciBhbnkgdXBkYXRlIG9u IHRoZSBncm91cCBwb2xpY3kgb3IgcmVuZXdhbCBvZiBncm91cCBrZXlzIHRvIGJlIGRpc3RyaWJ1 dGVkIGJ5IHRoZSBHQ0tTIHVzaW5nIGEgUFVTSCBtZXNzYWdlLiBUaGUgQUNLLW1lc3NhZ2UgaXMg dXNlZCB0byBvZmZlciBhIGZlZWRiYWNrIG1lY2hhbmlzbSB0byBhIHBvbGljeSB1cGRhdGUgZm9y IHRoZSBQVVNIIGV4Y2hhbmdlLg0KDQoqLy8qDQoNCiogIkZvciBleGFtcGxlLCBhIEdDS1MgcG9s aWN5IGNhbiB1c2UgdGhlIGFja25vd2xlZGdlbWVudHMgdG8gZGV0ZXJtaW5lIFsuLi5dDQp3aGlj aCBtZW1iZXJzIG1heSBubyBsb25nZXIgYmUgbWVtYmVycyBvZiB0aGUgZ3JvdXAuIiBUaGlzIHNl bnRlbmNlIGlzIHZlcnkNCmNvbmZ1c2luZzogd2hlbiBhcmUgbWVtYmVycyBub3QgbWVtYmVycz8N Cldl4oCZdmUgcmV3b3JkZWQgdGhpcyB0ZXh0LiBJdOKAmXMgdHJ5aW5nIHRvIGNvbnZleSB0aGF0 IGEgbWlzc2luZyBBQ0sgbWVzc2FnZSAob3IgYSBjZXJ0YWluIG51bWJlciBvZiBpdCkgY2FuIGJl IHVzZWQgdG8gaWRlbnRpZnkgdGhhdCBhIGdyb3VwIG1lbWJlciBpcyBubyBsb25nZXIgcmVjZWl2 aW5nIGdyb3VwIHRyYWZmaWMsIGFuZCBpcyBub3cgbWF5IGJlIGNvbnNpZGVyZWQgYW4gZXgtZ3Jv dXAgbWVtYmVyLiBGb3IgZXhhbXBsZSwgaXQgY291bGQgYmUgYSBtdWx0aWNhc3QgcmVjZWl2ZXIg dGhhdCBpcyBubyBsb25nZXIgaW50ZXJlc3RlZCBpbiBiZWluZyBhIHJlY2VpdmVyIGZvciB0aGUg Z3JvdXAuIEJ1dCBpdCBjb3VsZCBhbHNvIGJlIHRoYXQgYSBuZXR3b3JrIGV2ZW50IGhhcyBjYXVz ZWQgaXQgdG8gYmUgdW5hdmFpbGFibGUgZm9yIGEgc3VmZmljaWVudCBsZW5ndGggb2YgdGltZSBz dWNoIHRoYXQgaXQgZG9lc27igJl0IGhhdmUgY3VycmVudCBrZXlpbmcgbWF0ZXJpYWwgYW5kIHRo ZXJlZm9yZSBjYW7igJl0IGJlIGNvbnNpZGVyZWQgYSBjdXJyZW50IGdyb3VwIG1lbWJlci4gVGhl cmUgaXMgbm8gcmVsaWFibGUg4oCcSeKAmW0gbGVhdmluZyB0aGUgZ3JvdXDigJ0gbWVzc2FnZSBm bG93LCBhbmQgb2YgY291cnNlIGluIG15IHNlY29uZCBleGFtcGxlIG5vIHN1Y2ggbWVzc2FnZXMg d291bGQgaGF2ZSBiZWVuIGludGVuZGVkIGJ5IHRoZSBncm91cCBtZW1iZXIuDQoqIFRoZSBuZXcg cHJvdG9jb2wgY2FwYWJpbGl0eSBpcyBkZWZpbmVkIGFzIG9wdGlvbmFsLCBidXQgcmVhbGx5IGlz bid0LiAiQSBHTQ0KcmVjZWl2aW5nIHRoZSBLRUtfQUNLX1JFUVVFU1RFRCBhdHRyaWJ1dGUgY2Fu IGNob29zZSB0byBpZ25vcmUgaXQsIHRodXMNCmFwcGVhcmluZyBhcyBpZiBpdCBkb2VzIG5vdCBz dXBwb3J0IHRoZSBLRUtfQUNLX1JFUVVFU1RFRCBhdHRyaWJ1dGUuIEhvd2V2ZXIsDQpHQ0tTIHBv bGljeSBtYXkgY29uc2lkZXIgYSBub24tcmVzcG9uc2l2ZSBHTSB0byBubyBsb25nZXIgZGVzaXJl IHRvIGJlIGEgbWVtYmVyDQpvZiB0aGUgZ3JvdXAuIiBTbyBpZiB5b3Ugd2FudCB0byBwbGF5IHRo ZSBnYW1lLCB5b3UgTVVTVCBzdXBwb3J0IHRoZSBuZXcNCmF0dHJpYnV0ZS4NClBvaW50IHRha2Vu LiBXZeKAmXZlIGNoYW5nZWQgdGhlIHRleHQgdG8gcmVmbGVjdCB0aGlzLg0KKiBJJ20gcHV6emxl ZCBhdCB0aGUgb3ZlcmFsbCBwcm90b2NvbC4gQmVpbmcgYWJsZSB0byBzZW5kIEFDS3MgaXMgYSBH TSBzb2Z0d2FyZQ0KY2FwYWJpbGl0eS4gV2h5IG5vdCBoYXZlIHRoZSBHTSBhbm5vdW5jZSB0aGlz IGNhcGFiaWxpdHkgd2hlbiBpdCBpbml0aWFsbHkNCnJlZ2lzdGVycyB0byB0aGUgR0NLUz8gVGhl biB0aGUgR0NLUyB3b3VsZCBrbm93IHdoYXQgdG8gZXhwZWN0LCB3aGVyZWFzIHdpdGgNCnRoZSBj dXJyZW50IHByb3RvY29sIGl0IGlzIGxlZnQgd2FpdGluZyBmb3IgYW4gQUNLIHRoYXQgbWF5IG5l dmVyIGNvbWUsIGVpdGhlcg0KYmVjYXVzZSB0aGUgR00gaXMgZGVhZCBvciBiZWNhdXNlIGl0IGp1 c3QgZG9lc24ndCBmZWVsIGxpa2UgcmVzcG9uZGluZy4gQWRkIHRoZQ0KbG9uZyB3YWl0cyAoaml0 dGVyIG9mICJhIGZldyBzZWNvbmRzIiBhbmQgcG90ZW50aWFsIHJldHJpZXMpLCBhbmQgdGhpcyBs b29rcw0KbGlrZSBhIGZhciBmcm9tIG9wdGltYWwgbWFuYWdlbWVudCBleHBlcmllbmNlLg0KSW5k ZWVkIGEgR00gY291bGQgYW5ub3VuY2UgaXRzIGNhcGFiaWxpdHksIGJ1dCB3aGV0aGVyIG9yIG5v dCBBQ0tzIGFyZSBkZXNpcmVkIGlzIGEgY29tcG9uZW50IG9mIHRoZSBncm91cCBwb2xpY3kuIElu IHRoZSBjb250ZXh0IG9mIEdET0kgdGhlIEdDS1MgaXMgdGhlIGVudGl0eSB0aGF0IGRlZmluZXMg dGhlIGdyb3VwIHBvbGljeS4gVGhlcmUgY2FuIGJlIGdyb3VwcyB3aGVyZSB0aGUgQUNLIGlzIHVz ZWQsIHdoZXJlYXMgb3RoZXJzIGRvIG5vdC4gIFRoZSBjYXBhYmlsaXRpZXMgYW5ub3VuY2VtZW50 IHlvdSBzdWdnZXN0IGNvdWxkIGNlcnRhaW5seSBoZWxwIHRoZSBLUyB0byBrbm93IHdoZXRoZXIg b3Igbm90IHRvIGV4cGVjdCB0aGUgQUNLIGZyb20gYSBwYXJ0aWN1bGFyIEdNLCBidXQgdGhlIGZv Y3VzIG9mIHRoaXMgSS1EIGlzIG9uIHRoZSB0aGUgZGVjbGFyYXRpb24gb2YgdGhlIHJlcXVlc3Qg Zm9yIEFDS3MgYnkgdGhlIEdDS1MgYW5kIHRoZSBmb3JtYXQgb2YgdGhlIEFDSy4NCiogMi4yOiAi VGhpcyBpcyBhIHByaXZhdGUga2V5IiAtIHRvIGF2b2lkIGNvbmZ1c2lvbiwgSSBzdWdnZXN0OiAi VGhpcyBpcyBhDQpzZWNyZXQgc3ltbWV0cmljIGtleSIgKGlmIHRoaXMgaXMgaW5kZWVkIHRoZSBj YXNlKS4gT2J2aW91c2x5IHVzaW5nIHRoZSBzYW1lDQprZXkgZm9yIGVuY3J5cHRpb24gYW5kIGZv ciBITUFDIGlzIG5vdCBhIGJlc3QgcHJhY3RpY2UuDQpXZeKAmXZlIG1hZGUgdGhpcyBjaGFuZ2Uu DQoqIFNlYy4gNTogQUNLIG1lc3NhZ2VzIGNhbiBhbHNvIGJlIGR1cGxpY2F0ZWQgaW4gdGhlIG5l dHdvcmsuIEkgc3VnZ2VzdCB0byBhZGQNCmEgc2VudGVuY2UgZGVzY3JpYmluZyB3aGF0IHRoZSBH Q0tTIHNob3VsZCBkbyBpbiB0aGlzIGNhc2UuDQpUaGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMg KHNlY3Rpb24gNy4zKSBkZXNjcmliZXMgYSBtZXRob2QgZm9yIHRoZSBHQ0tTIHRvIGRldGVjdCBy ZXBsYXlzLiBUaGlzIGlzIGFyZ3VhYmx5IGJldHRlciBwbGFjZWQgaW4gdGhpcyBzZWN0aW9uLCBz byB3ZeKAmXZlIG1vdmVkIGl0IGhlcmUuLg0KKiBTZWMuIDY6IEkgYW0gY29uZnVzZWQgYWJvdXQg dGhlIG5vdGlvbiBvZiAiaml0dGVyIiBoZXJlLiBJZiB0aGUgUFVTSCBtZXNzYWdlcw0KYXJlIHNl bnQgYXMgbXVsdGljYXN0ICh0aGUgcmVjb21tZW5kZWQgYWx0ZXJuYXRpdmUgQUZBSUNUKSwgSSdt IG5vdCBzdXJlIGFib3V0DQp0aGUgYmVuZWZpdCBvZiB1c2luZyBtdWx0aWNhc3QsIGdpdmVuIHRo YXQgZWFjaCByZWNpcGllbnQgcmVzcG9uZHMgd2l0aCBhDQp1bmljYXN0IEFDSy4gQW5kIGlmIHRo ZSBQVVNIIGlzIHVuaWNhc3QsIHRoZXJlIHNob3VsZCBiZSBubyByZWFzb24gZm9yIGEgaml0dGVy DQphcyB0aGUgc2VuZGVyIGNhbiB0aHJvdHRsZSB0aGUgUFVTSCBtZXNzYWdlcyBhcyBuZWNlc3Nh cnkuDQpUaGUgY29uY2VwdCBvZiDigJxqaXR0ZXLigJ0gaXMgbW9zdCB2YWx1YWJsZSBmb3IgcmVz cG9uc2VzIHRvIGEgbXVsdGljYXN0IFBVU0ggbWVzc2FnZS4gVGhlIHVzZSBvZiBhIG11bHRpY2Fz dCBQVVNIIG1lc3NhZ2UgbG93ZXIgcHJvY2Vzc2luZyBvbiB0aGUgR0NLUy4gU2luY2UgZWFjaCBH TSBjYW4gZSBnaXZlbiB0aGUgZXhhY3Qgc2FtZSBwb2xpY3ksIHRoZXJl4oCZcyBubyBjYWxsIHRv IHNlbmQgaXQgb3V0IGFzIGEgdW5pY2FzdCBtZXNzYWdlLiBUaGUgaml0dGVyIGhlbHBzIHNwcmVh ZCBvdXQgdGhlIHJlcGxpZXMgYSBiaXQgdG8gYXZvaWQgaW51bmRhdGluZyB0aGUgR0NLUy4NCiog TW9yZW92ZXIsIGV2ZXJ5dGhpbmcgd291bGQgYmUgbXVjaCBtb3JlIHByZWRpY3RhYmxlIGlmIHRo ZSBHQ0tTIGNvdWxkDQppbmRpY2F0ZSBpZiBhIGppdHRlciBpcyBleHBlY3RlZCBhbmQgaG93IG11 Y2ggb2YgYSBqaXR0ZXIgKGJhc2VkIG9uIHNpemUgb2YgdGhlDQpncm91cCwgbmV0d29yayB0aHJv dWdocHV0LCBhbmQgcXVldWUgbGVuZ3RoKS4gU3BlY2lmaWNhbGx5LCB0aGlzIHdvdWxkIGFsbG93 DQp0aGUgR0NLUyB0byB0ZWxsIGhvdyBsb25nIGl0IHNob3VsZCB3YWl0IGZvciBhbiBBQ0suDQpU aGlzIHdvdWxkIGJlIHNvbWV3aGF0IHVzZWZ1bCwgYnV0IGluIHByYWN0aWNlIG1pZ2h0IG5vdCBo ZWxwIHRoZSBHQ0tTIGFzIG11Y2ggYXMgaXQgc2VlbXMuIFRoZSBqaXR0ZXIgdmFsdWUgcHJvdmlk ZWQgd291bGQgYWxzbyBiZSBkZXBlbmRlbnQgb24gc2V2ZXJhbCBuZXR3b3JrIHBhcmFtZXRlcnMg dGhhdCBhcmVu4oCZdCB1bmRlciB0aGUgY29udHJvbCBvZiB0aGUgR0NLUyBvciB0aGUgR00uIEV2 ZW4gd2hlbiB0aGUgR00gZG9lcyBub3QgYWRkIGFueSBqaXR0ZXIgdG8gdGhlIEFDSywgdGhlIHVu ZGVybHlpbmcgbmV0d29yayBtYXkgZGVsYXkgdGhlIFBVU0ggYW5kL29yIGZvciB0aGUgQUNLLiBB bmQgYXMgc3RhdGVkIGluIFNlY3Rpb24gNiwgdGhlIEdDS1MgbWF5IGJlIGNvbmZpZ3VyZWQgd2l0 aCBhZGRpdGlvbmFsIHBvbGljeSBhY3Rpb25zIGxpa2UgcmV0cmFuc21pc3Npb25zIHRvIG92ZXJj b21lIGxvc3QgQUNLcy4gQWx0b2dldGhlciB0byBhZGQgaml0dGVyIHRvIHRoZSBBQ0sgaXMgbm90 IGEgbXVzdCwgaXQgaXMgYSB3YXkgdG8gaGVscCB0aGUgR0NLUyBkZWFsIHdpdGggYSBodWdlIG51 bWJlciBvZiBHTXMuIEluIHByYWN0aWNlLCB3ZeKAmXZlIGZvdW5kIHRoYXQgaGF2aW5nIHRoZSBH TXMgY2hvb3NlIHRoZSBqaXR0ZXIgaGFzIHdvcmtlZCB3ZWxsLCBldmVuIHdoZW4gdGhlIEdNcyBh cmUgZGlmZmVyZW50IGltcGxlbWVudGF0aW9ucy4NCiogQ3J5cHRvZ3JhcGhpYyBhZ2lsaXR5OiB0 aGlzIGRvY3VtZW50IHNwZWNpZmllcyBvbmx5IG9uZSBhbGdvcml0aG0gZm9yIHRoZQ0KSEFTSCB2 YWx1ZSwgYW5kIHNheXMgdGhhdCBpZiBhIG5ldyBhbGdvcml0aG0gaXMgbmVlZGVkLCB0aGVyZSB3 aWxsIGJlIGEgbmV3DQpLRUtfQUNLX1JFUVVFU1RFRCBwYXlsb2FkIGRlZmluZWQuIEhvd2V2ZXIg dG8gbWFrZSBzdXJlIHRoYXQgdGhpcyByZWFsbHkNCiJ3b3JrcyIsIHdlIG5lZWQgdG8gZGVmaW5l IHdoZXRoZXIgbXVsdGlwbGUgc3VjaCBwYXlsb2FkcyBjYW4gYmUgc2VudA0Kc2ltdWx0YW5lb3Vz bHkgKGlmIGUuZy4gc29tZSBHTXMgc3RpbGwgc3VwcG9ydCB0aGUgb2xkIGFsZ29yaXRobSkgYW5k IHdoYXQncw0KdGhlIGV4cGVjdGVkIGJlaGF2aW9yLiBJIHdvdWxkIHN1Z2dlc3QgdG8gZGVmaW5l IGFuIGFkZGl0aW9uYWwgU0hBLTUxMiBwYXlsb2FkDQpqdXN0IHRvIG1ha2UgZm9yIGEgY29uY3Jl dGUgZXhhbXBsZS4NClRoaXMgaXMgYSBnb29kIHN1Z2dlc3Rpb24uIFdl4oCZdmUgYWRkZWQgU0hB LTUxMiB2ZXJzaW9ucyBvZiB0aGUgZXhpc3RpbmcgS0VLX0FDS19SRVFVRVNURUQgdmFsdWVzLg0K U2VlIDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2Vpcy1nZG9pLXJla2V5LWFj ay0wNj4NClRoYW5rcywNCkJyaWFuDQotLQ0KQnJpYW4gV2Vpcw0KU2VjdXJpdHksIENTRywgQ2lz Y28gU3lzdGVtcw0KVGVsZXBob25lOiArMSA0MDggNTI2IDQ3OTYNCkVtYWlsOiBiZXdAY2lzY28u Y29tPG1haWx0bzpiZXdAY2lzY28uY29tPiA8bWFpbHRvOmJld0BjaXNjby5jb20+DQoNCi0tDQpC cmlhbiBXZWlzDQpTZWN1cml0eSwgQ1NHLCBDaXNjbyBTeXN0ZW1zDQpUZWxlcGhvbmU6ICsxIDQw OCA1MjYgNDc5Ng0KRW1haWw6IGJld0BjaXNjby5jb208bWFpbHRvOmJld0BjaXNjby5jb20+DQoN Cg== --_000_DE62366A03774DE19ED0A14E44A7EC05ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <469B0527BDA78C41ADCAA8616269AAD2@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgWWFyb24sDQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+T24gQXVnIDI2LCAyMDE3LCBhdCA4OjM0IEFNLCBZYXJvbiBTaGVm ZmVyICZsdDs8YSBocmVmPSJtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tIiBjbGFzcz0iIj55 YXJvbmYuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBw bGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5I aSBCcmlhbiw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGFuayB5b3UgZm9yIGFkZHJl c3NpbmcgbW9zdCBvZiBteSBjb21tZW50cyBpbiB0aGUgbmV3IHZlcnNpb24sIGFuZCBmb3IgY2xh cmlmeWluZyBwb2ludHMgd2hlcmUgSSB3YXMgb2ZmIHRoZSBtYXJrLjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NClRoZSBvbmx5IHJlbWFpbmluZyBjb21tZW50IHRoYXQncyBvbmx5IHBhcnRs eSBhZGRyZXNzZWQgaXMgdGhlIG9uZSBvbiBjcnlwdG8gYWdpbGl0eS4gUXVvdGluZyBteXNlbGY6 PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0Kd2UgbmVlZCB0byBkZWZpbmUgd2hldGhlciBt dWx0aXBsZSBzdWNoIHBheWxvYWRzIGNhbiBiZSBzZW50IHNpbXVsdGFuZW91c2x5IChpZiBlLmcu IHNvbWUgR01zIHN0aWxsIHN1cHBvcnQgdGhlIG9sZCBhbGdvcml0aG0pIGFuZCB3aGF0J3MgdGhl IGV4cGVjdGVkIGJlaGF2aW9yLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkluIG90aGVy IHdvcmRzLCBzdXBwb3J0aW5nIG1vcmUgYWxnb3JpdGhtcyBpbiBub3Qgc3VmZmljaWVudC4gVGhl IHF1ZXN0aW9uIGlzIHdoZXRoZXIgd2Ugc3VwcG9ydCBpbmNyZW1lbnRhbCBkZXBsb3ltZW50IG9m IGEgbmV3IGFsZ29yaXRobSB0byBhIGxhcmdlIGdyb3VwIG9mIEdNcy48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+U29ycnksIHdlIG1pc3NlZCB0aGlzLiBJbmNyZW1lbnRhbCBkZXBsb3lt ZW50IG9mIGFueSBuZXcgcG9saWN5IChhbGdvcml0aG0gb3Igb3RoZXJ3aXNlKSB3aXRoaW4gYSBn cm91cCBpcyBub3Qgc28gc3RyYWlnaHRmb3J3YXJkLiBUaGVyZSBjYW4gcmVhbGx5IG9ubHkgYmUg b25lIHNldCBvZiBwb2xpY3kgdXNlZCBieSB0aGUgZW50aXJlIGdyb3VwIGJlY2F1c2UgaWYgYSBz ZW5kZXIgaGFzIGJlZW4gdXBkYXRlZCB0byBhIG5ldw0KIHNldCBvZiBwb2xpY3kgaXQgY2Fu4oCZ dCByZWFsbHkgdXNlIGl0IHVudGlsIGFsbCByZWNlaXZlcnMgYXJlIHNpbWlsYXJseSB1cGdyYWRl ZC4gVGhpcyBpcyBhIHBsYWNlIHdoZXJlIGEgY2FwYWJpbGl0aWVzIGV4Y2hhbmdlIGNhbiBiZSB1 c2VmdWwgZm9yIGEga2V5IHNlcnZlciB0byBkZWNsYXJlIGEgc3dpdGNoIHRvIGEgbmV3IGFsZ29y aXRobSBhZnRlciBhbGwgbWVtYmVycyBjbGFpbSB0byBzdXBwb3J0IGl0LCBidXQgdGhhdCBtaWdo dCBuZXZlcg0KIGhhcHBlbiBpbiBhIGxhcmdlIGdyb3VwLiBQcmFjdGljYWxseSBzcGVha2luZyBp bmNyZW1lbnRhbCB1cGRhdGVzIGluIGEgbGFyZ2UgZ3JvdXAgbWlnaHQgcmVxdWlyZSB0d28gZGlm ZmVyZW50IGdyb3VwcyB3aXRoIGEgYnJpZGdlIGJldHdlZW4sIG9yIHNvbWUgb3RoZXIgZGVwbG95 bWVudCBzdHJ1Y3R1cmUuIFNpbmNlIGl04oCZcyBhIGJyb2FkZXIgcHJvYmxlbSwgSeKAmW0gbm90 IHN1cmUgd2hhdCBlbHNlIHdlIGNhbiBkbyBpbiB0aGlzIGRvY3VtZW50DQogdG8gYWRkcmVzcyBp bmNyZW1lbnRhbCBkZXBsb3ltZW50LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhhbmtzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Ccmlh bjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQpUaGFua3MsPGJy IGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3Bh Y2U6IHByZTsiPjwvc3Bhbj5ZYXJvbjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk9uIDI0 LzA4LzE3IDE5OjQ4LCBCcmlhbiBXZWlzIChiZXcpIHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPkhpIFlhcm9uLDxiciBjbGFzcz0iIj4NClRoYW5r cyBmb3IgdGhlIHJldmlldy4gV2XigJl2ZSBhZGRlZCBzb21lIGNsYXJpZmljYXRpb24gYmVsb3cs IGFuZCBtYWRlIHNvbWUgY2hhbmdlcyBpbiAtMDYgdG8gYWRkcmVzcyB5b3VyIGNvbW1lbnRzLiBQ bGVhc2UgbGV0IHVzIGtub3cgaWYgd2UgZGlkIG5vdCBhZGRyZXNzIHRoZW0gc2F0aXNmYWN0b3Jp bHkuPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+T24gQXVn IDUsIDIwMTcsIGF0IDg6NDkgQU0sIFlhcm9uIFNoZWZmZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp5 YXJvbmYuaWV0ZkBnbWFpbC5jb20iIGNsYXNzPSIiPnlhcm9uZi5pZXRmQGdtYWlsLmNvbTwvYT4m bmJzcDsmbHQ7PGEgaHJlZj0ibWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbSIgY2xhc3M9IiI+ bWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpSZXZpZXdlcjogWWFyb24gU2hlZmZlcjxiciBjbGFzcz0iIj4N ClJldmlldyByZXN1bHQ6IEhhcyBJc3N1ZXM8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpT dW1tYXJ5OiB0aGlzIHJldmlld2VyIGlzIG5vdCBjbGVhciBhYm91dCB0aGUgdmFsdWUgb2YgdGhl IHB1c2gtYWNrIChjb21wYXJlZDxiciBjbGFzcz0iIj4NCnRvIGEgcHVsbCkgYW5kIGFib3V0IHRo ZSBzdHJhdGVneSB0aGF0IHdhcyBjaG9zZW4uPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0K SW4gYSBncm91cCBrZXkgbWFuYWdlbWVudCBzeXN0ZW0gZWl0aGVyIGEg4oCccHVsbOKAnSAodHJp Z2dlcmVkIGJ5IGEgZ3JvdXAgbWVtYmVyKSBvciBhIOKAnHB1c2jigJ0gKGJ5IHRoZSBrZXkgc2Vy dmVyKSZxdW90OyBjb3VsZCBiZSB1c2VkIHRvIHByb3ZpZGUgdXBkYXRlcyB0byB0aGUgZ3JvdXAu IEhvd2V2ZXIsIGEg4oCccHVsbOKAnSBieSB0aGUgZ3JvdXAgbWVtYmVyIGltcGxpZXMgYSBwb2xs aW5nIG1ldGhvZCwgd2hpY2ggaGFzIHRoZSBkZWZpY2llbmN5IHRoYXQgdGhlDQoga2V5IHNlcnZl ciBjYW5ub3QgY2F1c2UgYSBwb2xpY3kgcmVwbGFjZW1lbnQgYW55IHNvb25lciB0aGFuIHRoZSBw b2xsaW5nIG1ldGhvZCBieSB0aGUgZ3JvdXAgbWVtYmVycy4gQWxzbyDigJxwb2xsaW5n4oCdIGNh biBjYXVzZSBhZGRpdGlvbmFsIHVubmVjZXNzYXJ5IHRyYWZmaWMuIFNvIGlzIGlzIGJldHRlciBm b3IgYW55IHVwZGF0ZSBvbiB0aGUgZ3JvdXAgcG9saWN5IG9yIHJlbmV3YWwgb2YgZ3JvdXAga2V5 cyB0byBiZSBkaXN0cmlidXRlZCBieQ0KIHRoZSBHQ0tTIHVzaW5nIGEgUFVTSCBtZXNzYWdlLiBU aGUgQUNLLW1lc3NhZ2UgaXMgdXNlZCB0byBvZmZlciBhIGZlZWRiYWNrIG1lY2hhbmlzbSB0byBh IHBvbGljeSB1cGRhdGUgZm9yIHRoZSBQVVNIIGV4Y2hhbmdlLjxiciBjbGFzcz0iIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCiovLyo8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQoqICZxdW90O0ZvciBleGFtcGxlLCBhIEdDS1MgcG9saWN5IGNh biB1c2UgdGhlIGFja25vd2xlZGdlbWVudHMgdG8gZGV0ZXJtaW5lIFsuLi5dPGJyIGNsYXNzPSIi Pg0Kd2hpY2ggbWVtYmVycyBtYXkgbm8gbG9uZ2VyIGJlIG1lbWJlcnMgb2YgdGhlIGdyb3VwLiZx dW90OyBUaGlzIHNlbnRlbmNlIGlzIHZlcnk8YnIgY2xhc3M9IiI+DQpjb25mdXNpbmc6IHdoZW4g YXJlIG1lbWJlcnMgbm90IG1lbWJlcnM/PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KV2Xi gJl2ZSByZXdvcmRlZCB0aGlzIHRleHQuIEl04oCZcyB0cnlpbmcgdG8gY29udmV5IHRoYXQgYSBt aXNzaW5nIEFDSyBtZXNzYWdlIChvciBhIGNlcnRhaW4gbnVtYmVyIG9mIGl0KSBjYW4gYmUgdXNl ZCB0byBpZGVudGlmeSB0aGF0IGEgZ3JvdXAgbWVtYmVyIGlzIG5vIGxvbmdlciByZWNlaXZpbmcg Z3JvdXAgdHJhZmZpYywgYW5kIGlzIG5vdyBtYXkgYmUgY29uc2lkZXJlZCBhbiBleC1ncm91cCBt ZW1iZXIuIEZvciBleGFtcGxlLCBpdCBjb3VsZCBiZQ0KIGEgbXVsdGljYXN0IHJlY2VpdmVyIHRo YXQgaXMgbm8gbG9uZ2VyIGludGVyZXN0ZWQgaW4gYmVpbmcgYSByZWNlaXZlciBmb3IgdGhlIGdy b3VwLiBCdXQgaXQgY291bGQgYWxzbyBiZSB0aGF0IGEgbmV0d29yayBldmVudCBoYXMgY2F1c2Vk IGl0IHRvIGJlIHVuYXZhaWxhYmxlIGZvciBhIHN1ZmZpY2llbnQgbGVuZ3RoIG9mIHRpbWUgc3Vj aCB0aGF0IGl0IGRvZXNu4oCZdCBoYXZlIGN1cnJlbnQga2V5aW5nIG1hdGVyaWFsIGFuZCB0aGVy ZWZvcmUgY2Fu4oCZdA0KIGJlIGNvbnNpZGVyZWQgYSBjdXJyZW50IGdyb3VwIG1lbWJlci4gVGhl cmUgaXMgbm8gcmVsaWFibGUg4oCcSeKAmW0gbGVhdmluZyB0aGUgZ3JvdXDigJ0gbWVzc2FnZSBm bG93LCBhbmQgb2YgY291cnNlIGluIG15IHNlY29uZCBleGFtcGxlIG5vIHN1Y2ggbWVzc2FnZXMg d291bGQgaGF2ZSBiZWVuIGludGVuZGVkIGJ5IHRoZSBncm91cCBtZW1iZXIuPGJyIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+KiBUaGUgbmV3IHByb3RvY29sIGNh cGFiaWxpdHkgaXMgZGVmaW5lZCBhcyBvcHRpb25hbCwgYnV0IHJlYWxseSBpc24ndC4gJnF1b3Q7 QSBHTTxiciBjbGFzcz0iIj4NCnJlY2VpdmluZyB0aGUgS0VLX0FDS19SRVFVRVNURUQgYXR0cmli dXRlIGNhbiBjaG9vc2UgdG8gaWdub3JlIGl0LCB0aHVzPGJyIGNsYXNzPSIiPg0KYXBwZWFyaW5n IGFzIGlmIGl0IGRvZXMgbm90IHN1cHBvcnQgdGhlIEtFS19BQ0tfUkVRVUVTVEVEIGF0dHJpYnV0 ZS4gSG93ZXZlciw8YnIgY2xhc3M9IiI+DQpHQ0tTIHBvbGljeSBtYXkgY29uc2lkZXIgYSBub24t cmVzcG9uc2l2ZSBHTSB0byBubyBsb25nZXIgZGVzaXJlIHRvIGJlIGEgbWVtYmVyPGJyIGNsYXNz PSIiPg0Kb2YgdGhlIGdyb3VwLiZxdW90OyBTbyBpZiB5b3Ugd2FudCB0byBwbGF5IHRoZSBnYW1l LCB5b3UgTVVTVCBzdXBwb3J0IHRoZSBuZXc8YnIgY2xhc3M9IiI+DQphdHRyaWJ1dGUuPGJyIGNs YXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KUG9pbnQgdGFrZW4uIFdl4oCZdmUgY2hhbmdlZCB0aGUg dGV4dCB0byByZWZsZWN0IHRoaXMuPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSIgY2xhc3M9IiI+KiBJJ20gcHV6emxlZCBhdCB0aGUgb3ZlcmFsbCBwcm90b2NvbC4gQmVpbmcg YWJsZSB0byBzZW5kIEFDS3MgaXMgYSBHTSBzb2Z0d2FyZTxiciBjbGFzcz0iIj4NCmNhcGFiaWxp dHkuIFdoeSBub3QgaGF2ZSB0aGUgR00gYW5ub3VuY2UgdGhpcyBjYXBhYmlsaXR5IHdoZW4gaXQg aW5pdGlhbGx5PGJyIGNsYXNzPSIiPg0KcmVnaXN0ZXJzIHRvIHRoZSBHQ0tTPyBUaGVuIHRoZSBH Q0tTIHdvdWxkIGtub3cgd2hhdCB0byBleHBlY3QsIHdoZXJlYXMgd2l0aDxiciBjbGFzcz0iIj4N CnRoZSBjdXJyZW50IHByb3RvY29sIGl0IGlzIGxlZnQgd2FpdGluZyBmb3IgYW4gQUNLIHRoYXQg bWF5IG5ldmVyIGNvbWUsIGVpdGhlcjxiciBjbGFzcz0iIj4NCmJlY2F1c2UgdGhlIEdNIGlzIGRl YWQgb3IgYmVjYXVzZSBpdCBqdXN0IGRvZXNuJ3QgZmVlbCBsaWtlIHJlc3BvbmRpbmcuIEFkZCB0 aGU8YnIgY2xhc3M9IiI+DQpsb25nIHdhaXRzIChqaXR0ZXIgb2YgJnF1b3Q7YSBmZXcgc2Vjb25k cyZxdW90OyBhbmQgcG90ZW50aWFsIHJldHJpZXMpLCBhbmQgdGhpcyBsb29rczxiciBjbGFzcz0i Ij4NCmxpa2UgYSBmYXIgZnJvbSBvcHRpbWFsIG1hbmFnZW1lbnQgZXhwZXJpZW5jZS48YnIgY2xh c3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQpJbmRlZWQgYSBHTSBjb3VsZCBhbm5vdW5jZSBpdHMgY2Fw YWJpbGl0eSwgYnV0IHdoZXRoZXIgb3Igbm90IEFDS3MgYXJlIGRlc2lyZWQgaXMgYSBjb21wb25l bnQgb2YgdGhlIGdyb3VwIHBvbGljeS4gSW4gdGhlIGNvbnRleHQgb2YgR0RPSSB0aGUgR0NLUyBp cyB0aGUgZW50aXR5IHRoYXQgZGVmaW5lcyB0aGUgZ3JvdXAgcG9saWN5LiBUaGVyZSBjYW4gYmUg Z3JvdXBzIHdoZXJlIHRoZSBBQ0sgaXMgdXNlZCwgd2hlcmVhcyBvdGhlcnMgZG8gbm90Lg0KICZu YnNwO1RoZSBjYXBhYmlsaXRpZXMgYW5ub3VuY2VtZW50IHlvdSBzdWdnZXN0IGNvdWxkIGNlcnRh aW5seSBoZWxwIHRoZSBLUyB0byBrbm93IHdoZXRoZXIgb3Igbm90IHRvIGV4cGVjdCB0aGUgQUNL IGZyb20gYSBwYXJ0aWN1bGFyIEdNLCBidXQgdGhlIGZvY3VzIG9mIHRoaXMgSS1EIGlzIG9uIHRo ZSB0aGUgZGVjbGFyYXRpb24gb2YgdGhlIHJlcXVlc3QgZm9yIEFDS3MgYnkgdGhlIEdDS1MgYW5k IHRoZSBmb3JtYXQgb2YgdGhlIEFDSy48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIiBjbGFzcz0iIj4qIDIuMjogJnF1b3Q7VGhpcyBpcyBhIHByaXZhdGUga2V5JnF1b3Q7IC0g dG8gYXZvaWQgY29uZnVzaW9uLCBJIHN1Z2dlc3Q6ICZxdW90O1RoaXMgaXMgYTxiciBjbGFzcz0i Ij4NCnNlY3JldCBzeW1tZXRyaWMga2V5JnF1b3Q7IChpZiB0aGlzIGlzIGluZGVlZCB0aGUgY2Fz ZSkuIE9idmlvdXNseSB1c2luZyB0aGUgc2FtZTxiciBjbGFzcz0iIj4NCmtleSBmb3IgZW5jcnlw dGlvbiBhbmQgZm9yIEhNQUMgaXMgbm90IGEgYmVzdCBwcmFjdGljZS48YnIgY2xhc3M9IiI+DQo8 L2Jsb2NrcXVvdGU+DQpXZeKAmXZlIG1hZGUgdGhpcyBjaGFuZ2UuPGJyIGNsYXNzPSIiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+KiBTZWMuIDU6IEFDSyBtZXNzYWdlcyBjYW4g YWxzbyBiZSBkdXBsaWNhdGVkIGluIHRoZSBuZXR3b3JrLiBJIHN1Z2dlc3QgdG8gYWRkPGJyIGNs YXNzPSIiPg0KYSBzZW50ZW5jZSBkZXNjcmliaW5nIHdoYXQgdGhlIEdDS1Mgc2hvdWxkIGRvIGlu IHRoaXMgY2FzZS48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQpUaGUgU2VjdXJpdHkgQ29u c2lkZXJhdGlvbnMgKHNlY3Rpb24gNy4zKSBkZXNjcmliZXMgYSBtZXRob2QgZm9yIHRoZSBHQ0tT IHRvIGRldGVjdCByZXBsYXlzLiBUaGlzIGlzIGFyZ3VhYmx5IGJldHRlciBwbGFjZWQgaW4gdGhp cyBzZWN0aW9uLCBzbyB3ZeKAmXZlIG1vdmVkIGl0IGhlcmUuLjxiciBjbGFzcz0iIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPiogU2VjLiA2OiBJIGFtIGNvbmZ1c2VkIGFib3V0 IHRoZSBub3Rpb24gb2YgJnF1b3Q7aml0dGVyJnF1b3Q7IGhlcmUuIElmIHRoZSBQVVNIIG1lc3Nh Z2VzPGJyIGNsYXNzPSIiPg0KYXJlIHNlbnQgYXMgbXVsdGljYXN0ICh0aGUgcmVjb21tZW5kZWQg YWx0ZXJuYXRpdmUgQUZBSUNUKSwgSSdtIG5vdCBzdXJlIGFib3V0PGJyIGNsYXNzPSIiPg0KdGhl IGJlbmVmaXQgb2YgdXNpbmcgbXVsdGljYXN0LCBnaXZlbiB0aGF0IGVhY2ggcmVjaXBpZW50IHJl c3BvbmRzIHdpdGggYTxiciBjbGFzcz0iIj4NCnVuaWNhc3QgQUNLLiBBbmQgaWYgdGhlIFBVU0gg aXMgdW5pY2FzdCwgdGhlcmUgc2hvdWxkIGJlIG5vIHJlYXNvbiBmb3IgYSBqaXR0ZXI8YnIgY2xh c3M9IiI+DQphcyB0aGUgc2VuZGVyIGNhbiB0aHJvdHRsZSB0aGUgUFVTSCBtZXNzYWdlcyBhcyBu ZWNlc3NhcnkuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KVGhlIGNvbmNlcHQgb2Yg4oCc aml0dGVy4oCdIGlzIG1vc3QgdmFsdWFibGUgZm9yIHJlc3BvbnNlcyB0byBhIG11bHRpY2FzdCBQ VVNIIG1lc3NhZ2UuIFRoZSB1c2Ugb2YgYSBtdWx0aWNhc3QgUFVTSCBtZXNzYWdlIGxvd2VyIHBy b2Nlc3Npbmcgb24gdGhlIEdDS1MuIFNpbmNlIGVhY2ggR00gY2FuIGUgZ2l2ZW4gdGhlIGV4YWN0 IHNhbWUgcG9saWN5LCB0aGVyZeKAmXMgbm8gY2FsbCB0byBzZW5kIGl0IG91dCBhcyBhIHVuaWNh c3QgbWVzc2FnZS4gVGhlIGppdHRlcg0KIGhlbHBzIHNwcmVhZCBvdXQgdGhlIHJlcGxpZXMgYSBi aXQgdG8gYXZvaWQgaW51bmRhdGluZyB0aGUgR0NLUy48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4qIE1vcmVvdmVyLCBldmVyeXRoaW5nIHdvdWxkIGJlIG11 Y2ggbW9yZSBwcmVkaWN0YWJsZSBpZiB0aGUgR0NLUyBjb3VsZDxiciBjbGFzcz0iIj4NCmluZGlj YXRlIGlmIGEgaml0dGVyIGlzIGV4cGVjdGVkIGFuZCBob3cgbXVjaCBvZiBhIGppdHRlciAoYmFz ZWQgb24gc2l6ZSBvZiB0aGU8YnIgY2xhc3M9IiI+DQpncm91cCwgbmV0d29yayB0aHJvdWdocHV0 LCBhbmQgcXVldWUgbGVuZ3RoKS4gU3BlY2lmaWNhbGx5LCB0aGlzIHdvdWxkIGFsbG93PGJyIGNs YXNzPSIiPg0KdGhlIEdDS1MgdG8gdGVsbCBob3cgbG9uZyBpdCBzaG91bGQgd2FpdCBmb3IgYW4g QUNLLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NClRoaXMgd291bGQgYmUgc29tZXdoYXQg dXNlZnVsLCBidXQgaW4gcHJhY3RpY2UgbWlnaHQgbm90IGhlbHAgdGhlIEdDS1MgYXMgbXVjaCBh cyBpdCBzZWVtcy4gVGhlIGppdHRlciB2YWx1ZSBwcm92aWRlZCB3b3VsZCBhbHNvIGJlIGRlcGVu ZGVudCBvbiBzZXZlcmFsIG5ldHdvcmsgcGFyYW1ldGVycyB0aGF0IGFyZW7igJl0IHVuZGVyIHRo ZSBjb250cm9sIG9mIHRoZSBHQ0tTIG9yIHRoZSBHTS4gRXZlbiB3aGVuIHRoZSBHTSBkb2VzIG5v dCBhZGQgYW55DQogaml0dGVyIHRvIHRoZSBBQ0ssIHRoZSB1bmRlcmx5aW5nIG5ldHdvcmsgbWF5 IGRlbGF5IHRoZSBQVVNIIGFuZC9vciBmb3IgdGhlIEFDSy4gQW5kIGFzIHN0YXRlZCBpbiBTZWN0 aW9uIDYsIHRoZSBHQ0tTIG1heSBiZSBjb25maWd1cmVkIHdpdGggYWRkaXRpb25hbCBwb2xpY3kg YWN0aW9ucyBsaWtlIHJldHJhbnNtaXNzaW9ucyB0byBvdmVyY29tZSBsb3N0IEFDS3MuIEFsdG9n ZXRoZXIgdG8gYWRkIGppdHRlciB0byB0aGUgQUNLIGlzIG5vdCBhDQogbXVzdCwgaXQgaXMgYSB3 YXkgdG8gaGVscCB0aGUgR0NLUyBkZWFsIHdpdGggYSBodWdlIG51bWJlciBvZiBHTXMuIEluIHBy YWN0aWNlLCB3ZeKAmXZlIGZvdW5kIHRoYXQgaGF2aW5nIHRoZSBHTXMgY2hvb3NlIHRoZSBqaXR0 ZXIgaGFzIHdvcmtlZCB3ZWxsLCBldmVuIHdoZW4gdGhlIEdNcyBhcmUgZGlmZmVyZW50IGltcGxl bWVudGF0aW9ucy48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij4qIENyeXB0b2dyYXBoaWMgYWdpbGl0eTogdGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgb25seSBv bmUgYWxnb3JpdGhtIGZvciB0aGU8YnIgY2xhc3M9IiI+DQpIQVNIIHZhbHVlLCBhbmQgc2F5cyB0 aGF0IGlmIGEgbmV3IGFsZ29yaXRobSBpcyBuZWVkZWQsIHRoZXJlIHdpbGwgYmUgYSBuZXc8YnIg Y2xhc3M9IiI+DQpLRUtfQUNLX1JFUVVFU1RFRCBwYXlsb2FkIGRlZmluZWQuIEhvd2V2ZXIgdG8g bWFrZSBzdXJlIHRoYXQgdGhpcyByZWFsbHk8YnIgY2xhc3M9IiI+DQomcXVvdDt3b3JrcyZxdW90 Oywgd2UgbmVlZCB0byBkZWZpbmUgd2hldGhlciBtdWx0aXBsZSBzdWNoIHBheWxvYWRzIGNhbiBi ZSBzZW50PGJyIGNsYXNzPSIiPg0Kc2ltdWx0YW5lb3VzbHkgKGlmIGUuZy4gc29tZSBHTXMgc3Rp bGwgc3VwcG9ydCB0aGUgb2xkIGFsZ29yaXRobSkgYW5kIHdoYXQnczxiciBjbGFzcz0iIj4NCnRo ZSBleHBlY3RlZCBiZWhhdmlvci4gSSB3b3VsZCBzdWdnZXN0IHRvIGRlZmluZSBhbiBhZGRpdGlv bmFsIFNIQS01MTIgcGF5bG9hZDxiciBjbGFzcz0iIj4NCmp1c3QgdG8gbWFrZSBmb3IgYSBjb25j cmV0ZSBleGFtcGxlLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NClRoaXMgaXMgYSBnb29k IHN1Z2dlc3Rpb24uIFdl4oCZdmUgYWRkZWQgU0hBLTUxMiB2ZXJzaW9ucyBvZiB0aGUgZXhpc3Rp bmcgS0VLX0FDS19SRVFVRVNURUQgdmFsdWVzLjxiciBjbGFzcz0iIj4NClNlZSAmbHQ7PGEgaHJl Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdlaXMtZ2RvaS1yZWtleS1hY2st MDYiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13ZWlzLWdkb2kt cmVrZXktYWNrLTA2PC9hPiZndDs8YnIgY2xhc3M9IiI+DQpUaGFua3MsPGJyIGNsYXNzPSIiPg0K QnJpYW48YnIgY2xhc3M9IiI+DQotLSZuYnNwOzxiciBjbGFzcz0iIj4NCkJyaWFuIFdlaXM8YnIg Y2xhc3M9IiI+DQpTZWN1cml0eSwgQ1NHLCBDaXNjbyBTeXN0ZW1zPGJyIGNsYXNzPSIiPg0KVGVs ZXBob25lOiAmIzQzOzEgNDA4IDUyNiA0Nzk2PGJyIGNsYXNzPSIiPg0KRW1haWw6Jm5ic3A7PGEg aHJlZj0ibWFpbHRvOmJld0BjaXNjby5jb20iIGNsYXNzPSIiPmJld0BjaXNjby5jb208L2E+Jm5i c3A7Jmx0OzxhIGhyZWY9Im1haWx0bzpiZXdAY2lzY28uY29tIiBjbGFzcz0iIj5tYWlsdG86YmV3 QGNpc2NvLmNvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KVGhhbmtzLDxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3Bh biIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPllhcm9uPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KT24gMjQvMDgvMTcgMTk6NDgsIEJyaWFuIFdlaXMgKGJldykgd3JvdGU6PGJy IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+SGkgWWFyb24sPGJy IGNsYXNzPSIiPg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3LiBXZeKAmXZlIGFkZGVkIHNvbWUgY2xh cmlmaWNhdGlvbiBiZWxvdywgYW5kIG1hZGUgc29tZSBjaGFuZ2VzIGluIC0wNiB0byBhZGRyZXNz IHlvdXIgY29tbWVudHMuIFBsZWFzZSBsZXQgdXMga25vdyBpZiB3ZSBkaWQgbm90IGFkZHJlc3Mg dGhlbSBzYXRpc2ZhY3RvcmlseS48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjbGFzcz0iIj5PbiBBdWcgNSwgMjAxNywgYXQgODo0OSBBTSwgWWFyb24gU2hlZmZlciAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbSIgY2xhc3M9IiI+eWFyb25mLmll dGZAZ21haWwuY29tPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNv bSIgY2xhc3M9IiI+bWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90 ZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpSZXZpZXdlcjogWWFyb24gU2hlZmZlcjxi ciBjbGFzcz0iIj4NClJldmlldyByZXN1bHQ6IEhhcyBJc3N1ZXM8YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpTdW1tYXJ5OiB0aGlzIHJldmlld2VyIGlzIG5vdCBjbGVhciBhYm91dCB0aGUg dmFsdWUgb2YgdGhlIHB1c2gtYWNrIChjb21wYXJlZDxiciBjbGFzcz0iIj4NCnRvIGEgcHVsbCkg YW5kIGFib3V0IHRoZSBzdHJhdGVneSB0aGF0IHdhcyBjaG9zZW4uPGJyIGNsYXNzPSIiPg0KPC9i bG9ja3F1b3RlPg0KSW4gYSBncm91cCBrZXkgbWFuYWdlbWVudCBzeXN0ZW0gZWl0aGVyIGEg4oCc cHVsbOKAnSAodHJpZ2dlcmVkIGJ5IGEgZ3JvdXAgbWVtYmVyKSBvciBhIOKAnHB1c2jigJ0gKGJ5 IHRoZSBrZXkgc2VydmVyKSZxdW90OyBjb3VsZCBiZSB1c2VkIHRvIHByb3ZpZGUgdXBkYXRlcyB0 byB0aGUgZ3JvdXAuIEhvd2V2ZXIsIGEg4oCccHVsbOKAnSBieSB0aGUgZ3JvdXAgbWVtYmVyIGlt cGxpZXMgYSBwb2xsaW5nIG1ldGhvZCwgd2hpY2ggaGFzIHRoZSBkZWZpY2llbmN5IHRoYXQgdGhl DQoga2V5IHNlcnZlciBjYW5ub3QgY2F1c2UgYSBwb2xpY3kgcmVwbGFjZW1lbnQgYW55IHNvb25l ciB0aGFuIHRoZSBwb2xsaW5nIG1ldGhvZCBieSB0aGUgZ3JvdXAgbWVtYmVycy4gQWxzbyDigJxw b2xsaW5n4oCdIGNhbiBjYXVzZSBhZGRpdGlvbmFsIHVubmVjZXNzYXJ5IHRyYWZmaWMuIFNvIGlz IGlzIGJldHRlciBmb3IgYW55IHVwZGF0ZSBvbiB0aGUgZ3JvdXAgcG9saWN5IG9yIHJlbmV3YWwg b2YgZ3JvdXAga2V5cyB0byBiZSBkaXN0cmlidXRlZCBieQ0KIHRoZSBHQ0tTIHVzaW5nIGEgUFVT SCBtZXNzYWdlLiBUaGUgQUNLLW1lc3NhZ2UgaXMgdXNlZCB0byBvZmZlciBhIGZlZWRiYWNrIG1l Y2hhbmlzbSB0byBhIHBvbGljeSB1cGRhdGUgZm9yIHRoZSBQVVNIIGV4Y2hhbmdlLjxiciBjbGFz cz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCiov Lyo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQoqICZxdW90O0ZvciBleGFtcGxlLCBhIEdD S1MgcG9saWN5IGNhbiB1c2UgdGhlIGFja25vd2xlZGdlbWVudHMgdG8gZGV0ZXJtaW5lIFsuLi5d PGJyIGNsYXNzPSIiPg0Kd2hpY2ggbWVtYmVycyBtYXkgbm8gbG9uZ2VyIGJlIG1lbWJlcnMgb2Yg dGhlIGdyb3VwLiZxdW90OyBUaGlzIHNlbnRlbmNlIGlzIHZlcnk8YnIgY2xhc3M9IiI+DQpjb25m dXNpbmc6IHdoZW4gYXJlIG1lbWJlcnMgbm90IG1lbWJlcnM/PGJyIGNsYXNzPSIiPg0KPC9ibG9j a3F1b3RlPg0KV2XigJl2ZSByZXdvcmRlZCB0aGlzIHRleHQuIEl04oCZcyB0cnlpbmcgdG8gY29u dmV5IHRoYXQgYSBtaXNzaW5nIEFDSyBtZXNzYWdlIChvciBhIGNlcnRhaW4gbnVtYmVyIG9mIGl0 KSBjYW4gYmUgdXNlZCB0byBpZGVudGlmeSB0aGF0IGEgZ3JvdXAgbWVtYmVyIGlzIG5vIGxvbmdl ciByZWNlaXZpbmcgZ3JvdXAgdHJhZmZpYywgYW5kIGlzIG5vdyBtYXkgYmUgY29uc2lkZXJlZCBh biBleC1ncm91cCBtZW1iZXIuIEZvciBleGFtcGxlLCBpdCBjb3VsZCBiZQ0KIGEgbXVsdGljYXN0 IHJlY2VpdmVyIHRoYXQgaXMgbm8gbG9uZ2VyIGludGVyZXN0ZWQgaW4gYmVpbmcgYSByZWNlaXZl ciBmb3IgdGhlIGdyb3VwLiBCdXQgaXQgY291bGQgYWxzbyBiZSB0aGF0IGEgbmV0d29yayBldmVu dCBoYXMgY2F1c2VkIGl0IHRvIGJlIHVuYXZhaWxhYmxlIGZvciBhIHN1ZmZpY2llbnQgbGVuZ3Ro IG9mIHRpbWUgc3VjaCB0aGF0IGl0IGRvZXNu4oCZdCBoYXZlIGN1cnJlbnQga2V5aW5nIG1hdGVy aWFsIGFuZCB0aGVyZWZvcmUgY2Fu4oCZdA0KIGJlIGNvbnNpZGVyZWQgYSBjdXJyZW50IGdyb3Vw IG1lbWJlci4gVGhlcmUgaXMgbm8gcmVsaWFibGUg4oCcSeKAmW0gbGVhdmluZyB0aGUgZ3JvdXDi gJ0gbWVzc2FnZSBmbG93LCBhbmQgb2YgY291cnNlIGluIG15IHNlY29uZCBleGFtcGxlIG5vIHN1 Y2ggbWVzc2FnZXMgd291bGQgaGF2ZSBiZWVuIGludGVuZGVkIGJ5IHRoZSBncm91cCBtZW1iZXIu PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+KiBUaGUgbmV3 IHByb3RvY29sIGNhcGFiaWxpdHkgaXMgZGVmaW5lZCBhcyBvcHRpb25hbCwgYnV0IHJlYWxseSBp c24ndC4gJnF1b3Q7QSBHTTxiciBjbGFzcz0iIj4NCnJlY2VpdmluZyB0aGUgS0VLX0FDS19SRVFV RVNURUQgYXR0cmlidXRlIGNhbiBjaG9vc2UgdG8gaWdub3JlIGl0LCB0aHVzPGJyIGNsYXNzPSIi Pg0KYXBwZWFyaW5nIGFzIGlmIGl0IGRvZXMgbm90IHN1cHBvcnQgdGhlIEtFS19BQ0tfUkVRVUVT VEVEIGF0dHJpYnV0ZS4gSG93ZXZlciw8YnIgY2xhc3M9IiI+DQpHQ0tTIHBvbGljeSBtYXkgY29u c2lkZXIgYSBub24tcmVzcG9uc2l2ZSBHTSB0byBubyBsb25nZXIgZGVzaXJlIHRvIGJlIGEgbWVt YmVyPGJyIGNsYXNzPSIiPg0Kb2YgdGhlIGdyb3VwLiZxdW90OyBTbyBpZiB5b3Ugd2FudCB0byBw bGF5IHRoZSBnYW1lLCB5b3UgTVVTVCBzdXBwb3J0IHRoZSBuZXc8YnIgY2xhc3M9IiI+DQphdHRy aWJ1dGUuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KUG9pbnQgdGFrZW4uIFdl4oCZdmUg Y2hhbmdlZCB0aGUgdGV4dCB0byByZWZsZWN0IHRoaXMuPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+KiBJJ20gcHV6emxlZCBhdCB0aGUgb3ZlcmFsbCBwcm90 b2NvbC4gQmVpbmcgYWJsZSB0byBzZW5kIEFDS3MgaXMgYSBHTSBzb2Z0d2FyZTxiciBjbGFzcz0i Ij4NCmNhcGFiaWxpdHkuIFdoeSBub3QgaGF2ZSB0aGUgR00gYW5ub3VuY2UgdGhpcyBjYXBhYmls aXR5IHdoZW4gaXQgaW5pdGlhbGx5PGJyIGNsYXNzPSIiPg0KcmVnaXN0ZXJzIHRvIHRoZSBHQ0tT PyBUaGVuIHRoZSBHQ0tTIHdvdWxkIGtub3cgd2hhdCB0byBleHBlY3QsIHdoZXJlYXMgd2l0aDxi ciBjbGFzcz0iIj4NCnRoZSBjdXJyZW50IHByb3RvY29sIGl0IGlzIGxlZnQgd2FpdGluZyBmb3Ig YW4gQUNLIHRoYXQgbWF5IG5ldmVyIGNvbWUsIGVpdGhlcjxiciBjbGFzcz0iIj4NCmJlY2F1c2Ug dGhlIEdNIGlzIGRlYWQgb3IgYmVjYXVzZSBpdCBqdXN0IGRvZXNuJ3QgZmVlbCBsaWtlIHJlc3Bv bmRpbmcuIEFkZCB0aGU8YnIgY2xhc3M9IiI+DQpsb25nIHdhaXRzIChqaXR0ZXIgb2YgJnF1b3Q7 YSBmZXcgc2Vjb25kcyZxdW90OyBhbmQgcG90ZW50aWFsIHJldHJpZXMpLCBhbmQgdGhpcyBsb29r czxiciBjbGFzcz0iIj4NCmxpa2UgYSBmYXIgZnJvbSBvcHRpbWFsIG1hbmFnZW1lbnQgZXhwZXJp ZW5jZS48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQpJbmRlZWQgYSBHTSBjb3VsZCBhbm5v dW5jZSBpdHMgY2FwYWJpbGl0eSwgYnV0IHdoZXRoZXIgb3Igbm90IEFDS3MgYXJlIGRlc2lyZWQg aXMgYSBjb21wb25lbnQgb2YgdGhlIGdyb3VwIHBvbGljeS4gSW4gdGhlIGNvbnRleHQgb2YgR0RP SSB0aGUgR0NLUyBpcyB0aGUgZW50aXR5IHRoYXQgZGVmaW5lcyB0aGUgZ3JvdXAgcG9saWN5LiBU aGVyZSBjYW4gYmUgZ3JvdXBzIHdoZXJlIHRoZSBBQ0sgaXMgdXNlZCwgd2hlcmVhcyBvdGhlcnMg ZG8gbm90Lg0KICZuYnNwO1RoZSBjYXBhYmlsaXRpZXMgYW5ub3VuY2VtZW50IHlvdSBzdWdnZXN0 IGNvdWxkIGNlcnRhaW5seSBoZWxwIHRoZSBLUyB0byBrbm93IHdoZXRoZXIgb3Igbm90IHRvIGV4 cGVjdCB0aGUgQUNLIGZyb20gYSBwYXJ0aWN1bGFyIEdNLCBidXQgdGhlIGZvY3VzIG9mIHRoaXMg SS1EIGlzIG9uIHRoZSB0aGUgZGVjbGFyYXRpb24gb2YgdGhlIHJlcXVlc3QgZm9yIEFDS3MgYnkg dGhlIEdDS1MgYW5kIHRoZSBmb3JtYXQgb2YgdGhlIEFDSy48YnIgY2xhc3M9IiI+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4qIDIuMjogJnF1b3Q7VGhpcyBpcyBhIHByaXZhdGUg a2V5JnF1b3Q7IC0gdG8gYXZvaWQgY29uZnVzaW9uLCBJIHN1Z2dlc3Q6ICZxdW90O1RoaXMgaXMg YTxiciBjbGFzcz0iIj4NCnNlY3JldCBzeW1tZXRyaWMga2V5JnF1b3Q7IChpZiB0aGlzIGlzIGlu ZGVlZCB0aGUgY2FzZSkuIE9idmlvdXNseSB1c2luZyB0aGUgc2FtZTxiciBjbGFzcz0iIj4NCmtl eSBmb3IgZW5jcnlwdGlvbiBhbmQgZm9yIEhNQUMgaXMgbm90IGEgYmVzdCBwcmFjdGljZS48YnIg Y2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQpXZeKAmXZlIG1hZGUgdGhpcyBjaGFuZ2UuPGJyIGNs YXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+KiBTZWMuIDU6IEFDSyBt ZXNzYWdlcyBjYW4gYWxzbyBiZSBkdXBsaWNhdGVkIGluIHRoZSBuZXR3b3JrLiBJIHN1Z2dlc3Qg dG8gYWRkPGJyIGNsYXNzPSIiPg0KYSBzZW50ZW5jZSBkZXNjcmliaW5nIHdoYXQgdGhlIEdDS1Mg c2hvdWxkIGRvIGluIHRoaXMgY2FzZS48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQpUaGUg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgKHNlY3Rpb24gNy4zKSBkZXNjcmliZXMgYSBtZXRob2Qg Zm9yIHRoZSBHQ0tTIHRvIGRldGVjdCByZXBsYXlzLiBUaGlzIGlzIGFyZ3VhYmx5IGJldHRlciBw bGFjZWQgaW4gdGhpcyBzZWN0aW9uLCBzbyB3ZeKAmXZlIG1vdmVkIGl0IGhlcmUuLjxiciBjbGFz cz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPiogU2VjLiA2OiBJIGFtIGNv bmZ1c2VkIGFib3V0IHRoZSBub3Rpb24gb2YgJnF1b3Q7aml0dGVyJnF1b3Q7IGhlcmUuIElmIHRo ZSBQVVNIIG1lc3NhZ2VzPGJyIGNsYXNzPSIiPg0KYXJlIHNlbnQgYXMgbXVsdGljYXN0ICh0aGUg cmVjb21tZW5kZWQgYWx0ZXJuYXRpdmUgQUZBSUNUKSwgSSdtIG5vdCBzdXJlIGFib3V0PGJyIGNs YXNzPSIiPg0KdGhlIGJlbmVmaXQgb2YgdXNpbmcgbXVsdGljYXN0LCBnaXZlbiB0aGF0IGVhY2gg cmVjaXBpZW50IHJlc3BvbmRzIHdpdGggYTxiciBjbGFzcz0iIj4NCnVuaWNhc3QgQUNLLiBBbmQg aWYgdGhlIFBVU0ggaXMgdW5pY2FzdCwgdGhlcmUgc2hvdWxkIGJlIG5vIHJlYXNvbiBmb3IgYSBq aXR0ZXI8YnIgY2xhc3M9IiI+DQphcyB0aGUgc2VuZGVyIGNhbiB0aHJvdHRsZSB0aGUgUFVTSCBt ZXNzYWdlcyBhcyBuZWNlc3NhcnkuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KVGhlIGNv bmNlcHQgb2Yg4oCcaml0dGVy4oCdIGlzIG1vc3QgdmFsdWFibGUgZm9yIHJlc3BvbnNlcyB0byBh IG11bHRpY2FzdCBQVVNIIG1lc3NhZ2UuIFRoZSB1c2Ugb2YgYSBtdWx0aWNhc3QgUFVTSCBtZXNz YWdlIGxvd2VyIHByb2Nlc3Npbmcgb24gdGhlIEdDS1MuIFNpbmNlIGVhY2ggR00gY2FuIGUgZ2l2 ZW4gdGhlIGV4YWN0IHNhbWUgcG9saWN5LCB0aGVyZeKAmXMgbm8gY2FsbCB0byBzZW5kIGl0IG91 dCBhcyBhIHVuaWNhc3QgbWVzc2FnZS4gVGhlIGppdHRlcg0KIGhlbHBzIHNwcmVhZCBvdXQgdGhl IHJlcGxpZXMgYSBiaXQgdG8gYXZvaWQgaW51bmRhdGluZyB0aGUgR0NLUy48YnIgY2xhc3M9IiI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4qIE1vcmVvdmVyLCBldmVyeXRoaW5n IHdvdWxkIGJlIG11Y2ggbW9yZSBwcmVkaWN0YWJsZSBpZiB0aGUgR0NLUyBjb3VsZDxiciBjbGFz cz0iIj4NCmluZGljYXRlIGlmIGEgaml0dGVyIGlzIGV4cGVjdGVkIGFuZCBob3cgbXVjaCBvZiBh IGppdHRlciAoYmFzZWQgb24gc2l6ZSBvZiB0aGU8YnIgY2xhc3M9IiI+DQpncm91cCwgbmV0d29y ayB0aHJvdWdocHV0LCBhbmQgcXVldWUgbGVuZ3RoKS4gU3BlY2lmaWNhbGx5LCB0aGlzIHdvdWxk IGFsbG93PGJyIGNsYXNzPSIiPg0KdGhlIEdDS1MgdG8gdGVsbCBob3cgbG9uZyBpdCBzaG91bGQg d2FpdCBmb3IgYW4gQUNLLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NClRoaXMgd291bGQg YmUgc29tZXdoYXQgdXNlZnVsLCBidXQgaW4gcHJhY3RpY2UgbWlnaHQgbm90IGhlbHAgdGhlIEdD S1MgYXMgbXVjaCBhcyBpdCBzZWVtcy4gVGhlIGppdHRlciB2YWx1ZSBwcm92aWRlZCB3b3VsZCBh bHNvIGJlIGRlcGVuZGVudCBvbiBzZXZlcmFsIG5ldHdvcmsgcGFyYW1ldGVycyB0aGF0IGFyZW7i gJl0IHVuZGVyIHRoZSBjb250cm9sIG9mIHRoZSBHQ0tTIG9yIHRoZSBHTS4gRXZlbiB3aGVuIHRo ZSBHTSBkb2VzIG5vdCBhZGQgYW55DQogaml0dGVyIHRvIHRoZSBBQ0ssIHRoZSB1bmRlcmx5aW5n IG5ldHdvcmsgbWF5IGRlbGF5IHRoZSBQVVNIIGFuZC9vciBmb3IgdGhlIEFDSy4gQW5kIGFzIHN0 YXRlZCBpbiBTZWN0aW9uIDYsIHRoZSBHQ0tTIG1heSBiZSBjb25maWd1cmVkIHdpdGggYWRkaXRp b25hbCBwb2xpY3kgYWN0aW9ucyBsaWtlIHJldHJhbnNtaXNzaW9ucyB0byBvdmVyY29tZSBsb3N0 IEFDS3MuIEFsdG9nZXRoZXIgdG8gYWRkIGppdHRlciB0byB0aGUgQUNLIGlzIG5vdCBhDQogbXVz dCwgaXQgaXMgYSB3YXkgdG8gaGVscCB0aGUgR0NLUyBkZWFsIHdpdGggYSBodWdlIG51bWJlciBv ZiBHTXMuIEluIHByYWN0aWNlLCB3ZeKAmXZlIGZvdW5kIHRoYXQgaGF2aW5nIHRoZSBHTXMgY2hv b3NlIHRoZSBqaXR0ZXIgaGFzIHdvcmtlZCB3ZWxsLCBldmVuIHdoZW4gdGhlIEdNcyBhcmUgZGlm ZmVyZW50IGltcGxlbWVudGF0aW9ucy48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIiBjbGFzcz0iIj4qIENyeXB0b2dyYXBoaWMgYWdpbGl0eTogdGhpcyBkb2N1bWVudCBzcGVj aWZpZXMgb25seSBvbmUgYWxnb3JpdGhtIGZvciB0aGU8YnIgY2xhc3M9IiI+DQpIQVNIIHZhbHVl LCBhbmQgc2F5cyB0aGF0IGlmIGEgbmV3IGFsZ29yaXRobSBpcyBuZWVkZWQsIHRoZXJlIHdpbGwg YmUgYSBuZXc8YnIgY2xhc3M9IiI+DQpLRUtfQUNLX1JFUVVFU1RFRCBwYXlsb2FkIGRlZmluZWQu IEhvd2V2ZXIgdG8gbWFrZSBzdXJlIHRoYXQgdGhpcyByZWFsbHk8YnIgY2xhc3M9IiI+DQomcXVv dDt3b3JrcyZxdW90Oywgd2UgbmVlZCB0byBkZWZpbmUgd2hldGhlciBtdWx0aXBsZSBzdWNoIHBh eWxvYWRzIGNhbiBiZSBzZW50PGJyIGNsYXNzPSIiPg0Kc2ltdWx0YW5lb3VzbHkgKGlmIGUuZy4g c29tZSBHTXMgc3RpbGwgc3VwcG9ydCB0aGUgb2xkIGFsZ29yaXRobSkgYW5kIHdoYXQnczxiciBj bGFzcz0iIj4NCnRoZSBleHBlY3RlZCBiZWhhdmlvci4gSSB3b3VsZCBzdWdnZXN0IHRvIGRlZmlu ZSBhbiBhZGRpdGlvbmFsIFNIQS01MTIgcGF5bG9hZDxiciBjbGFzcz0iIj4NCmp1c3QgdG8gbWFr ZSBmb3IgYSBjb25jcmV0ZSBleGFtcGxlLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NClRo aXMgaXMgYSBnb29kIHN1Z2dlc3Rpb24uIFdl4oCZdmUgYWRkZWQgU0hBLTUxMiB2ZXJzaW9ucyBv ZiB0aGUgZXhpc3RpbmcgS0VLX0FDS19SRVFVRVNURUQgdmFsdWVzLjxiciBjbGFzcz0iIj4NClNl ZSAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdlaXMtZ2Rv aS1yZWtleS1hY2stMDYiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC13ZWlzLWdkb2ktcmVrZXktYWNrLTA2PC9hPiZndDs8YnIgY2xhc3M9IiI+DQpUaGFua3MsPGJy IGNsYXNzPSIiPg0KQnJpYW48YnIgY2xhc3M9IiI+DQotLSA8YnIgY2xhc3M9IiI+DQpCcmlhbiBX ZWlzPGJyIGNsYXNzPSIiPg0KU2VjdXJpdHksIENTRywgQ2lzY28gU3lzdGVtczxiciBjbGFzcz0i Ij4NClRlbGVwaG9uZTogJiM0MzsxIDQwOCA1MjYgNDc5NjxiciBjbGFzcz0iIj4NCkVtYWlsOiA8 YSBocmVmPSJtYWlsdG86YmV3QGNpc2NvLmNvbSIgY2xhc3M9IiI+YmV3QGNpc2NvLmNvbTwvYT4g Jmx0OzxhIGhyZWY9Im1haWx0bzpiZXdAY2lzY28uY29tIiBjbGFzcz0iIj5tYWlsdG86YmV3QGNp c2NvLmNvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4t LSZuYnNwOzxiciBjbGFzcz0iIj4NCkJyaWFuIFdlaXM8YnIgY2xhc3M9IiI+DQpTZWN1cml0eSwg Q1NHLCBDaXNjbyBTeXN0ZW1zPGJyIGNsYXNzPSIiPg0KVGVsZXBob25lOiAmIzQzOzEgNDA4IDUy NiA0Nzk2PGJyIGNsYXNzPSIiPg0KRW1haWw6IDxhIGhyZWY9Im1haWx0bzpiZXdAY2lzY28uY29t IiBjbGFzcz0iIj5iZXdAY2lzY28uY29tPC9hPiA8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DE62366A03774DE19ED0A14E44A7EC05ciscocom_-- From nobody Tue Aug 29 14:00:15 2017 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 3E0E0132944; Tue, 29 Aug 2017 14:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 v1kzSKQCoijz; Tue, 29 Aug 2017 14:00:04 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A011E124E15; Tue, 29 Aug 2017 14:00:03 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id u26so5222729wma.0; Tue, 29 Aug 2017 14:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=6YGrK2gCM29k+y7ct+1x7Dwb+DppKUiUtJ7d7zmm6WI=; b=Ph+680gQ4ibGuDeDQYN0b5wtAp1ZR+r3BunYehMLTBldOEanAZfIqzJxeIJ1hGTyW2 0S8+NuIOFm097gmq+aJ7xtPDZYumiEZ3vGALLHcpxaAYKz0by92yoazVZ9Bfczg+ievz FBL+5LgSqUZF3EMuEFLU3//okvU4HmOG36cPs9uPcWPT0QCqziSs0qyo04jEAnp74KZK b4+Uu59ryEHIghhhW4Np3jxnT0BtI0vo4LG7C4dToc/bwBi7UQZedOG7LkYRyKO5Bu4l GSqUrg5AQeTKcXQlQPFAAp8hyFYR5JaIp/Mkoasy/xDg/tqByUNKbsWdXkPFECc+PcZ5 UeXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6YGrK2gCM29k+y7ct+1x7Dwb+DppKUiUtJ7d7zmm6WI=; b=N6QlW/dBDQlCDHJBjiOWCVERmeNMEdsP6MfrYV5jIV9D8BMu+HA6I3Y020UeAfEXZ4 hQaPC4UQ5Lb0AIXbuAZ4TLJDM50m1D+WWBW1BEUmLlBL54DTquOuk9CHTzY2lzaeLC/s x7E5RzAU7Y2y6peUePdtsQWvOjrj7r+GkvRS2E8fhfd9jRrevNpk42muXETP6xo3WCSe F6aMQy+I/6aUZW5R92qjZnfAj6MImYLuM+JpzXeBVGabu670MHoFFHn07HZqwHzWzCsP P3DgaETvEwleXI2emNOMygxwfCCOYnH8dncuZo25TTtmzaCWFDEpMjoruRWuwnutqi4/ IiGg== X-Gm-Message-State: AHYfb5g+RO/mkbLXx8kBSr74+8KmcnSXs3SmKp26djrKrIlK/UniaHzx Bux1RM4j+Qv2UztNQ5k= X-Received: by 10.28.238.197 with SMTP id j66mr354824wmi.170.1504040401535; Tue, 29 Aug 2017 14:00:01 -0700 (PDT) Received: from [10.0.0.10] (bzq-109-67-55-26.red.bezeqint.net. [109.67.55.26]) by smtp.gmail.com with ESMTPSA id v60sm5177895wrc.71.2017.08.29.14.00.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Aug 2017 14:00:00 -0700 (PDT) To: "Brian Weis (bew)" Cc: "secdir@ietf.org" , "draft-weis-gdoi-rekey-ack.all@ietf.org" , "ietf@ietf.org" References: <150194814585.18635.3104789196001873381@ietfa.amsl.com> From: Yaron Sheffer Message-ID: Date: Tue, 29 Aug 2017 23:59:58 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [secdir] Secdir last call review of draft-weis-gdoi-rekey-ack-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 21:00:07 -0000 Hi Brian, To me, incremental deployment is what crypto-agility is all about. But I guess others might disagree. In any case, this limitation needs to be discussed when we talk about agility. Thanks, Yaron On 29/08/17 23:48, Brian Weis (bew) wrote: > Hi Yaron, > >> On Aug 26, 2017, at 8:34 AM, Yaron Sheffer > > wrote: >> >> Hi Brian, >> >> Thank you for addressing most of my comments in the new version, and >> for clarifying points where I was off the mark. >> >> The only remaining comment that's only partly addressed is the one on >> crypto agility. Quoting myself: >> >> we need to define whether multiple such payloads can be sent >> simultaneously (if e.g. some GMs still support the old algorithm) and >> what's the expected behavior. >> >> In other words, supporting more algorithms in not sufficient. The >> question is whether we support incremental deployment of a new >> algorithm to a large group of GMs. > > Sorry, we missed this. Incremental deployment of any new policy > (algorithm or otherwise) within a group is not so straightforward. There > can really only be one set of policy used by the entire group because if > a sender has been updated to a new set of policy it can’t really use it > until all receivers are similarly upgraded. This is a place where a > capabilities exchange can be useful for a key server to declare a switch > to a new algorithm after all members claim to support it, but that might > never happen in a large group. Practically speaking incremental updates > in a large group might require two different groups with a bridge > between, or some other deployment structure. Since it’s a broader > problem, I’m not sure what else we can do in this document to address > incremental deployment. > > Thanks, > Brian > >> >> Thanks, >> Yaron >> >> On 24/08/17 19:48, Brian Weis (bew) wrote: >>> Hi Yaron, >>> Thanks for the review. We’ve added some clarification below, and made >>> some changes in -06 to address your comments. Please let us know if >>> we did not address them satisfactorily. >>>> On Aug 5, 2017, at 8:49 AM, Yaron Sheffer >>> > wrote: >>>> >>>> Reviewer: Yaron Sheffer >>>> Review result: Has Issues >>>> >>>> Summary: this reviewer is not clear about the value of the push-ack >>>> (compared >>>> to a pull) and about the strategy that was chosen. >>> In a group key management system either a “pull” (triggered by a >>> group member) or a “push” (by the key server)" could be used to >>> provide updates to the group. However, a “pull” by the group member >>> implies a polling method, which has the deficiency that the key >>> server cannot cause a policy replacement any sooner than the polling >>> method by the group members. Also “polling” can cause additional >>> unnecessary traffic. So is is better for any update on the group >>> policy or renewal of group keys to be distributed by the GCKS using a >>> PUSH message. The ACK-message is used to offer a feedback mechanism >>> to a policy update for the PUSH exchange. >>>> >>>> *//* >>>> >>>> * "For example, a GCKS policy can use the acknowledgements to >>>> determine [...] >>>> which members may no longer be members of the group." This sentence >>>> is very >>>> confusing: when are members not members? >>> We’ve reworded this text. It’s trying to convey that a missing ACK >>> message (or a certain number of it) can be used to identify that a >>> group member is no longer receiving group traffic, and is now may be >>> considered an ex-group member. For example, it could be a multicast >>> receiver that is no longer interested in being a receiver for the >>> group. But it could also be that a network event has caused it to be >>> unavailable for a sufficient length of time such that it doesn’t have >>> current keying material and therefore can’t be considered a current >>> group member. There is no reliable “I’m leaving the group” message >>> flow, and of course in my second example no such messages would have >>> been intended by the group member. >>>> * The new protocol capability is defined as optional, but really >>>> isn't. "A GM >>>> receiving the KEK_ACK_REQUESTED attribute can choose to ignore it, thus >>>> appearing as if it does not support the KEK_ACK_REQUESTED attribute. >>>> However, >>>> GCKS policy may consider a non-responsive GM to no longer desire to >>>> be a member >>>> of the group." So if you want to play the game, you MUST support the new >>>> attribute. >>> Point taken. We’ve changed the text to reflect this. >>>> * I'm puzzled at the overall protocol. Being able to send ACKs is a >>>> GM software >>>> capability. Why not have the GM announce this capability when it >>>> initially >>>> registers to the GCKS? Then the GCKS would know what to expect, >>>> whereas with >>>> the current protocol it is left waiting for an ACK that may never >>>> come, either >>>> because the GM is dead or because it just doesn't feel like >>>> responding. Add the >>>> long waits (jitter of "a few seconds" and potential retries), and >>>> this looks >>>> like a far from optimal management experience. >>> Indeed a GM could announce its capability, but whether or not ACKs >>> are desired is a component of the group policy. In the context of >>> GDOI the GCKS is the entity that defines the group policy. There can >>> be groups where the ACK is used, whereas others do not. The >>> capabilities announcement you suggest could certainly help the KS to >>> know whether or not to expect the ACK from a particular GM, but the >>> focus of this I-D is on the the declaration of the request for ACKs >>> by the GCKS and the format of the ACK. >>>> * 2.2: "This is a private key" - to avoid confusion, I suggest: >>>> "This is a >>>> secret symmetric key" (if this is indeed the case). Obviously using >>>> the same >>>> key for encryption and for HMAC is not a best practice. >>> We’ve made this change. >>>> * Sec. 5: ACK messages can also be duplicated in the network. I >>>> suggest to add >>>> a sentence describing what the GCKS should do in this case. >>> The Security Considerations (section 7.3) describes a method for the >>> GCKS to detect replays. This is arguably better placed in this >>> section, so we’ve moved it here.. >>>> * Sec. 6: I am confused about the notion of "jitter" here. If the >>>> PUSH messages >>>> are sent as multicast (the recommended alternative AFAICT), I'm not >>>> sure about >>>> the benefit of using multicast, given that each recipient responds >>>> with a >>>> unicast ACK. And if the PUSH is unicast, there should be no reason >>>> for a jitter >>>> as the sender can throttle the PUSH messages as necessary. >>> The concept of “jitter” is most valuable for responses to a multicast >>> PUSH message. The use of a multicast PUSH message lower processing on >>> the GCKS. Since each GM can e given the exact same policy, there’s no >>> call to send it out as a unicast message. The jitter helps spread out >>> the replies a bit to avoid inundating the GCKS. >>>> * Moreover, everything would be much more predictable if the GCKS could >>>> indicate if a jitter is expected and how much of a jitter (based on >>>> size of the >>>> group, network throughput, and queue length). Specifically, this >>>> would allow >>>> the GCKS to tell how long it should wait for an ACK. >>> This would be somewhat useful, but in practice might not help the >>> GCKS as much as it seems. The jitter value provided would also be >>> dependent on several network parameters that aren’t under the control >>> of the GCKS or the GM. Even when the GM does not add any jitter to >>> the ACK, the underlying network may delay the PUSH and/or for the >>> ACK. And as stated in Section 6, the GCKS may be configured with >>> additional policy actions like retransmissions to overcome lost ACKs. >>> Altogether to add jitter to the ACK is not a must, it is a way to >>> help the GCKS deal with a huge number of GMs. In practice, we’ve >>> found that having the GMs choose the jitter has worked well, even >>> when the GMs are different implementations. >>>> * Cryptographic agility: this document specifies only one algorithm >>>> for the >>>> HASH value, and says that if a new algorithm is needed, there will >>>> be a new >>>> KEK_ACK_REQUESTED payload defined. However to make sure that this really >>>> "works", we need to define whether multiple such payloads can be sent >>>> simultaneously (if e.g. some GMs still support the old algorithm) >>>> and what's >>>> the expected behavior. I would suggest to define an additional >>>> SHA-512 payload >>>> just to make for a concrete example. >>> This is a good suggestion. We’ve added SHA-512 versions of the >>> existing KEK_ACK_REQUESTED values. >>> See >>> Thanks, >>> Brian >>> -- >>> Brian Weis >>> Security, CSG, Cisco Systems >>> Telephone: +1 408 526 4796 >>> Email: bew@cisco.com >> >> >> Thanks, >> Yaron >> >> On 24/08/17 19:48, Brian Weis (bew) wrote: >>> Hi Yaron, >>> Thanks for the review. We’ve added some clarification below, and made >>> some changes in -06 to address your comments. Please let us know if >>> we did not address them satisfactorily. >>>> On Aug 5, 2017, at 8:49 AM, Yaron Sheffer >>> > wrote: >>>> >>>> Reviewer: Yaron Sheffer >>>> Review result: Has Issues >>>> >>>> Summary: this reviewer is not clear about the value of the push-ack >>>> (compared >>>> to a pull) and about the strategy that was chosen. >>> In a group key management system either a “pull” (triggered by a >>> group member) or a “push” (by the key server)" could be used to >>> provide updates to the group. However, a “pull” by the group member >>> implies a polling method, which has the deficiency that the key >>> server cannot cause a policy replacement any sooner than the polling >>> method by the group members. Also “polling” can cause additional >>> unnecessary traffic. So is is better for any update on the group >>> policy or renewal of group keys to be distributed by the GCKS using a >>> PUSH message. The ACK-message is used to offer a feedback mechanism >>> to a policy update for the PUSH exchange. >>>> >>>> *//* >>>> >>>> * "For example, a GCKS policy can use the acknowledgements to >>>> determine [...] >>>> which members may no longer be members of the group." This sentence >>>> is very >>>> confusing: when are members not members? >>> We’ve reworded this text. It’s trying to convey that a missing ACK >>> message (or a certain number of it) can be used to identify that a >>> group member is no longer receiving group traffic, and is now may be >>> considered an ex-group member. For example, it could be a multicast >>> receiver that is no longer interested in being a receiver for the >>> group. But it could also be that a network event has caused it to be >>> unavailable for a sufficient length of time such that it doesn’t have >>> current keying material and therefore can’t be considered a current >>> group member. There is no reliable “I’m leaving the group” message >>> flow, and of course in my second example no such messages would have >>> been intended by the group member. >>>> * The new protocol capability is defined as optional, but really >>>> isn't. "A GM >>>> receiving the KEK_ACK_REQUESTED attribute can choose to ignore it, thus >>>> appearing as if it does not support the KEK_ACK_REQUESTED attribute. >>>> However, >>>> GCKS policy may consider a non-responsive GM to no longer desire to >>>> be a member >>>> of the group." So if you want to play the game, you MUST support the new >>>> attribute. >>> Point taken. We’ve changed the text to reflect this. >>>> * I'm puzzled at the overall protocol. Being able to send ACKs is a >>>> GM software >>>> capability. Why not have the GM announce this capability when it >>>> initially >>>> registers to the GCKS? Then the GCKS would know what to expect, >>>> whereas with >>>> the current protocol it is left waiting for an ACK that may never >>>> come, either >>>> because the GM is dead or because it just doesn't feel like >>>> responding. Add the >>>> long waits (jitter of "a few seconds" and potential retries), and >>>> this looks >>>> like a far from optimal management experience. >>> Indeed a GM could announce its capability, but whether or not ACKs >>> are desired is a component of the group policy. In the context of >>> GDOI the GCKS is the entity that defines the group policy. There can >>> be groups where the ACK is used, whereas others do not. The >>> capabilities announcement you suggest could certainly help the KS to >>> know whether or not to expect the ACK from a particular GM, but the >>> focus of this I-D is on the the declaration of the request for ACKs >>> by the GCKS and the format of the ACK. >>>> * 2.2: "This is a private key" - to avoid confusion, I suggest: >>>> "This is a >>>> secret symmetric key" (if this is indeed the case). Obviously using >>>> the same >>>> key for encryption and for HMAC is not a best practice. >>> We’ve made this change. >>>> * Sec. 5: ACK messages can also be duplicated in the network. I >>>> suggest to add >>>> a sentence describing what the GCKS should do in this case. >>> The Security Considerations (section 7.3) describes a method for the >>> GCKS to detect replays. This is arguably better placed in this >>> section, so we’ve moved it here.. >>>> * Sec. 6: I am confused about the notion of "jitter" here. If the >>>> PUSH messages >>>> are sent as multicast (the recommended alternative AFAICT), I'm not >>>> sure about >>>> the benefit of using multicast, given that each recipient responds >>>> with a >>>> unicast ACK. And if the PUSH is unicast, there should be no reason >>>> for a jitter >>>> as the sender can throttle the PUSH messages as necessary. >>> The concept of “jitter” is most valuable for responses to a multicast >>> PUSH message. The use of a multicast PUSH message lower processing on >>> the GCKS. Since each GM can e given the exact same policy, there’s no >>> call to send it out as a unicast message. The jitter helps spread out >>> the replies a bit to avoid inundating the GCKS. >>>> * Moreover, everything would be much more predictable if the GCKS could >>>> indicate if a jitter is expected and how much of a jitter (based on >>>> size of the >>>> group, network throughput, and queue length). Specifically, this >>>> would allow >>>> the GCKS to tell how long it should wait for an ACK. >>> This would be somewhat useful, but in practice might not help the >>> GCKS as much as it seems. The jitter value provided would also be >>> dependent on several network parameters that aren’t under the control >>> of the GCKS or the GM. Even when the GM does not add any jitter to >>> the ACK, the underlying network may delay the PUSH and/or for the >>> ACK. And as stated in Section 6, the GCKS may be configured with >>> additional policy actions like retransmissions to overcome lost ACKs. >>> Altogether to add jitter to the ACK is not a must, it is a way to >>> help the GCKS deal with a huge number of GMs. In practice, we’ve >>> found that having the GMs choose the jitter has worked well, even >>> when the GMs are different implementations. >>>> * Cryptographic agility: this document specifies only one algorithm >>>> for the >>>> HASH value, and says that if a new algorithm is needed, there will >>>> be a new >>>> KEK_ACK_REQUESTED payload defined. However to make sure that this really >>>> "works", we need to define whether multiple such payloads can be sent >>>> simultaneously (if e.g. some GMs still support the old algorithm) >>>> and what's >>>> the expected behavior. I would suggest to define an additional >>>> SHA-512 payload >>>> just to make for a concrete example. >>> This is a good suggestion. We’ve added SHA-512 versions of the >>> existing KEK_ACK_REQUESTED values. >>> See >>> Thanks, >>> Brian >>> -- >>> Brian Weis >>> Security, CSG, Cisco Systems >>> Telephone: +1 408 526 4796 >>> Email: bew@cisco.com > > -- > Brian Weis > Security, CSG, Cisco Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com > From nobody Tue Aug 29 14:51:55 2017 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 2E9CA132969; Tue, 29 Aug 2017 14:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Lvth4W5Ckf7S; Tue, 29 Aug 2017 14:51:45 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.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 644EB12426E; Tue, 29 Aug 2017 14:51:42 -0700 (PDT) X-AuditID: 1209190d-f2fff700000018a4-aa-59a5e1ecb573 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 73.D4.06308.DE1E5A95; Tue, 29 Aug 2017 17:51:41 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v7TLpdZs024714; Tue, 29 Aug 2017 17:51:40 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v7TLpZKI026539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Aug 2017 17:51:38 -0400 Date: Tue, 29 Aug 2017 16:51:35 -0500 From: Benjamin Kaduk To: iesg@ietf.org, secdir@ietf.org, draft-ietf-teas-lsp-diversity.all@ietf.org Message-ID: <20170829215133.GP96685@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBIsWRmVeSWpSXmKPExsUixCmqrPv24dJIg6mveCxmt/5hspjxZyKz xYeFD1kcmD2WLPnJFMAYxWWTkpqTWZZapG+XwJXxdoV2wW6nikmTjzI2MLaYdTFyckgImEis 3fqSqYuRi0NIYDGTxItNr1ghnI2MEo2/dzFCOFeZJO78ms8M0sIioCqxpvE3E4jNJqAi0dB9 GSwuIuAn0XCyhQ3EFhawkmhp2MgIYvMCrXj8aBeULShxcuYTFhCbWUBL4sY/kNUcQLa0xPJ/ HCBhUQFliXn7VrFNYOSdhaRjFpKOWQgdCxiZVzHKpuRW6eYmZuYUpybrFicn5uWlFuka6eVm luilppRuYgQHlyTvDsZ/d70OMQpwMCrx8O4oXRopxJpYVlyZe4hRkoNJSZT32G2gEF9Sfkpl RmJxRnxRaU5q8SFGCQ5mJRHehw+AcrwpiZVVqUX5MClpDhYlcV5xjcYIIYH0xJLU7NTUgtQi mKwMB4eSBG8MSKNgUWp6akVaZk4JQpqJgxNkOA/Q8CVgw4sLEnOLM9Mh8qcYjTmevNn+m4mj 5S2QFGLJy89LlRLn/X4fqFQApDSjNA9uGihBSGTvr3nFKA70nDDvdZCBPMDkAjfvFdAqJqBV sV5gq0oSEVJSDYwRV7NWaK3Ii5yRvuHxar/V51K/bfwbt3ZKRYlq8o85J9u/s566aKncczvB ce0O7Y1BZWk8suXv7wk+74h/q10otK4y5n7Wk9/W17mjXiYUe5t7yWdPj5vEx8RXO0llEnuB 9N48nyWRwlbpWUol16I/ip3LFpOdVzvv7t9lir/+Lnf3/SCWz6PEUpyRaKjFXFScCAApo8Qp 6wIAAA== Archived-At: Subject: [secdir] secdir review of draft-ietf-teas-lsp-diversity-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 21:51:48 -0000 Hi all, 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 summary, I think this document is ready with nits (largely editorial). The main point of the document is to allow for source nodes to request path diversity in new LSPs being created, in the case where the source node does not have full knowledge of the relevant topology. (The case where the source node does have such knowledge is already handled via eXclude Route Objects and Explicit Exclusion Route Subobjects.) My understanding is that the main reason to request such path diversity is to introduce redundancy and improve the system functionality in the case of (localized) outages, but this does not really seem to be emphasized in the Introduction -- maybe it should? Path diversity is effected by the use of a "reference path" that already exists between a source and destination, and requesting that the new path is diverse with respect to that reference path. Similarly to the above, it may be helpful to explictly introduce the notion of a reference path instead of introducing it implicitly, in passing. The security considerations largely refer to/include by reference RFCs 5920, 2205, 3209, 3473, and 4874, though not all of these are listed as normative references. (I'm not sure whether there is a convention for such cases.) Of those, RFC 3473 also refers to RFC 2747, and there may (or may not) be value in flattening the chain of references by explicitly mentioning RFC 2747 here as well. To a large extent, those references do seem to cover the relevant security considerations for this document, as there is little that is conceptually new in this document. The final paragraph of the security considerations calls out an exception to the rule from RFC 4874 that XRO could/should be removed from the Path message to avoid leaking internal information, because the diversity subobject needs to be preserved in order to perform its function. One could potentially claim that even the diversity subobject is leaking some information about the internal network in some cases, but since the "leaked" information is essentially an opaque identifier, the usual case would generally be that it is worth the minor leak in order to obtain path diversity, as this document states. Whenever new identifiers are issued, the corresponding privacy considerations should also be considered. Given that the role of a core network is probably (?) considered to be just transit, I am not very concerned about path identifiers leaking information (or correlations) about what physical path a given set of data traverses. I suppose one could consider potential security/privacy issues inherent in path diversity as well, which seems mostly limited to the case where only a subset of nodes/links are compromised in some fashion (monitored or subject to traffic injection). In that case, someone knowing that a reference path is not subject to attack could try to create a new (diverse) path in an attempt to have the new path traverse the compromised equipment. But that seems quite far-fetched as an attack, especially in the context of the RFC 5920 model where the core is considered to be equally/globally trusted. I'm also possibly confused at the requirements introduced in section 2.3 (page 19) for the node performing path computation to take action when a previously unknown (excluded) path becomes known, or when LSPs (?) change so that a requested exclusion is no longer satisfied. This seems to require that the PCE store all XRO subobjects along with the path state, so as to be able to do this processing upon (all!) LSP changes. Is the extra storage and/or computation likely to be a significant burden on the PCE that might lead to resource-exhaustion and denial of service? There is also some minor risk in section 1.3 (page 8) where PAS assignment and distribution is left as out of scope for this document -- certain assignment schemes could leak information or allow outside parties to guess "new" values that would be treated as valid by the core network. But it's hard to see this leading to a concrete attack, especially when the PAS number space is only 32 bits wide. I'll mention a few of the more significant editorial issues here, and defer the really nitty-gritty stuff to a later message with narrower scope, in the interest of expediency (as this document is scheduled for this week's telechat). It may be worth double-checking that acronyms not listed as "well-known" at https://www.rfc-editor.org/materials/abbrev.expansion.txt are expanded at first use; UNI-N and RRO are a couple that I noticed while reviewing. In the abstract: [...] Three different mechanisms are supported how LSP diversity can be accomplished in the provider or core network: the signaled diversity type, indicates whether diversity is based on client, path computation engine (PCE), or network assigned identifiers. am I correct to infer that "indicates whether diversity is based on client" is supposed to clarify what "signaled diversity type" means, so that the rest of the sentence is a three-element list corresponding to the three diversity identifiers introduced by this document? If so, it's probably better to put it inside parentheses than offset by commas, or even to reword it entirely to just be something like "a client-initiated method". The next sentence could also be made smoother, something about assuming that LSPs are created at a slow rate and exist for a long time, so that it is reasonable to assume that a given (reference) path currently existing, with a well-known identifier, will continue to exist and can be used as a reference when creating the new path. At the top of page 4, "exemplified" should probably be something like "illustrated" (this particular diagram is not really the epitome of path exclusion). In page 4, a "single-homed UNI" is referred to. My understanding was that the UNI was akin to an edge in the topology graph, and that "single-homed" would more commonly apply to an EN (but maybe my understanding is incorrect). Page 5, first complete paragraph, does "across the UNI boundary" just mean in the CN to EN direction? At the end of section 1 (just before section 1.1), the listing "client-initiated, allocated by the (core) network or managed by a PCE" should probably have the last two swapped, to match the ordering used in the rest of the document. At the bottom of page 5 (last line), should "LSP IS = L1" be "LSP ID = L2" (S-->D and 1-->2)? Also, the previous line has "LSP-IDENTIFIER12" which probably is meant to just be the '2'. Page 8, third paragraph, "included for exclusion" is a little awkward of a phrasing; "[i]f a PAS identifier is used as an exclusion identifier" might be better. Page 11 just lists the three diversity identifier types created by this document; should there be consideration of (text for) how to allocate additional types in the future? The string "IPv4/ IPv6" appears many times in the text; I believe it's more conventionally written without the space, as "IPv4/IPv6". Crossing from page 16 to page 16, "sends [...] request from ingress node to egress node including diversity constraints to a PCE" is potentially confusing about what is being sent where, since it's the request for a path [from ingress node to egress node] that is sent to the PCE. So, "path computation request for a path from ingress node to egress node" might be better, or even reordering things more drastically. The last two sentences of the Security Considerations are a little hard to read; I might reword them, potentially as: However, when the diversity subobjects specified in this document are used, removing at the administrative boundary an XRO containing these diversity subobjects would result in the request for diversity being dropped at the boundary, and path computation would be unlikely to produce the requested divers path. As such, diversity subobjects MUST be retained in an XRO crossing an administrative boundary, even if other subobjects are removed. -Ben From nobody Tue Aug 29 15:11:08 2017 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 9EC29126DD9; Tue, 29 Aug 2017 15:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=infineon.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 n8R5xTTwRj8q; Tue, 29 Aug 2017 15:11:05 -0700 (PDT) Received: from smtp2.infineon.com (smtp2.infineon.com [IPv6:2a00:18f0:1e00:4::4]) (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 BA8DA13295E; Tue, 29 Aug 2017 15:11:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=infineon.com; i=@infineon.com; q=dns/txt; s=IFXMAIL; t=1504044665; x=1535580665; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=lp7o42YLAu9dU95PXy+RXg5CqROZo8UvjzNf0+rG/Wg=; b=mtk3hpy13VVQ1rsowAmRYWz+gJ36iksEkfKeeE6zV2oz864d4Jz4nBZg jh3q+1ZePYt22c7QYs7UEhZy2buneyVy+8y1irnKhM8APivmMFU6KY8l0 jN/xHsGoXLnHI3PsYAI4NtFVSYK06lJQqwn6CaxsunTvvrIx2erESSjwO 8=; X-SBRS: None Received: from unknown (HELO mucxv001.muc.infineon.com) ([172.23.11.16]) by smtp2.infineon.com with ESMTP/TLS/AES256-GCM-SHA384; 30 Aug 2017 00:11:02 +0200 Received: from MUCSE606.infineon.com (mucse606.infineon.com [172.23.7.107]) by mucxv001.muc.infineon.com (Postfix) with ESMTPS; Wed, 30 Aug 2017 00:11:02 +0200 (CEST) Received: from MUCSE611.infineon.com (172.23.7.112) by MUCSE606.infineon.com (172.23.7.107) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 30 Aug 2017 00:11:02 +0200 Received: from MUCSE609.infineon.com (172.23.7.110) by MUCSE611.infineon.com (172.23.7.112) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 30 Aug 2017 00:11:02 +0200 Received: from MUCSE609.infineon.com ([172.23.103.71]) by MUCSE609.infineon.com ([172.23.103.71]) with mapi id 15.00.1263.000; Wed, 30 Aug 2017 00:11:01 +0200 From: To: , , , Thread-Topic: SecDir Last Call Review of draft-ietf-codec-opus-update-08 Thread-Index: AdMSlVHlzvP1oT9WQReYKDkXHAsw4gCmDEkAAvlfnTA= Date: Tue, 29 Aug 2017 22:11:01 +0000 Message-ID: <5874d5e61f584977a06c68c250c609b0@MUCSE609.infineon.com> References: In-Reply-To: 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.23.8.247] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] SecDir Last Call Review of draft-ietf-codec-opus-update-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 22:11:07 -0000 Jean-Marc, Sorry to be slow in responding to your email. All the fixes that you propose seem completely appropriate to me and resolv= e my concerns. I see that these changes have already been made and the docu= ment approved for RFC status. Bravo! Thanks, Steve -----Original Message----- From: Jean-Marc Valin [mailto:jmvalin@jmvalin.ca]=20 Sent: Monday, August 14, 2017 4:46 PM To: Hanna Steve (IFAM CCS SMD AMR); iesg@ietf.org; secdir@ietf.org; draft-i= etf-codec-opus-update.all@ietf.org Subject: Re: SecDir Last Call Review of draft-ietf-codec-opus-update-08 Hi Steve, Thanks for the review and useful comments. See below. On 11/08/17 09:38 AM, Steve.Hanna@infineon.com wrote: > 1) In section 5, the third problem with the SILK resampler involves a=20 > possible buffer overrun. This bug looks like to me like it could=20 > result in unauthorized writes to the stack beyond the end of the=20 > buffer. These writes could be used for return-oriented programming, to=20 > modify variables stored in the stack, or even to execute arbitrary=20 > code. The draft says that "the code never produced any error in=20 > testing" and "suggests that in practice [...] none of the issues above=20 > was ever a problem." Many security vulnerabilities do not produce any=20 > errors in testing but lead to serious security problems. Unless the=20 > authors can prove that the bug is harmless, they should not minimize=20 > its potential impact. Therefore, I suggest that this language in the=20 > draft be changed to avoid minimizing the impact of the bug in any way.=20 > Rather, the draft should warn that a buffer overrun permitting writes=20 > into the stack is a dangerous vulnerability that can in some cases=20 > lead to arbitrary code execution, although the authors are not aware=20 > at this time of any successful exploits. Minimizing the impact of the=20 > bug may discourage readers from rapidly deploying the fix or adopting oth= er countermeasures. So I spent some time to evaluate the consequences of the problem and came t= o the conclusion that no out-of-bounds read or write is possible. That's because the buffers involved (buf and S->sFIR) are actually larger t= han they needed to be for the code to work. So the extra bytes copied do no= t overrun any of the buffers. I'll update the text to state to make it clea= r that the bug is harmless. It's still good to fix it because it *does* loo= k a bit scary until you've done the full analysis. > 2) Section 7 discusses and fixes the CVE-2017-0381 vulnerability. > Although the CVE description says that "A remote code execution=20 > vulnerability in silk/NLSF_stabilize.c in libopus in Mediaserver could=20 > enable an attacker using a specially crafted file to cause memory=20 > corruption during media file and data processing.", subsequent=20 > analysis by many parties (e.g., > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D851612#10) indicates= =20 > that this vulnerability cannot lead to remote code execution. Rather,=20 > it can only result in an illegal read access to the stack. That's not=20 > good but it's not nearly as bad as remote code execution. The draft=20 > correctly states that "The end result of the wrap-around is an illegal=20 > read access on the stack". The text in the CVE description should be=20 > corrected, if possible. I tried getting the CVE corrected at the time, but didn't get far aside fro= m having the severity lowered slightly. It's worth noting that the CVE came= in about 6 months after the bug was fixed. > 3) Section 12 says that "CVE-2017-0381 [...] could not be exploited in=20 > any way (despite the claims in the CVE), unless the read-only table=20 > was somehow placed very close to sensitive data, which is highly unlikely= ." > Those who write library code don't control the placement of input=20 > parameters such as buffers. That's especially true for open source=20 > reference code that may be adapted in almost any way. Therefore, the=20 > statement that the CVE could not be exploited in any way seems to be a=20 > stretch. Rather, it would be better to warn about the worst possible=20 > risks of the bug than to minimize its impact. Still, there would be=20 > some benefit in explaining that community analysis of this=20 > vulnerability has not supported the claim in the CVE that it enables remo= te code execution. Here's the revised text I would suggest: "CVE-2017-0381 is fixed by Section 7 and can only result in a 16-bit out-of= -bounds read to a fixed location 256 bytes before a constant table. That lo= cation would normally be part of an executable's read-only data segment, bu= t if that is not the case, the bug could at worst results in either a crash= or the leakage of 16 bits of information from that fixed memory location (= if the attacker has access to the decoded output). Despite the claims of th= e CVE, the bug cannot results in arbitrary code execution." > Also, here are a few nits: >=20 > * At the end of section 1, the text "has a SHA1" should be "has a=20 > SHA-1 hash of". >=20 > * In section 10 at the end of the first paragraph, "artefacts" should=20 > be "artifacts". >=20 > * In section 11 just before the hexadecimal values, "SHA1 hash" should=20 > be "SHA-1 hashes". >=20 > * In section 12, "theoretically cause information leak" should be=20 > "theoretically cause an information leak". This text is split by a=20 > line break so search for "information leak". Will fix as suggested. Cheers, Jean-Marc From nobody Tue Aug 29 19:03:21 2017 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 42EEE1320BD for ; Tue, 29 Aug 2017 19:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SqDHxDW1vXS for ; Tue, 29 Aug 2017 19:03:15 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9C5F126BF3 for ; Tue, 29 Aug 2017 19:03:14 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id a77so22720187qkb.1 for ; Tue, 29 Aug 2017 19:03:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=02jvH5tqYuRSttIYJWbrvNUqe9Gbyh80Ze62j3UWZNY=; b=g8dtw8HO2kLFmGA2S36Xowzy6r29avse6b0VrxnUjPnZg3V92WbRNQrh+GWElBmhRZ 5OYze/jnu5va+r4yvV5Kv8FI9ubV0xLnr6SqFEr3lTLsoaWmFMl3c/D+82maMehY0xbC QyY6SDFdBwtTAWC7jtkWy08bj4VOAYBrjBpDEScAJDiHGPSkQ6QtXpoD+xTUIOF46ZRl IkfgWWl2Pcslv0/8tftNPd9uG6f1lCd40Bwci/BYM/0/42+r1yuae4fK21wIfZh8oVJx Kca2QDCI6/QF9rosm1clCaoiC4MSCd2ZR1PJufc/8vXI/J6avaCKvf+Xw3QKzayVZjmZ gstQ== 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=02jvH5tqYuRSttIYJWbrvNUqe9Gbyh80Ze62j3UWZNY=; b=s4D9Tq1rDiFDjoS/FX48Hw/nQXBr0nO7TH65LuEZjfQE/ftrNA2sNeviZRCsWgBQtz IK543yad+9Na1HIJHFJoDFJsWHl/rQ0cnKZo/d0+NWPPZ+LCmgzbPOxhQ9dp0c8ipgMq AFNc2+y+fMCJa0ogfPn0cKsOI3bJvAf083EEzg+IsE1BiPj5AoaxVivEvpjRiu2o12JO LJXdcv2RUjCm06B2V3xH4SL1Brkcws55hD4IDkDD0S5DQLMmLg9UvEb+1VpKQUwfzJqD ZYFkJBFLQqsbTIAIKaSiU+Bc82n6UKQo2vqL+BUYoFuKX86G6iNaNOg4yE60ot0z3K+E 7s7g== X-Gm-Message-State: AHYfb5ir9IECViMSzCS5x7B86aAv85ydMtyN48lPTwMlr1loZxVU1vb6 hY80kFiP+4UjBPYf3rZPdQ== X-Received: by 10.55.103.151 with SMTP id b145mr8231501qkc.78.1504058593596; Tue, 29 Aug 2017 19:03:13 -0700 (PDT) Received: from cavall.w50.lede.home (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id q88sm2973371qtd.80.2017.08.29.19.03.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Aug 2017 19:03:12 -0700 (PDT) From: Ted Lemon Message-Id: <5C378A81-AB6B-4F2F-8D97-CDED30D788AE@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_35742441-512C-4B16-A871-25F8F5ED881A" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 29 Aug 2017 22:03:10 -0400 In-Reply-To: <150307463977.14156.2178189421671973906@ietfa.amsl.com> Cc: secdir@ietf.org, HOMENET To: Daniel Migault References: <150307463977.14156.2178189421671973906@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-homenet-dot-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 02:03:20 -0000 --Apple-Mail=_35742441-512C-4B16-A871-25F8F5ED881A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks for the review, Daniel. I've included changes based on your = observations inline. On Aug 18, 2017, at 12:43 PM, Daniel Migault = wrote: > Abstract >=20 > This document specifies the behavior that is expected from the = Domain > Name System with regard to DNS queries for names ending with > '.home.arpa.', and designates this domain as a special-use domain > name. 'home.arpa.' is designated for non-unique use in residential > home networks. Home Networking Control Protocol (HNCP) is updated = to > use the 'home.arpa.' domain instead of '.home'. >=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 > MGLT: I would personally start by saying the document defines a > special-use domain name and then defines the behavior.=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 No change > Users and devices within a home network (hereafter "homenet") = require > devices and services to be identified by names that are unique = within > the boundaries of the homenet [RFC7368]. The naming mechanism needs > to function without configuration from the user. While it may be > possible for a name to be delegated by an ISP, homenets must also > function in the absence of such a delegation. A default name with a > scope limited to each individual homenet needs to be used. >=20 > This document corrects an error in [RFC7788], replacing '.home' with > 'home.arpa.' as the default domain-name for homenets. '.home' had > been selected as the most user-friendly option. However, there are > existing uses of '.home' that may be in conflict with this use: > evidence indicates that '.home' queries frequently leak out and = reach > the root name servers [ICANN1] [ICANN2]. >=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 > MGLT: I believe that more important than the leak is that the=20 > introduction of .home in the root zone has been identified as > highly risky. Another reason for not adopting it are also some > uncertainty about its introduction into the root zone. =20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 This is irrelevant, because the IETF hasn't asked ICANN for a = delegation. We deliberately left out this discussion because it's a = moot point now and potentially a political hot potato. I personally = agree with you that this is important, but I think despite its = importance, we got out of that what we needed, and it's better not to = mention it here. > This document registers the domain '.home.arpa.' as a special-use > domain name [RFC6761] and specifies the behavior that is expected > from the Domain Name System with regard to DNS queries for names > whose rightmost non-terminal labels are 'home.arpa.'. Queries for > names ending with '.home.arpa.' are of local significance within the > scope of a homenet, meaning that identical queries will result in > different results from one homenet to another. In other words, a > name ending in 'home.arpa.' is not globally unique. >=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 > MGLT: I think the text mentioned in the beginning of the paragraph=20 > above should be in the abstract. That was the sense of my previous > comment.=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 The point of an abstract is to give a quick summary of what the document = does, not to recapitulate what it does. This is a bit of a hobby horse = for me, so I'm not going to lengthen the abstract to include more = details unless my AD tells me I have to. I do appreciate your point, = but I do not think that the additional text that you are referring to is = necessary in the abstract. > DNS queries for names ending with '.home.arpa.' are resolved using > local resolvers on the homenet. Such queries MUST NOT be = recursively > forwarded to servers outside the logical boundaries of the homenet. >=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 > MGLT: "local resolvers" seems to me mis-leading. Your resolver may > be local but still forward the query to the Global Internet. I do > not see better ways to say it other than inside the boundaries of > the homenet. Maybe we could say: =20 >=20 > DNS queries for names ending with '.home.arpa.' are resolved using > homenet specific resolution mechanisms.=20 >=20 > Eventually an informational reference to the simple naming=20 > architecture may be added so the reader can refer to the doc > for further information. For full disclosure Ted and I are > co-authors. =20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 The document makes this really clear in a later section. The text you = are proposing to add makes it _less_ clear. I do not think this change = is a good idea. > Some service discovery user interfaces that are expected to be used > on homenets conceal information such as domain names from end users. > However, it is still expected that in some cases, users will need to > see, remember, and even type, names ending with 'home.arpa.'. It is > therefore desirable that users identify the domain and understand > that using it expresses the intention to connect to a service that = is > specific to the homenet to which they are connected. Enforcing the > fulfillment of this intention is out of scope for this document. >=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 > MGLT: I have difficulties understanding the paragraph above. If=20 > the idea is to say home.arpa has special meaning that should be > considered by GUIs I would propose the following ordering. >=20 > It is > therefore desirable that users identify the domain and understand > that using it expresses the intention to connect to a service that = is > specific to the homenet to which they are connected.=20 > Some service discovery user interfaces that are expected to be used > on homenets conceal information such as domain names from end users. > However, it is still expected that in some cases, users will need to > see, remember, and even type, names ending with 'home.arpa.'. =20 > Enforcing the > fulfillment of this intention is out of scope for this document. =20= > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 The text here is actually present as a justification for why we wanted = '.home' but didn't get eliminated. I don't think there'd be consensus = to completely eliminated it, but I've clarified it by taking out the = text that I think confused you: Some service discovery user interfaces that are expected to be used on homenets conceal information such as domain names from end users. However, it is still expected that in some cases, users will need to see, remember, and even type, names ending with 'home.arpa.'. The working group hopes that this name will in some way indicate to as many readers as possible that such domain names are referring to devices in the home, but we recognize that it is an imperfect solution. > 2. Application software SHOULD NOT treat names ending in > 'home.arpa.' differently than other names. In particular, there > is no basis for trusting names that are subdomains of > 'home.arpa.' (see Section 6). >=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 > MGLT: a domain name ending in home.arpa may be resolved differently > that a regular domain name. As a result a different treatment is=20 > applied. I think that "treat" means that no special meaning - other > that the domain name is inside the homenet boundaries - should be=20 > associated to a home.arpa. If I am correct I would limit the=20 > consideration to the name rather then the application.=20 > I would suggest the text below: > =09 > names ending in home.arpa SHOULD NOT be associated any other=20 > properties than the affiliation to the homenet. In particular, there > is no basis for trusting names that are subdomains of > 'home.arpa.' (see Section 6). > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 This section is present in accordance with RFC 6761 and is required to = talk about applications, so this change would not make sense in that = context. I agree that talking about applications in this case is = fraught, but with that in mind I think the text is as good as we can do. = I think that your proposed change makes it less clear, because you = haven't said what you mean by "properties." The only property that I = think is really important here is trust, so clarifying that "home.arpa" = does not imply extra trust is important. Think of this in the context = of https://w3c.github.io/webappsec-secure-contexts/ = . This text is to = specifically exclude that sort of assumption, not that I think the W3C = would make such a mistake! > 3. Name resolution APIs and libraries MUST NOT recognize names that > end in '.home.arpa.' as special and MUST NOT treat them > differently. Name resolution APIs MUST send queries for such > names to a recursive DNS server that is configured to be > authoritative for the 'home.arpa.' zone appropriate to the > homenet. =20 >=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 > MGLT: I believe the text below does not concern the library but=20 > the resolver. It is different to say libraries MUST NOT have=20 > specific considerations for home.arpa than a resolution service=20 > that may use different libraries MUST NOT consider the home.arpa > differently.=20 > My understanding of the text below is that the resolver and the > authoritative server for the home.arpa MUST be co-located. The > reasons I think this is not exact is that resolution for=20 > home.arpa can also be provided by other mechanisms than an=20 > authoritative server. Typically, resolution can be done by=20 > requesting Authoritative Servers, Advertising Proxies, Hybrid=20 > Proxies (now called Discovery Proxies).... > The other reason is do not see the text below accurate is that > you may have a DNS Proxy that transparently to the end user split > the resolution between homenet specific resolutions when home.arpa > is encountered while other names are sent to the ISP resolver. > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 No, this text is required by RFC 6761 to address the behavior of local = stub resolvers and resolution libraries. Changing it to talk about = recursive resolvers and proxies would make it incorrect according to = those requirements. That said, I have substantially revised that text = and it may now make more sense to you: 3. Name resolution APIs and libraries MUST NOT recognize names that end in '.home.arpa.' as special and MUST NOT treat them as = having special significance, except that it may be necessary that such APIs not bypass the locally configured recursive resolvers. One or more IP addresses for recursive DNS servers will usually be supplied to the client through router advertisements or DHCP. For an administrative domain that uses names in 'home.arpa.', such as a homenet, the recursive resolvers provided by that domain will be able to answer queries for subdomains of home.arpa; other resolvers will not, or will provide answers = that are not correct within that administrative domain. A host that is configured to use a resolver other than one that has been provided by the local network may be unable to resolve, or may receive incorrect results for, names in sub domains of 'home.arpa.'. In order to avoid this, it is permissible that hosts use the locally-provided resolvers for resolving 'home.arpa.' even when they are configured to use other resolvers. I also added this related text to the security considerations section: In Section 4, item 3, an exception is made to the behavior of stub resolvers allowing them to query local resolvers for subdomains of 'home.arpa.' even when they have been manually configured to use other resolvers. This behavior obviously has security and privacy implications, and may not be desirable depending on the context. It may be better to simply ignore this exception and, when one or more recursive resolvers are configured manually, simply fail to provide correct answers for subdomains of 'home.arpa.'. At this time we do not have operational experience that would guide us in making this decision; implementors are encouraged to consider the context in which their software will be deployed when deciding how to resolve this question. > 4. Caching resolvers conforming to this specification MUST support > DNSSEC queries. While validation is not required, it is = strongly > encouraged; a caching resolver that does not validate answers > that can be validated may cache invalid data; this will prevent > validating stub resolvers from successfully validating answers. > =20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 > MGLT: I see the text above as a recommendation for caching resolvers > in the homenet, but the relation to the home.arpa is unclear to me.=20 > Was the intention to say that names under the home.arpa zone SHOULD=20 > be secured with DNSSEC so caching resolvers MUST support DNSSEC=20 > validation. In addition, these caching resolvers MUST also be able=20 > to be configured with a Trust Anchor for the home.arpa. =20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 The text was actually incorrect. I've substantially rewritten that = item: A. Recursive resolvers at sites using 'home.arpa.' MUST transparently support DNSSEC queries: queries for DNSSEC records and queries with the DO bit set ([RFC4035] section 3.2.1) . While validation is not required, it is strongly encouraged; a caching recursive resolver that does not validate answers that can be validated may cache invalid data; this will prevent validating stub resolvers from successfully validating answers. The other requirements you list are impossible, because we don't have a = mechanism for generating such trust anchors, nor for disambiguating = between different instances of such trust anchors that a host may need = in order to use resources on different homenets. Furthermore, = requiring host changes is out of charter. I agree with you in = principle that this needs to happen, and as you are aware we are working = on addressing this problem, both in homenet and in dnssd. But we can't = address it here. > It is permissible to combine the recursive resolver function for > general DNS lookups with an authoritative resolver for > 'home.arpa.'; in this case, rather than forwarding queries for > subdomains of 'home.arpa.' to an authoritative server, the > caching resolver answers them authoritatively. The behavior = with > respect to forwarding queries specifically for 'home.arpa.' > remains the same. >=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 > MGLT: The full consideration seems to me to be conformance to RFC6303. > In particular the recommendations for DNSSEC in RFC 6303 seems to me > accurated and are not specifically mentioned here. Maybe that should=20= > be clearly stated that all considerations of RFC6303 should be=20 > considered as home.arpa is of local scope.=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 I think you are missing the point of this text. The behavior for = RFC6303 was already specified a few paragraphs earlier, and is required = for all resolvers, not just homenet resolvers. This text is simply = allowing a homenet router implementation to either implement a caching = server and a separate authoritative server, or merge the two into a = hybrid authoritative/recursive server. You can do this today with an = out-of-the-box BIND 9 installation. =20 > 5. No special processing of 'home.arpa.' is required for > authoritative DNS server implementations. It is possible that = an > authoritative DNS server might attempt to check the = authoritative > servers for 'home.arpa.' for a delegation beneath that name > before answering authoritatively for such a delegated name. In > such a case, because the name always has only local significance > there will be no such delegation in the 'home.arpa.' zone, and = so > the server would refuse to answer authoritatively for such a > zone. A server that implements this sort of check MUST be > configurable so that either it does not do this check for the > 'home.arpa.' domain, or it ignores the results of the check. >=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 > MGLT: I understand this as being incorrect. The resolver can also be = configured=20 > with a trust anchor. I would refer to the RFC6303: >=20 > As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA > namespaces, the zones listed above will need to be delegated as > insecure delegations, or be within insecure zones. This will allow > DNSSEC validation to succeed for queries in these spaces despite not > being answered from the delegated servers. >=20 > It is recommended that sites actively using these namespaces secure > them using DNSSEC [RFC4035] by publishing and using DNSSEC trust > anchors. This will protect the clients from accidental import of > unsigned responses from the Internet. =20 > =20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 This text is about authoritative servers, not resolvers. = Locally-served zones are covered under item 4. > The 'home.arpa.' special-use name does not require a special > resolution protocol. Names for which the rightmost two labels = are > 'home.arpa.' are resolved using the DNS protocol [RFC1035]. >=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 > MGLT: If home.arpa are no different than other resolutions and we=20 > start from the root zone responses are likely to be NXDOMAIN. I=20 > think we should clarify that DNS is used as a transport protocol,=20 > but that resolution may be handled differently. > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 No, this is incorrect. The DNS protocol is being used to do = resolution. No host changes are required. > It is not possible to install a trust anchor for this zone in the > '.arpa' zone. The reason for this is that in order to do so, it > would be necessary to have the key-signing key for the zone > ([RFC4034] Section 5). Since the zone is not globally unique, no = one > key would work. >=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 > MGLT: I think that DS is meant rather than trust anchor. > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 A DS record is a trust anchor. I've updated it as follows: It is not possible to install a trust anchor (a DS RR) for this zone = in the '.arpa' zone. The reason for this is that in order to do so, it would be necessary to have the key-signing key for the zone ([RFC4034] Section 5). Since the zone is not globally unique, no one key would work. > An alternative would be to install a authenticated denial of > existence ([RFC4033] Section 3.2). =20 >=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 > MGLT: This is unclear where the denial of existence is set. Is=20 > that in the home.arpa zone or the arpa zone.=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 There is only one place where it can be set. I have updated the text = as follows: An alternative would be to provide a authenticated denial of existence ([RFC4033] Section 3.2). This would be done simply by not having a delegation from the 'arpa.' zone.=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 > MGLT: There are also some privacy issues associated to leaking names > outside the homenet boundaries. For example daniel_smith.home.arpa > reveal the identity of the member of the homenet, my_ipad.home.arpa > reveals the devices you own, the application.=20 This is a known issue, and it's up to the vendors of devices to decide = how much they are willing to reveal. There is work going on in dnssd = to provide a secure way of doing this. It's out of scope for this = document. The document doesn't create a new problem here. > home.arpa may also used in larger environment such as corporate /=20 > private. going from one to the other may also leak such information.=20= Use of home.arpa is for home networks. If a corporate environment uses = it, it's no different than them using some other ad-hoc name. > The leak can be from the homenet to the outside world in which case > one neeed to control the queries sent. But in intruder (or guest)=20 > may also access the homenet and proceed to discovery of the names.=20 > As a result even though homenet is believe to be a trusted = environment,=20 > care should be considered while publishing under the home.arpa. as > well as whose the information is accessible to. =20 Yes, an attacker can suborn your home router, and if they do, your = privacy will be more easily violated. And, as with existing = technology, devices may or may not reveal private information about you = to the network. This is not a problem that we are creating with this = document, and it is not a problem we can solve with this document. = Work to solve this is ongoing; I would prefer to publish this document = now rather than holding it up waiting for that other work. > They might be collision as well. myprinter.home.arpa may be found > in various environments, and upon discovery you may also -=20 > in this example - print confidential information to that printer.=20 > In some case you may not even be aware, for example, if your=20 > printing information failed home, and is re-activated once you=20 > are in another environment. =20 This issue is already documented in the security considerations section. > As information may be sensitive it may be encrypted using IPsec=20 > DTLS as described by dprive for both authentication and = confidentiality.=20 How would we arrange to distribute the trust anchor here? PKI won't = work. I don't see how we would establish trust with IKE either. = Again, work is going on in dnssd to provide an infrastructure that would = allow this, but right now this is empty advice: this is a document about = home networks, operated by end users, so if there isn't a way to do this = automatically, there is no point in saying that end users should do it: = they are never going to read this document. > When the trust anchor is configured in the resolver, these must be > able to roll-over the key and should follows the requirements for = DNSSEC > validators. if it is impossible for a resolver to see the difference=20= > between an attack and a re-key we are in trouble.=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 This is an excellent point, and we should consider it when we write the = document where we explain how to manage these trust anchors. This is = work that I fully intend to do in homenet, but right now this point = doesn't make sense to mention here because this document doesn't provide = an automatic way of setting up trust anchors. > In order to be fully functional, there must be a delegation of > 'home.arpa.' in the '.arpa.' zone [RFC3172]. This delegation MUST > NOT include a DS record, and MUST point to one or more black hole > servers, for example 'blackhole-1.iana.org.' and 'blackhole- > 2.iana.org.'. The reason that this delegation must not be signed is > that not signing the delegation breaks the DNSSEC chain of trust, > which prevents a validating stub resolver from rejecting names > published under 'home.arpa.' on a homenet name server. >=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 > MGLT: The zone home.arpa MUST NOT be seen as belonging to the=20 > homenet. As a result, NS and DS records for home.arpa does not=20 > have meanings outside a specific domain. A Public server outside=20 > the boundaries of the homenet MUST consider this traffic as=20 > irrelevant and sink. =20 >=20 > Redirection to as112 without coordination with as112 operator=20 > may rather be performed using DNAME. I believe more text should=20 > document the two alternative. With the proposed configuration,=20 > the query will be directed to a server that is not authoritative for=20= > the zone. The response is likely to be REFUSED, while in the other=20 > case it is likely to be NXDOMAIN. > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 This document was reviewed extensively in DNSOP. The text specifies = what is supposed to happen. It's not a discussion: it's a directive to = IANA and an explanation for the IAB, which operates .arpa. I cannot = make this change without breaking the document. > 8. IANA Considerations >=20 > IANA is requested to record the domain name 'home.arpa.' in the > Special-Use Domain Names registry [SUDN]. IANA is requested, with > the approval of IAB, to implement the delegation requested in > Section 7. >=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 > MGLT: OK if IANA may make the direct way work. In that case is=20 > there any need to update a registry for zone served by as112?=20 > = %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% = =20 Yes. As far as I know the text gives IANA the information they need to = do; I do not know how they operate their black hole servers, so I am = trusting that these instructions are sufficient. They have been = reviewed by people who understand this problem better than I do, like = Andrew Sullivan, Paul Hoffman and Mark Andrews. I was specifically = advised not to overspecify this. I would rather take their word on = this than yours, if you will forgive my saying so. :) Thanks for the detailed review. I didn't take all of your suggestions = as written, but the document has definitely been improved as a result of = this review. --Apple-Mail=_35742441-512C-4B16-A871-25F8F5ED881A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Thanks for the review, Daniel.   I've = included changes based on your observations inline.

On Aug 18, 2017, at 12:43 PM, Daniel = Migault <daniel.migault@ericsson.com> wrote:
Abstract

=   This document specifies the behavior that is expected from = the Domain
  Name System with regard to DNS = queries for names ending with
  '.home.arpa.', = and designates this domain as a special-use domain
=   name. 'home.arpa.' is designated for non-unique use in = residential
  home networks.  Home = Networking Control Protocol (HNCP) is updated to
=   use the 'home.arpa.' domain instead of '.home'.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%      
MGLT: I would = personally start by saying the document defines a
= special-use domain name and then defines the behavior.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%      

No = change

  Users and devices within a home = network (hereafter "homenet") require
  devices = and services to be identified by names that are unique within
  the boundaries of the homenet [RFC7368]. =  The naming mechanism needs
  to function = without configuration from the user.  While it may be
=   possible for a name to be delegated by an ISP, homenets must = also
  function in the absence of such a = delegation.  A default name with a
  scope = limited to each individual homenet needs to be used.

  This document corrects an error in [RFC7788], = replacing '.home' with
  'home.arpa.' as the = default domain-name for homenets. '.home' had
=   been selected as the most user-friendly option. =  However, there are
  existing uses of = '.home' that may be in conflict with this use:
=   evidence indicates that '.home' queries frequently leak out = and reach
  the root name servers [ICANN1] = [ICANN2].

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   
MGLT: I believe that more important = than the leak is that the
introduction of .home in the = root zone has been identified as
highly risky. Another = reason for not adopting it are also some
uncertainty = about its introduction into the root zone.    
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   

This is irrelevant, because the IETF hasn't asked ICANN = for a delegation.   We deliberately left out this discussion = because it's a moot point now and potentially a political hot potato. =   I personally agree with you that this is important, but I think = despite its importance, we got out of that what we needed, and it's = better not to mention it here.

=   This document registers the domain '.home.arpa.' as a = special-use
  domain name [RFC6761] and = specifies the behavior that is expected
  from = the Domain Name System with regard to DNS queries for names
=   whose rightmost non-terminal labels are 'home.arpa.'. =  Queries for
  names ending with '.home.arpa.' = are of local significance within the
  scope of = a homenet, meaning that identical queries will result in
=   different results from one homenet to another.  In = other words, a
  name ending in 'home.arpa.' is = not globally unique.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   
MGLT: I think the text mentioned in = the beginning of the paragraph
above should be in the = abstract. That was the sense of my previous
comment.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%      

The point = of an abstract is to give a quick summary of what the document does, not = to recapitulate what it does.   This is a bit of a hobby horse for = me, so I'm not going to lengthen the abstract to include more details = unless my AD tells me I have to.   I do appreciate your point, but = I do not think that the additional text that you are referring to is = necessary in the abstract.

  DNS = queries for names ending with '.home.arpa.' are resolved using
  local resolvers on the homenet.  Such = queries MUST NOT be recursively
  forwarded to = servers outside the logical boundaries of the homenet.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   
MGLT: "local resolvers" seems to me = mis-leading. Your resolver may
be local but still forward = the query to the Global Internet. I do
not see better ways = to say it other than inside the boundaries of
the homenet. = Maybe we could say:   

=   DNS queries for names ending with '.home.arpa.' are resolved = using
  homenet specific resolution mechanisms. =

Eventually an informational reference to = the simple naming
architecture may be added so the reader = can refer to the doc
for further information. For full = disclosure Ted and I are
co-authors.  
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   

The document makes this really clear in a later = section.   The text you are proposing to add makes it _less_ clear. =   I do not think this change is a good idea.

  Some service discovery user interfaces that are = expected to be used
  on homenets conceal = information such as domain names from end users.
=   However, it is still expected that in some cases, users will = need to
  see, remember, and even type, names = ending with 'home.arpa.'.  It is
=   therefore desirable that users identify the domain and = understand
  that using it expresses the = intention to connect to a service that is
=   specific to the homenet to which they are connected. =  Enforcing the
  fulfillment of this = intention is out of scope for this document.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   
MGLT: I have difficulties = understanding the paragraph above. If
the idea is to say = home.arpa has special meaning that should be
considered by = GUIs I would propose the following ordering.

It is
  therefore desirable that = users identify the domain and understand
  that = using it expresses the intention to connect to a service that is
  specific to the homenet to which they are = connected.
Some service discovery user interfaces that = are expected to be used
  on homenets conceal = information such as domain names from end users.
=   However, it is still expected that in some cases, users will = need to
  see, remember, and even type, names = ending with 'home.arpa.'.  
Enforcing the
  fulfillment of this intention is out of scope = for this document.   
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   

The text here is actually present as a justification = for why we wanted '.home' but didn't get eliminated.   I don't = think there'd be consensus to completely eliminated it, but I've = clarified it by taking out the text that I think confused = you:

    Some =
service discovery user interfaces that are expected to be used
    on homenets conceal information such as domain names from end users.
    However, it is still expected that in some cases, users will need to
    see, remember, and even type, names ending with 'home.arpa.'.  The
    working group hopes that this name will in some way indicate to as
    many readers as possible that such domain names are referring to
    devices in the home, but we recognize that it is an imperfect
    solution.

  2. =  Application software SHOULD NOT treat names ending in
=       'home.arpa.' differently than other = names.  In particular, there
=       is no basis for trusting names that = are subdomains of
=       'home.arpa.' (see Section 6).

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   
MGLT: a domain name ending in = home.arpa may be resolved differently
that a regular = domain name. As a result a different treatment is
applied. = I think that "treat" means that no special meaning - other
that the domain name is inside the homenet boundaries - = should be
associated to a home.arpa. If I am correct I = would limit the
consideration to the name rather then the = application.
I would suggest the text below:
=
names ending in home.arpa SHOULD NOT be associated = any other
properties than the affiliation to the homenet. = In particular, there
=       is no basis for trusting names that = are subdomains of
=       'home.arpa.' (see Section 6).
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   

This section is present in accordance with RFC 6761 and = is required to talk about applications, so this change would not make = sense in that context.   I agree that talking about applications in = this case is fraught, but with that in mind I think the text is as good = as we can do.   I think that your proposed change makes it less = clear, because you haven't said what you mean by "properties."   = The only property that I think is really important here is trust, so = clarifying that "home.arpa" does not imply extra trust is important. =   Think of this in the context of https://w3c.github.io/webappsec-secure-contexts/.   = This text is to specifically exclude that sort of assumption, not that I = think the W3C would make such a mistake!

  3.  Name resolution APIs and libraries MUST NOT = recognize names that
=       end in '.home.arpa.' as special and = MUST NOT treat them
=       differently.  Name resolution = APIs MUST send queries for such
=       names to a recursive DNS server that = is configured to be
=       authoritative for the 'home.arpa.' = zone appropriate to the
=       homenet.  

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   
MGLT: I believe the text below does = not concern the library but
the resolver. It is different = to say libraries MUST NOT have
specific considerations = for home.arpa than a resolution service
that may use = different libraries MUST NOT consider the home.arpa
differently.
My understanding of the text = below is that the resolver and the
authoritative server = for the home.arpa MUST be co-located. The
reasons I think = this is not exact is that resolution for
home.arpa can = also be provided by other mechanisms than an
authoritative = server. Typically, resolution can be done by
requesting = Authoritative Servers, Advertising Proxies, Hybrid
Proxies = (now called Discovery Proxies)....
The other reason is do = not see the text below accurate is that
you may have a DNS = Proxy that transparently to the end user split
the = resolution between homenet specific resolutions when home.arpa
is encountered while other names are sent to the ISP = resolver.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   

No, this text is required by RFC 6761 to address the = behavior of local stub resolvers and resolution libraries.   = Changing it to talk about recursive resolvers and proxies would make it = incorrect according to those requirements.   That said, I have = substantially revised that text and it may now make more sense to = you:

    3.  Name =
resolution APIs and libraries MUST NOT recognize names that
        end in '.home.arpa.' as special and MUST NOT treat them as =
having
        special significance, except that it may be necessary that such
        APIs not bypass the locally configured recursive =
resolvers.
        One or more IP addresses for recursive DNS =
servers will usually
        be supplied to the client through router advertisements or DHCP.
        For an administrative domain that uses names in 'home.arpa.',
        such as a homenet, the recursive resolvers provided by that
        domain will be able to answer queries for subdomains of
        home.arpa; other resolvers will not, or will provide answers =
that
        are not correct within that administrative domain.
    =
    A host that is configured to use a resolver other than one that
        has been provided by the local network may be unable to resolve,
        or may receive incorrect results for, names in sub domains of
        'home.arpa.'.  In order to avoid this, it is permissible that
        hosts use the locally-provided resolvers for resolving
        'home.arpa.' even when they are configured to use other
        resolvers.
I also added this related text = to the security considerations section:

    In Section =
4, item 3, an exception is made to the behavior of stub
    resolvers allowing them to query local resolvers for subdomains of
    'home.arpa.' even when they have been manually configured to use
    other resolvers.  This behavior obviously has security and privacy
    implications, and may not be desirable depending on the context.  It
    may be better to simply ignore this exception and, when one or more
    recursive resolvers are configured manually, simply fail to provide
    correct answers for subdomains of 'home.arpa.'.  At this time we do
    not have operational experience that would guide us in making this
    decision; implementors are encouraged to consider the context in
    which their software will be deployed when deciding how to resolve
    this question.
  4.  Caching = resolvers conforming to this specification MUST support
=       DNSSEC queries.  While = validation is not required, it is strongly
=       encouraged; a caching resolver that = does not validate answers
=       that can be validated may cache = invalid data; this will prevent
=       validating stub resolvers from = successfully validating answers.
=   
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   
MGLT: I see the text above as a = recommendation for caching resolvers
in the homenet, but = the relation to the home.arpa is unclear to me.
Was the = intention to say that names under the home.arpa zone SHOULD
be secured with DNSSEC so caching resolvers MUST support = DNSSEC
validation. In addition, these caching resolvers = MUST also be able
to be configured with a Trust Anchor = for the home.arpa.   
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   

The text was actually incorrect.   I've = substantially rewritten that item:

        A.  Recursive resolvers at sites using 'home.arpa.'  =
MUST
            transparently support DNSSEC queries: queries for DNSSEC
            records and queries with the DO bit set ([RFC4035] section
            3.2.1) .  While validation is not required, it is strongly
            encouraged; a caching recursive resolver that does not
            validate answers that can be validated may cache invalid
            data; this will prevent validating stub resolvers from
            successfully validating answers.

The other requirements you list are = impossible, because we don't have a mechanism for generating such trust = anchors, nor for disambiguating between different instances of such = trust anchors that a host may need in order to use resources on = different homenets.   Furthermore, requiring host changes is out of = charter.   I agree with you in principle that this needs to happen, = and as you are aware we are working on addressing this problem, both in = homenet and in dnssd.   But we can't address it here.

      It is = permissible to combine the recursive resolver function for
=       general DNS lookups with an = authoritative resolver for
=       'home.arpa.'; in this case, rather = than forwarding queries for
=       subdomains of 'home.arpa.' to an = authoritative server, the
=       caching resolver answers them = authoritatively.  The behavior with
=       respect to forwarding queries = specifically for 'home.arpa.'
=       remains the same.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   
MGLT: The full consideration seems = to me to be conformance to RFC6303.
In particular the = recommendations for DNSSEC in RFC 6303 seems to me
accurated= and are not specifically mentioned here. Maybe that should
be clearly stated that all considerations of RFC6303 should = be
considered as home.arpa is of local scope.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   

I think you are missing the point of this text. =  The behavior for RFC6303 was already specified a few paragraphs = earlier, and is required for all resolvers, not just homenet resolvers. =   This text is simply allowing a homenet router implementation to = either implement a caching server and a separate authoritative server, = or merge the two into a hybrid authoritative/recursive server.   = You can do this today with an out-of-the-box BIND 9 = installation.
   
  5.  No special processing of 'home.arpa.' = is required for
=       authoritative DNS server = implementations.  It is possible that an
=       authoritative DNS server might = attempt to check the authoritative
=       servers for 'home.arpa.' for a = delegation beneath that name
=       before answering authoritatively for = such a delegated name.  In
=       such a case, because the name always = has only local significance
=       there will be no such delegation in = the 'home.arpa.' zone, and so
=       the server would refuse to answer = authoritatively for such a
=       zone.  A server that implements = this sort of check MUST be
=       configurable so that either it does = not do this check for the
=       'home.arpa.' domain, or it ignores = the results of the check.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   
MGLT: I understand this as being = incorrect. The resolver can also be configured
with a = trust anchor. I would refer to the RFC6303:

= As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA
=   namespaces, the zones listed above will need to be delegated = as
  insecure delegations, or be within = insecure zones.  This will allow
  DNSSEC = validation to succeed for queries in these spaces despite not
  being answered from the delegated servers.

  It is recommended that sites = actively using these namespaces secure
  them = using DNSSEC [RFC4035] by publishing and using DNSSEC trust
=   anchors.  This will protect the clients from = accidental import of
  unsigned responses from = the Internet. =   
  
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   

This text is about authoritative servers, not = resolvers.   Locally-served zones are covered under item = 4.

     The = 'home.arpa.' special-use name does not require a special
=      resolution protocol.  Names for which = the rightmost two labels are
=      'home.arpa.' are resolved using the DNS = protocol [RFC1035].

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   
MGLT: If home.arpa are no different = than other resolutions and we
start from the root zone = responses are likely to be NXDOMAIN. I
think we should = clarify that DNS is used as a transport protocol,
but = that resolution may be handled differently.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   

No, this is incorrect.   The DNS protocol is being = used to do resolution.   No host changes are = required.

  It is not possible to = install a trust anchor for this zone in the
=   '.arpa' zone.  The reason for this is that in order to = do so, it
  would be necessary to have the = key-signing key for the zone
  ([RFC4034] = Section 5).  Since the zone is not globally unique, no one
  key would work.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%      
MGLT: I think that = DS is meant rather than trust anchor.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   

A DS record is a trust anchor.   I've updated it = as follows:

  It is not possible to = install a trust anchor (a DS RR) for this zone in the
  '.arpa' zone.  The reason for this is that = in order to do so, it
  would be necessary to = have the key-signing key for the zone
  ([RFC4034]= Section 5).  Since the zone is not globally unique, no one
  key would work.

  An alternative would be to = install a authenticated denial of
  existence = ([RFC4033] Section 3.2).  

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%      
MGLT: This is = unclear where the denial of existence is set. Is
that in = the home.arpa zone or the arpa zone.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   

There is only one place where it can be set.   I = have updated the text as follows:
    An =
alternative would be to provide a authenticated denial of
    existence ([RFC4033] Section 3.2).  This would be done simply by not
    having a delegation from the 'arpa.' zone.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%      
MGLT: There are = also some privacy issues associated to leaking names
outside= the homenet boundaries. For example daniel_smith.home.arpa
reveal the identity of the member of the homenet, = my_ipad.home.arpa
reveals the devices you own, the = application.

This is a known issue, and it's up to the vendors of = devices to decide how much they are willing to reveal.   There is = work going on in dnssd to provide a secure way of doing this.   = It's out of scope for this document.   The document doesn't create = a new problem here.

home.arpa may also used in = larger environment such as corporate /
private. going = from one to the other may also leak such information.

Use of = home.arpa is for home networks.   If a corporate environment uses = it, it's no different than them using some other ad-hoc = name.

The leak can be from the homenet to the = outside world in which case
one neeed to control the = queries sent. But in intruder (or guest)
may also access = the homenet and proceed to discovery of the names.
As a = result even though homenet is believe to be a trusted environment,
care should be considered while publishing under the = home.arpa. as
well as whose the information is accessible = to.   

Yes, an attacker can suborn your home router, and if = they do, your privacy will be more easily violated.   And, as with = existing technology, devices may or may not reveal private information = about you to the network.   This is not a problem that we are = creating with this document, and it is not a problem we can solve with = this document.   Work to solve this is ongoing; I would prefer to = publish this document now rather than holding it up waiting for that = other work.

They might be collision as = well. myprinter.home.arpa may be found
in various = environments, and upon discovery you may also -
in this = example - print confidential information to that printer.
In some case you may not even be aware, for example, if your =
printing information failed home, and is re-activated = once you
are in another environment.  

This issue = is already documented in the security considerations = section.

As information may be = sensitive it may be encrypted using IPsec
DTLS as = described by dprive for both authentication and confidentiality.

How would = we arrange to distribute the trust anchor here?   PKI won't work. =   I don't see how we would establish trust with IKE either.   = Again, work is going on in dnssd to provide an infrastructure that would = allow this, but right now this is empty advice: this is a document about = home networks, operated by end users, so if there isn't a way to do this = automatically, there is no point in saying that end users should do it: = they are never going to read this document.

When the trust anchor is configured in the resolver, these = must be
able to roll-over the key and should follows the = requirements for DNSSEC
validators. if it is impossible = for a resolver to see the difference
between an attack = and a re-key we are in trouble.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%   

This is an excellent point, and we should consider it = when we write the document where we explain how to manage these trust = anchors.   This is work that I fully intend to do in homenet, but = right now this point doesn't make sense to mention here because this = document doesn't provide an automatic way of setting up trust = anchors.

  In order to be fully = functional, there must be a delegation of
=   'home.arpa.' in the '.arpa.' zone [RFC3172].  This = delegation MUST
  NOT include a DS record, and = MUST point to one or more black hole
  servers, = for example 'blackhole-1.iana.org.' and 'blackhole-
=   2.iana.org.'. =  The reason that this delegation must not be signed is
=   that not signing the delegation breaks the DNSSEC chain of = trust,
  which prevents a validating stub = resolver from rejecting names
  published under = 'home.arpa.' on a homenet name server.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%      
MGLT: The zone = home.arpa MUST NOT be seen as belonging to the
homenet. = As a result, NS and DS records for home.arpa does not
have = meanings outside a specific domain. A Public server outside
the boundaries of the homenet MUST consider this traffic as =
irrelevant and sink.    

Redirection to as112 without coordination with as112 operator =
may rather be performed using DNAME. I believe more text = should
document the two alternative. With the proposed = configuration,
the query will be directed to a server = that is not authoritative for
the zone. The response is = likely to be REFUSED, while in the other
case it is = likely to be NXDOMAIN.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%      

This = document was reviewed extensively in DNSOP.   The text specifies = what is supposed to happen.   It's not a discussion: it's a = directive to IANA and an explanation for the IAB, which operates .arpa. =   I cannot make this change without breaking the = document.

8.  IANA = Considerations

  IANA is = requested to record the domain name 'home.arpa.' in the
=   Special-Use Domain Names registry [SUDN].  IANA is = requested, with
  the approval of IAB, to = implement the delegation requested in
  Section = 7.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%      
MGLT: OK if IANA = may make the direct way work. In that case is
there any = need to update a registry for zone served by as112?
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%      

Yes. =   As far as I know the text gives IANA the information they need to = do; I do not know how they operate their black hole servers, so I am = trusting that these instructions are sufficient.   They have been = reviewed by people who understand this problem better than I do, like = Andrew Sullivan, Paul Hoffman and Mark Andrews.   I was = specifically advised not to overspecify this.   I would rather take = their word on this than yours, if you will forgive my saying so. = :)

Thanks for the detailed review. =   I didn't take all of your suggestions as written, but the = document has definitely been improved as a result of this = review.

= --Apple-Mail=_35742441-512C-4B16-A871-25F8F5ED881A-- From nobody Wed Aug 30 08:22:16 2017 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 8B0961326FE; Wed, 30 Aug 2017 08:22:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Matthew Miller To: Cc: draft-ietf-teas-pce-central-control.all@ietf.org, ietf@ietf.org, teas@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150410652452.21632.6924902183838903689@ietfa.amsl.com> Date: Wed, 30 Aug 2017 08:22:04 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-teas-pce-central-control-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 15:22:05 -0000 Reviewer: Matthew Miller Review result: Has Nits 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. Document: Reviewer: Matthew A. Miller Review Date: 2017-08-30 IETF LC End Date: 2017-08-25 IESG Telechat date: 2017-08-31 Summary: This document is ready for publication as Informational, with one potential nit. This document describes an overall architecture (with some variants) utilizing central PCE-based controller for SDN, and its implication on PCEP. The document notes the tradeoffs between the variants, including some of the vulnerabilities. My nit is in the Security Considerations; I'm not sure how likely in practice a central controller architecture will be operated with "higher level of security", and therefore not sure it's worth calling out like this. I can see how a central controller makes management easier, and that has a potential benefit of better visibility into the network's operation and finding problems (including security-related) sooner and better. Otherwise I think the rest of this section addresses the concerns that a central controller architecture has. From nobody Wed Aug 30 11:11:11 2017 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 B7FDC1326EA; Wed, 30 Aug 2017 11:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 TWIR_MLUpWMf; Wed, 30 Aug 2017 11:11:07 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0103.outbound.protection.outlook.com [104.47.38.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13A53132355; Wed, 30 Aug 2017 11:11:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=h0HId4kAMVZIL8nr6O7Pg/+aClZ8o7CakDNWAaPeiY8=; b=LYMie2bNCCtsMY9ccaSoAn3fwjcrpMgHhkpR08Zw7msKxhauHqbAFCcltUl+ZtUSDI2Pd7PeDBm/AAiE6EWagOzT82yjynFZ1F6by25xdt46uEWfxPlJMDfsvssFweYd+OCQd/IDQN71wQoZ4+ZTsG6ElHaqBVkoW6lpLHOtrVs= Received: from CO2PR05MB971.namprd05.prod.outlook.com (10.141.226.17) by CO2PR05MB668.namprd05.prod.outlook.com (10.141.230.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.2; Wed, 30 Aug 2017 18:11:04 +0000 Received: from CO2PR05MB971.namprd05.prod.outlook.com ([10.141.226.17]) by CO2PR05MB971.namprd05.prod.outlook.com ([10.141.226.17]) with mapi id 15.20.0013.005; Wed, 30 Aug 2017 18:11:04 +0000 From: Adrian Farrel To: Matthew Miller , "secdir@ietf.org" CC: "draft-ietf-teas-pce-central-control.all@ietf.org" , "ietf@ietf.org" , "teas@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-teas-pce-central-control-04 Thread-Index: AQHTIaO9swi/FejJaU6mn0gkr6jvyqKdMj5w Date: Wed, 30 Aug 2017 18:11:04 +0000 Message-ID: References: <150410652452.21632.6924902183838903689@ietfa.amsl.com> In-Reply-To: <150410652452.21632.6924902183838903689@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=afarrel@juniper.net; x-originating-ip: [193.110.55.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO2PR05MB668; 6:PSyP2gD04QaumuEeYzOEvUMA0iErn9ngaixYAE7dlQxq8wv/0DKyO4zW7hfOjcVctZ9XkxSwSmxh7/i9VY0vil0C0uCL9krXbpsD3F7T+CYZ9RSNoUHO3SNiQdm6E9R7ORBHAnCNB3WVmuy/I3y6vwV4slljAxmuA6Zq0BnBUButxb5a+Grrus/TrSE0QhlELODWlIHFUTmzR9HqaYsI8E1e0mm2nv/Bn/y2P5THb3qvDpN5O7wukx+N4elnLG3iTftoroBXV0ZC/JfimfIi1PwlmSTh1StFaA5qEf5pHMmvaaaBP4gdI3fZB62EBjTupDhxC/SLoZcTuORl/ASP4Q==; 5:xtp7Iy1Te7cJ5qf49Moa8vSNqx+9C7fqi616E+FKusCmWV4Q5lZa04caY1Q6hN1hcEyTaWyD6AVVVf6jG7dynDSj9rlyzEyeo0/ipUqkhyAWTilxipLqDMFx6f26DkCNYfF1yk1jpi35O70PhNG02w==; 24:nSncw90/TdaNsYjubfENV9qHCEfRdAxpRaAHslUd94AvibcK22/Bd4dxcrtSz/zY0E0/v8jOObPI6O1Puhge9Ycr8H/252S2OqIC6bhNoj0=; 7:+97kWB2Vc5JwDnL62BxkSrstxOm5WVbM5vRAOwHwIRScF0+7JSQMkoxJcIxVZKmUI4R6u7KSB9MqzXEo6twckAzWiN7dncaTvL4WNufds7mWGgDSO0b5fERFERdBqJvqWr+su/Dek0MfLdnEuTjnp63spRzb/XvicNUCd21PVCdgjUOTR0bpP7UKNb3ogczr0X82efI45bdPYMgXnD/kFDsb3fqejo2Jryw23jtHxTw= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 67763ad8-6349-4e68-4dc6-08d4efd27ab7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CO2PR05MB668; x-ms-traffictypediagnostic: CO2PR05MB668: x-exchange-antispam-report-test: UriScan:(192374486261705); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123562025)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CO2PR05MB668; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CO2PR05MB668; x-forefront-prvs: 041517DFAB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(13464003)(377424004)(189002)(199003)(74316002)(97736004)(4326008)(105586002)(2906002)(106356001)(33656002)(7696004)(3660700001)(230783001)(3280700002)(229853002)(6436002)(7736002)(76176999)(77096006)(305945005)(54356999)(6506006)(50986999)(2950100002)(66066001)(101416001)(5660300001)(53546010)(68736007)(2501003)(189998001)(14454004)(99286003)(55016002)(8676002)(6116002)(3846002)(81156014)(81166006)(102836003)(9686003)(54906002)(53936002)(8936002)(478600001)(25786009)(86362001)(6246003)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB668; H:CO2PR05MB971.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2017 18:11:04.5367 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB668 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-teas-pce-central-control-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 18:11:10 -0000 VGhhbmtzIE1hdHRoZXcsDQoNClRoZSBwb2ludCBJIHdhcyBhaW1pbmcgZm9yIGlzIHRoYXQgY29u dHJvbCBwbGFuZXMgYXJlIG9mdGVuIG9wZXJhdGVkIHdpdGggYSAiZG9tYWluIG9mIHRydXN0IiBv ciAiY2hhaW4gb2YgdHJ1c3QiIG1vZGVsIChmb3IgYmV0dGVyIG9yIHdvcnNlKSBidXQgdGhhdCBt YW5hZ2VtZW50IHN5c3RlbXMgYXJlIG9mdGVuIG9wZXJhdGVkIHdpdGggc2VjdXJlIGNoYW5uZWxz IGJldHdlZW4gbWFuYWdlbWVudCBzdGF0aW9uIGFuZCBtYW5hZ2VkIG5vZGUuDQoNCkkgdGhpbmss IGluIG90aGVyIHdvcmRzLCB0aGF0IHRoZSBwb2ludCBjb3ZlcmVkIGJ5IHRoZSB0ZXh0IGlzIHRy dWUgaW4gdG9kYXkncyBuZXR3b3Jrcy4NCg0KQmVzdCwNCkFkcmlhbg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWF0dGhldyBNaWxsZXIgW21haWx0bzpsaW51eHdvbGYraWV0 ZkBvdXRlci1wbGFuZXMubmV0XSANClNlbnQ6IDMwIEF1Z3VzdCAyMDE3IDE2OjIyDQpUbzogc2Vj ZGlyQGlldGYub3JnDQpDYzogZHJhZnQtaWV0Zi10ZWFzLXBjZS1jZW50cmFsLWNvbnRyb2wuYWxs QGlldGYub3JnOyBpZXRmQGlldGYub3JnOyB0ZWFzQGlldGYub3JnDQpTdWJqZWN0OiBTZWNkaXIg bGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLXRlYXMtcGNlLWNlbnRyYWwtY29udHJvbC0w NA0KDQpSZXZpZXdlcjogTWF0dGhldyBNaWxsZXINClJldmlldyByZXN1bHQ6IEhhcyBOaXRzDQoN CkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRp cmVjdG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBi ZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuICBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4g cHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMu ICBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1l bnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQpEb2N1bWVudDoN ClJldmlld2VyOiBNYXR0aGV3IEEuIE1pbGxlcg0KUmV2aWV3IERhdGU6IDIwMTctMDgtMzANCklF VEYgTEMgRW5kIERhdGU6IDIwMTctMDgtMjUNCklFU0cgVGVsZWNoYXQgZGF0ZTogMjAxNy0wOC0z MQ0KDQpTdW1tYXJ5Og0KDQpUaGlzIGRvY3VtZW50IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbiBh cyBJbmZvcm1hdGlvbmFsLCB3aXRoIG9uZSBwb3RlbnRpYWwgbml0Lg0KDQpUaGlzIGRvY3VtZW50 IGRlc2NyaWJlcyBhbiBvdmVyYWxsIGFyY2hpdGVjdHVyZSAod2l0aCBzb21lIHZhcmlhbnRzKSB1 dGlsaXppbmcgY2VudHJhbCBQQ0UtYmFzZWQgY29udHJvbGxlciBmb3IgU0ROLCBhbmQgaXRzIGlt cGxpY2F0aW9uIG9uIFBDRVAuICBUaGUgZG9jdW1lbnQgbm90ZXMgdGhlIHRyYWRlb2ZmcyBiZXR3 ZWVuIHRoZSB2YXJpYW50cywgaW5jbHVkaW5nIHNvbWUgb2YgdGhlIHZ1bG5lcmFiaWxpdGllcy4N Cg0KTXkgbml0IGlzIGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9uczsgSSdtIG5vdCBzdXJl IGhvdyBsaWtlbHkgaW4gcHJhY3RpY2UgYSBjZW50cmFsIGNvbnRyb2xsZXIgYXJjaGl0ZWN0dXJl IHdpbGwgYmUgb3BlcmF0ZWQgd2l0aCAiaGlnaGVyIGxldmVsIG9mIHNlY3VyaXR5IiwgYW5kIHRo ZXJlZm9yZSBub3Qgc3VyZSBpdCdzIHdvcnRoIGNhbGxpbmcgb3V0IGxpa2UgdGhpcy4NCg0KSSBj YW4gc2VlIGhvdyBhIGNlbnRyYWwgY29udHJvbGxlciBtYWtlcyBtYW5hZ2VtZW50IGVhc2llciwg YW5kIHRoYXQgaGFzIGEgcG90ZW50aWFsIGJlbmVmaXQgb2YgYmV0dGVyIHZpc2liaWxpdHkgaW50 byB0aGUgbmV0d29yaydzIG9wZXJhdGlvbiBhbmQgZmluZGluZyBwcm9ibGVtcyAoaW5jbHVkaW5n IHNlY3VyaXR5LXJlbGF0ZWQpIHNvb25lciBhbmQgYmV0dGVyLg0KDQpPdGhlcndpc2UgSSB0aGlu ayB0aGUgcmVzdCBvZiB0aGlzIHNlY3Rpb24gYWRkcmVzc2VzIHRoZSBjb25jZXJucyB0aGF0IGEg Y2VudHJhbCBjb250cm9sbGVyIGFyY2hpdGVjdHVyZSBoYXMuDQoNCg0K From nobody Wed Aug 30 12:59:46 2017 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 3F9FF132A05 for ; Wed, 30 Aug 2017 12:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGu3Gxirtpqj for ; Wed, 30 Aug 2017 12:59:39 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEBB1132A90 for ; Wed, 30 Aug 2017 12:59:33 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id a77so32582850qkb.1 for ; Wed, 30 Aug 2017 12:59:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=DMVHSy26eDrZrGZsLMN4dKz0sxT5lbw5HeL6W2am+Bw=; b=HLi7Pb5rWOss42Ny9zAssRLRMJJjZcGvLFF47VoASdMgoRdwuKmC59vZ/iR3xUZBjz X1ACURs+c9FrRBAuFSMKsk79c6R5FP+Ja82tNGtBz5Gc+8yQQ6yVt7EvqxoV4BZl7vbr Eqkj3LxQybCQvdM+r7Y03kHBtzFPKZ+5qcl18CRfBTkzRZg3TmljEE9PCPwvQDaJfdm2 A+Zj9SgR0N45M8yPPdPiDweJrlNeCgihR09R4NxX6CBtOFr1tEc332nIVgkCniw2/Bwt AKdSXvU2Lrz6QhnwQRomHYIQ/VLBBQZ9jSIdlsQN494ojcwZaefH2nAkiTTdMVP718/T NryA== 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=DMVHSy26eDrZrGZsLMN4dKz0sxT5lbw5HeL6W2am+Bw=; b=UjY13OF8g6cdTVRq+NRmhFOccBBXooED6NfWggyTNYK6g/blQZcl+abmriy4/c8T3F JDEcYh2+wlQEPdpnjU9eMz3vBNi/qjMzfT28VjrwzBHiJn6EL6y8k7+1VF7wREfjzAjk K1OQUIX/0xyse+zvEayHT4JVOHql2o45BUdq7y53a/rQaCxp6pERzsiAoQXfncAdFdBM r2QyApPLeEoA25c1BBqhnY35z2UicVnMFAmKVBU6KoCcIJPvCsT83CQcpSJoNV5LByZN 3kqAg7Ujt2hOHSGXHoJD8RCFEQQ3S0EAivXWEcfQndxjz1vbjhB17y2vSndXpOP1Cdgp sdWw== X-Gm-Message-State: AHYfb5ggyQBxIT/C9vTOThg/gjf4NSpJL2GmHP8WnSPHeb5LA39Fpvgz Bip4tTXDuTn2GcOz X-Received: by 10.55.204.214 with SMTP id n83mr606536qkl.47.1504123172957; Wed, 30 Aug 2017 12:59:32 -0700 (PDT) Received: from cavall.ether.lede.home (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id a63sm4292956qkb.45.2017.08.30.12.59.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Aug 2017 12:59:32 -0700 (PDT) From: Ted Lemon Message-Id: <7561B4DC-2695-4A2A-B61C-C8ACD7431638@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_EC046B7F-F20A-49A9-A87E-8BA05B33CB26" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 30 Aug 2017 15:59:31 -0400 In-Reply-To: <5C378A81-AB6B-4F2F-8D97-CDED30D788AE@fugue.com> Cc: secdir@ietf.org, HOMENET To: Daniel Migault References: <150307463977.14156.2178189421671973906@ietfa.amsl.com> <5C378A81-AB6B-4F2F-8D97-CDED30D788AE@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-homenet-dot-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 19:59:40 -0000 --Apple-Mail=_EC046B7F-F20A-49A9-A87E-8BA05B33CB26 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 29, 2017, at 10:03 PM, Ted Lemon wrote: > Yes. As far as I know the text gives IANA the information they need = to do; I do not know how they operate their black hole servers, so I am = trusting that these instructions are sufficient. They have been = reviewed by people who understand this problem better than I do, like = Andrew Sullivan, Paul Hoffman and Mark Andrews. I was specifically = advised not to overspecify this. I would rather take their word on = this than yours, if you will forgive my saying so. :) Argh. Warren made me look more closely, and you were right. Sorry = for doubting. :] Here is the new text for the IANA considerations = section: IANA is further requested to create a new subregistry within the = "Locally-Served DNS Zones" registry , titled = "Transport-Independent Locally-Served DNS Zones", with the same format as the other subregistries. IANA = is requested to add an entry in this new registry for 'home.arpa.' with the description = "Homenet Special-Use Domain", listing this document as the reference. --Apple-Mail=_EC046B7F-F20A-49A9-A87E-8BA05B33CB26 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Aug 29, 2017, at 10:03 PM, Ted Lemon <mellon@fugue.com> = wrote:
Yes.   As far as I know the = text gives IANA the information they need to do; I do not know how they = operate their black hole servers, so I am trusting that these = instructions are sufficient.   They have been reviewed by people = who understand this problem better than I do, like Andrew Sullivan, Paul = Hoffman and Mark Andrews.   I was specifically advised not to = overspecify this.   I would rather take their word on this than = yours, if you will forgive my saying so. = :)

Argh. =   Warren made me look more closely, and you were right.   = Sorry for doubting.   :]   Here is the new text for the IANA = considerations section:

IANA is further requested to create a new = subregistry within the "Locally-Served DNS
= Zones" = registry <xref target=3D"LSDZ"/>, titled "Transport-Independent = Locally-Served DNS
Zones", with the same format as the other = subregistries.  IANA is requested to add an
entry in this new registry for 'home.arpa.' = with the description "Homenet Special-Use
= Domain", = listing this document as the reference.

= --Apple-Mail=_EC046B7F-F20A-49A9-A87E-8BA05B33CB26-- From nobody Thu Aug 31 00:49:40 2017 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 D51901320D9; Thu, 31 Aug 2017 00:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 vBe-JsMnZ77K; Thu, 31 Aug 2017 00:49:31 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.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 6B9FB1320B5; Thu, 31 Aug 2017 00:49:31 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 263D83494AF; Thu, 31 Aug 2017 07:49:24 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 13B4B160044; Thu, 31 Aug 2017 07:49:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E7AD2160053; Thu, 31 Aug 2017 07:49:23 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id RWv2cLCSIFtI; Thu, 31 Aug 2017 07:49:23 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 90CB7160044; Thu, 31 Aug 2017 07:49:23 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id EFC3B83DAC59; Thu, 31 Aug 2017 17:49:20 +1000 (AEST) To: Ted Lemon Cc: Daniel Migault , HOMENET , secdir@ietf.org From: Mark Andrews References: <150307463977.14156.2178189421671973906@ietfa.amsl.com> <5C378A81-AB6B-4F2F-8D97-CDED30D788AE@fugue.com> <7561B4DC-2695-4A2A-B61C-C8ACD7431638@fugue.com> In-reply-to: Your message of "Wed, 30 Aug 2017 15:59:31 -0400." <7561B4DC-2695-4A2A-B61C-C8ACD7431638@fugue.com> Date: Thu, 31 Aug 2017 17:49:20 +1000 Message-Id: <20170831074920.EFC3B83DAC59@rock.dv.isc.org> Archived-At: Subject: Re: [secdir] [homenet] Secdir last call review of draft-ietf-homenet-dot-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 07:49:33 -0000 In message <7561B4DC-2695-4A2A-B61C-C8ACD7431638@fugue.com>, Ted Lemon writes: > > On Aug 29, 2017, at 10:03 PM, Ted Lemon wrote: > > Yes. As far as I know the text gives IANA the information they need > > to do; I do not know how they operate their black hole servers, so I am > > trusting that these instructions are sufficient. They have been > > reviewed by people who understand this problem better than I do, like > > Andrew Sullivan, Paul Hoffman and Mark Andrews. I was specifically > > advised not to overspecify this. I would rather take their word on this > > than yours, if you will forgive my saying so. :) > > Argh. Warren made me look more closely, and you were right. Sorry for > doubting. :] Here is the new text for the IANA considerations section: > > IANA is further requested to create a new subregistry within the > "Locally-Served DNS Zones" registry , titled > "Transport-Independent Locally-Served DNS Zones", with the same > format as the other subregistries. IANA is requested to add an > entry in this new registry for 'home.arpa.' with the description > "Homenet Special-Use Domain", listing this document as the reference. It is up to IANA as to how they implement the delegation. We just specify the requirements (insecure delegation to a empty zone). We don't need to prescribe *where* leaked traffic is sunk. IANA has decades of experience with moving traffic flows if needed. The simplest delegation is back to the servers for .arpa. The servers can be updated by IANA if/when they need to sink the traffic somewhere else. The AS112 server however not the set of servers to sink the traffic too as they are not under IANA's control and there is no way to get them all to serve home.arpa. If there is another round I would remove , and MUST point to one or more black hole servers, for example 'blackhole-1.iana.org.' and 'blackhole- 2.iana.org.' as it is a over specification. Just let IANA manage it. B.T.W. blackhole-1.iana.org and blackhole-2.iana.org aren't really blackholes as they respond to queries. Operators if blackhole-1.iana.org and blackhole-2.iana.org are required to ensure that they do answer and to withdraw routing anouncements for them when they fail to do so. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Aug 31 04:32:46 2017 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 42D7B132D56 for ; Thu, 31 Aug 2017 04:32: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYcr_0Btahqu for ; Thu, 31 Aug 2017 04:32:42 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39190132D64 for ; Thu, 31 Aug 2017 04:32:42 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id v20so1532621qtg.3 for ; Thu, 31 Aug 2017 04:32:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=XzYoKjdkYY8KC+ausGT3XQEVT06A0lz1n+DLyE9Pt9M=; b=fUqEcuIjzUPxgRGnGVi+ajEwV6TBgI5TV6piv4OtuSjPnwNJB81vWe9tC+EIk1owPG UcnmcZlwrz/Nx64TuBJuBz0hCK+gy5+Eolc0XwKqT+KvKVUokApyNJ0XH3+8oESaprQm BciIAg+7Y/YouSCEiQ6A2wl5CcjTC5iyOZAPwBEKyj71jnzfnRTHK7fmBAnblAJJhmdP kk73GXqZ88L1KFhUR8GNlzOiD/0Ohss+yFRaCLhDNbG9l4fRS5k+Dp99jPclt9J7Yf58 xZRk/DVxbtycDnnL0Y65XZkCC3p/hgyTGtQ28ktv8WEs0w1ni5Tj1K+He1VoUoUybXdE aa9g== 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=XzYoKjdkYY8KC+ausGT3XQEVT06A0lz1n+DLyE9Pt9M=; b=q9KMfPaKTenDzOcA4xnNPqdxpnDom6eJq6pB1yHWI7gD4dvO7dMjV9cj+ILPfIG9/A O3D7bBt5KBSln+8dc53k5xLPJiwo1UXL2SvmLmJ7M3IVJxauVpoA89hrdeOMdTW79K04 nXQF04FbuxVNxnIZNqAUEhCsqnH3YurjpFU4DuF+L+0GaoEIxXz6NeiumasepWgOTr9P tX3soB7Jy8fTMM5vlTr8qooaKH8YYzS6AGmM0jJkZe7Y+rgbexmFtsnECg7KxoJzvPRX OG0iBEO7Wiz5zYyqzOwUYbp7ALOTVarOUene0M7LH281VhUTYk2ShxGmytDEfApw9S/3 /1YA== X-Gm-Message-State: AHYfb5h1f1/DOVAE2hiRBZUZwua80TKM/pEGOqembvJHK7/RT2PF/Gn/ hIhgTxlexL9xuaj/ X-Received: by 10.200.23.236 with SMTP id r41mr6751021qtk.160.1504179161414; Thu, 31 Aug 2017 04:32:41 -0700 (PDT) Received: from cavall.w50.lede.home (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id j185sm5124884qkf.62.2017.08.31.04.32.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Aug 2017 04:32:40 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_4D9348B0-ACB1-4351-B8C8-BFFCDCF39413" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 31 Aug 2017 07:32:38 -0400 In-Reply-To: <20170831074920.EFC3B83DAC59@rock.dv.isc.org> Cc: Daniel Migault , HOMENET , secdir@ietf.org To: Mark Andrews References: <150307463977.14156.2178189421671973906@ietfa.amsl.com> <5C378A81-AB6B-4F2F-8D97-CDED30D788AE@fugue.com> <7561B4DC-2695-4A2A-B61C-C8ACD7431638@fugue.com> <20170831074920.EFC3B83DAC59@rock.dv.isc.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [secdir] [homenet] Secdir last call review of draft-ietf-homenet-dot-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 11:32:44 -0000 --Apple-Mail=_4D9348B0-ACB1-4351-B8C8-BFFCDCF39413 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Aug 31, 2017, at 3:49 AM, Mark Andrews wrote: > as it is a over specification. Just let IANA manage it. This makes sense--thanks! --Apple-Mail=_4D9348B0-ACB1-4351-B8C8-BFFCDCF39413 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Aug 31, 2017, at 3:49 AM, Mark Andrews <marka@isc.org> = wrote:
as it is a over = specification.  Just let IANA manage it.

This = makes sense--thanks!

= --Apple-Mail=_4D9348B0-ACB1-4351-B8C8-BFFCDCF39413-- From nobody Thu Aug 31 04:51:00 2017 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 77221132D66; Thu, 31 Aug 2017 04:50:59 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 IIy2UYfFb6er; Thu, 31 Aug 2017 04:50:57 -0700 (PDT) Received: from mail-wr0-x244.google.com (mail-wr0-x244.google.com [IPv6:2a00:1450:400c:c0c::244]) (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 7F34F132D56; Thu, 31 Aug 2017 04:50:56 -0700 (PDT) Received: by mail-wr0-x244.google.com with SMTP id z91so312527wrc.1; Thu, 31 Aug 2017 04:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=IojoS93a5TXRrky61mZENVkR/mQVSy/CNiuTPOKWrMA=; b=n99ItV50/nvLG9xNUQkfud/8Ti4dVN08EMfYFBXsf9DxrnTARoH1hq1wjt31hdy6S8 07xnOSA5SNXeRPnR+x3SH55wytOCMAVFsUThE7D9H4VPChbIR3OjixSXle8hEtSeCFRy eauSryf7MwslUf54XM9Q2Bl4wV8FN3gtzYT2nOPpSIA6ps21rIDvNvkz7a3vO5MAQGWz sd9OpW1Jwp5sZOdig4/BYa9vjFMyec5Dw7D4xlWVy0PpnQwVv0md9n+psoNyeXLFy4lY vvDP/zRNXn6Wq7YbVMCoJhfGgWetj1Gol4lCiua9HFbfveH292n3ACWrxui1D9LI9Ypt m5ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=IojoS93a5TXRrky61mZENVkR/mQVSy/CNiuTPOKWrMA=; b=pTraKf48EAAfXPKQVzoIN7H6hIuJajvvb3zYFCMrtAR2wChCTuIgPf4gCWfDbwrTSE RVOB6qomr6GjedkyRfblIypGZgVLrXiP2oCtYdUHTYK2xg5cq8bHlxzqm7H9u7ko6wv4 edyoCTBIv3MDKsJerFsKQ38IQplb/2Iyk2PTbjeuV0qOKIMrRim0Shst1fjOu7tHS9bU EUfNHriUS4sL9oKJgou+gWc7gMmeUZ8d0mj7U6hlaEgTEjEO6HNSSdpyznYilvXA4ek0 yvaUbkDE4z2etXR/ZHUIl9mxISFsJ1yr5j8PNpLuQN0hawulnwP/gP7yEMVVFwnG949u g5JA== X-Gm-Message-State: AHYfb5gw/Ra0IRP8jayA4a5Lm6V7+6YxNEXw9IkofdK3KlamyHrbwNio wm3c5Kx/GUT/LQ== X-Google-Smtp-Source: ADKCNb6zGDtVG7OHtwgYW4+zKqIb5+sFGtGIpyZPfL0m4hg31R7TZg3ArAffmZT7XPhdnkHepJTYKw== X-Received: by 10.223.134.240 with SMTP id 45mr3529558wry.49.1504180254993; Thu, 31 Aug 2017 04:50:54 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id 6sm6607234wre.0.2017.08.31.04.50.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Aug 2017 04:50:54 -0700 (PDT) To: Tero Kivinen Cc: iesg@ietf.org, secdir@ietf.org, draft-ietf-pals-p2mp-pw.all@tools.ietf.org, "mpls-chairs@ietf.org" , Kathleen Moriarty , "pals-chairs@tools.ietf.org" References: <201708270627.v7R6RLjk004141@fireball.acr.fi> <201708280757.v7S7vZxH028695@fireball.acr.fi> From: Stewart Bryant Message-ID: <29b3a151-0a79-d2f0-c051-35396010e2c6@gmail.com> Date: Thu, 31 Aug 2017 12:50:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <201708280757.v7S7vZxH028695@fireball.acr.fi> Content-Type: multipart/alternative; boundary="------------6A6C156384623AEE55035A9D" Content-Language: en-GB Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-pals-p2mp-pw-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 11:50:59 -0000 This is a multi-part message in MIME format. --------------6A6C156384623AEE55035A9D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit How about if we changed the security text to something of the form: In general the security measures described in [RFC4447bis ] are adequate for this protocol. However the use of MD5 as the method of securing an LDP control plane is no longer considered adequately secure. Implementations should be written in such a way that they can migrate to a more secure cryptographic hash function when that function is agreed as the new default hash for LDP. - Stewart (speaking as Shepherd) On 28/08/2017 08:57, Tero Kivinen wrote: > Stewart Bryant writes: >> Tero >> >> Thank you for your comment. >> >> I believe that it if wrong to hold this document hostage to a security >> issue that applies to a major MPLS protocol widely used throughout the >> Internet. > I agree on that, but I think the text claiming "security is adequate" > in the security considerations section is also wrong, so it should be > fixed to include note explaining what you explained below: > >> The right way to address the problem is via an update to the security of >> LDP (in the MPLS WG) and have that specification update the RFCs that >> use LDP. >> >> If an attacker were able to use the vulnerability in MD5 as a vector to >> attack LDP, I doubt that this relatively low key aspect of pseudowires >> would be their first priority. > I.e., current security is using MD5, which is not considered safe, but > this document will be able to use the better security mechanisms when > they are defined, and there are better targets to attack if attacker > is able to break MD5 based security... > >> Regards >> >> - Stewart >> >> >> On 27/08/2017 07:27, Tero Kivinen 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 describes the mechanims to signal point-to-multipoint >>> pseudowires using LDP. The security considerations section simply >>> points to the RFC4447bis (i.e., RFC8077) saying that security >>> mechanisms described there are adequate. >>> >>> On the other hand RFC8077, says that LDP MD5 authentication key option >>> as described in the section 2.9 of RFC5036 MUST be implemented. The >>> section 2.9 of RFC5036 describes TCP MD5 signature option for LDP. >>> This might have been adequate security for some protocol in 2007 (when >>> RFC5036 was published, altought MD5 was already then known to be >>> broken), but it IS NOT adequate security in 2017. >>> >>> I understand that this document is not really the one supposed to >>> update the security option for the LDP, but there is >>> draft-ijln-mpls-rfc5036bis which is moving LDP to internet standard >>> still trying to keep the same broken MD5 based security in it. I think >>> this document should include note saying, that security of the RFC5036 >>> is no longer adequate for any use because it uses broken security >>> protocol, but there is nothing better out there yet (or is there, I do >>> not know enough of the LDP to know that), and perhaps point to the >>> rfc5036bis also in hopes that it might some day fix the security of >>> the LDP. >>> >>> I think this document (or whole PW and LDP system) has issues that >>> needs to be fixed before it can be published. --------------6A6C156384623AEE55035A9D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


How about if we changed the security text to something of the form:

In general the security measures described in [RFC4447bis] are adequate for this
protocol. However the use of MD5 as the method of securing an LDP
control plane is no longer considered adequately secure. Implementations should be
written in such a way that they can migrate to a more secure cryptographic
hash function when that function is agreed as the new default hash for LDP.

- Stewart
(speaking as Shepherd)
On 28/08/2017 08:57, Tero Kivinen wrote:
Stewart Bryant writes:

Tero

Thank you for your comment.

I believe that it if wrong to hold this document hostage to a security 
issue that applies to a major MPLS protocol widely used throughout the 
Internet.

I agree on that, but I think the text claiming "security is adequate"
in the security considerations section is also wrong, so it should be
fixed to include note explaining what you explained below:


The right way to address the problem is via an update to the security of 
LDP (in the MPLS WG) and have that specification update the RFCs that 
use LDP.

If an attacker were able to use the vulnerability in MD5 as a vector to 
attack LDP, I doubt that this relatively low key aspect of pseudowires 
would be their first priority.

I.e., current security is using MD5, which is not considered safe, but
this document will be able to use the better security mechanisms when
they are defined, and there are better targets to attack if attacker
is able to break MD5 based security... 


Regards

- Stewart


On 27/08/2017 07:27, Tero Kivinen 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 describes the mechanims to signal point-to-multipoint
pseudowires using LDP. The security considerations section simply
points to the RFC4447bis (i.e., RFC8077) saying that security
mechanisms described there are adequate.

On the other hand RFC8077, says that LDP MD5 authentication key option
as described in the section 2.9 of RFC5036 MUST be implemented. The
section 2.9 of RFC5036 describes TCP MD5 signature option for LDP.
This might have been adequate security for some protocol in 2007 (when
RFC5036 was published, altought MD5 was already then known to be
broken), but it IS NOT adequate security in 2017.

I understand that this document is not really the one supposed to
update the security option for the LDP, but there is
draft-ijln-mpls-rfc5036bis which is moving LDP to internet standard
still trying to keep the same broken MD5 based security in it. I think
this document should include note saying, that security of the RFC5036
is no longer adequate for any use because it uses broken security
protocol, but there is nothing better out there yet (or is there, I do
not know enough of the LDP to know that), and perhaps point to the
rfc5036bis also in hopes that it might some day fix the security of
the LDP.

I think this document (or whole PW and LDP system) has issues that
needs to be fixed before it can be published.


    

    

  


--------------6A6C156384623AEE55035A9D--


From nobody Thu Aug 31 12:57:01 2017
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 C88F0132DFA; Thu, 31 Aug 2017 12:56:31 -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, 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 4TjFHUYB99IE; Thu, 31 Aug 2017 12:56:21 -0700 (PDT)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 F35DF1329BD; Thu, 31 Aug 2017 12:56:20 -0700 (PDT)
Received: from [169.254.114.42] (50-1-98-42.dsl.dynamic.fusionbroadband.com [50.1.98.42]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v7VJtFvh099562 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 31 Aug 2017 12:55:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 50-1-98-42.dsl.dynamic.fusionbroadband.com [50.1.98.42] claimed to be [169.254.114.42]
From: "Paul Hoffman" 
To: "Mark Andrews" 
Cc: HOMENET , secdir@ietf.org
Date: Thu, 31 Aug 2017 12:56:17 -0700
Message-ID: <81929571-D70C-45D3-9A67-38EF54DF0DA9@vpnc.org>
In-Reply-To: <20170831074920.EFC3B83DAC59@rock.dv.isc.org>
References: <150307463977.14156.2178189421671973906@ietfa.amsl.com> <5C378A81-AB6B-4F2F-8D97-CDED30D788AE@fugue.com> <7561B4DC-2695-4A2A-B61C-C8ACD7431638@fugue.com> <20170831074920.EFC3B83DAC59@rock.dv.isc.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.6r5347)
Archived-At: 
Subject: Re: [secdir] [homenet] Secdir last call review of draft-ietf-homenet-dot-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Aug 2017 19:56:32 -0000

On 31 Aug 2017, at 0:49, Mark Andrews wrote:

> In message <7561B4DC-2695-4A2A-B61C-C8ACD7431638@fugue.com>, Ted Lemon 
> writes:
>>
>> On Aug 29, 2017, at 10:03 PM, Ted Lemon  wrote:
>>> Yes.   As far as I know the text gives IANA the information they 
>>> need
>>> to do; I do not know how they operate their black hole servers, so I 
>>> am
>>> trusting that these instructions are sufficient.   They have been
>>> reviewed by people who understand this problem better than I do, 
>>> like
>>> Andrew Sullivan, Paul Hoffman and Mark Andrews.   I was specifically
>>> advised not to overspecify this.   I would rather take their word on 
>>> this
>>> than yours, if you will forgive my saying so. :)
>>
>> Argh.   Warren made me look more closely, and you were right.   Sorry 
>> for
>> doubting.   :]   Here is the new text for the IANA considerations 
>> section:
>>
>> 	IANA is further requested to create a new subregistry within the
>> 	"Locally-Served DNS Zones" registry , titled
>> 	"Transport-Independent Locally-Served DNS Zones", with the same
>> 	format as the other subregistries.  IANA is requested to add an
>> 	entry in this new registry for 'home.arpa.' with the description
>> 	"Homenet Special-Use Domain", listing this document as the 
>> reference.
>
> It is up to IANA as to how they implement the delegation.

I could be wrong, but I think it is up to the IAB how they implement the 
delegations in .arpa. The sentences above are just about the registry, 
not about the DNS.

--Paul Hoffman


From nobody Thu Aug 31 15:50:55 2017
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 0CC9A132F2A for ; Thu, 31 Aug 2017 15:50:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, 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 1KCSqnZkil1g for ; Thu, 31 Aug 2017 15:50:52 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 9BE47132E26 for ; Thu, 31 Aug 2017 15:50:51 -0700 (PDT)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v7VMolEC015453 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 1 Sep 2017 01:50:47 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v7VMoluE001058; Fri, 1 Sep 2017 01:50:47 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <22952.37575.299245.614169@fireball.acr.fi>
Date: Fri, 1 Sep 2017 01:50:47 +0300
From: Tero Kivinen 
To: Stewart Bryant 
Cc: iesg@ietf.org, secdir@ietf.org, draft-ietf-pals-p2mp-pw.all@tools.ietf.org, "mpls-chairs\@ietf.org" , Kathleen Moriarty , "pals-chairs\@tools.ietf.org" 
In-Reply-To: <29b3a151-0a79-d2f0-c051-35396010e2c6@gmail.com>
References: <201708270627.v7R6RLjk004141@fireball.acr.fi>  <201708280757.v7S7vZxH028695@fireball.acr.fi> <29b3a151-0a79-d2f0-c051-35396010e2c6@gmail.com>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 2 min
X-Total-Time: 1 min
Archived-At: 
Subject: Re: [secdir] Secdir review of draft-ietf-pals-p2mp-pw-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Aug 2017 22:50:54 -0000

Stewart Bryant writes:
> How about if we changed the security text to something of the form:
> 
> In general the security measures described in [RFC4447bis] are
> adequate for this protocol. However the use of MD5 as the method of
> securing an LDP control plane is no longer considered adequately
> secure. Implementations should be written in such a way that they
> can migrate to a more secure cryptographic hash function when that
> function is agreed as the new default hash for LDP.

Looks mostly good, except I would say "... can migrate to more secure
authentication algorithm when ...", i.e., the next authentication
method to be used in the LDP might not be simple hash based
authentication algorithm. 
-- 
kivinen@iki.fi


From nobody Thu Aug 31 16:09:52 2017
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 4F50A132A89; Thu, 31 Aug 2017 16:09:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.119
X-Spam-Level: 
X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] 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 Lsc0TMFz8zxz; Thu, 31 Aug 2017 16:09:50 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 B7166132FB9; Thu, 31 Aug 2017 16:09:47 -0700 (PDT)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v7VN9jHq017392 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 1 Sep 2017 02:09:45 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v7VN9jl9009650; Fri, 1 Sep 2017 02:09:45 +0300 (EEST)
Resent-From: kivinen@iki.fi
Resent-Message-ID: <22952.38713.497174.495741@fireball.acr.fi>
Resent-Date: Fri, 1 Sep 2017 02:09:45 +0300
Resent-To: secdir@ietf.org, iesg@ietf.org, draft-ietf-pce-rfc6006bis.all@ietf.org
Thread-Topic: Secdir review of draft-ietf-pce-rfc6006bis
Thread-Index: AQHTE+LwKl1xiooPeEezcBh2V63s7Q==
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-MS-Exchange-Organization-RecordReviewCfmType: 0
x-ms-publictraffictype: Email
From: Charlie Kaufman 
To: "secdir\@ietf.org" , "iesg\@ietf.org" , "draft-ietf-pce-rfc6006bis.all\@tools.ietf.org" 
Content-Type: multipart/alternative; boundary="_000_CY4PR1701MB1926723B19518B2895C016D9DF8F0CY4PR1701MB1926_"
MIME-Version: 1.0
X-Edit-Time: 1 min
X-Total-Time: 0 min
Archived-At: 
Subject: [secdir] Secdir review of draft-ietf-pce-rfc6006bis
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
Date: Thu, 31 Aug 2017 23:09:51 -0000
X-Original-Date: Sun, 13 Aug 2017 03:24:19 +0000
X-List-Received-Date: Thu, 31 Aug 2017 23:09:51 -0000

--_000_CY4PR1701MB1926723B19518B2895C016D9DF8F0CY4PR1701MB1926_
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. Document =
editors and WG chairs should treat these comments just like any other last =
call comments.


Summary: No significant security issues



This document is a "refreshing" of rfc6006 (Extensions to PCEP for Point-to=
-Multipoint Traffic Engineering Label Switched Paths) to incorporate errata=
 that have accumulated over the last seven years. There may be some small a=
dditional changes.


One minor change was made to Security considerations, and it was a good cha=
nge, but I fear makes the security considerations somewhat internally incon=
sistent. That change was to change a recommendation to use TCP-AO to a reco=
mmendation to use TLS. TLS is a more logical protocol to use in this contex=
t, but the security considerations also references RFC5440, what mandates T=
CP-MD5 and recommends TCP-AO (which was not available when RFC5440 was writ=
ten).


I'm not sure the best way to resolve this... probably to leave it as is. So=
meday, RFC5440 should be updated.


Security considerations in this document discusses that dangers of someone =
impersonating a client for the purpose of denying service or learning about=
 the network configuration, and RFC5440 talks about that dangers of eavesdr=
opping in learning what the client is doing. It does not discuss whether th=
ere are important threats posed by someone impersonating a PCEP server and =
returning bad routing information. I suspect that might be a more serious t=
hreat then either of the other attacks, but don't know enough about how the=
 protocol is used to know for sure.


In any case, all the considerations mentioned above probably belong in RFC5=
440 (PCEP) rather than this document concerning extensions.


 --Charlie Kaufman



--_000_CY4PR1701MB1926723B19518B2895C016D9DF8F0CY4PR1701MB1926_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <3D5A08764AF066458FD8E67D1935B24C@namprd17.prod.outlook.com>
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. =
Document editors and WG chairs should treat these comments just like any ot=
her last call comments.







Summary: No significant security issues









This document is a "refreshing" of rfc6006 (Extensions to PCEP=
 for Point-to-Multipoint Traffic Engineering Label Switched Paths) to incor=
porate errata that have accumulated over the last seven years. There may be=
 some small additional changes.







One minor change was made to Security considerations, and it was a good =
change, but I fear makes the security considerations somewhat internally in=
consistent. That change was to change a recommendation to use TCP-AO to a r=
ecommendation to use TLS. TLS is
 a more logical protocol to use in this context, but the security considera=
tions also references RFC5440, what mandates TCP-MD5 and recommends TCP-AO =
(which was not available when RFC5440 was written).







I'm not sure the best way to resolve this... probably to leave it as is.=
 Someday, RFC5440 should be updated.







Security considerations in this document discusses that dangers of someo=
ne impersonating a client for the purpose of denying service or learning ab=
out the network configuration, and RFC5440 talks about that dangers of eave=
sdropping in learning what the client
 is doing. It does not discuss whether there are important threats posed by=
 someone impersonating a PCEP server and returning bad routing information.=
 I suspect that might be a more serious threat then either of the other att=
acks, but don't know enough about
 how the protocol is used to know for sure.







In any case, all the considerations mentioned above probably belong in R=
FC5440 (PCEP) rather than this document concerning extensions.






--Charlie Kaufman












--_000_CY4PR1701MB1926723B19518B2895C016D9DF8F0CY4PR1701MB1926_--


From nobody Thu Aug 31 16:40:24 2017
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 9EFB4133035 for ; Thu, 31 Aug 2017 16:40:22 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Tero Kivinen 
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.59.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-to: secdir-secretary@mit.edu
Message-ID: <150422282264.4683.11620898705453686414.idtracker@ietfa.amsl.com>
Date: Thu, 31 Aug 2017 16:40:22 -0700
Archived-At: 
Subject: [secdir] Assignments
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Aug 2017 23:40:23 -0000

Review instructions and related resources are at:
http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

For telechat 2017-08-31

Reviewer               LC end     Draft
Ólafur Guðmundsson     2017-08-15 draft-ietf-sidr-rpki-validation-reconsidered-08
Ben Laurie             2017-08-23 draft-ietf-pce-pce-initiated-lsp-10

For telechat 2017-09-14

Reviewer               LC end     Draft
Daniel Franke          2017-07-30 draft-ietf-curdle-ssh-dh-group-exchange-05
Daniel Gillmor         2017-07-30 draft-ietf-curdle-des-des-des-die-die-die-04
Dan Harkins            2017-08-09 draft-ietf-bess-evpn-etree-13
Sandra Murphy          2017-09-01 draft-ietf-mpls-ldp-mrt-06
Hilarie Orman          2017-09-14 draft-ietf-tsvwg-ecn-experimentation-05
Radia Perlman          2017-09-14 draft-ietf-taps-transports-usage-udp-05
Derrell Piper          2017-09-14 draft-ietf-taps-transports-usage-08

Last calls:

Reviewer               LC end     Draft
Phillip Hallam-Baker   2017-08-11 draft-ietf-rtcweb-jsep-22
Russ Mundy             2017-09-14 draft-spinosa-urn-lex-11
Yoav Nir               2017-09-27 draft-kille-ldap-xmpp-schema-01
Magnus Nystrom         2017-09-13 draft-ietf-dcrup-dkim-usage-04
Tim Polk               2017-09-11 draft-ietf-kitten-rfc5653bis-05
Vincent Roca           2017-09-11 draft-ietf-curdle-rsa-sha2-10
Tom Yu                 2017-07-25 draft-ietf-lamps-rfc5280-i18n-update-02
Tom Yu                 2017-02-20 draft-ietf-slim-negotiating-human-language-13

Early review requests:

Reviewer               Due        Draft
Daniel Gillmor         2016-02-01 draft-ietf-rtcweb-security-08

Next in the reviewer rotation:

  Joseph Salowey
  Rich Salz
  Stefan Santesson
  Yaron Sheffer
  Rifaat Shekh-Yusef
  Melinda Shore
  Robert Sparks
  Takeshi Takahashi
  Tina Tsou
  Sean Turner


From nobody Thu Aug 31 22:13:31 2017
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 3FECB1330FA; Thu, 31 Aug 2017 22:13:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 lSI4J1Ow4ejT; Thu, 31 Aug 2017 22:13:27 -0700 (PDT)
Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C42D1330F1; Thu, 31 Aug 2017 22:13:27 -0700 (PDT)
Received: by mail-qk0-x230.google.com with SMTP id l65so6711163qkc.0; Thu, 31 Aug 2017 22:13:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=hXs3loFdPVPq7sdxo8PdFl4JOab3FjWd9RMQiRS7Qfw=; b=IeS54nkLl6QHavY0BJsjt8ACPX3MNwj4Med6mkWrL9C8txWn6uG72U7EH5SV/ygyrc taTF9pdG7Z6oR+f6Lwss6PeldICg3WrqTRk5j+0Bnglc72eoCwlnQY6Yq2f04c506elx 6ZX80svpP4KatQWKZ1ctDfK39QiOgGjNwBHG7siI3S8FVK+mq4LysTKDRBzjLqD22O6j RzsyyJvblDPbgcO6B8hT/OPZAdt+VM5ZVuvE6nU04OErhgH1ldDwOA+ZF0Janv9K4xtO 6P3HPGEg1/aB2QQUPyqAxfqljfMV7FcSIeqTcWh5TfFhLT3e5ixcXkBKEAch5b/A67Gw WFmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=hXs3loFdPVPq7sdxo8PdFl4JOab3FjWd9RMQiRS7Qfw=; b=oH2SMBNlo+jMT12rEvIhvq/0OAwD9EadApaZ6UvU3rhr85VPdQ2k1OdvlSQVSfA1hp 09n81iWw16sJSBZNL7UlaGuceM4tSD09X9iFW4b6xGQ9DnYBm+xVM4mByo/CRhC5XAnH 0AO3Qkjdj7OSgo5xnr1NfDM9rB4ptnPkVcdVwC5dlhI1FLmac8v9a7v8Ky1UVWCjhM1W gpGA5hC94Ci5Jy5Y6Z6z2hutGtDq85rcUmBMbaAPakzQEZMtsbs1okb8yeW5tSmnhwBX aBknI8sBugyGh5gopNLQRgAtGtMWs7744X+trQEMGxEvKOOfE14XVdcm8Rt7hpZWseNU f2zw==
X-Gm-Message-State: AHPjjUgeEaeV71DTCrKbfXOdESDJd73YilmK/pq1llbAVEkw/w/CKnMK npOqwkco5N0IDCtA4rs/ViCtwH4DiA==
X-Google-Smtp-Source: ADKCNb4kGQtXH6cLqlmS3g3r55Dl5nVL/kiPvkE8xAITfCoBWUTtDrxsgbRSJCE2OfK+JmQzE+FlCiSHkwEMhQF7NSM=
X-Received: by 10.55.41.69 with SMTP id p66mr1098798qkh.109.1504242806113; Thu, 31 Aug 2017 22:13:26 -0700 (PDT)
MIME-Version: 1.0
Sender: dhruvdhody@gmail.com
X-Google-Sender-Delegation: dhruvdhody@gmail.com
Received: by 10.140.107.73 with HTTP; Thu, 31 Aug 2017 22:13:25 -0700 (PDT)
In-Reply-To: 
References: 
From: Dhruv Dhody 
Date: Fri, 1 Sep 2017 10:43:25 +0530
X-Google-Sender-Auth: lOl3Wosb4yAGggf8nU2boT08_ng
Message-ID: 
To: Charlie Kaufman 
Cc: "secdir@ietf.org" , "iesg@ietf.org" ,  "draft-ietf-pce-rfc6006bis.all@tools.ietf.org" ,  "BRUNGARD, DEBORAH A" , pce-chairs@ietf.org,  "dhruv.dhody@huawei.com" 
Content-Type: multipart/alternative; boundary="001a1147af321d4bc8055819d2e4"
Archived-At: 
Subject: Re: [secdir] Secdir review of draft-ietf-pce-rfc6006bis
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Sep 2017 05:13:29 -0000

--001a1147af321d4bc8055819d2e4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Charlie,

Thanks for your review and comments. Eric also raised similar concerns and
I proposed this as the updated text as what can be a part of a bid document
for a PCEP extension -

5.  Security Considerations

   As described in [RFC5862], P2MP path computation requests are more
   CPU-intensive and also utilize more link bandwidth.  In the event of
   an unauthorized P2MP path computation request, or a denial of service
   attack, the subsequent PCEP requests and processing may be disruptive
   to the network.  Consequently, it is important that implementations
   conform to the relevant security requirements that specifically help
   to minimize or negate unauthorized P2MP path computation requests and
   denial of service attacks.  These mechanisms include:

   o  Securing the PCEP session requests and responses is RECOMMENDED
      using TCP security techniques such as TCP Authentication Option
      (TCP-AO) [RFC5925] or using Transport Layer Security (TLS) [I-
      D.ietf-pce-pceps], as per the recommendations and best current
      practices in [RFC7525].

   o  Authenticating the PCEP requests and responses to ensure the
      message is intact and sent from an authorized node using TCP-AO or
      TLS is RECOMMENDED.

   o  Providing policy control by explicitly defining which PCCs, via IP
      access-lists, are allowed to send P2MP path requests to the PCE.

   PCEP operates over TCP, so it is also important to secure the PCE and
   PCC against TCP denial of service attacks.

   As stated in [RFC6952], PCEP implementations should support TCP-AO
   [RFC5925] and not use TCP-MD5 because of the known vulnerabilities
   and weakness.

You can see the diff at - https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-pc=
e-
rfc6006bis-03&url2=3Dhttps://raw.githubusercontent.com/
dhruvdhody-huawei/ietf/master/draft-ietf-pce-rfc6006bis-04.txt

Let me know if you have any modification suggestions here.

See inline...


On Sun, Aug 13, 2017 at 8:54 AM, Charlie Kaufman  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.
> Document editors and WG chairs should treat these comments just like any
> other last call comments.
>
>
> Summary: No significant security issues
>
>
> This document is a "refreshing" of rfc6006 (Extensions to PCEP for
> Point-to-Multipoint Traffic Engineering Label Switched Paths) to
> incorporate errata that have accumulated over the last seven years. There
> may be some small additional changes.
>
>
> One minor change was made to Security considerations, and it was a good
> change, but I fear makes the security considerations somewhat internally
> inconsistent. That change was to change a recommendation to use TCP-AO to=
 a
> recommendation to use TLS. TLS is a more logical protocol to use in this
> context, but the security considerations also references RFC5440, what
> mandates TCP-MD5 and recommends TCP-AO (which was not available when
> RFC5440 was written).
>
>
> I'm not sure the best way to resolve this... probably to leave it as is.
> Someday, RFC5440 should be updated.
>
>
> Security considerations in this document discusses that dangers of
> someone impersonating a client for the purpose of denying service or
> learning about the network configuration, and RFC5440 talks about that
> dangers of eavesdropping in learning what the client is doing. It does
> not discuss whether there are important threats posed by someone
> impersonating a PCEP server and returning bad routing information. I
> suspect that might be a more serious threat then either of the other
> attacks, but don't know enough about how the protocol is used to know for
> sure.
>
>
> =E2=80=8BRFC5440 has this text -

   Attacks on PCEP may result in damage to active networks.  If path
   computation responses are changed, the PCC may be encouraged to set
   up inappropriate LSPs.  Such LSPs might deviate to parts of the
   network susceptible to snooping, or might transit congested or
   reserved links.  Path computation responses may be attacked by
   modification of the PCRep message, by impersonation of the PCE, or by
   modification of the PCReq to cause the PCE to perform a different
   computation from that which was originally requested.

=E2=80=8B


> In any case, all the considerations mentioned above probably belong in
> RFC5440 (PCEP) rather than this document concerning extensions.
>
>
>
=E2=80=8BAgreed. =E2=80=8B



> --Charlie Kaufman
>
>
> =E2=80=8BThanks for your review.

Regards,
Dhruv=E2=80=8B

--001a1147af321d4bc8055819d2e4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Charlie,=C2=A0

Th=
anks for your review and comments. Eric also raised similar concerns and I =
proposed this as the updated text=C2=A0as what can be a part of a bid do=
cument for a PCEP extension -=C2=A0=C2=A0

5.=C2=A0 Security =
Considerations

=C2=A0 =C2=A0As=
 described in [RFC5862], P2MP path computation requests are more
=C2=A0 =C2=A0CPU-intensive and also utilize more link bandwidth.=
=C2=A0 In the event of
=C2=A0 =C2=A0an unauthorized P2MP path computation request, o=
r a denial of service
=C2=A0 =C2=A0attack, the subsequent PCEP requests and processing may be d=
isruptive
=C2=A0 =C2=A0to the network.=C2=A0 Consequently, it is important that impl=
ementations
=C2=A0 =C2=A0conform to the relevant security requirements that specific=
ally help
=C2=A0 =C2=A0to minimize or negate unauthorized P2MP path computation requ=
ests and
=C2=A0 =C2=A0denial of service attacks.=C2=A0 These mechanisms include:

=C2=A0 =C2=A0o =C2=A0Securing the PCEP session requests and r=
esponses is RECOMMENDED
=C2=A0 =C2=A0 =C2=A0 using TCP security techniques such as=
 TCP Authentication Option
=C2=A0 =C2=A0 =C2=A0 (TCP-AO=
) [RFC5925] or using Transport Layer Security (TLS) [I-
=C2=A0 =C2=A0 =C2=A0 D.ietf-pce-pceps], =
as per the recommendations and best current
=C2=A0 =C2=
=A0 =C2=A0 practices in [RFC7=
525].

=C2=A0 =C2=A0o =C2=A0Authenticating the PCEP requests=
 and responses to ensure the
=C2=A0 =C2=A0 =C2=A0 message is intact and sent from an=
 authorized node using TCP-AO or
<=
font color=3D"#0c343d" face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 T=
LS is RECOMMENDED.

=C2=A0 =C2=
=A0o =C2=A0Providing policy c=
ontrol by explicitly defining which PCCs, via IP
=C2=A0=
 =C2=A0 =C2=A0 access-lists, =
are allowed to send P2MP path requests to the PCE.
=C2=A0 =C2=A0PCEP operates over TCP, so it is also i=
mportant to secure the PCE and
=C2=A0 =C2=A0PCC against=
 TCP denial of service attacks.=C2=A0

=

=C2=A0 =C2=A0As stated in [RFC6952], PCEP implementations should su=
pport TCP-AO
=C2=A0 =C2=A0[RFC5925] and not use TCP-MD5=
 because of the known vulnerabilities
=C2=A0 =C2=A0and weakness.=C2=A0
<=
/div>

You can see the diff at -=C2=A0https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-=
pce-rfc6006bis-03&url2=3Dhttps://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-rfc6006bis-04.txt=


Let me know if you have any modification suggestions here.=C2=A0

See inline...


On Sun, Aug 13, 2017 at 8:54 AM, Charlie Kaufman <charliekaufman@outlook.com> wrote:










I have reviewed this document as part of the security directorate&=
#39;s ongoing effort to review all IETF documents being processed by the IE=
SG. Document editors and WG chairs should treat these comments just like an=
y other last call comments.







Summary: No significant security issues









This document is a "refreshing" of rfc6006 (Extensions to PCEP=
 for Point-to-Multipoint Traffic Engineering Label Switched Paths) to incor=
porate errata that have accumulated over the last seven years. There may be=
 some small additional changes.







One minor change was made to Security considerations, and it was a good =
change, but I fear makes the security considerations somewhat internally in=
consistent. That change was to change a recommendation to use TCP-AO to a r=
ecommendation to use TLS. TLS is
 a more logical protocol to use in this context, but the security considera=
tions also references RFC5440, what mandates TCP-MD5 and recommends TCP-AO =
(which was not available when RFC5440 was written).







I'm not sure the best way to resolve this... probably to leave it as is. Someday, RFC5440 should =
be updated.







Security considerations in this document discusses that danger=
s of someone impersonating a client for the purpose of denying servi=
ce or learning about the network configuration, and RFC5440 talks about tha=
t dangers of eavesdropping in=
 learning what the client
 is doing. It does not discuss whether there are important threats posed by=
 someone impersonating a PCEP server and returning bad routing information.=
 I suspect that might be a more serious threat then either of the other attacks, but don't know enou=
gh about
 how the protocol is used to know for sure.



=E2=80=8BRFC5440 has this text -=C2=A0

=C2=A0 =C2=A0Attacks on PCEP may result in damage to active=
 networks.=C2=A0 If path
=C2=A0 =C2=A0computation responses are c=
hanged, the PCC may be encouraged to set
=C2=A0 =C2=A0up inapprop=
riate LSPs.=C2=A0 Such LSPs might deviate to parts of the
=C2=A0 =
=C2=A0network susceptible to snooping, or might transit congested or
<=
div>=C2=A0 =C2=A0reserved links.=C2=A0 Path computation responses may be at=
tacked by
=C2=A0 =C2=A0modification of the PCRep message, by impe=
rsonation of the PCE, or by
=C2=A0 =C2=A0modification of the PCRe=
q to cause the PCE to perform a different
=C2=A0 =C2=A0computatio=
n from that which was originally requested. =C2=A0=C2=A0
=


<=
div>
=E2=80=8B
=C2=A0




In any case, all the considerations mentioned above probably belong in R=
FC5440 (PCEP) rather than this document concerning extensions.




=E2=80=8BAgreed. =E2=80=8B

=
=C2=A0



--Charlie Kaufman




=E2=80=8BThanks for your review.=C2=A0

=

Regards,
Dhruv=E2=80=8B
=C2=A0



--001a1147af321d4bc8055819d2e4--