From nobody Wed Jan 1 14:02:33 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B728120020; Wed, 1 Jan 2020 14:02:25 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 GtZL_nNbwcG2; Wed, 1 Jan 2020 14:02:23 -0800 (PST) Received: from smtp120.iad3a.emailsrvr.com (smtp120.iad3a.emailsrvr.com [173.203.187.120]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33B9212000F; Wed, 1 Jan 2020 14:02:23 -0800 (PST) Received: from app37.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp16.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 622C417BB; Wed, 1 Jan 2020 17:02:22 -0500 (EST) X-Sender-Id: scott@hyperthought.com Received: from app37.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Wed, 01 Jan 2020 17:02:22 -0500 Received: from hyperthought.com (localhost.localdomain [127.0.0.1]) by app37.wa-webapps.iad3a (Postfix) with ESMTP id 4EA296004A; Wed, 1 Jan 2020 17:02:22 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Wed, 1 Jan 2020 14:02:22 -0800 (PST) X-Auth-ID: scott@hyperthought.com Date: Wed, 1 Jan 2020 14:02:22 -0800 (PST) From: "Scott G. Kelly" To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-bess-nsh-bgp-control-plane.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: <1577916142.318315934@apps.rackspace.com> X-Mailer: webmail/17.2.3-RC Archived-At: Subject: [secdir] secdir review of draft-ietf-bess-nsh-bgp-control-plane-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jan 2020 22:02:26 -0000 This review is several weeks late, I hope it is still useful.=0A=0AI have r= eviewed this document as part of the security directorate's ongoing effort = to review all IETF documents being processed by the IESG. These comments w= ere written primarily for the benefit of the security area directors. Docu= ment editors and WG chairs should treat these comments just like any other = last call comments.=0A=0AThe summary of the review is Ready.=0A=0AFrom the = abstract, this document describes the use of BGP as a control plane for net= works that support Service Function Chaining (SFC).=0A=0AThe document is we= ll-written and the security considerations section points to other RFCs whe= re appropriate, and seems to call out all relevant additional consideration= s.=0A=0AI could leave it at that, but I have little routing expertise/exper= ience, so I can't state with confidence that nothing was missed. The instru= ctions for secdir reviews say that the most important item is to give the (= security) ADs a sense of how important it is that they pay attention to the= document. Given the complexity and interactions between BGP, SFC, and the = control plane mechanisms described in this document, I think it *is* import= ant that the security ADs pay attention to this document.=0A=0A--Scott=0A= =0A From nobody Fri Jan 3 08:05:06 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F85B12008D; Fri, 3 Jan 2020 08:04:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Montville via Datatracker To: Cc: last-call@ietf.org, draft-ietf-6lo-ap-nd.all@ietf.org, 6lo@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Montville Message-ID: <157806749349.9008.754513854275764571@ietfa.amsl.com> Date: Fri, 03 Jan 2020 08:04:53 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-6lo-ap-nd-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 16:04:54 -0000 Reviewer: Adam Montville Review result: Ready Address Protected Neighbor Discovery for Low-power and Lossy Networks, which guards against address theft, is almost ready for publication. There are two points that may warrant attention by the ADs: 1. In the first exchange with a 6LR: "When a 6LR receives a NS(EARO) registration with a new Crypto-ID as a ROVR, it SHOULD challenge by responding with a NA(EARO) with a status of "Validation Requested"". Under what circumstances would a challenge not be warranted? In other words, could this SHOULD be a MUST? 2. The following sentence in 7.1 reads, "The 6LR must protect itself against overflows and reject excessive registration with a status 2 "Neighbor Cache Full"". Does that need to be a MUST instead of a must? From nobody Mon Jan 6 02:27:13 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF6E120124; Mon, 6 Jan 2020 02:27:02 -0800 (PST) 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 header.b=dI/G0Rj5; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=0TfODARc Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hn1qQbbhmyxQ; Mon, 6 Jan 2020 02:27:01 -0800 (PST) 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 37971120106; Mon, 6 Jan 2020 02:27:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1232; q=dns/txt; s=iport; t=1578306421; x=1579516021; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QKcSQekGzzuLgPpAJvUV2de9gVyMZg9V1FHTcpOmdpQ=; b=dI/G0Rj5TqCij+5iP9AVMDSeIu2iXSfPeuJh61fNxuxfGRKlV7kbcJ4o 1E3GqxfV508xN4nOKQPh7cVTffqPgD23OCFH9jrvBYyzLsG541io5EgQH 3QSgB7DYjGqOP3uMajd0SdqDqc4H5YmFBw3tKr/e89f4jB9zxHdubBXJ/ 0=; IronPort-PHdr: =?us-ascii?q?9a23=3AownASxeHQq0U6I1cXO4hBSXnlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGQD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/dzA6Ac5PTkNN9HCgOk8TE8H7NBXf?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BWAQBiChNe/4UNJK1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWsEAQELAYFTUAWBRCAECyqECYNGA4p/gl+YDYJSA1QJAQEBDAE?= =?us-ascii?q?BLQIBAYRAAheBUiQ3Bg4CAw0BAQQBAQECAQUEbYU3DIVeAQEBAQIBEhERDAE?= =?us-ascii?q?BNwEECwIBBgIaAiYCAgIwFRACBAENDRqFRwMOIAECkSKQZAKBOIhhdYEygn4?= =?us-ascii?q?BAQWFABiCDAmBDigBhRyFOYFDGoFBP4ERR4JMPoRLgw4ygiyNc4JLiBmHIY4?= =?us-ascii?q?2bwqCNpY1gkaHfYtWhEKOU5pZAgQCBAUCDgEBBYFoI4FYcBWDJ1AYDY0Sg3O?= =?us-ascii?q?KU3SBKIsSLYIUAQE?= X-IronPort-AV: E=Sophos;i="5.69,402,1571702400"; d="scan'208";a="409445030" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Jan 2020 10:27:00 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 006AR01q008965 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 6 Jan 2020 10:27:00 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 6 Jan 2020 04:26:59 -0600 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 6 Jan 2020 05:26:58 -0500 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 6 Jan 2020 05:26:58 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y3kfUxCPDQ5svOMcOYBK/JAZ9MQp+OMI/YhIL7pi//RuT2HtKpI38XwBkkuGwEwgmUbKADDIOq6ekBu8VSewbjpxUlccZVG/crrUwg4kCECaesGTFT5nc2O8OccUttp/5WIHVhrP8tZL6aiw+F5dsW5ArTVjExV7k4l0D/FhCqkH2/tnXKLb6I3SLDaNRT/oJcuMvVUvHStSOpNV7AaBIeXFKokAAUBwTA/16/NEp4gT7QSJCjtycQ54sOdliKaeadyFOwJyibrSTS0ZNSMKnJd79xbbgC/749Rk+JaX+xEuPN39dZVK6rvC1IZmrrQpJW0yshdUVuSeaStsafn3RA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QKcSQekGzzuLgPpAJvUV2de9gVyMZg9V1FHTcpOmdpQ=; b=jpzfG19jxNzJ82gQpgO34ZiW8FhGLhHanlgxdnPUcN4GasIuG0llOPj+DKA78VUXeoda/x77OKJpy/3Qv9q45AmUy57Qf9Z3jKm5Pp/vpdKgD+F/asACO6SYDvpSnTcILJwZUj887j4xN2nXww9xUNdVmUjWLEuvZEU+xrR/zvaNrV/94afmMjSZcPzDAOB/n8eTjVptBahEersj2zBfnCNdvOFXw8bUyjY7lYWdkYobODoTgjLteCjb+4qP0UCp10PzR63z5MP9Ts+FFm0XgjvM393y1OCUp1IlACQCg02S7+R/FX5SbmVVevpp4UrA4MeMxtS0q+AacOHhlt3N4A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QKcSQekGzzuLgPpAJvUV2de9gVyMZg9V1FHTcpOmdpQ=; b=0TfODARccFaoY4Df3/3U0T6fwEn8psTZJH5bcwYTnG8a6yESHNzwVl8xuMFkJf0qta4TBZ75u/WBkzqW0n27U0mU1jK/zacW/tsvjDrC6ILaxiPcb2q0MZ8/m8ztbVCIEVovny9RgDZ/N/ZBvefGCVMaPiMnTbbfHCv6Uh3EhFo= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3838.namprd11.prod.outlook.com (20.178.252.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.12; Mon, 6 Jan 2020 10:26:57 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a%3]) with mapi id 15.20.2602.015; Mon, 6 Jan 2020 10:26:57 +0000 From: "Pascal Thubert (pthubert)" To: Adam Montville , "secdir@ietf.org" CC: "last-call@ietf.org" , "draft-ietf-6lo-ap-nd.all@ietf.org" , "6lo@ietf.org" <6lo@ietf.org> Thread-Topic: [6lo] Secdir last call review of draft-ietf-6lo-ap-nd-12 Thread-Index: AQHVwk+geWGCc+mHh0O5f6aJXz2JJKfdb9Dw Date: Mon, 6 Jan 2020 10:26:28 +0000 Deferred-Delivery: Mon, 6 Jan 2020 10:25:32 +0000 Message-ID: References: <157806749349.9008.754513854275764571@ietfa.amsl.com> In-Reply-To: <157806749349.9008.754513854275764571@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:c0c0:1007::25a] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 542c2970-1665-425d-f18d-08d79292f563 x-ms-traffictypediagnostic: MN2PR11MB3838: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0274272F87 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(376002)(346002)(396003)(39860400002)(199004)(189003)(5660300002)(86362001)(52536014)(33656002)(66556008)(66446008)(64756008)(66476007)(55016002)(2906002)(7696005)(9686003)(8936002)(66946007)(76116006)(6506007)(71200400001)(81156014)(478600001)(6666004)(8676002)(110136005)(316002)(54906003)(4326008)(81166006)(4744005)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3838; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: s54jIcBcAi2RjTDxOKVcFyrRSclp5KtLdpOqI16+LoHo9+zsK8NZ0iFcmVfqD3vqbbdz7vAAdMqmo24EfWlKMzHG6C6k8SfPniCD46BqmWfdGat0vksYiNM02mQdAz8t+c8tc6KFMmXkppkflQHcbYt5Wj+wa5/Va1+HRP7YprQlerwPGQjuLHi7GpXdvwvgWaiAzUbMQBHp+4xXXiLvgjA2IZ2ItnjbCf+S0voxhgIaHED78qMZDlJZmVTyy+8QPJspclWSzpFBJB/SPulUsUifg+QoF6tx0b3aqAcC7e6CpIz649/iAM1gwKGiOHaBVjPCDY6PDcgamo/FoHoSHhU12U4/nPeqIKRp82xg+fnxq5L6ExaSkNP/o+gX2kd76jJfItJ9Yyk/ZZbtFXUw5XuaSCsBQEUMJPyNtN1YP7YCILmo7Ka/uWflk052No7I x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 542c2970-1665-425d-f18d-08d79292f563 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2020 10:26:57.4173 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: G5MC9/IgMKCCOSIPkIxeJbtAr0Znlr/gm4XVsRDMt4C0sMb3WUCgi6mDNTE8jTkFz/CkmQ57ejW1sbMy9LsQUw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3838 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.20, xch-rcd-010.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: Re: [secdir] [6lo] Secdir last call review of draft-ietf-6lo-ap-nd-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 10:27:03 -0000 SGVsbG8gQWRhbQ0KDQpNYW55IHRoYW5rcyBmb3IgeW91ciByZXZpZXcg8J+YiiANCg0KUGxlYXNl IHNlZSBiZWxvdzoNCg0KIA0KPiAxLiBJbiB0aGUgZmlyc3QgZXhjaGFuZ2Ugd2l0aCBhIDZMUjog IldoZW4gYSA2TFIgcmVjZWl2ZXMgYSBOUyhFQVJPKQ0KPiByZWdpc3RyYXRpb24gd2l0aCBhIG5l dyBDcnlwdG8tSUQgYXMgYSBST1ZSLCBpdCBTSE9VTEQgY2hhbGxlbmdlIGJ5DQo+IHJlc3BvbmRp bmcgd2l0aCBhIE5BKEVBUk8pIHdpdGggYSBzdGF0dXMgb2YgIlZhbGlkYXRpb24gUmVxdWVzdGVk IiIuIFVuZGVyDQo+IHdoYXQgY2lyY3Vtc3RhbmNlcyB3b3VsZCBhIGNoYWxsZW5nZSBub3QgYmUg d2FycmFudGVkPyBJbiBvdGhlciB3b3JkcywgY291bGQNCj4gdGhpcyBTSE9VTEQgYmUgYSBNVVNU Pw0KDQpZZXMgSSBndWVzcyBpdCBpcyBhIE1VU1QsIHVubGVzcyB0aGUgcmVnaXN0cmF0aW9uIGlz IHJlamVjdGVkIGZvciBhbm90aGVyIHJlYXNvbiwgZS5nLiwgdGhlIG92ZXJmbG93IGJlbG93Lg0K VW5sZXNzIHNvbWVvbmUgcG9zdHMgYWdhaW5zdCBpdCBJJ2xsIG1ha2UgdGhlIGNoYW5nZSB3aXRo IHRoZSBuZXh0IHJldmlzaW9uLg0KDQoNCj4gMi4gVGhlIGZvbGxvd2luZyBzZW50ZW5jZSBpbiA3 LjEgcmVhZHMsICJUaGUgNkxSIG11c3QgcHJvdGVjdCBpdHNlbGYgYWdhaW5zdA0KPiBvdmVyZmxv d3MgYW5kIHJlamVjdCBleGNlc3NpdmUgcmVnaXN0cmF0aW9uIHdpdGggYSBzdGF0dXMgMiAiTmVp Z2hib3IgQ2FjaGUNCj4gRnVsbCIiLiBEb2VzIHRoYXQgbmVlZCB0byBiZSBhIE1VU1QgaW5zdGVh ZCBvZiBhIG11c3Q/DQoNClllcywgSSBzdXBwb3NlIHNvLiBJJ2xsIG1ha2UgdGhhdCBjaGFuZ2Ug dG9vLg0KDQpNYW55IHRoYW5rcyBhZ2FpbiBBZGFtIQ0KDQpQYXNjYWwNCg== From nobody Tue Jan 7 10:35:27 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88531200F5; Tue, 7 Jan 2020 10:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=sinodun.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 Me8YrLV5C7fZ; Tue, 7 Jan 2020 10:35:17 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72F4F120131; Tue, 7 Jan 2020 10:35:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sinodun.com ; s=mythic-beasts-k1; h=To:Date:From:Subject; bh=hfUvIUE1/4ouVOvgS0Z8V5cgCp0/JmD276ROKjgQ5DM=; b=X0LoROsEpigOcLCzM1Sx/ywkPY JLXPBdbm1anfNEHBC6zX+QL/j6ARorXhlV3sAJXYgdJtxcHiFcV+nYTJAggCtxQlrXL+rqIcfRWCM OYpgDW4CklI1t95G653023POX+R6cQducgmWJnvf13OEZWv2XFIriG3Au6K+he+gRBx1/JegTBmkC ouBMHrzG/t6RTHxiy4HZz7M3GmbpWhyqoEBzN/QUM2DIaQ9+rMwQg5t6XxCxR34tMnzuvRJlFiQc7 Kc6vAirdAOqJFWA3bqyjNedbdcPodc4KZLegg3m+G8cjlZmBPl5m0HCemJHLfCM3Xqp1nHPyJ55oG MSuLc4jQ==; Received: from [2a02:8010:6126:0:1d21:ef98:8b8e:dcec] (port=64235) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1ioth9-0000pN-38; Tue, 07 Jan 2020 18:35:15 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sara Dickinson In-Reply-To: <20191223220509.GK35479@kduck.mit.edu> Date: Tue, 7 Jan 2020 18:34:58 +0000 Cc: last-call@ietf.org, DNS Privacy Working Group , draft-ietf-dprive-rfc7626-bis.all@ietf.org, secdir@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <157504194893.4871.5551746255324168227@ietfa.amsl.com> <208AD30F-1213-4784-81FC-4AB76730CEC2@sinodun.com> <20191223220509.GK35479@kduck.mit.edu> To: Benjamin Kaduk , Stephen Farrell X-Mailer: Apple Mail (2.3445.104.11) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [secdir] [dns-privacy] Secdir last call review of draft-ietf-dprive-rfc7626-bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 18:35:21 -0000 > On 23 Dec 2019, at 22:05, Benjamin Kaduk wrote: >=20 > On Wed, Dec 18, 2019 at 02:00:45PM +0000, Stephen Farrell wrote: >>=20 >> Hiya, >>=20 >> On 18/12/2019 13:45, Sara Dickinson wrote: >>>=20 >>>=20 >>>> On 29 Nov 2019, at 15:39, Stephen Farrell via Datatracker = wrote: >>>>=20 >>>> Reviewer: Stephen Farrell >>>> Review result: Ready >>>=20 >>> Hi Stephen,=20 >>>=20 >>> Thanks for reviewing (again)! >>>=20 >>>>=20 >>>> I might not be the best reviewer for this one as I've read it a few = times >>>> before. But anyway, I scanned the diff [1] with RFC7626 and figure = it >>>> seems fine.=20 >>>>=20 >>>> The only thing that occurred to me that seemed missing was to note >>>> that while the new privacy analysis in 3.5.1.1 is already complex, = many >>>> systems are mobile and hence an analysis that ignores that won't be=20= >>>> sufficient. For a mobile device one really needs to analyse all of = the=20 >>>> possible setups, and hence it's even harder to get to a good = answer.=20 >>>> (It could be that that's elsewhere in the document but since I only=20= >>>> read the diff, I didn't see it:-) >>>=20 >>> There was a bit of discussion about this and the following text in = 3.4.1 was added: >>>=20 >>> =E2=80=9C It is also noted that typically a device connected _only_ = to a modern >>> cellular network is >>>=20 >>> o directly configured with only the recursive resolvers of the = IAP >>> and >>>=20 >>> o all traffic (including DNS) between the device and the cellular >>> network is encrypted following an encryption profile edited by = the >>> Third Generation Partnership Project (3GPP [2]). >>>=20 >>> The attack surface for this specific scenario is not considered = here." >>>=20 >>> Which hopefully covers this? >>=20 >> Not really, no. My point is that the analysis in 3.5.1.1 >> doesn't encompass the fact that hosts are often (or even >> mostly) mobile and hence connect to many networks, and that >> the results of a privacy analysis related to DoT/DoH will >> likely differ for each of those networks, from the POV >> of the user or device owner, and even those two may not >> agree in some cases. >>=20 >> I don't believe that point is made in the document. But >> I'm ok that you and the ADs figure out if its needed or >> not. >=20 > I think some kind of treatment is needed, even if the extent of the > treatment might still be up for debate. >=20 > Sara: note that "mobile" here is used in the generic sense of "moving > around", not specific to a mobile or "cellular" pocket computer (aka > "phone=E2=80=9D). Thanks - I did misread Stephens response - I see the issue now. As a starting point I would suggest some text at the very beginning of = Section 3 along these lines.=20 =E2=80=9CThis section outlines the privacy considerations associated = with different aspects of the DNS for the end user. When reading this = section it needs to be kept in mind that many of the considerations (for = example, recursive resolver and transport protocol) can be specific to = the network context that a device is using at a given point in time. A = user may have many devices and each device might utilise many different = networks (e.g. home, work, public or cellular) over a period of time or = even concurrently. An exhaustive analysis of the privacy considerations = for an individual user would need to take into account the set of = devices used and the multiple dynamic contexts of each device. This = document does not attempt such a complex analysis, instead it presents = an overview of the various considerations that could form the basis of = such an analysis. " >=20 > (I also agree with Ekr that the considerations around 3GPP encryption > remain not great and would prefer to not rely on them.) I think the idea of the above text was to show there is an orthogonal = but out of scope issue with 3GPP encryption, not to make any judgement = on it as a technology. Are you saying that the document should make an = explicit statement something like =E2=80=99This form of encryption = should not generally be considered secure but an analysis is out of = scope for this document. The attack surface for this specific scenario = is not considered here.=E2=80=99? If I have misunderstood, please suggest some text to be used here. Sara.=20 From nobody Tue Jan 7 12:07:18 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55BB412080E; Tue, 7 Jan 2020 12:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZymgDBrM5yQ; Tue, 7 Jan 2020 12:07:10 -0800 (PST) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 0DC3512018B; Tue, 7 Jan 2020 12:07:07 -0800 (PST) Received: from trixy.bergandi.net (cpe-76-93-158-174.san.res.rr.com [76.93.158.174]) by wwwlocal.goatley.com (PMDF V6.8-0 #1001) with ESMTP id <0Q3R00OF96JUIM@wwwlocal.goatley.com>; Tue, 07 Jan 2020 14:07:06 -0600 (CST) Received: from Dans-MacBook-Pro.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #1001) with ESMTPSA id <0Q3R00GFF6JQXQ@trixy.bergandi.net>; Tue, 07 Jan 2020 12:07:02 -0800 (PST) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO Dans-MacBook-Pro.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Tue, 07 Jan 2020 12:07:02 -0800 Date: Tue, 07 Jan 2020 12:07:01 -0800 From: Dan Harkins To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-dtn-bpsec.all@ietf.org Cc: Rick Taylor , "Edward.Birrane@jhuapl.edu" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Content-language: en-US Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO Dans-MacBook-Pro.local) X-PMAS-Software: PreciseMail V3.3 [200104] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: [secdir] secdir review of draft-ietf-dtn-bpsec X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 20:07:11 -0000   Hello,   1000 pardons for the tardiness of this re-review. It fell through the cracks and I was reminded of it during the end-of-the-year break.   This draft is Ready With (a single) Nit.   This draft is much improved over -06 which I previously reviewed. All of my recommendations have been acted on (thank you). The addition of AEAD for the BCB is a very good addition. The block interactions in 3.9 look correct and my only suggestion would be to remove "NOTE:" from the final paragraph which implies it is informative. Also remove "probably" because it is most decidedly insecure. Make this a normative paragraph prohibiting an insecure construction.   The examples are helpful, especially as one expands on the other, that helps illustrate the 3.9 block interaction rules.   regards,   Dan. From nobody Tue Jan 7 12:24:15 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA2CA120077; Tue, 7 Jan 2020 12:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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] 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 4RXT9wuLycYN; Tue, 7 Jan 2020 12:17:01 -0800 (PST) Received: from weald.air.saab.se (weald.air.saab.se [136.163.212.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D843E12010C; Tue, 7 Jan 2020 12:17:00 -0800 (PST) Received: from mailhub1.air.saab.se ([136.163.213.4]) by weald.air.saab.se (8.14.4/8.14.4) with ESMTP id 007KGw1a030920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 7 Jan 2020 21:16:58 +0100 Received: from corpappl16596.corp.saab.se (corpappl16596.corp.saab.se [10.12.12.128]) by mailhub1.air.saab.se (8.13.8/8.13.8) with ESMTP id 007KGiTD024527 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 Jan 2020 21:16:44 +0100 Received: from corpappl16595.corp.saab.se (10.12.12.127) by corpappl16596.corp.saab.se (10.12.12.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Tue, 7 Jan 2020 21:16:44 +0100 Received: from corpappl16595.corp.saab.se ([fe80::3c3e:6470:4c56:a86f]) by corpappl16595.corp.saab.se ([fe80::3c3e:6470:4c56:a86f%4]) with mapi id 15.01.1847.003; Tue, 7 Jan 2020 21:16:44 +0100 From: Seitz Ludwig To: Charlie Kaufman CC: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-ace-oauth-params.all@ietf.org" , "ace@ietf.org" Thread-Topic: Secdir review of draft-ietf-ace-oauth-params-06 Thread-Index: AQHVtSWsVML0EqYNLk+qsAH30Mo1kKffwt9Q Date: Tue, 7 Jan 2020 20:16:44 +0000 Message-ID: <2a0e711297c642b49413d7d749e619b4@combitech.se> References: <20191217220157.GH81833@kduck.mit.edu> In-Reply-To: <20191217220157.GH81833@kduck.mit.edu> Accept-Language: en-SE, sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.13.198] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Saab-MailScanner-Information: Please contact the ISP for more information X-Saab-MailScanner-ID: 007KGiTD024527 X-Saab-MailScanner: Found to be clean X-Saab-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.498, required 5, ALL_TRUSTED -1.00, KAM_NUMSUBJECT 0.50, SURBL_BLOCKED 0.00, URIBL_BLOCKED 0.00) X-Saab-MailScanner-From: ludwig.seitz@combitech.se X-Saab-MailScanner-Watermark: 1579033004.95031@Rqw2G2HARVI185TIGoWbSw X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (weald.air.saab.se [136.163.212.3]); Tue, 07 Jan 2020 21:16:58 +0100 (CET) Archived-At: X-Mailman-Approved-At: Tue, 07 Jan 2020 12:24:13 -0800 Subject: Re: [secdir] Secdir review of draft-ietf-ace-oauth-params-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 20:17:09 -0000 Hello Charlie, Thank you for the review, sorry for the tardive reply (things got a bit cha= otic due to an affiliation change on my part). The -10 version here: https:= //datatracker.ietf.org/doc/draft-ietf-ace-oauth-params addresses your comme= nts given the additional explanations by Ben. Please confirm if this satisfies your requested changes. Regards, Ludwig -----Original Message----- From: Benjamin Kaduk =20 Sent: den 17 december 2019 23:02 To: Charlie Kaufman Cc: secdir@ietf.org; iesg@ietf.org; draft-ietf-ace-oauth-params.all@ietf.or= g Subject: Re: Secdir review of draft-ietf-ace-oauth-params-06 Hi Charlie, Thanks for the review! On Fri, Dec 13, 2019 at 07:48:22AM +0000, Charlie Kaufman wrote: > I have reviewed this document as part of the security directorate's ongoi= ng effort to review all IETF documents being processed by the IESG. These = comments were written primarily for the benefit of the security area direct= ors. Document editors and WG chairs should treat these comments just like = any other last call comments. >=20 > This document only exists because of a scheduling issue between the ACE a= nd OAUTH working groups. The ACE working group needed some additional OAUTH= extensions added more quickly that the OAUTH group could manage to do it. = This document is intended to only exist until the OAUTH group can make the = corresponding changes. As such, it really doesn't have security considerati= ons beyond those in the document it modifies. >=20 > The security considerations section says (and I agree): >=20 > This document is an extension to [I-D.ietf-ace-oauth-authz]. All security= considerations from that document apply here as well. >=20 > Some acronyms that were not defined (but this might be OK in the=20 > context of this being a modification to another document): AS, RS,=20 > CoAP, cnf, CBOR, pop, CWT >=20 >=20 > A few typos / odd phrasing: >=20 > Abstract: whishes -> wishes > Appendix A: possesion -> possession >=20 > >From Section 2: > Note that the term "endpoint" is used here following its OAuth 2.0 [RFC67= 49] definition, which is to denote resources such as token and introspectio= n at the AS and authz-info at the RS. >=20 > Really? The term "endpoint" refers to tokens and authz-info data structur= es? This seems unlikely. Not data structures, but (HTTP/CoAP) resources -- "things you can POST to". > Continuing in Section 2: > The CoAP [RFC7252] definition, which is "An entity participating in the C= oAP protocol" is not used in this specification. >=20 > Why is a definition that does not apply relevant to this document? This document is at the intersection of two worlds: CoAP and OAuth. Both d= efine "endpoint" but in contradictory ways. Since at least one has to lose= , giving the reader a pretty explicit hint that they're wrong to use a give= n definition seems to have value. But maybe I'm in the rough; we'll see :) -Ben From nobody Thu Jan 9 04:35:34 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6F9120018 for ; Thu, 9 Jan 2020 04:35:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <157857333357.11762.12210726366769011319.idtracker@ietfa.amsl.com> Date: Thu, 09 Jan 2020 04:35:33 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 12:35:33 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2020-01-09 Reviewer LC end Draft Leif Johansson 2019-12-19 draft-ietf-jmap-websocket-04 For telechat 2020-01-23 Reviewer LC end Draft Aanchal Malhotra 2019-12-23 draft-ietf-pce-stateful-flags-00 Last calls: Reviewer LC end Draft John Bradley 2019-11-22 draft-schaad-cbor-content-02 Shaun Cooley 2019-11-12 draft-ietf-regext-login-security-07 Roman Danyliw 2019-11-12 draft-ietf-dtn-bpbis-17 Alan DeKok 2019-11-27 draft-ietf-6man-ra-pref64-09 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-08 Donald Eastlake 2019-11-14 draft-ietf-hip-dex-11 Tobias Gondrom 2019-12-02 draft-ietf-tls-tls13-cert-with-extern-psk-07 Leif Johansson 2019-12-19 draft-ietf-jmap-websocket-04 Aanchal Malhotra 2019-12-23 draft-ietf-pce-stateful-flags-00 Daniel Migault 2020-01-17 draft-kucherawy-rfc8478bis-03 Russ Mundy 2020-01-02 draft-ietf-dprive-bcp-op-07 Sandra Murphy 2019-10-04 draft-ietf-mpls-ldp-yang-06 Yoav Nir 2020-01-22 draft-ietf-6tisch-enrollment-enhanced-beacon-06 Magnus Nystrom 2020-01-21 draft-ietf-dnsop-rfc2845bis-06 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-09 Hilarie Orman 2020-01-21 draft-ietf-rmcat-wireless-tests-08 Takeshi Takahashi 2019-11-04 draft-ietf-netmod-yang-data-ext-05 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Next in the reviewer rotation: Radia Perlman Derrell Piper Tirumaleswar Reddy.K Vincent Roca Kyle Rose Joseph Salowey Rich Salz Stefan Santesson Yaron Sheffer Rifaat Shekh-Yusef From nobody Thu Jan 9 05:06:34 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 586E11200C1; Thu, 9 Jan 2020 05:06:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Leif Johansson via Datatracker To: Cc: last-call@ietf.org, draft-ietf-jmap-websocket.all@ietf.org, jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Leif Johansson Message-ID: <157857518227.11730.7008293637130176864@ietfa.amsl.com> Date: Thu, 09 Jan 2020 05:06:22 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-jmap-websocket-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 13:06:22 -0000 Reviewer: Leif Johansson Review result: Has Issues 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. I apologize for being very late with this review and since this is already in the IESG process it is clearly ok to completely ignore this review! In summary I think the security considerations sections have a few issues. In particular several of the identified security issues in section 10 of RFC 6455 place requirements on implementations and profiles but JMAP websocket makes no effort to expand on those requirements. For instance is the intention of jmap websocket to be built into non- browser clients so section 10.1 applies (or not)? What are the authentication requirements of jmap websocket (section 10.5) etc. I think the security considerations should make an attempt to cover this if at all possible. From nobody Sun Jan 12 19:58:13 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64EC512001E; Sun, 12 Jan 2020 19:58:06 -0800 (PST) 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyYeM0hgVtZb; Sun, 12 Jan 2020 19:58:03 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AC41120013; Sun, 12 Jan 2020 19:58:03 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00D3vrOS012066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 12 Jan 2020 22:57:55 -0500 Date: Sun, 12 Jan 2020 19:57:52 -0800 From: Benjamin Kaduk To: Sara Dickinson Cc: Stephen Farrell , last-call@ietf.org, DNS Privacy Working Group , draft-ietf-dprive-rfc7626-bis.all@ietf.org, secdir@ietf.org Message-ID: <20200113035752.GC27483@kduck.mit.edu> References: <157504194893.4871.5551746255324168227@ietfa.amsl.com> <208AD30F-1213-4784-81FC-4AB76730CEC2@sinodun.com> <20191223220509.GK35479@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [secdir] [dns-privacy] Secdir last call review of draft-ietf-dprive-rfc7626-bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2020 03:58:07 -0000 On Tue, Jan 07, 2020 at 06:34:58PM +0000, Sara Dickinson wrote: > > > > On 23 Dec 2019, at 22:05, Benjamin Kaduk wrote: > > > > On Wed, Dec 18, 2019 at 02:00:45PM +0000, Stephen Farrell wrote: > >> > >> Hiya, > >> > >> On 18/12/2019 13:45, Sara Dickinson wrote: > >>> > >>> > >>>> On 29 Nov 2019, at 15:39, Stephen Farrell via Datatracker wrote: > >>>> > >>>> Reviewer: Stephen Farrell > >>>> Review result: Ready > >>> > >>> Hi Stephen, > >>> > >>> Thanks for reviewing (again)! > >>> > >>>> > >>>> I might not be the best reviewer for this one as I've read it a few times > >>>> before. But anyway, I scanned the diff [1] with RFC7626 and figure it > >>>> seems fine. > >>>> > >>>> The only thing that occurred to me that seemed missing was to note > >>>> that while the new privacy analysis in 3.5.1.1 is already complex, many > >>>> systems are mobile and hence an analysis that ignores that won't be > >>>> sufficient. For a mobile device one really needs to analyse all of the > >>>> possible setups, and hence it's even harder to get to a good answer. > >>>> (It could be that that's elsewhere in the document but since I only > >>>> read the diff, I didn't see it:-) > >>> > >>> There was a bit of discussion about this and the following text in 3.4.1 was added: > >>> > >>> “ It is also noted that typically a device connected _only_ to a modern > >>> cellular network is > >>> > >>> o directly configured with only the recursive resolvers of the IAP > >>> and > >>> > >>> o all traffic (including DNS) between the device and the cellular > >>> network is encrypted following an encryption profile edited by the > >>> Third Generation Partnership Project (3GPP [2]). > >>> > >>> The attack surface for this specific scenario is not considered here." > >>> > >>> Which hopefully covers this? > >> > >> Not really, no. My point is that the analysis in 3.5.1.1 > >> doesn't encompass the fact that hosts are often (or even > >> mostly) mobile and hence connect to many networks, and that > >> the results of a privacy analysis related to DoT/DoH will > >> likely differ for each of those networks, from the POV > >> of the user or device owner, and even those two may not > >> agree in some cases. > >> > >> I don't believe that point is made in the document. But > >> I'm ok that you and the ADs figure out if its needed or > >> not. > > > > I think some kind of treatment is needed, even if the extent of the > > treatment might still be up for debate. > > > > Sara: note that "mobile" here is used in the generic sense of "moving > > around", not specific to a mobile or "cellular" pocket computer (aka > > "phone”). > > Thanks - I did misread Stephens response - I see the issue now. > > As a starting point I would suggest some text at the very beginning of Section 3 along these lines. > > “This section outlines the privacy considerations associated with different aspects of the DNS for the end user. When reading this section it needs to be kept in mind that many of the considerations (for example, recursive resolver and transport protocol) can be specific to the network context that a device is using at a given point in time. A user may have many devices and each device might utilise many different networks (e.g. home, work, public or cellular) over a period of time or even concurrently. An exhaustive analysis of the privacy considerations for an individual user would need to take into account the set of devices used and the multiple dynamic contexts of each device. This document does not attempt such a complex analysis, instead it presents an overview of the various considerations that could form the basis of such an analysis. " Okay. > > > > (I also agree with Ekr that the considerations around 3GPP encryption > > remain not great and would prefer to not rely on them.) > > I think the idea of the above text was to show there is an orthogonal but out of scope issue with 3GPP encryption, not to make any judgement on it as a technology. Are you saying that the document should make an explicit statement something like ’This form of encryption should not generally be considered secure but an analysis is out of scope for this document. The attack surface for this specific scenario is not considered here.’? I don't think it's necessary to make an explicit statement such as you propose, but would prefer to just not not say as much about 3GPP encryption at all. The current text in the -03 is prefaced with "a device connected _only_ to a modern cellular network", and while the latest-and-greatest stuff has less known breakage, in practice current deployments still seem to allow downgrade attacks to the more-vulnerable older protocols. > If I have misunderstood, please suggest some text to be used here. My thinking would be more along the lines of updating the bullet point in 3.4.1 to be like: o some level of protection against some types of eavesdropping is afforded to all traffic (including DNS traffic) due to the cellular network link-layer encryption. This is probably not the document in which to attempt a comprehensive analysis of cellular traffic (including radio and core network), and with this wording it probably avoids the need to pull in specific references for attacks on cellular links, along the lines of https://www.zdnet.com/article/stingray-security-flaw-cell-networks-phone-tracking-surveillance/, https://arxiv.org/pdf/1510.07563.pdf, https://alter-attack.net/, https://blog.cryptographyengineering.com/2013/05/14/a-few-thoughts-on-cellular-encryption/, https://techcrunch.com/2019/02/24/new-4g-5g-security-flaws/, etc. -Ben From nobody Mon Jan 13 08:09:04 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D447120025; Mon, 13 Jan 2020 08:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=I5ErMybH; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=LE3frCBs Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtEAOklfTFUk; Mon, 13 Jan 2020 08:09:01 -0800 (PST) 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 BE08B120077; Mon, 13 Jan 2020 08:09:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5909; q=dns/txt; s=iport; t=1578931740; x=1580141340; h=from:to:cc:subject:date:message-id:mime-version; bh=SsbIpwirEh8SZ+brYE2KGZdP575qAy7PIRdJpp6kRIo=; b=I5ErMybHFnl1Ex1XpYc4SonTeK7OMOuWhkdaSCSSQS/X+V2HJmrVTlV3 7Y4R1Y2VIxxW/jKTkwrGXhs5Fd8Z2ty1dXIKzUOSr+mldRo2fBVwPoCQE 5Yw3vH4m2mpcTzEl9cSVpOWClqdiWCrfPazgDUyFJXBkeg8KkvkU64u10 A=; IronPort-PHdr: =?us-ascii?q?9a23=3AfX0f2hO8w6PwUliRqxUl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu60/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBj2Mu/sZC83NM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CzEgDBlBxe/4cNJK1mgkGBJS9QBWx?= =?us-ascii?q?YIAQLKoQMg0YDiwROgWyTUIRigS4UgRADVAkBAQEMAQEtAgEBhEAZgWEkNAk?= =?us-ascii?q?OAgMNAQEEAQEBAgEFBG2FNwyFYRYRHQEBMQYBEQFKAgQwJwQOGQ6DBAGBfU0?= =?us-ascii?q?DLgGfDgKBOIhhdYEygn4BAQWFFxiCDAmBNowZGoFBP4E4DBSHIAESAYMvMoI?= =?us-ascii?q?sjUyCRjuFV4JFllcKgjcElikbmmypUQIEAgQFAg4BAQWBUjlncXAVZQGCQVA?= =?us-ascii?q?YDYt0ilN0gSiJRIFTXwEB?= X-IronPort-AV: E=Sophos;i="5.69,429,1571702400"; d="scan'208,217";a="414215406" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Jan 2020 16:08:59 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 00DG8x8m017763 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 13 Jan 2020 16:08:59 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 13 Jan 2020 10:08:58 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 13 Jan 2020 11:08:58 -0500 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 13 Jan 2020 10:08:58 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hTY79uWQEnoIsBjvIop03X9oLSYIbLa30i4g5SG9zHJKuXMGsROh0WXSiNYEch3ZVaPb5GB1AjH3kgAJK7zy483G+kV5s/en8RssURamsuMF1k0NVnU+pKWdVQLgz6xwfFtAGdYmyLA4EbbvudJbuhVqOW6zARxnj1rmg4adwzOcb3fUvfQj2ouibvpXkEfymHAC/sjmbgS3bnryIZwfcH5zoDjxyjo+jtpQN7rraQknvcf/HZzG4cYASFzGN2KMRfKBy+d2qoGruue2OrgkPv06psyVllX2BcxSOUXk6nSGjb21PG5HmKpY/qc/pHll+RMKEkvDDStLGDnPLoLIVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SsbIpwirEh8SZ+brYE2KGZdP575qAy7PIRdJpp6kRIo=; b=bWTUrMOlOGnN+Fy1XfWVVuOXtpMzMXUvuiZ6MYAWBrOt/XDhnohgj4VALfQSuU30eO4PBZW7Ej2D82DCE/bZwkcaLyZfX8QBCSVDKBAn/J52HWxeeQN0BvFLgOLF6T96T0CYu0ycn9r4kAbyV8ltZD3g+ZnGHO1A8EfFa/4eb+/V2dVWVjCf4vrnGM/Dm5v5j0K+U1PiqsmOcYwSVTjjzYL3Op9xGvWWVg1EQUaEdnuEluinsKlbrHnUpT1dhGeVdSklvjIXDNFi6nerdJa7bytlftvWBzPXetK69YHtKCJDfYjhZHHDRH/iXPc5gdjnbKPW3BlRfjM8zhuLRn/7HA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SsbIpwirEh8SZ+brYE2KGZdP575qAy7PIRdJpp6kRIo=; b=LE3frCBsRts00jLwLkE1DLrEd1Rzl9GIaqhw50BZ0KDRWGW7ofW1DcRQWtqhemRrQ7Oa5L4bYVSw1B0NSyLKfI69gFppm4a+0l9aL2/biBzW17GWjARbKlFPvm49b6sm2u8xQDEleBXCRKNiQqcSw4wXmP3O1Jyf7/Fg6+CWX3E= Received: from DM5PR11MB1753.namprd11.prod.outlook.com (10.175.88.141) by DM5PR11MB1291.namprd11.prod.outlook.com (10.168.108.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.13; Mon, 13 Jan 2020 16:08:57 +0000 Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::9528:bb7a:843e:5ea3]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::9528:bb7a:843e:5ea3%12]) with mapi id 15.20.2623.015; Mon, 13 Jan 2020 16:08:57 +0000 From: "Eric Vyncke (evyncke)" To: DNS Privacy Working Group CC: "draft-ietf-dprive-rfc7626-bis.all@ietf.org" , "secdir@ietf.org" , Rob Sayre , Martin Thomson , "'Eric Rescorla'" , S Moonesamy , Neil Cook , Christian Huitema , Vittorio Bertola , Stephen Farrell , Benjamin Kaduk Thread-Topic: Moving forward with draft-ietf-dprive-rfc7626-bis Thread-Index: AQHVyivCuLFFvCccjkCdWb4noRNAQA== Date: Mon, 13 Jan 2020 16:08:57 +0000 Message-ID: <3FE94AA3-6592-4F3A-A780-7A224903806D@cisco.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.20.0.191208 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:3df9:4f35:7f13:6077] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 986ccadb-fb24-48cb-fd98-08d79842e513 x-ms-traffictypediagnostic: DM5PR11MB1291: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 028166BF91 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(396003)(346002)(366004)(39860400002)(189003)(199004)(71200400001)(186003)(33656002)(2906002)(6506007)(7416002)(54906003)(2616005)(478600001)(6916009)(81156014)(6512007)(4326008)(81166006)(316002)(6486002)(66476007)(8936002)(66446008)(64756008)(8676002)(4744005)(5660300002)(66574012)(66946007)(86362001)(66556008)(76116006)(36756003)(91956017); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1291; H:DM5PR11MB1753.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dpZjXg59G5SJ5EEaLw9Xe2sKimKuWrcQKXpBEKbrFS4X08ivbPVEViSKwfvXxCaOh/0j6DBb8T+WMb+waMDkhY0IjP9mARDWbawLDkmfUGI8SDxLGj6ELp+wTU5a4yqcPq0SWr1nXM83sX5pHtn7eyC+eijShD/VfsP+9dGM8Yp6IJEJDW3ezANr+dTGGA9GOLzDLftWLMPAZu7iKB52wIPaOMmFIOjVl+vLq45dKSOu0kJ0clZpx7ESlXccuuzsVizHaOplkIyVxsalwPOusvoeiCeVfuryayIUJln8B22oWW50Hv6wT1Mrh5uKt/f+jifmUxVeFkgjoDxN4owfZ4QF4/YJ0NEZW1UqFsS3kKdWyD96U8Om+Vu28Ltal3J9iP111VrIgx6vHpwhQqONOSNopexs5w8R1rIwP81Fwvw2yAYDw6jioO6O6j2h22kV x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_3FE94AA365924F3AA7807A224903806Dciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 986ccadb-fb24-48cb-fd98-08d79842e513 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2020 16:08:57.4235 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: E+LKo4wdG8j3NjhI8ZmmGDY42EH4IB6QecouMNAHYOnbeomYkHYR67zrvqxdnif76voMOlDTq2ZQZ4twReaPZA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1291 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: [secdir] Moving forward with draft-ietf-dprive-rfc7626-bis X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2020 16:09:03 -0000 --_000_3FE94AA365924F3AA7807A224903806Dciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2l0aCBteSBBRCBoYXQgb24NCg0KVGhlcmUgaGF2ZSBiZWVuIGEgbG90IG9mIGVtYWlscyBmb2xs b3dpbmcgdGhlIElFVEYgbGFzdCBjYWxsICh0aGF0IGV4cGlyZWQgMm5kIG9mIERlY2VtYmVyIDIw MTkpLiBVcCB0byB0aGUgcG9pbnQgdGhhdCBub3cgdGhlIGRpc2N1c3Npb24gaXMgYWJvdXQgY29t bWVudGluZyBjb21tZW50cyB0aGF0IHdlcmUgY29tbWVudHMgb24gYSBwcmV2aW91cyBjb21tZW50 LiBUbyBiZSBob25lc3QsIEkgaGF2ZSBsb3N0IHRoZSB0aHJlYWQgaGVyZS4NCg0KQnkgdGhpcyBl bWFpbCwgSSBhbSBhc2tpbmcgU2FyYSBhbmQgU3TDqXBoYW5lIHRvIHByb3Bvc2UgYSByZXZpc2Vk IElEIHRyeWluZyB0byBpbnRlZ3JhdGUgdGhlIG1heGltdW0gZmVlZGJhY2sgdGhhdCBhcmUgYmFz ZWQgb24gZmFjdHMvZGF0YSByYXRoZXIgdGhhbiBvcGluaW9ucy4gT25jZSBpdCBpcyBkb25lLCB0 aGVuIHdlIGNhbiBjb250aW51ZSB0aGUgZGlzY3Vzc2lvbiBpbiBhIG1vcmUgdXNlZnVsIHdheS4g SWYgdGhlIGRvY3VtZW50IGlzIGhlYXZpbHkgdXBkYXRlZCwgdGhlbiBJIGFtIHJlcXVlc3Rpbmcg YW5vdGhlciBJRVRGIGxhc3QgY2FsbC4NCg0KSSBzaW5jZXJlbHkgYmVsaWV2ZSB0aGF0IHRoaXMg d2lsbCBiZSB0aGUgYmVzdCB1c2Ugb2YgdGhlIHRpbWUgb2YgdGhpcyBjb21tdW5pdHkuDQoNClRo YW5rIHlvdSB2ZXJ5IG11Y2ggU2FyYSBhbmQgU3TDqXBoYW5lIGluIGFkdmFuY2UgZm9yIGNvbnNp ZGVyaW5nIHRoaXMgcmVxdWVzdC4NClRoYW5rIHlvdSBhbGwgZm9yIGFsbCB0aGUgY29tbWVudHMg b24gdGhpcyB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudC4NCg0KUmVnYXJkcywNCg0KLcOpcmljDQoN Cg== --_000_3FE94AA365924F3AA7807A224903806Dciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0 IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9 IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5XaXRoIG15IEFEIGhhdCBvbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhlcmUgaGF2ZSBiZWVuIGEg bG90IG9mIGVtYWlscyBmb2xsb3dpbmcgdGhlIElFVEYgbGFzdCBjYWxsICh0aGF0IGV4cGlyZWQg MjxzdXA+bmQ8L3N1cD4gb2YgRGVjZW1iZXIgMjAxOSkuIFVwIHRvIHRoZSBwb2ludCB0aGF0IG5v dyB0aGUgZGlzY3Vzc2lvbiBpcyBhYm91dCBjb21tZW50aW5nIGNvbW1lbnRzIHRoYXQgd2VyZSBj b21tZW50cyBvbiBhIHByZXZpb3VzDQogY29tbWVudC4gVG8gYmUgaG9uZXN0LCBJIGhhdmUgbG9z dCB0aGUgdGhyZWFkIGhlcmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5CeSB0aGlzIGVtYWlsLCBJIGFtIGFza2luZyBTYXJhIGFuZCBTdMOpcGhhbmUgdG8gcHJv cG9zZSBhIHJldmlzZWQgSUQgdHJ5aW5nIHRvIGludGVncmF0ZSB0aGUgbWF4aW11bSBmZWVkYmFj ayB0aGF0IGFyZSBiYXNlZCBvbiBmYWN0cy9kYXRhIHJhdGhlciB0aGFuIG9waW5pb25zLiBPbmNl IGl0IGlzIGRvbmUsIHRoZW4gd2UgY2FuIGNvbnRpbnVlIHRoZSBkaXNjdXNzaW9uDQogaW4gYSBt b3JlIHVzZWZ1bCB3YXkuIElmIHRoZSBkb2N1bWVudCBpcyBoZWF2aWx5IHVwZGF0ZWQsIHRoZW4g SSBhbSByZXF1ZXN0aW5nIGFub3RoZXIgSUVURiBsYXN0IGNhbGwuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIHNpbmNlcmVseSBiZWxpZXZlIHRoYXQgdGhpcyB3 aWxsIGJlIHRoZSBiZXN0IHVzZSBvZiB0aGUgdGltZSBvZiB0aGlzIGNvbW11bml0eS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoYW5rIHlvdSB2ZXJ5IG11Y2gg U2FyYSBhbmQgU3TDqXBoYW5lIGluIGFkdmFuY2UgZm9yIGNvbnNpZGVyaW5nIHRoaXMgcmVxdWVz dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+VGhhbmsgeW91IGFsbCBmb3IgYWxsIHRoZSBjb21tZW50cyBv biB0aGlzIHZlcnNpb24gb2YgdGhlIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPi3DqXJpYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_3FE94AA365924F3AA7807A224903806Dciscocom_-- From nobody Mon Jan 13 08:27:22 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72306120876; Mon, 13 Jan 2020 08:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=sinodun.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 nuHZk_giKDT0; Mon, 13 Jan 2020 08:27:16 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 508A6120869; Mon, 13 Jan 2020 08:27:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sinodun.com ; s=mythic-beasts-k1; h=To:Date:Subject:From; bh=q1sQUlX3eVgbzGoPnhi0Yc1rqqRijrDM94hTmZeJwl0=; b=E4C7lpY6NAKDpWUe1INTJfANP8 TM/Jh4JFEUQBOGmfw0Gc1Y0nYv0/yWWdPH5zAIecYAaURgt3f1FfOOu+btkvL0uWx6ODoaH04JRgz 1y4hrzgZVaulubQdo+PdMgcIr4m+78jqlm+etMmjWtkx5ZQ5EHHXcVMl9GFgDcNV3eE/DsSO/gfY2 zEmp9QMREKzHpobUD4leBJDGYCYvDloTx2K3JO8lL2w0v8zXfk36ma0rq8gEDG2+tbizICn621isD mvabaQ3H0gW7xgzXe3Awx+6PGYD72qQmyarF7z/+s9s4VkOYegf7uHmE931JjzzDU1XAwwEeH5qGj xVDYsSwQ==; Received: from [2a02:8010:6126:0:9c9f:b1c0:94d0:50ec] (port=55777) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1ir2YY-0003EB-4F; Mon, 13 Jan 2020 16:27:14 +0000 From: Sara Dickinson Message-Id: <5E9BE2DD-8525-4F77-BDF3-1A76E3E9E41E@sinodun.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4932D130-68B2-4408-A4A3-C9AA1A63FD1B" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 13 Jan 2020 16:26:17 +0000 In-Reply-To: <3FE94AA3-6592-4F3A-A780-7A224903806D@cisco.com> Cc: DNS Privacy Working Group , "draft-ietf-dprive-rfc7626-bis.all@ietf.org" , "secdir@ietf.org" , Rob Sayre , Martin Thomson , Eric Rescorla , S Moonesamy , Neil Cook , Christian Huitema , Vittorio Bertola , Stephen Farrell , Benjamin Kaduk To: "Eric Vyncke (evyncke)" References: <3FE94AA3-6592-4F3A-A780-7A224903806D@cisco.com> X-Mailer: Apple Mail (2.3445.104.11) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [secdir] Moving forward with draft-ietf-dprive-rfc7626-bis X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2020 16:27:19 -0000 --Apple-Mail=_4932D130-68B2-4408-A4A3-C9AA1A63FD1B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Eric,=20 Many thanks for this - I will work my way through the current = discussions and try to have an updated draft out in the next few days. Best regards Sara.=20 > On 13 Jan 2020, at 16:08, Eric Vyncke (evyncke) = wrote: >=20 > With my AD hat on > =20 > There have been a lot of emails following the IETF last call (that = expired 2nd of December 2019). Up to the point that now the discussion = is about commenting comments that were comments on a previous comment. = To be honest, I have lost the thread here. > =20 > By this email, I am asking Sara and St=C3=A9phane to propose a revised = ID trying to integrate the maximum feedback that are based on facts/data = rather than opinions. Once it is done, then we can continue the = discussion in a more useful way. If the document is heavily updated, = then I am requesting another IETF last call. > =20 > I sincerely believe that this will be the best use of the time of this = community. > =20 > Thank you very much Sara and St=C3=A9phane in advance for considering = this request. > Thank you all for all the comments on this version of the document. > =20 > Regards, > =20 > -=C3=A9ric --Apple-Mail=_4932D130-68B2-4408-A4A3-C9AA1A63FD1B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Eric, 

Many = thanks for this - I will work my way through the current discussions and = try to have an updated draft out in the next few days.

Best regards

Sara. 

On 13 Jan 2020, at 16:08, Eric Vyncke (evyncke) <evyncke@cisco.com> = wrote:

With my AD hat on
 
There have been a = lot of emails following the IETF last call (that expired 2nd of = December 2019). Up to the point that now the discussion is about = commenting comments that were comments on a previous comment. To be = honest, I have lost the thread here.
 
By this email, I = am asking Sara and St=C3=A9phane to propose a revised ID trying to = integrate the maximum feedback that are based on facts/data rather than = opinions. Once it is done, then we can continue the discussion in a more = useful way. If the document is heavily updated, then I am requesting = another IETF last call.
 
I sincerely = believe that this will be the best use of the time of this = community.
 
Thank you very = much Sara and St=C3=A9phane in advance for considering this request.
Thank you all for all the comments = on this version of the document.
 
Regards,
 
-=C3=A9ric

= --Apple-Mail=_4932D130-68B2-4408-A4A3-C9AA1A63FD1B-- From nobody Thu Jan 16 08:01:20 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A185120072; Thu, 16 Jan 2020 02:24:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1579170259; bh=JvBuoha1vWYWGoFyO/gk7gW/JOxMv5KFpw6E56GSpVU=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=h9WbjpDI7LL7hPck+ncbdOmbToPXixH4wG3cjXFDemerUIE/+zZx8F5KtS6wBiEyD +RYb3wZc2KBKn6RUofAKWRC7c9Zj12Vv5Iv+/Ex36x46OCVh5vAElJTeyDMS2gx9jZ +uOUiFDToaph5/q8YrCir0b2pwl26MVEKYBzUZZI= X-Mailbox-Line: From new-work-bounces@ietf.org Thu Jan 16 02:24:18 2020 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A971200F9; Thu, 16 Jan 2020 02:24:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1579170258; bh=JvBuoha1vWYWGoFyO/gk7gW/JOxMv5KFpw6E56GSpVU=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=AUcT820RuX4hO3hHNRdGi/oc73qPcPHcgW9UVR0rK70cHQ/PcjcW0ySfjFaCzuw/Q lln/8gWdTubn2WQt1xWhFes4G2A4AHLh2JuKHsjlUWnNVHtoWR6yJMYraq55Mf8Aga JLn8gjWZ9KOhnibJGW2VnPMKDXhIc/nru+noRepY= 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 5171D120A2E for ; Thu, 16 Jan 2020 02:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, 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 VxwfrxUUxaLg for ; Thu, 16 Jan 2020 02:24:05 -0800 (PST) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0E4312006F for ; Thu, 16 Jan 2020 02:24:05 -0800 (PST) Received: from [42.100.6.117] (helo=[192.168.1.2]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1is2Jo-0006Vl-0h for new-work@ietf.org; Thu, 16 Jan 2020 10:24:04 +0000 To: new-work@ietf.org From: xueyuan Message-ID: <5b2571e9-d88c-3671-1b27-04c0d538ea86@w3.org> Date: Thu, 16 Jan 2020 18:24:00 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Thu, 16 Jan 2020 08:01:19 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: WebAssembly Working Group (until 2020-02-13) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 10:24:21 -0000 CkhlbGxvLAoKVG9kYXkgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMgcmVj ZWl2ZWQgYSBQcm9wb3NhbAp0byByZXZpZXcgYSBkcmFmdCBjaGFydGVyIGZvciB0aGUgV2ViQXNz ZW1ibHkgV29ya2luZyBHcm91cDoKIMKgIGh0dHBzOi8vd3d3LnczLm9yZy8yMDIwLzAxL3dhc20t d2ctY2hhcnRlci0yMDIwLXByb3Bvc2VkLmh0bWwKCkFzIHBhcnQgb2YgZW5zdXJpbmcgdGhhdCB0 aGUgY29tbXVuaXR5IGlzIGF3YXJlIG9mIHByb3Bvc2VkIHdvcmsKYXQgVzNDLCB0aGlzIGRyYWZ0 IGNoYXJ0ZXIgaXMgcHVibGljIGR1cmluZyB0aGUgQWR2aXNvcnkKQ29tbWl0dGVlIHJldmlldyBw ZXJpb2QuCgpXM0MgaW52aXRlcyBwdWJsaWMgY29tbWVudHMgdGhyb3VnaCAyMDIwLTAyLTEzIG9u IHRoZQpwcm9wb3NlZCBjaGFydGVyLiBQbGVhc2Ugc2VuZCBjb21tZW50cyB0bwpwdWJsaWMtbmV3 LXdvcmtAdzMub3JnLCB3aGljaCBoYXMgYSBwdWJsaWMgYXJjaGl2ZToKIMKgIGh0dHA6Ly9saXN0 cy53My5vcmcvQXJjaGl2ZXMvUHVibGljL3B1YmxpYy1uZXctd29yay8KCk90aGVyIHRoYW4gY29t bWVudHMgc2VudCBpbiBmb3JtYWwgcmVzcG9uc2VzIGJ5IFczQyBBZHZpc29yeQpDb21taXR0ZWUg UmVwcmVzZW50YXRpdmVzLCBXM0MgY2Fubm90IGd1YXJhbnRlZSBhIHJlc3BvbnNlIHRvCmNvbW1l bnRzLiBJZiB5b3Ugd29yayBmb3IgYSBXM0MgTWVtYmVyIFsxXSwgcGxlYXNlIGNvb3JkaW5hdGUK eW91ciBjb21tZW50cyB3aXRoIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZl LiBGb3IKZXhhbXBsZSwgeW91IG1heSB3aXNoIHRvIG1ha2UgcHVibGljIGNvbW1lbnRzIHZpYSB0 aGlzIGxpc3QgYW5kCmhhdmUgeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50YXRpdmUg cmVmZXIgdG8gaXQgZnJvbSBoaXMKb3IgaGVyIGZvcm1hbCByZXZpZXcgY29tbWVudHMuCgpUaGUg V2ViQXNzZW1ibHkgV29ya2luZyBHcm91cCdzIGN1cnJlbnQgY2hhcnRlciBpcyBoZXJlYnkgZXh0 ZW5kZWQKdW50aWwgMjggRmVicnVhcnkgMjAyMCwgdG8gYWNjb21tb2RhdGUgdGhlIGNoYXJ0ZXIg cmV2aWV3IHBlcmlvZC4KIMKgIGh0dHBzOi8vd3d3LnczLm9yZy8yMDE3LzA4L3dhc20tY2hhcnRl cgoKSWYgeW91IHNob3VsZCBoYXZlIGFueSBxdWVzdGlvbnMgb3IgbmVlZCBmdXJ0aGVyIGluZm9y bWF0aW9uLCBwbGVhc2UKY29udGFjdCBFcmljIFBydWQnaG9tbWVhdXgsIFdlYkFzc2VtYmx5IFdv cmtpbmcgR3JvdXAKVGVhbSBDb250YWN0LCBhdCA8ZXJpY3BAdzMub3JnPi4KClRoYW5rIHlvdSwK Clh1ZXl1YW4gSmlhLCBXM0MgTWFya2V0aW5nICYgQ29tbXVuaWNhdGlvbnMKClsxXSBodHRwOi8v d3d3LnczLm9yZy9Db25zb3J0aXVtL01lbWJlci9MaXN0CgpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwpuZXctd29yayBtYWlsaW5nIGxpc3QKbmV3LXdvcmtA aWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXctd29yawo= From nobody Thu Jan 16 10:03:32 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 99570120071; Thu, 16 Jan 2020 10:03:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yoav Nir via Datatracker To: Cc: last-call@ietf.org, 6tisch@ietf.org, draft-ietf-6tisch-enrollment-enhanced-beacon.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Yoav Nir Message-ID: <157919779948.26195.4879220696306890525@ietfa.amsl.com> Date: Thu, 16 Jan 2020 10:03:19 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-6tisch-enrollment-enhanced-beacon-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 18:03:20 -0000 Reviewer: Yoav Nir Review result: Has Nits The draft is short and to the point and easy to understand. The security considerations (and privacy considerations!) sections are well written and cover everything. I'm just missing one clause. The first paragraph reads: All of the contents of this Information Element are sent in the clear. The containing Enhanced Beacon is not encrypted. What I'm missing is "...and this is fine because the 6tisch-Join-Info structure contains no sensitive information." I'm not disputing this or asking for rigorous proof, but it you say "this is sent in the clear", you should finish with at least a statement that says that this is OK. From nobody Thu Jan 16 14:26:28 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D82D912010D for ; Thu, 16 Jan 2020 14:26:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mail-udp-cl.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 EpFyKA0OYcLV for ; Thu, 16 Jan 2020 14:26:07 -0800 (PST) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (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 A96011200FA for ; Thu, 16 Jan 2020 14:26:07 -0800 (PST) Received: by mail-ot1-x32c.google.com with SMTP id r27so20881055otc.8 for ; Thu, 16 Jan 2020 14:26:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail-udp-cl.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pL2qz41DzRdx27CsfzJm9GRBB9EJHhF5p1T6C0lOah8=; b=d8EeWVqE6eWEwsO6Wh35egb0Yy9/BTFr9hfUbrgCaNUY/fUOfGJIQQNUtbdqQQvdFZ UaHIQHp92DDrePH9Jd2JUUSAFTP8+ckrYPxOAGd5q8bK3ltGx7YlqnYPT6A/uZo/dweq Qr9kmoO68ndgGx+9D8hBDlHi+qlBZQN39ndGop1V49+lXo3n87YwVgpwAw6pB4/IptkL zVDe29PvsorB1hrrloyRnepTdkm8LalMyHennsWsNLZJWSGHy3FhxuuVe2us+jysTdV7 xQODBOeolfqg57eAYS5n4YOaf2HRNvZuMQYdG18MUjSHXBORWj1K47uot1MMni7xLDGd KMQQ== 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=pL2qz41DzRdx27CsfzJm9GRBB9EJHhF5p1T6C0lOah8=; b=SegPopjDLN3fBp4Sx0V2RqVO+ggNtXdXRxjSNZ72c+wNXptxeG1NHuNCmhjXdSxUYN Lohfoy+GQbxeW9hO4KZv8fkls9lmi0C27az3Bepf5gcnYYf3TC5Qja31b3BJvEmhMjkG u8uOgCWCBU7fk1kMmY8xUH3t5WGkrIIJUQjif7Eyuxlop/NyFZni2jy3faT1If7/owXO ESeNHBrirED1wn1MfDOu6nkjq9hfX5o+NPwBnAZ79er3vnw9kTcqkgoZi0Rz2ZYGF1vo /yWMsD5rczY+QwTqimKZG5PGIJk4c4zwE2m6E6CmzJm5JlyKFLqYbCh8O4LnsKOAVKVQ TmAw== X-Gm-Message-State: APjAAAVMcT4ZkQagQMhXy//XlNels0EmEsFFqvGve+8XptAEsKNfBnOE znyhPiOLV1cfaz7xZDuhNfyQH6uY/KgvqbMl/qiDYA== X-Google-Smtp-Source: APXvYqxAwPvmTbrKNgtqWe7IDqAhrbgUCDpUUDIvbLCRCjXxjYeF84xbR3tqMLQu/tulxUxPXwKRwto0bbYQYt3y4f4= X-Received: by 2002:a05:6830:1042:: with SMTP id b2mr3888016otp.306.1579213566825; Thu, 16 Jan 2020 14:26:06 -0800 (PST) MIME-Version: 1.0 References: <157919779948.26195.4879220696306890525@ietfa.amsl.com> In-Reply-To: <157919779948.26195.4879220696306890525@ietfa.amsl.com> From: "Prof. Diego Dujovne" Date: Thu, 16 Jan 2020 19:25:54 -0300 Message-ID: To: Yoav Nir Cc: secdir@ietf.org, last-call@ietf.org, 6tisch@ietf.org, draft-ietf-6tisch-enrollment-enhanced-beacon.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000ad3cfe059c494f2f" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-6tisch-enrollment-enhanced-beacon-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 22:26:16 -0000 --000000000000ad3cfe059c494f2f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yoav, Thank you for your feedback. I will add that line on the next version. Regards, Diego Dujovne Le jeu. 16 janv. 2020 =C3=A0 15:03, Yoav Nir via Datatracker a =C3=A9crit : > Reviewer: Yoav Nir > Review result: Has Nits > > The draft is short and to the point and easy to understand. The security > considerations (and privacy considerations!) sections are well written an= d > cover everything. I'm just missing one clause. > > The first paragraph reads: > All of the contents of this Information Element are sent in the > clear. The containing Enhanced Beacon is not encrypted. > > What I'm missing is "...and this is fine because the 6tisch-Join-Info > structure > contains no sensitive information." > > I'm not disputing this or asking for rigorous proof, but it you say "this > is > sent in the clear", you should finish with at least a statement that says > that > this is OK. > > --=20 DIEGO DUJOVNE Profesor Asociado Escuela de Inform=C3=A1tica y Telecomunicaciones Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile www.ingenieria.udp.cl (56 2) 676 8125 --000000000000ad3cfe059c494f2f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yoav,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thank you for = your feedback. I will add that line on the next version.
Regards,=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Diego = Dujovne

Le=C2=A0jeu. 16 janv. 2020 =C3=A0=C2=A015:03, Yoav Nir via Dat= atracker <noreply@ietf.org> a= =C3=A9crit=C2=A0:
Reviewer: Yoav Nir
Review result: Has Nits

The draft is short and to the point and easy to understand.=C2=A0 The secur= ity
considerations (and privacy considerations!) sections are well written and<= br> cover everything.=C2=A0 I'm just missing one clause.

The first paragraph reads:
=C2=A0 =C2=A0All of the contents of this Information Element are sent in th= e
=C2=A0 =C2=A0clear.=C2=A0 The containing Enhanced Beacon is not encrypted.<= br>
What I'm missing is "...and this is fine because the 6tisch-Join-I= nfo structure
contains no sensitive information."

I'm not disputing this or asking for rigorous proof, but it you say &qu= ot;this is
sent in the clear", you should finish with at least a statement that s= ays that
this is OK.



--
DIEG= O DUJOVNE
Profesor Asociado
Escuela de Inform=C3=A1tica y Telecomunic= aciones
Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile=
www.ingenier= ia.udp.cl
(56 2) 676 8125
--000000000000ad3cfe059c494f2f-- From nobody Thu Jan 16 19:13:48 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E48A1200C7; Thu, 16 Jan 2020 19:13:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Daniel Migault via Datatracker To: Cc: last-call@ietf.org, draft-kucherawy-rfc8478bis.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Daniel Migault Message-ID: <157923082130.28013.7055294120071438477@ietfa.amsl.com> Date: Thu, 16 Jan 2020 19:13:41 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-kucherawy-rfc8478bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 03:13:41 -0000 Reviewer: Daniel Migault Review result: Has Nits 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: Has Nits Please find my comments below Yours , Daniel [...] 3.1.1. Zstandard Frames The structure of a single Zstandard frame is as follows: +--------------------+------------+ | Magic_Number | 4 bytes | +--------------------+------------+ | Frame_Header | 2-14 bytes | +--------------------+------------+ | Data_Block | n bytes | +--------------------+------------+ | [More Data_Blocks] | | +--------------------+------------+ | [Content_Checksum] | 0-4 bytes | +--------------------+------------+ Magic_Number: 4 bytes, little-endian format. Value: 0xFD2FB528. Frame_Header: 2 to 14 bytes, detailed in Section 3.1.1.1. Data_Block: Detailed in Section 3.1.1.2. This is where data appears. Given that Content Check sum is mentioned as optional, I believe that its size can be indicated to 4 bytes. One additional nit, the Frame Header does not take any value between 2 and 14 but actually a subset of such values. I am not sure these values should be listed instead. [...] 3.1.1.1.1.1. Frame_Content_Size_Flag This is a 2-bit flag (equivalent to Frame_Header_Descriptor right- shifted 6 bits) specifying whether Frame_Content_Size (the decompressed data size) is provided within the header. Flag_Value provides FCS_Field_Size, which is the number of bytes used by Frame_Content_Size according to the following table: +----------------+--------+---+---+---+ | Flag_Value | 0 | 1 | 2 | 3 | +----------------+--------+---+---+---+ | FCS_Field_Size | 0 or 1 | 2 | 4 | 8 | +----------------+--------+---+---+---+ When Flag_Value is 0, FCS_Field_Size depends on Single_Segment_Flag: If Single_Segment_Flag is set, FCS_Field_Size is 1. Otherwise, FCS_Field_Size is 0; Frame_Content_Size is not provided. Purely editorial, but it seems to me clearer not having to designations for the same entity, so maybe replacing Flag by Frame_Content_Size_Flag might be easier to read. In addition, Flag_Value looks like another variable and might represented as Frame_Content_Size_Flag value instead. Similarly, it might be clearer replacing FCS_Field_Size by Frame_Content_Size field's length. 3.1.1.1.1.2. Single_Segment_Flag If this flag is set, data must be regenerated within a single continuous memory segment. In this case, Window_Descriptor byte is skipped, but Frame_Content_Size is necessarily present. As a consequence, the decoder must allocate a memory segment of size equal or larger than Frame_Content_Size. I understand this information as being interpreted by the decompressor to proceed to the decompression. More specifically, the decompressed files indicates that such amount of memory will be needed to proceed to the decompression. I assume that at least the decompressed frame is expected to fit into value indicated by the Frame_Content_Size. I believe it might be useful to clearly indicate that mechanism needs to be provided to check while processing the file, the process does not go beyond the allocated memory, and if so an error needs to be returned and the decompression aborted. The main difference with the considerations mentioned below is that the check is not provided at run time. This is somewhat mentioned in the security consideration, but it might be beneficial to have this at specific places in the document. [...] 3.1.1.1.1.3. Unused Bit A decoder compliant with this specification version shall not interpret this bit. It might be used in a future version, to signal a property that is not mandatory to properly decode the frame. An encoder compliant with this specification must set this bit to zero. Probably normative language may be needed here (MUST/MUST NOT). SHOULD be zero for the decompressor and MUST be set to zero by the compressor. 3.1.1.1.1.4. Reserved Bit This bit is reserved for some future feature. Its value must be zero. A decoder compliant with this specification version must ensure it is not set. This bit may be used in a future revision, to signal a feature that must be interpreted to decode the frame correctly. Normative language may be appropriated as well. [...] 3.1.1.1.1.6. Dictionary_ID_Flag This is a 2-bit flag (= Frame_Header_Descriptor & 0x3) indicating whether a dictionary ID is provided within the header. It also specifies the size of this field as DID_Field_Size: +----------------+---+---+---+---+ | Flag_Value | 0 | 1 | 2 | 3 | +----------------+---+---+---+---+ | DID_Field_Size | 0 | 1 | 2 | 4 | +----------------+---+---+---+---+ same comments regarding _Value and FIeld_Size> 3.1.1.1.2. Window Descriptor This provides guarantees about the minimum memory buffer required to decompress a frame. This information is important for decoders to allocate enough memory. Same comment regarding the ability to set boundaries to the memory allocating. I have the impression that memory allocation can serve two purposes: storing the Block as well as some context associated to the processing. I am wondering if that is correct or not. I suspect that if there is a relation with the Frame Size, it might be restricted to the decompressed data. The Window_Descriptor byte is optional. When Single_Segment_Flag is set, Window_Descriptor is not present. In this case, Window_Size is Collet & Kucherawy Expires June 22, 2020 [Page 9] Internet-Draft application/zstd December 2019 Frame_Content_Size, which can be any value from 0 to 2^64-1 bytes (16 ExaBytes). I have the impression that some checks on Windows Size with the Frame SIze can be performed. If that is correct, I believe these should be mentioned. It seems that in any cases Window_Size <= Frame_Size. +------------+----------+----------+ | Bit Number | 7-3 | 2-0 | +------------+----------+----------+ | Field Name | Exponent | Mantissa | +------------+----------+----------+ The minimum memory buffer size is called Window_Size. It is described by the following formulae: windowLog = 10 + Exponent; windowBase = 1 << windowLog; windowAdd = (windowBase / 8) * Mantissa; Window_Size = windowBase + windowAdd; The minimum Window_Size is 1 KB. The maximum Window_Size is (1<<41) + 7*(1<<38) bytes, which is 3.75 TB. In general, larger Window_Size values tend to improve the compression ratio, but at the cost of increased memory usage. To properly decode compressed data, a decoder will need to allocate a buffer of at least Window_Size bytes. In order to protect decoders from unreasonable memory requirements, a decoder is allowed to reject a compressed frame that requests a memory size beyond decoder's authorized range. For improved interoperability, it's recommended for decoders to support values of Window_Size up to 8 MB and for encoders not to generate frames requiring a Window_Size larger than 8 MB. It's merely a recommendation though, and decoders are free to support larger or lower limits, depending on local limitations. I think the recommendation is to not use Window_Size larger than 8MB, which will leave minimal implementation to have a fixed Windows Size of 8MB. This also means that Windows_Size mechanism is not supported. I would be a bit reluctant to discourage implementing this mechanism as those implementation may stay forever, and make any use of larger Windows_Size than 8MB. I am wondering if the limitation should not result from deployed hardware. In which case we could write this recommendation as to limit the Windows Size to 8MB. 3.1.1.1.3. Dictionary_ID This is a variable size field, which contains the ID of the dictionary required to properly decode the frame. This field is optional. When it's not present, it's up to the decoder to know which dictionary to use. I understand the document does not define Dictionary_ID. It might be worth clarifying this here. Dictionary_ID field size is provided by DID_Field_Size. DID_Field_Size is directly derived from the value of Dictionary_ID_Flag. One byte can represent an ID 0-255; 2 bytes can represent an ID 0-65535; 4 bytes can represent an ID 0-4294967295. Format is little-endian. Collet & Kucherawy Expires June 22, 2020 [Page 10] Internet-Draft application/zstd December 2019 It is permitted to represent a small ID (for example, 13) with a large 4-byte dictionary ID, even if it is less efficient. Within private environments, any dictionary ID can be used. However, for frames and dictionaries distributed in public space, Dictionary_ID must be attributed carefully. I think that "carefully" needs to be specified a bit more. Though I suppose this is defined in the IANA section. I also suppose that low and high ranges are allocated to specific categories. If these ranges are introduced, it might worth to specify the purpose of each range. The ranges (high, low) do not map the possibles sizes (unspecified, 0-255, 256-2**16-1, 2**16-2**32-1). Maybe ths could be clarified as well. The following ranges are reserved for use only with dictionaries that have been registered with IANA (see Section 7.4): low range: <= 32767 high range: >= (1 << 31) Any other value for Dictionary_ID can be used by private arrangement between participants. Any payload presented for decompression that references an unregistered reserved dictionary ID results in an error. 3.1.1.1.4. Frame Content Size This is the original (uncompressed) size. This information is optional. Frame_Content_Size uses a variable number of bytes, provided by FCS_Field_Size. FCS_Field_Size is provided by the value of Frame_Content_Size_Flag. FCS_Field_Size can be equal to 0 (not present), 1, 2, 4, or 8 bytes. +----------------+--------------+ | FCS Field Size | Range | +----------------+--------------+ | 0 | unknown | +----------------+--------------+ | 1 | 0 - 255 | +----------------+--------------+ | 2 | 256 - 65791 | +----------------+--------------+ | 4 | 0 - 2^32 - 1 | +----------------+--------------+ | 8 | 0 - 2^64 - 1 | +----------------+--------------+ Frame_Content_Size format is little-endian. When FCS_Field_Size is 1, 4, or 8 bytes, the value is read directly. When FCS_Field_Size is 2, the offset of 256 is added. It's allowed to represent a small size (for example 18) using any compatible variant. Probably some checks needs to be enforced and decompressor behavior needs to be specified. [...] 3.1.1.2.3. Block_Size The upper 21 bits of Block_Header represent the Block_Size. When Block_Type is Compressed_Block or Raw_Block, Block_Size is the size of Block_Content (hence excluding Block_Header). When Block_Type is RLE_Block, since Block_Content's size is always 1, Block_Size represents the number of times this byte must be repeated. Block_Size is limited by Block_Maximum_Size (see below). I suspect that Block_Size may be verified against the Frame Content Size ? 3.1.1.2.4. Block_Content and Block_Maximum_Size The size of Block_Content is limited by Block_Maximum_Size, which is the smallest of: o Window_Size o 128 KB Given that it was recommended to support windows up to 8MB, I am wondering why blocks cannot be larger. This is probably ignorance and I apology for the question. Block_Maximum_Size is constant for a given frame. This maximum is applicable to both the decompressed size and the compressed size of any block in the frame. The reasoning for this limit is that a decoder can read this information at the beginning of a frame and use it to allocate buffers. The guarantees on the size of blocks ensure that the buffers will be large enough for any following block of the valid frame. 3.1.1.3. Compressed Blocks To decompress a compressed block, the compressed size must be provided from the Block_Size field within Block_Header. Collet & Kucherawy Expires June 22, 2020 [Page 13] Internet-Draft application/zstd December 2019 A compressed block consists of two sections: a Literals Section (Section 3.1.1.3.1) and a Sequences_Section (Section 3.1.1.3.2). The results of the two sections are then combined to produce the decompressed data in Sequence Execution (Section 3.1.1.4). To decode a compressed block, the following elements are necessary: o Previous decoded data, up to a distance of Window_Size, or the beginning of the Frame, whichever is smaller. Single_Segment_Flag will be set in the latter case. o List of "recent offsets" from the previous Compressed_Block. This is a general comment when execution is based on computed length, size, or involve offsets. I also susect that reading backward might result in a few additional risks. It would be good to specify the boundaries associated to these values to avoid buffer overflow. If such check ar not possible, it would be good also to raise the concern that the implementation needs to carefully handle that operation. Now that have been through the Security Consideration Section, I can see this has been done for one variable, but I am not sure others variable defined in the doc are not subject to the same type of attacks. o The previous Huffman tree, required by Treeless_Literals_Block type. o Previous Finite State Entropy (FSE) decoding tables, required by Repeat_Mode, for each symbol type (literals lengths, match lengths, offsets). Note that decoding tables are not always from the previous Compressed_Block: o Every decoding table can come from a dictionary. o The Huffman tree comes from the previous Compressed_Literals_Block. My knowledge in compression are too weak to comment, but my understanding is that decompression relies on decoding tables. Which means that they can influence the processing either via the dictionary, a specifically crafted compressed block,.... I am wondering how these tables can influence the execution: * does different tables end in different usage of resources? I think no. If the table ends in different outputs, this might be used to compress Content1 and decompress it in Content 2. ? If that is possible, I believe the security consideration should recommend that Content signature MUST always be provided on the decompressed content, and not the compressed content. The same considerations are of course valid for anything that influence the compression/decompression. [...] 3.1.1.3.1.6. Jump_Table The Jump_Table is only present when there are 4 Huffman-coded streams. (Reminder: Huffman-compressed data consists of either 1 or 4 Huffman- coded streams.) If only 1 stream is present, it is a single bitstream occupying the entire remaining portion of the literals block, encoded as described within Section 4.2.2. If there are 4 streams, Literals_Section_Header only provides enough information to know the decompressed and compressed sizes of all 4 streams combined. The decompressed size of each stream is equal to (Regenerated_Size+3)/4, except for the last stream, which may be up to 3 bytes smaller, to reach a total decompressed size as specified in Regenerated_Size. The compressed size of each stream is provided explicitly in the Jump_Table. The Jump_Table is 6 bytes long and consists of three 2-byte little-endian fields, describing the compressed sizes of the first 3 streams. Stream4_Size is computed from Total_Streams_Size minus sizes of other streams. Stream4_Size = Total_Streams_Size - 6 - Stream1_Size - Stream2_Size - Stream3_Size Note that if Stream1_Size + Stream2_Size + Stream3_Size exceeds Total_Streams_Size, the data are considered corrupted. I would maybe expect that implementation MUST check this. Each of these 4 bitstreams is then decoded independently as a Huffman-Coded stream, as described in Section 4.2.2. [...] 4.1.1. FSE Table Description To decode FSE streams, it is necessary to construct the decoding table. The Zstandard format encodes FSE table descriptions as described here. An FSE distribution table describes the probabilities of all symbols from 0 to the last present one (included) on a normalized scale of (1 << Accuracy_Log). Note that there must be two or more symbols with non-zero probability. A bitstream is read forward, in little-endian fashion. It is not necessary to know its exact size, since the size will be discovered and reported by the decoding process. The bitstream starts by reporting on which scale it operates. If low4bits designates the lowest 4 bits of the first byte, then Accuracy_Log = low4bits + 5. This looks like processing until the end to determine the size. If that is correct, it seems dangerous unless some measurements are take to prevent resource exhaustion. [...] 4.2. Huffman Coding Zstandard Huffman-coded streams are read backwards, similar to the FSE bitstreams. Therefore, to find the start of the bitstream, it is necessary to know the offset of the last byte of the Huffman-coded stream. After writing the last bit containing information, the compressor writes a single 1 bit and then fills the byte with 0-7 0 bits of padding. The last byte of the compressed bitstream cannot be 0 for that reason. fills the byte with 0-7 0 bits of... I have hard time to parse the sentence. I understand it as fills the byte by setting bits 0-7 to 0. [...] 7. IANA Considerations Given that the documents defines Dictionnaries, I am wondering if a registry shoudl not be created. [...] 7.4. Dictionaries Work in progress includes development of dictionaries that will optimize compression and decompression of particular types of data. Specification of such dictionaries for public use will necessitate registration of a code point from the reserved range described in Section 3.1.1.1.3 and its association with a specific dictionary. However, there are at present no such dictionaries published for public use, so this document makes no immediate request of IANA to create such a registry. Dictionnaries will probably be defined later through a standard process, I believe that is worth being mentioned. In addition, we may also insist on specifying the impact on resource as well as the resulting output need to be closely looked at. The problem being essentially if decompres(f, dict1) and decompress(f, dict2) provides different outputs and this property can be used by an attacker to transform the uncompressed file. 8. Security Considerations Any data compression method involves the reduction of redundancy in the data. Zstandard is no exception, and the usual precautions apply. One should never compress a message whose content must remain secret with a message generated by a third party. Such a compression can be used to guess the content of the secret message through analysis of entropy reduction. This was demonstrated in the Compression Ratio Info-leak Made Easy (CRIME) attack [CRIME], for example. When uncompressed data needs to be protected, it might be worth clarifying the differences associated to protecting (authenticating) the compressed data as opposed to the uncompressed data. I suspect if might be recommended to authenticate uncompressed data. A decoder has to demonstrate capabilities to detect and prevent any kind of data tampering in the compressed frame from triggering system faults, such as reading or writing beyond allowed memory ranges. This can be guaranteed by either the implementation language or careful bound checkings. Of particular note is the encoding of Number_of_Sequences values that cause the decoder to read into the block header (and beyond), as well as the indication of a Frame_Content_Size that is smaller than the actual decompressed data, in an attempt to trigger a buffer overflow. It is highly recommended to fuzz-test (i.e., provide invalid, unexpected, or random input and verify safe operation of) decoder implementations to test and harden Collet & Kucherawy Expires June 22, 2020 [Page 42] Internet-Draft application/zstd December 2019 their capability to detect bad frames and deal with them without any adverse system side effect. An attacker may provide correctly formed compressed frames with unreasonable memory requirements. A decoder must always control memory requirements and enforce some (system-specific) limits in order to protect memory usage from such scenarios. Compression can be optimized by training a dictionary on a variety of related content payloads. This dictionary must then be available at the decoder for decompression of the payload to be possible. While this document does not specify how to acquire a dictionary for a given compressed payload, it is worth noting that third-party dictionaries may interact unexpectedly with a decoder, leading to possible memory or other resource exhaustion attacks. We expect such topics to be discussed in further detail in the Security Considerations section of a forthcoming RFC for dictionary acquisition and transmission, but highlight this issue now out of an abundance of caution. As discussed in Section 3.1.2, it is possible to store arbitrary user metadata in skippable frames. While such frames are ignored during decompression of the data, they can be used as a watermark to track the path of the compressed payload. From nobody Fri Jan 17 14:50:15 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2E412006B; Fri, 17 Jan 2020 14:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PW2Q4bESQf8t; Fri, 17 Jan 2020 14:50:01 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41C0B12004C; Fri, 17 Jan 2020 14:50:01 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 5489C3897D; Fri, 17 Jan 2020 17:49:31 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 43D2E5D4; Fri, 17 Jan 2020 17:49:59 -0500 (EST) From: Michael Richardson To: Yoav Nir , secdir@ietf.org, last-call@ietf.org, 6tisch@ietf.org, draft-ietf-6tisch-enrollment-enhanced-beacon.all@ietf.org In-Reply-To: <157919779948.26195.4879220696306890525@ietfa.amsl.com> References: <157919779948.26195.4879220696306890525@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [secdir] [6tisch] Secdir last call review of draft-ietf-6tisch-enrollment-enhanced-beacon-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 22:50:03 -0000 <#secure method=pgpmime mode=sign> Yoav Nir via Datatracker wrote: > The draft is short and to the point and easy to understand. The security > considerations (and privacy considerations!) sections are well written and > cover everything. I'm just missing one clause. > The first paragraph reads: > All of the contents of this Information Element are sent in the > clear. The containing Enhanced Beacon is not encrypted. > What I'm missing is "...and this is fine because the 6tisch-Join-Info structure > contains no sensitive information." point taken. How do you feel about this: # Security Considerations All of the contents of this Information Element are sent in the clear. The containing Enhanced Beacon is not encrypted. This is a restriction in the cryptographic architecture of the TSCH mechanism. In order to decrypt or do integrity checking of layer-2 frames in TSCH, the TSCH Absolute Slot Number (ASN) is needed. The Enhanced Beacon provides the ASN to new (and long-sleeping) nodes. The Enhanced Beagon is authenticated at the layer-2 level using 802.15.4 mechanisms using the network-wide keying material. Nodes which are enrolled will have the network-wide keying material and can validate the beacon. Pledges which have not yet enrolled are unable to authenticate the beacons, and will be forced to temporarily take the contents on trust. After enrollment, the pledge will be able to return to the beacon and validate it. In addition to the enrollment and join information described in this document, the Enhanced Beacon contains a description of the TSCH schedule to be used by the transmitter of this packet. The schedule can provide an attacker with a list of channels and frequencies on which communication will occur. Knowledge of this can help an attacker to more efficiently jam communications, although there is future work being considered to make some of the schedule less visible. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- From nobody Sat Jan 18 20:23:47 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCB0120041; Sat, 18 Jan 2020 20:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUAbMw8HXyIU; Sat, 18 Jan 2020 20:23:27 -0800 (PST) Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (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 95ED9120025; Sat, 18 Jan 2020 20:23:27 -0800 (PST) Received: by mail-wr1-x443.google.com with SMTP id c14so26210019wrn.7; Sat, 18 Jan 2020 20:23:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sWZn+yDLv14eOPhOa62btO6jvKDsdo8AuCla/QEO9cY=; b=s7ew7IqflHDBP3RbyDlzExmdkAOkTGpJO0gvMchi1j+EsAeDeNIy8NFvsFGATqGGyO QEzoj8gsp/RrZKeO4FPySue0LfuyZHE+7kearK50yDvVhU34WlU+YZLIAHM4EVkiITBb UBkig7LYUKkhuAl80jPBwh2NJc5gawB+LwlwG5NL6c46ajSwzIRU74hEScGvFCoNS7im 5O6Yb2C/9Ygx4HHRofDrxWyVshXXVBXiwzlMcqe/KrEAuvrkJVB8PLe39sO5sJqzS3XF na6asCQmuplR7Au690MXhnKxEeWZv1SiE/GpnM2QeB5uFPhEY3WQrxm9IlkNjOfgDw/f jzRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sWZn+yDLv14eOPhOa62btO6jvKDsdo8AuCla/QEO9cY=; b=UAn0R0OBmn+jVYQSeNl8n17WM0WIx3hMun3KLRWjy2fcrfQV788TVB2pfHQD/qBDrf hkWX0DRtK+tZGScpgTdhJQxBvs5cNf2NPQgqHFJ+OhPcArofGBwRo/INv8ZAJsSpsvHJ +/8Ks2jgftPrxd3aDHD/smQIOrQ+ttfw6DPfon6wE1EKA9yjwvZ43qCqGUccq26L6Zcr f1GaCNx7b3t+PTZxyS4QuIpFKL0U2oA6GU21ntoT/z8Vdy8zndtRb5W4c2G+9vusGisr TMJMyYQ0f8H7R4Jou8J1nxzjhRSDPahBAupzarGFimgteux3sggw8/llCqJlTxNmSHSP nTAQ== X-Gm-Message-State: APjAAAUZDlucsUkd3rodnIDoV4tTb/ZKJ40i/DLjuczsdjIp6x10DjEZ /C84StLoGXWW2KOpv+/ioWDqnWoi X-Google-Smtp-Source: APXvYqxI68RYVGzmUCB8gui2KYumUtV97BVNCURTkmVOeZb9aQ04DGQacnm+RrBkNVatBw5eM5YNwQ== X-Received: by 2002:adf:eb0a:: with SMTP id s10mr10980925wrn.320.1579407806080; Sat, 18 Jan 2020 20:23:26 -0800 (PST) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id p17sm41387656wrx.20.2020.01.18.20.23.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Jan 2020 20:23:25 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Yoav Nir In-Reply-To: <1093.1579301399@localhost> Date: Sun, 19 Jan 2020 06:23:22 +0200 Cc: secdir , last-call@ietf.org, 6tisch@ietf.org, draft-ietf-6tisch-enrollment-enhanced-beacon.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <738E789C-14A8-41D5-956E-66E6CE2624DB@gmail.com> References: <157919779948.26195.4879220696306890525@ietfa.amsl.com> <1093.1579301399@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [secdir] [6tisch] Secdir last call review of draft-ietf-6tisch-enrollment-enhanced-beacon-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2020 04:23:29 -0000 Not really. You=E2=80=99ve added an explanation of why it=E2=80=99s hard = to encrypt. That is not needed IMO. What is needed is a statement that = sending in the clear (not the default in IETF protocols these days) is = OK because the data is not sensitive. > On 18 Jan 2020, at 0:49, Michael Richardson = wrote: >=20 >=20 > <#secure method=3Dpgpmime mode=3Dsign> >=20 > Yoav Nir via Datatracker wrote: >=20 >> The draft is short and to the point and easy to understand. The = security >> considerations (and privacy considerations!) sections are well = written and >> cover everything. I'm just missing one clause. >=20 >> The first paragraph reads: >> All of the contents of this Information Element are sent in the >> clear. The containing Enhanced Beacon is not encrypted. >=20 >> What I'm missing is "...and this is fine because the 6tisch-Join-Info = structure >> contains no sensitive information." >=20 > point taken. How do you feel about this: >=20 > # Security Considerations >=20 > All of the contents of this Information Element are sent in the clear. > The containing Enhanced Beacon is not encrypted. > This is a restriction in the cryptographic architecture of the TSCH > mechanism. > In order to decrypt or do integrity checking of layer-2 frames in = TSCH, the > TSCH Absolute Slot Number (ASN) is needed. > The Enhanced Beacon provides the ASN to new (and long-sleeping) nodes. >=20 > The Enhanced Beagon is authenticated at the layer-2 level using = 802.15.4 > mechanisms using the network-wide keying material. Nodes which are = enrolled > will have the network-wide keying material and can validate the = beacon. >=20 > Pledges which have not yet enrolled are unable to authenticate the = beacons, > and will be forced to temporarily take the contents on trust. > After enrollment, the pledge will be able to return to the beacon and > validate it. >=20 > In addition to the enrollment and join information described in this > document, the Enhanced Beacon contains a description of the TSCH = schedule to > be used by the transmitter of this packet. > The schedule can provide an attacker with a list of channels and = frequencies > on which communication will occur. > Knowledge of this can help an attacker to more efficiently jam > communications, although there is future work being considered to make = some > of the schedule less visible. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 From nobody Sun Jan 19 09:16:34 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBCB120033; Sun, 19 Jan 2020 09:16:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhuAIlvN5y-5; Sun, 19 Jan 2020 09:16:22 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA14E12001A; Sun, 19 Jan 2020 09:16:22 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 84F9C3897A; Sun, 19 Jan 2020 12:15:51 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7C4FE1057; Sun, 19 Jan 2020 12:16:21 -0500 (EST) From: Michael Richardson To: Yoav Nir cc: secdir , last-call@ietf.org, 6tisch@ietf.org, draft-ietf-6tisch-enrollment-enhanced-beacon.all@ietf.org In-Reply-To: <738E789C-14A8-41D5-956E-66E6CE2624DB@gmail.com> References: <157919779948.26195.4879220696306890525@ietfa.amsl.com> <1093.1579301399@localhost> <738E789C-14A8-41D5-956E-66E6CE2624DB@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [secdir] [6tisch] Secdir last call review of draft-ietf-6tisch-enrollment-enhanced-beacon-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2020 17:16:25 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yoav Nir wrote: > Not really. You=E2=80=99ve added an explanation of why it=E2=80=99s h= ard to encrypt. > That is not needed IMO. What is needed is a statement that sending in > the clear (not the default in IETF protocols these days) is OK because > the data is not sensitive. No, I'm saying that it's architecturally impossible to encrypt. It's not a choice. Anything you plan to put into the beacon has to take this into account. I take your point about explaining why the contents are not sensitive thoug= h. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4kjuUACgkQgItw+93Q 3WWnZAf/bJg2HcvUeBeIDWlGNjiuzji5mNFABn9kuHoJtkdrQXIm/FWJj2NLfjqg laKUPvjHEI8lo9Fro8YqOQ5es2D22olSOCXBAeJtF8BG2nodxpuWhOkWt9SKN5LV mT6FkGSVKFv9ej5dbdRXQKGHv2RWvWUViKDinMQ0FPQDwRGme1/KPB+Q7Xcjxy94 LsebRC9fycCoNAgcbygGvjoN34XS2FtSmUaUn8/yE5JEl5uGqdzCHCPf5OxwaES9 BN6S5AIhQxQATSTBMB4mIPNA9FwNHvcl5Ec2RksvOcW+VL1bX7CK3wsaAvE5FS57 0UD/rxvzV2wZvJsw/U2JnIa13Y31Mw== =a+Au -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jan 19 14:33:37 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42AEB120019 for ; Sun, 19 Jan 2020 14:33:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <157947321526.19753.15778629342866143534.idtracker@ietfa.amsl.com> Date: Sun, 19 Jan 2020 14:33:35 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2020 22:33:35 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2020-01-23 Reviewer LC end Draft Shaun Cooley 2019-11-12 draft-ietf-regext-login-security-07 Aanchal Malhotra 2019-12-23 draft-ietf-pce-stateful-flags-00 For telechat 2020-02-06 Reviewer LC end Draft Roman Danyliw 2019-11-12 draft-ietf-dtn-bpbis-19 Last calls: Reviewer LC end Draft Shaun Cooley 2019-11-12 draft-ietf-regext-login-security-07 Roman Danyliw 2019-11-12 draft-ietf-dtn-bpbis-19 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-08 Donald Eastlake 2019-11-14 draft-ietf-hip-dex-11 Aanchal Malhotra 2019-12-23 draft-ietf-pce-stateful-flags-00 Russ Mundy 2020-01-02 draft-ietf-dprive-bcp-op-07 Sandra Murphy 2019-10-04 draft-ietf-mpls-ldp-yang-06 Magnus Nystrom 2020-01-21 draft-ietf-dnsop-rfc2845bis-06 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-09 Hilarie Orman 2020-01-21 draft-ietf-rmcat-wireless-tests-08 Radia Perlman 2020-01-31 draft-ietf-uta-tls-for-email-03 Derrell Piper 2020-01-31 draft-ietf-6lo-minimal-fragment-07 Tirumaleswar Reddy.K 2020-01-30 draft-ietf-6lo-fragment-recovery-08 Vincent Roca 2020-01-30 draft-ietf-pim-msdp-yang-08 Kyle Rose 2020-01-29 draft-ietf-emu-rfc5448bis-06 Rich Salz 2020-01-27 draft-ietf-sipcore-locparam-04 Stefan Santesson 2020-01-27 draft-ietf-dots-architecture-15 Yaron Sheffer 2020-01-27 draft-ietf-nfsv4-rpcrdma-cm-pvt-data-06 Rifaat Shekh-Yusef 2020-01-24 draft-ietf-ice-pac-03 Takeshi Takahashi 2019-11-04 draft-ietf-netmod-yang-data-ext-05 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Next in the reviewer rotation: Joseph Salowey Rich Salz Stefan Santesson Yaron Sheffer Rifaat Shekh-Yusef Melinda Shore Valery Smyslov Robert Sparks Takeshi Takahashi Tina Tsou From nobody Sun Jan 19 16:35:33 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D976612001E; Sun, 19 Jan 2020 16:35:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rifaat Shekh-Yusef via Datatracker To: Cc: last-call@ietf.org, draft-ietf-ice-pac.all@ietf.org, ice@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Rifaat Shekh-Yusef Message-ID: <157948053175.19616.12562131515450060047@ietfa.amsl.com> Date: Sun, 19 Jan 2020 16:35:31 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-ice-pac-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 00:35:32 -0000 Reviewer: Rifaat Shekh-Yusef Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready. This document extends the existing ICE mechanism to allow the ICE agent to wait a bit longer to allow for the discovery of candidates by adding new timer to the ICE agent. The new timer does not change the existing operation of the ICE mechanism and has no security implications. From nobody Sun Jan 19 21:37:52 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0087B120099; Sun, 19 Jan 2020 21:37:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXjAq2bXmssW; Sun, 19 Jan 2020 21:37:49 -0800 (PST) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 205F9120077; Sun, 19 Jan 2020 21:37:49 -0800 (PST) Received: by mail-pl1-x62f.google.com with SMTP id p9so12682908plk.9; Sun, 19 Jan 2020 21:37:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=RqoCdaT2c8CHQ+a71GVT93zReDfs5i1jk6HnKOTcSrc=; b=I8C2sL38ETjI+CSowaxqdvkNn93g0nf8/XXguma2NHwpkhZ5f439F/WKWv0G2OMOyC FnKGPkNYYBsXB5UqikGyyrhVHIl5lQhB/F4M3vAnmUuTr0J+2nG/NzZzqRvpgc98ZJxX iFm498/q1BaPq4uL1tZBZqkoHmKFWeAHJ6dj5zuaOx81MmOQQ2NmqJsjs7Q4wZ5QC2uZ 123jpXgsKGLLDi0lFik4VE7AKhhkTonXW2OjXr7LOpefRDjXkDkT9thg0Lcw+yWuVO8h x/lL9Bdovw+azJG5mKFbJhow/PCBx5UIAaA1ZnrJGWf9ggGP810ej8ePJyrV/Qpntqje SpoQ== 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; bh=RqoCdaT2c8CHQ+a71GVT93zReDfs5i1jk6HnKOTcSrc=; b=QofKejtzrZKDlfIO6IiY2MmA2QUdbT0ly7du2cHgprzPQDwbhJfiRKF9Hlr7KSB2Xz rZNIK9nG4LubGcEuq11RWTuYBpvp07ZkQGGQvxfaF2+ovmf6eSJUHBQURJRx55n1AQip rOX+27auuZ/00fTxJDIgzsKYSwI86N0IJ+2TQKR1vakC4hznpY8oE+N1KR6iMHQMJRab nrsokJbP6l7UpJv0F1ARtrp+tn+gGiG3ntPwK1fIU4jq0KjLNZyicLX58xzhSfw9Azr0 ewMZUv47XGb54FHF4Lx7ggpzV7HmlIggzV4k1XkCsc6LOzb/wPzm6mSqSqHNBPmMZI/s tcZQ== X-Gm-Message-State: APjAAAXm8N0VEspYO9ZmABW27SbzWSktUNJoesM35TwfWRpKD2aY6bYK yRSX/Mxe1IQMNC7/oJgStbpIEvrPftiDetwXdHrPMNnP X-Google-Smtp-Source: APXvYqx5C6i4FJaUqFy4Rjx32+5ZcfCucTSg1DIxYagqusOjK/zNPMbYl4JUNvFbBG4erCqf9bqUTccNrsF137M0oy4= X-Received: by 2002:a17:90a:98d:: with SMTP id 13mr21904016pjo.102.1579498668467; Sun, 19 Jan 2020 21:37:48 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= Date: Sun, 19 Jan 2020 21:37:36 -0800 Message-ID: To: secdir@ietf.org, draft-ietf-dnsop-rfc2845bis@ietf.org Content-Type: multipart/alternative; boundary="0000000000000eaba2059c8bb105" Archived-At: Subject: [secdir] Secdir review of draft-ietf-dnsop-rfc2845bis-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 05:37:51 -0000 --0000000000000eaba2059c8bb105 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 document defines a mechanism to provide authenticity and integrity of DNS transactions such as update requests. My main comment about this document is that it recommends use, and mandates support, of HMAC-SHA1, even truncated HMAC-SHA1. In light of recent cryptanalysis results, e.g., - https://eprint.iacr.org/2020/014.pdf - https://www.mitls.org/downloads/transcript-collisions.pdf it seems to me that an update to RFC 2845 would be better off not to recommend (or even mandate) use of SHA-1 but rather stronger hash functions such as SHA-256. Likewise, the statement "longer [authentication values] are believed to be stronger" is potentially misleading as it is the strength of the algorithm, and not the length of its output, that ultimately determines its security. Thanks, -- Magnus --0000000000000eaba2059c8bb105 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security directorate's ong= oing effort to review all IETF documents being processed by the IESG. These= comments were written primarily for the benefit of the security area direc= tors.=C2=A0 Document editors and WG chairs should treat these comments just= like any other last call comments.

This document defines a mechanism to provide authentici= ty and integrity of DNS transactions such as update requests.
    <= /div>
    My main comment about this document is that it recommends use, an= d mandates support, of HMAC-SHA1, even truncated HMAC-SHA1. In light of rec= ent cryptanalysis results, e.g.,
    it s= eems to me that an update to RFC 2845 would be better off not to recommend = (or even mandate) use of SHA-1 but rather stronger hash functions such as S= HA-256.
    Likewise, the statement "longer [authentication valu= es] are believed to be stronger" is potentially misleading as it is th= e strength of the algorithm, and not the length of its output, that ultimat= ely determines its security.

    Thanks,
    -- Magnus=
    --0000000000000eaba2059c8bb105-- From nobody Mon Jan 20 09:19:37 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4281209E6; Mon, 20 Jan 2020 09:19:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rich Salz via Datatracker To: Cc: last-call@ietf.org, sipcore@ietf.org, draft-ietf-sipcore-locparam.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Rich Salz Message-ID: <157954076633.1692.4566366506529807317@ietfa.amsl.com> Date: Mon, 20 Jan 2020 09:19:26 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-sipcore-locparam-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 17:19:27 -0000 Reviewer: Rich Salz Review result: Has Nits This is the security directorate (secdir) review for the sipcore-locparam draft. Secdir tries to review all documents. The primary intended recipient of this review if the security AD's; all others should consider this to be like any other last-call review. Summary: ready with nits. End of Sec 1 has a quote-based typo. In Sec 3, "This document does not comment..." paragraph is a beautiful acceptance of reality. In Sec 6, do proxies normally add themselves to the Record-Route field? If so, that might be worth mentioning explicitly. In Sec 7, looks good. A couple of typo's "multiple*S* locations" and "hop-by-hop" and "another domain." From nobody Mon Jan 20 20:19:11 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D62120045; Mon, 20 Jan 2020 20:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 ZQ4_TuMaiRPL; Mon, 20 Jan 2020 20:19:01 -0800 (PST) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 B87FE120046; Mon, 20 Jan 2020 20:19:01 -0800 (PST) Received: by mail-il1-x12b.google.com with SMTP id p8so1255207iln.12; Mon, 20 Jan 2020 20:19:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=V1dZ95E0F0+F/jy8JuNnqCzkNL1MgTwFpMCWNpajiR4=; b=hgZsGzx7BZzgEonI6PjCs5GwqTS3PZRg+UAfQkIpXvtuMjsdPxojhuJ4jc+V7jbloH i30qeImADOfzjjQ/88XR1q1ix51C29DZZMzLj1HJuucWPTAU9MksX3YyGTPE94pomr2H TdRMLIMTHmFaApSgFY47m27SU3f8mCP//KETu41zrB3OLk7hc93xsleC4pfSwnSh5EMP dlGPQKhGDOQuzfLLntV2070LGNge2/H+VdRLCijA0YBOeb7wSKrclGFkG9DXH3Xr8UiU 9ITyhTUYFFbADtjYlKTqftkp810+tGEIPBxAbWSpFM4O1qZy7rX8fbboy7g6lWvEdHgn RctA== 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=V1dZ95E0F0+F/jy8JuNnqCzkNL1MgTwFpMCWNpajiR4=; b=JUAR4r2UMPoYJbcT+OjOWhyYK3PemepgT6HUhESKM+B5eSABP9VI7TtmK01ial0EAB nOsqRjlf+I0RVp/sTxMEmdE2+NgusSVUtu55hpXilVSDXNueboTYGw10UUexq8KK4bCw U3wxln75n919HD4FgqGvhWwJJk/+brz0ASz3tOIBS4Uf5MuXNJhIbZWae3VaUeGHaFtN U+In1Km4OcxXuhEZPk/E3kpHwAAiSzaW5gYh2E43N4A01AKFyrQMbcsyKwl5EPCWjnpu xxwaYfSuyemXaRx09lSL7Lf8oLxq29aD5KoPAE8aJsTqv7p1Rjg7oYOb7fPiiVvPzAZp E7TQ== X-Gm-Message-State: APjAAAUVVa3JU0dYFj/7rWzjou8i/R948fgsvJnCF/F7OydyrsFAsjyL ZtKxsol65g2FeXgta8oGJN+T0Qop0oe7qf5zG/5U4wQ2 X-Google-Smtp-Source: APXvYqyiej58jiTYrHcH0PcSiJKBZd02MOatLTV5Y44wBuF1cY1B+tPYjAVTYdAf9uG3UHwvI/y4B8rcpNuxysccl5E= X-Received: by 2002:a92:cd52:: with SMTP id v18mr2143634ilq.83.1579580340655; Mon, 20 Jan 2020 20:19:00 -0800 (PST) MIME-Version: 1.0 From: Donald Eastlake Date: Mon, 20 Jan 2020 23:18:49 -0500 Message-ID: To: draft-ietf-hip-dex.all@ietf.org Cc: "iesg@ietf.org" , secdir Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [secdir] SECDIR Reveiw of draft-ietf-hip-dex-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 04:19:03 -0000 I have reviewed this document as (a very late) part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. The summary of the review is Ready with Nits. Sorry to get this review in so late but, while approved by the IESG, the draft is still in revised draft needed state so this may do some good. On the security front, although the draft is pretty complex and I am not that familiar with HIP, I did not see any significant security issues that were not already called out in the draft. So I concentrated on possible editorial issues. Editorial: Section 1.1, 3rd paragraph, page 5. Delete "However," a the beginning of the 2nd sentence. It doesn't make sense. Section 2.3, Definitions should be in alphabetic order. Section 2.3: It seems to me that people who are puzzled about what something means are most likely to be puzzled by the acronym. So I would put the acronym first, where there is an acronym or acronym-like term to use, then the expansion in parenthesis or in the body of the definition. This done for a couple of entries like CMAC and CKDF but most are the other way. Section 3 last paragraph and Section 12.10 5th bullet: "to use" -> "use of" I think OGA and KEYMAT should be in the Definitions list and KEYMAT, which I assume just is short for "keying material", should be expanded on first use in Section 6.3. Alternatively, you could just replace all occurrences of KEYMAT with "Keying Material". Section 5.3.2, page 23. The first sentence of the first paragraph starting on that page has problems. Maybe "chose" should be "choses" but I'm not sure: "The DH_GROUP_LIST parameter contains the Responder's order of preference based on which the Responder chose the ECDH key contained in the HOST_ID parameter (see below)." Appendix A, first sentence, "allows to identify" -> "allows identifying" Appendix B, "IEDG" -> "IESG" Appendix B, around the middle of page 51, right after the line beginning with "Section 6," there are three line with a blank line before and after. I found this confusing at first. I suggest those three line also be indented. Appendix B, page 52, "SHOUDS" -> "SHOUDs" Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com From nobody Mon Jan 20 22:21:32 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E00120071; Mon, 20 Jan 2020 22:21:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkHACpsuAB4u; Mon, 20 Jan 2020 22:21:17 -0800 (PST) Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) (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 E8B0112006E; Mon, 20 Jan 2020 22:21:16 -0800 (PST) Received: from in01.mta.xmission.com ([166.70.13.51]) by out03.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1itmuZ-0007CW-DA; Mon, 20 Jan 2020 23:21:15 -0700 Received: from [166.70.232.207] (helo=rumpleteazer.rhmr.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1itmuY-0004ah-H2; Mon, 20 Jan 2020 23:21:15 -0700 Received: from rumpleteazer.rhmr.com (localhost [127.0.0.1]) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 00L6JdEw025428; Mon, 20 Jan 2020 23:19:39 -0700 Received: (from hilarie@localhost) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Submit) id 00L6JdAc025427; Mon, 20 Jan 2020 23:19:39 -0700 Date: Mon, 20 Jan 2020 23:19:39 -0700 Message-Id: <202001210619.00L6JdAc025427@rumpleteazer.rhmr.com> From: "Hilarie Orman" Reply-To: "Hilarie Orman" To: iesg@ietf.org, secdir@ietf.org Cc: draft-ietf-rmcat-wireless-tests.all@tools.ietf.org X-XM-SPF: eid=1itmuY-0004ah-H2; ; ; mid=<202001210619.00L6JdAc025427@rumpleteazer.rhmr.com>; ; ; hst=in01.mta.xmission.com; ; ; ip=166.70.232.207; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-AID: U2FsdGVkX19ByW0nQgL6N1nDTIgiiSMm X-SA-Exim-Connect-IP: 166.70.232.207 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ***;iesg@ietf.org, secdir@ietf.org X-Spam-Relay-Country: X-Spam-Timing: total 563 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 3.1 (0.5%), b_tie_ro: 2.2 (0.4%), parse: 0.73 (0.1%), extract_message_metadata: 3.3 (0.6%), get_uri_detail_list: 0.93 (0.2%), tests_pri_-1000: 2.7 (0.5%), tests_pri_-950: 1.42 (0.3%), tests_pri_-900: 1.15 (0.2%), tests_pri_-90: 18 (3.2%), check_bayes: 16 (2.9%), b_tokenize: 4.8 (0.9%), b_tok_get_all: 5 (0.9%), b_comp_prob: 1.97 (0.3%), b_tok_touch_all: 2.4 (0.4%), b_finish: 0.66 (0.1%), tests_pri_0: 520 (92.5%), check_dkim_signature: 0.46 (0.1%), check_dkim_adsp: 215 (38.2%), poll_dns_idle: 209 (37.1%), tests_pri_10: 2.9 (0.5%), tests_pri_500: 7 (1.2%), rewrite_mail: 0.00 (0.0%) X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Archived-At: Subject: [secdir] Security review of draft-ietf-rmcat-wireless-tests-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 06:21:24 -0000 Security review of Evaluation Test Cases for Interactive Real-Time Media over Wireless Networks draft-ietf-rmcat-wireless-tests-08 Do not be alarmed. I generated this review of this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. The focus of this document is the definition of test cases that can be used evaluate congestion control algorithms for cellular and Wi-Fi networks. If the testing is done on isolated testbed networks, there are are few, if any, security considerations. The Security Considerations section mentions safeguards to avoid "congestion collapse of the Internet" and "leaking non-responsive traffic from unproven congestion avoidance techniques onto the open Internet". The former seems overly general (shouldn't all IETF protocols strive to avoid breaking the Internet?), and I am not at all sure what the latter means. I would recommend that test setups use passwords and keys that are specific to the test environment, but that is a generic recommendation for all test environments. It is probably not needed in this document. Hilarie From nobody Tue Jan 21 00:50:03 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F01CB120043; Tue, 21 Jan 2020 00:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.498 X-Spam-Level: X-Spam-Status: No, score=-14.498 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.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=aRr7fZDZ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=zGJo2JPs Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMmZXbRQVS7P; Tue, 21 Jan 2020 00:49:55 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDB94120025; Tue, 21 Jan 2020 00:49:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3978; q=dns/txt; s=iport; t=1579596595; x=1580806195; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=70DIuN/57erH5PBhQuN7ona+zUxtwj5fYAUNt9H0erc=; b=aRr7fZDZ9oRoqjJByWbt25Sslh69atqYN0W9RX9x17U1Tu0p95xXI7ah W7k81MMThdPXrKK01sInqHLQOlLBT/DGMIzUYKA7ZVwDEUejV9Z+RB1e1 Xe8sVQSIbdfVzNZeayb1Z2aoTIXDB+wvOi0dlnzdy3dI4BW5UR9CMU+3P 0=; IronPort-PHdr: =?us-ascii?q?9a23=3AMknACRwcByeOiDvXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhSN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZuIF1z9J/3nRyc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CdBQDXuiZe/5NdJa1bBwMcAQEBAQE?= =?us-ascii?q?HAQERAQQEAQGBe4FUUAWBRCAECyqEEoNGA4p+jD+OLoJSA1QJAQEBDAEBLQI?= =?us-ascii?q?BAYRAAheBeSQ4EwIDDQEBBAEBAQIBBQRthTcMhV8CAQMSEQQNDAEBNwEPAgE?= =?us-ascii?q?IDgwCJgICAh8RFRACBAENBSKDBIJLAy4BoHwCgTmIYXV/M4J/AQEFhQUNC4I?= =?us-ascii?q?MCYEOKoV9hhcagUE/gREnIIJMPoIbggMrFwomgkkygiyQVZ4RLEQKgjmNAIU?= =?us-ascii?q?IhCkbljOERI5eiwKQBAIEAgQFAg4BAQWBaSKBWHAVOyoBgkFQGA2IAQwXg1C?= =?us-ascii?q?KU3Qyd4xHAQE?= X-IronPort-AV: E=Sophos;i="5.70,345,1574121600"; d="scan'208";a="469074291" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Jan 2020 08:49:54 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 00L8ns1k004216 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 Jan 2020 08:49:54 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 21 Jan 2020 02:49:53 -0600 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 21 Jan 2020 02:49:52 -0600 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 21 Jan 2020 02:49:52 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FkJjiNrSIbQKPOE0UEPc9Tu2nO/4FDHIIizHybzwgK/FLkZqPDHvAt5l0MBCwFhkUp2d44ULIiMFWcY3KhDkY7NanT0fSqLaqkLmcdq4Mj315f+cYQoWPsuPKR1EyShRRGcTm5VXt5sQIe8SIhZnOi+zS72OGDWEb5rZWoq6t5cKEkDkLLfpV4bi0xjUs/zScMOt/8GM484jdnUKyIgKwuoPbZtRBfHJwfKH9e2R6iJcS4EEr+3RtBIfDryNw3h3hxNnqnJwRzukTiS+/qpf5A0DTlqaC51YlrQpLIu+RskQLUO+C3WXZ1Qs02XdpSAsSw39ohcnHBs2vzqfVeQM2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=70DIuN/57erH5PBhQuN7ona+zUxtwj5fYAUNt9H0erc=; b=bMPxOILKSRqDrlfZRjKQueoKiTj9CAbaWRNFuzwdPSFUKTE7u3LbHiliihyDPA5ZIYZdtmtK0Sdy1yDeL5NC10fgJbQD91q2o+1NhbWSZ0zFVH70tCzaqLvMp4OVkaJSscloXuG4XgjyCrE8cciAO8xqdKZ6NIJ1bcbnhEpQ/MsW3WQmAi7kq/RWUWu6iTA2yYY8XdtqbHauJpliv1S6+RXHKXfjasz6TALoWF7eCm+nkIqqEhNMLnC9KsGs/fIKl5VybqncDZfKDyajILdp7A9xwMZqs4FRjpmL4jHQwL+dOU+ckxlq6hyBPTT+1btimAfrEpXPFO832wBlkkiiUQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=70DIuN/57erH5PBhQuN7ona+zUxtwj5fYAUNt9H0erc=; b=zGJo2JPsmskKRoQIJWtSVlBndoM54Q5kPS2vZtFLGDY5VXgPZ18ayYdOToU4EThHjzZ92KtZUWSuw/xilarrwgTuIuIVokltTwoUcRbSKAEImx3iZSlN2objQxoAWxjpLwl8CP41Jg01UvE1pToVzujH73Uqb8OW0N5gZKmBWBc= Received: from DM5PR11MB1753.namprd11.prod.outlook.com (10.175.88.141) by DM5PR11MB1675.namprd11.prod.outlook.com (10.172.38.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.20; Tue, 21 Jan 2020 08:49:51 +0000 Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::9528:bb7a:843e:5ea3]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::9528:bb7a:843e:5ea3%12]) with mapi id 15.20.2644.026; Tue, 21 Jan 2020 08:49:51 +0000 From: "Eric Vyncke (evyncke)" To: Donald Eastlake , "draft-ietf-hip-dex.all@ietf.org" CC: secdir Thread-Topic: SECDIR Reveiw of draft-ietf-hip-dex-11 Thread-Index: AQHV0BHvB/wMJBby40WWNBrTjuSqXKf04BoA Date: Tue, 21 Jan 2020 08:49:51 +0000 Message-ID: <5C2542F3-3B12-426B-9DB3-C2AAB5E16D4C@cisco.com> References: In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:44f0:1252:455b:4b74:3469:9ee1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7ebc2178-6a3a-46a8-7830-08d79e4ee0f7 x-ms-traffictypediagnostic: DM5PR11MB1675: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0289B6431E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(376002)(346002)(366004)(396003)(199004)(189003)(2616005)(4326008)(5660300002)(6486002)(33656002)(6512007)(2906002)(66476007)(6506007)(186003)(71200400001)(76116006)(8936002)(66946007)(478600001)(66446008)(66556008)(64756008)(91956017)(36756003)(110136005)(81156014)(316002)(86362001)(81166006)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1675; H:DM5PR11MB1753.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: TcSN0KUVbH5h2RuyBct4c/MDLEtTTFc+1Tqj47GL5OPK4JD11AZxL98WZWrJrpd3V/UPdI308e2FGQXvq/BS8/oiS5zXL2gCB6X6oO4yibCchi3Pgia26q8FPETxDDk09s+/VMK5rHwbhlrwnkj2aLZ7elLuZNmRx89i7/z1fX7eQKj/nZEHAQGUJXBdYJvYfxq9i4beBUGcHnbXLVXWYtwZeql9Tfuirvsl0vMxZpG0jaVfL0FXzYCE1gYmLBkqa60iO+N/NwtecOQ4KU0K7G6PpMF/QvEb5lVWW2Bzi9I6NphbIuV6O0FWlHvnGTtkhJ+84L4G20NFHWGmfuPoxXP856iDeIGARJZqZUuK98sopvdC/1iSIwmo7iWCbFVkGHwXYgqp0xTLdfpuI26ufe9qkhNSEWXT14BQfND0epJQw5JD5YnwCz4jjYMenrQ7 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <002F45657253E74F8B46640706F02CFF@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7ebc2178-6a3a-46a8-7830-08d79e4ee0f7 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2020 08:49:51.4826 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: B4yIhUSdSskZqU6UiRkYiDx9C4i8McT/ghiL4pVkveP3D6atftCuCPndJs5OI0CR5AKdFVCnIaRyVMYmVXmtFw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1675 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.20, xch-aln-010.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [secdir] SECDIR Reveiw of draft-ietf-hip-dex-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 08:50:01 -0000 VGhhbmsgeW91IERvbmFsZCBmb3IgeW91ciByZXZpZXcsIGl0IGlzIHZlcnkgbXVjaCBhcHByZWNp YXRlLg0KDQpJIHdpbGwgbGV0IHRoZSBhdXRob3JzIHJlcGx5IGFib3V0IHRoZSByZXZpZXcNCg0K UmVnYXJkcw0KDQoNCi3DqXJpYw0KDQrvu79PbiAyMS8wMS8yMDIwLCAwNToxOSwgImllc2cgb24g YmVoYWxmIG9mIERvbmFsZCBFYXN0bGFrZSIgPGllc2ctYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhh bGYgb2YgZDNlM2UzQGdtYWlsLmNvbT4gd3JvdGU6DQoNCiAgICBJIGhhdmUgcmV2aWV3ZWQgdGhp cyBkb2N1bWVudCBhcyAoYSB2ZXJ5IGxhdGUpIHBhcnQgb2YgdGhlIHNlY3VyaXR5DQogICAgZGly ZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJl aW5nDQogICAgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLg0KICAgIA0KICAgIFRoZSBzdW1tYXJ5IG9m IHRoZSByZXZpZXcgaXMgUmVhZHkgd2l0aCBOaXRzLg0KICAgIA0KICAgIFNvcnJ5IHRvIGdldCB0 aGlzIHJldmlldyBpbiBzbyBsYXRlIGJ1dCwgd2hpbGUgYXBwcm92ZWQgYnkgdGhlIElFU0csDQog ICAgdGhlIGRyYWZ0IGlzIHN0aWxsIGluIHJldmlzZWQgZHJhZnQgbmVlZGVkIHN0YXRlIHNvIHRo aXMgbWF5IGRvIHNvbWUNCiAgICBnb29kLiBPbiB0aGUgc2VjdXJpdHkgZnJvbnQsIGFsdGhvdWdo IHRoZSBkcmFmdCBpcyBwcmV0dHkgY29tcGxleCBhbmQNCiAgICBJIGFtIG5vdCB0aGF0IGZhbWls aWFyIHdpdGggSElQLCBJIGRpZCBub3Qgc2VlIGFueSBzaWduaWZpY2FudA0KICAgIHNlY3VyaXR5 IGlzc3VlcyB0aGF0IHdlcmUgbm90IGFscmVhZHkgY2FsbGVkIG91dCBpbiB0aGUgZHJhZnQuIFNv IEkNCiAgICBjb25jZW50cmF0ZWQgb24gcG9zc2libGUgZWRpdG9yaWFsIGlzc3Vlcy4NCiAgICAN CiAgICBFZGl0b3JpYWw6DQogICAgDQogICAgU2VjdGlvbiAxLjEsIDNyZCBwYXJhZ3JhcGgsIHBh Z2UgNS4gRGVsZXRlICJIb3dldmVyLCIgYSB0aGUgYmVnaW5uaW5nDQogICAgb2YgdGhlIDJuZCBz ZW50ZW5jZS4gSXQgZG9lc24ndCBtYWtlIHNlbnNlLg0KICAgIA0KICAgIFNlY3Rpb24gMi4zLCBE ZWZpbml0aW9ucyBzaG91bGQgYmUgaW4gYWxwaGFiZXRpYyBvcmRlci4NCiAgICANCiAgICBTZWN0 aW9uIDIuMzogSXQgc2VlbXMgdG8gbWUgdGhhdCBwZW9wbGUgd2hvIGFyZSBwdXp6bGVkIGFib3V0 IHdoYXQNCiAgICBzb21ldGhpbmcgbWVhbnMgYXJlIG1vc3QgbGlrZWx5IHRvIGJlIHB1enpsZWQg YnkgdGhlIGFjcm9ueW0uIFNvIEkNCiAgICB3b3VsZCBwdXQgdGhlIGFjcm9ueW0gZmlyc3QsIHdo ZXJlIHRoZXJlIGlzIGFuIGFjcm9ueW0gb3IgYWNyb255bS1saWtlDQogICAgdGVybSB0byB1c2Us IHRoZW4gdGhlIGV4cGFuc2lvbiBpbiBwYXJlbnRoZXNpcyBvciBpbiB0aGUgYm9keSBvZiB0aGUN CiAgICBkZWZpbml0aW9uLiBUaGlzIGRvbmUgZm9yIGEgY291cGxlIG9mIGVudHJpZXMgbGlrZSBD TUFDIGFuZCBDS0RGIGJ1dA0KICAgIG1vc3QgYXJlIHRoZSBvdGhlciB3YXkuDQogICAgDQogICAg U2VjdGlvbiAzIGxhc3QgcGFyYWdyYXBoIGFuZCBTZWN0aW9uIDEyLjEwIDV0aCBidWxsZXQ6ICJ0 byB1c2UiIC0+ICJ1c2Ugb2YiDQogICAgDQogICAgSSB0aGluayBPR0EgIGFuZCBLRVlNQVQgc2hv dWxkIGJlIGluIHRoZSBEZWZpbml0aW9ucyBsaXN0IGFuZCBLRVlNQVQsDQogICAgd2hpY2ggSSBh c3N1bWUganVzdCBpcyBzaG9ydCBmb3IgImtleWluZyBtYXRlcmlhbCIsIHNob3VsZCBiZSBleHBh bmRlZA0KICAgIG9uIGZpcnN0IHVzZSBpbiBTZWN0aW9uIDYuMy4gQWx0ZXJuYXRpdmVseSwgeW91 IGNvdWxkIGp1c3QgcmVwbGFjZSBhbGwNCiAgICBvY2N1cnJlbmNlcyBvZiBLRVlNQVQgd2l0aCAi S2V5aW5nIE1hdGVyaWFsIi4NCiAgICANCiAgICBTZWN0aW9uIDUuMy4yLCBwYWdlIDIzLiBUaGUg Zmlyc3Qgc2VudGVuY2Ugb2YgdGhlIGZpcnN0IHBhcmFncmFwaA0KICAgIHN0YXJ0aW5nIG9uIHRo YXQgcGFnZSBoYXMgcHJvYmxlbXMuIE1heWJlICJjaG9zZSIgc2hvdWxkIGJlICJjaG9zZXMiDQog ICAgYnV0IEknbSBub3Qgc3VyZToNCiAgICAgICJUaGUgREhfR1JPVVBfTElTVCBwYXJhbWV0ZXIg Y29udGFpbnMgdGhlIFJlc3BvbmRlcidzIG9yZGVyIG9mDQogICAgICAgcHJlZmVyZW5jZSBiYXNl ZCBvbiB3aGljaCB0aGUgUmVzcG9uZGVyIGNob3NlIHRoZSBFQ0RIIGtleSBjb250YWluZWQNCiAg ICAgICBpbiB0aGUgSE9TVF9JRCBwYXJhbWV0ZXIgKHNlZSBiZWxvdykuIg0KICAgIA0KICAgIEFw cGVuZGl4IEEsIGZpcnN0IHNlbnRlbmNlLCAiYWxsb3dzIHRvIGlkZW50aWZ5IiAtPiAiYWxsb3dz IGlkZW50aWZ5aW5nIg0KICAgIA0KICAgIEFwcGVuZGl4IEIsICJJRURHIiAtPiAiSUVTRyINCiAg ICANCiAgICBBcHBlbmRpeCBCLCBhcm91bmQgdGhlIG1pZGRsZSBvZiBwYWdlIDUxLCByaWdodCBh ZnRlciB0aGUgbGluZQ0KICAgIGJlZ2lubmluZyB3aXRoICJTZWN0aW9uIDYsIiB0aGVyZSBhcmUg dGhyZWUgbGluZSB3aXRoIGEgYmxhbmsgbGluZQ0KICAgIGJlZm9yZSBhbmQgYWZ0ZXIuIEkgZm91 bmQgdGhpcyBjb25mdXNpbmcgYXQgZmlyc3QuIEkgc3VnZ2VzdCB0aG9zZQ0KICAgIHRocmVlIGxp bmUgYWxzbyBiZSBpbmRlbnRlZC4NCiAgICANCiAgICBBcHBlbmRpeCBCLCBwYWdlIDUyLCAiU0hP VURTIiAtPiAiU0hPVURzIg0KICAgIA0KICAgIFRoYW5rcywNCiAgICBEb25hbGQNCiAgICA9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQogICAgIERvbmFsZCBFLiBFYXN0bGFrZSAzcmQg ICArMS01MDgtMzMzLTIyNzAgKGNlbGwpDQogICAgIDIzODYgUGFub3JhbWljIENpcmNsZSwgQXBv cGthLCBGTCAzMjcwMyBVU0ENCiAgICAgZDNlM2UzQGdtYWlsLmNvbQ0KICAgIA0KICAgIA0KDQo= From nobody Tue Jan 21 12:21:22 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D501612002F; Tue, 21 Jan 2020 12:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 xOzZYm-dY0mA; Tue, 21 Jan 2020 12:21:16 -0800 (PST) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 5AB6B12007A; Tue, 21 Jan 2020 12:21:16 -0800 (PST) Received: by mail-il1-x130.google.com with SMTP id f5so3390685ilq.5; Tue, 21 Jan 2020 12:21:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=PlbHlrdiWc86KUBhgsRcYG4uEi70ZWG5V2DHe0CPjBY=; b=CR6uXEWKd+7LK/JA2UR615LXgSyYdN5KUeqzQ8FiJ3L9wPx5u/ZaIBOnRucSA4seI9 brKLKHT0GldOEar3LhxovoQSyK1ZtLWOjpMJtXDUF3OLCaLuT4nFoEI8FUbbxr/QVdqe fYlcuGgpnMyCqwkRIfe++fOulRojLpcMeQddjRC3s6V4xRfh8ma0FRX/HE2teBfc64BY MVnIapMEN9RNfYykTzSpm9HtpyAocvWkEdbag7viHuPMkmh02jgPGKVJISqqZSxIF7iu DsaHi2Kyg5tystBI8tmdSkskRdCf337OEGMus60pa+pE0ZbZI+IAq45Zy75iQ12RW759 kDIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=PlbHlrdiWc86KUBhgsRcYG4uEi70ZWG5V2DHe0CPjBY=; b=EDHP1w6rNulb+Z2fzEJd3Rc9z8vUoO4JQ3dWdUTVxHESZMaeeNymQ3vvcF7D6D+kvX 1kmlxBFXySOxUyCm2oGYaP1nVEPP9G5L9k4Ba+LT9oD8pG1JF3VDz8TlO5rd4+9NIqbZ bpnKBo5gnP23fFbyrdrL8fVLP15ynJymvObdQkp9lfrN14p/mZoPLrVoUOqKof80iu7c q3NxZi/RlTro8XqNFIPDDEKtoN1wBVPVHedmyeMFfoUIVQ4FXuEjFeUWAsGeJma0GNip 0GlFHNO/IPMGtpK9Aci4U7epbg+QRK1/jRNegHKaSb/GfeaydPLjA5oBct7iuQJRyDiv JMng== X-Gm-Message-State: APjAAAWbPq3tEQgKPqHon7fKKPgSQvHs2eHkzQzhpDTLtDEDiGsJUewa 1NK7qwA02e9l6Z+fYzRquTciglou8NRZJNvBUM4= X-Google-Smtp-Source: APXvYqyUvvQw7WID+pSB31yzBDkANM8tG91btN80p1O6FX86l9FVx7/PJEt+NueFCYYuHZXJe919AemkUbEdR3Zqj4s= X-Received: by 2002:a92:da44:: with SMTP id p4mr5446130ilq.168.1579638075585; Tue, 21 Jan 2020 12:21:15 -0800 (PST) MIME-Version: 1.0 References: <5C2542F3-3B12-426B-9DB3-C2AAB5E16D4C@cisco.com> In-Reply-To: <5C2542F3-3B12-426B-9DB3-C2AAB5E16D4C@cisco.com> From: Donald Eastlake Date: Tue, 21 Jan 2020 15:21:04 -0500 Message-ID: To: "Eric Vyncke (evyncke)" Cc: "draft-ietf-hip-dex.all@ietf.org" , secdir Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] SECDIR Reveiw of draft-ietf-hip-dex-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 20:21:21 -0000 Your welcome. (There is a typo in my review "SHOUD" -> "SHOULD".) Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Tue, Jan 21, 2020 at 3:49 AM Eric Vyncke (evyncke) w= rote: > > Thank you Donald for your review, it is very much appreciate. > > I will let the authors reply about the review > > Regards > > > -=C3=A9ric > > =EF=BB=BFOn 21/01/2020, 05:19, "iesg on behalf of Donald Eastlake" wrote: > > I have reviewed this document as (a very late) part of the security > directorate's ongoing effort to review all IETF documents being > processed by the IESG. > > The summary of the review is Ready with Nits. > > Sorry to get this review in so late but, while approved by the IESG, > the draft is still in revised draft needed state so this may do some > good. On the security front, although the draft is pretty complex and > I am not that familiar with HIP, I did not see any significant > security issues that were not already called out in the draft. So I > concentrated on possible editorial issues. > > Editorial: > > Section 1.1, 3rd paragraph, page 5. Delete "However," a the beginning > of the 2nd sentence. It doesn't make sense. > > Section 2.3, Definitions should be in alphabetic order. > > Section 2.3: It seems to me that people who are puzzled about what > something means are most likely to be puzzled by the acronym. So I > would put the acronym first, where there is an acronym or acronym-lik= e > term to use, then the expansion in parenthesis or in the body of the > definition. This done for a couple of entries like CMAC and CKDF but > most are the other way. > > Section 3 last paragraph and Section 12.10 5th bullet: "to use" -> "u= se of" > > I think OGA and KEYMAT should be in the Definitions list and KEYMAT, > which I assume just is short for "keying material", should be expande= d > on first use in Section 6.3. Alternatively, you could just replace al= l > occurrences of KEYMAT with "Keying Material". > > Section 5.3.2, page 23. The first sentence of the first paragraph > starting on that page has problems. Maybe "chose" should be "choses" > but I'm not sure: > "The DH_GROUP_LIST parameter contains the Responder's order of > preference based on which the Responder chose the ECDH key contain= ed > in the HOST_ID parameter (see below)." > > Appendix A, first sentence, "allows to identify" -> "allows identifyi= ng" > > Appendix B, "IEDG" -> "IESG" > > Appendix B, around the middle of page 51, right after the line > beginning with "Section 6," there are three line with a blank line > before and after. I found this confusing at first. I suggest those > three line also be indented. > > Appendix B, page 52, "SHOUDS" -> "SHOUDs" > > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e3e3@gmail.com > > > From nobody Tue Jan 21 12:41:45 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF17912003F; Tue, 21 Jan 2020 12:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRkDoSPiPDe9; Tue, 21 Jan 2020 12:41:32 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 10EBE12001B; Tue, 21 Jan 2020 12:41:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 6323062129; Tue, 21 Jan 2020 15:41:30 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Td61wU1bX6aF; Tue, 21 Jan 2020 15:41:20 -0500 (EST) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id C61F062123; Tue, 21 Jan 2020 15:41:19 -0500 (EST) To: Donald Eastlake , draft-ietf-hip-dex.all@ietf.org Cc: "iesg@ietf.org" , secdir References: From: Robert Moskowitz Message-ID: <00644d2c-82b8-e486-981c-ee52e46c5492@labs.htt-consult.com> Date: Tue, 21 Jan 2020 15:41:14 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E35558D7E8181E59D64AABE0" Content-Language: en-US Archived-At: Subject: Re: [secdir] SECDIR Reveiw of draft-ietf-hip-dex-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 20:41:38 -0000 This is a multi-part message in MIME format. --------------E35558D7E8181E59D64AABE0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit thanks I am overdue to finish my editing. I will add these.... On 1/20/20 11:18 PM, Donald Eastlake wrote: > I have reviewed this document as (a very late) part of the security > directorate's ongoing effort to review all IETF documents being > processed by the IESG. > > The summary of the review is Ready with Nits. > > Sorry to get this review in so late but, while approved by the IESG, > the draft is still in revised draft needed state so this may do some > good. On the security front, although the draft is pretty complex and > I am not that familiar with HIP, I did not see any significant > security issues that were not already called out in the draft. So I > concentrated on possible editorial issues. > > Editorial: > > Section 1.1, 3rd paragraph, page 5. Delete "However," a the beginning > of the 2nd sentence. It doesn't make sense. > > Section 2.3, Definitions should be in alphabetic order. > > Section 2.3: It seems to me that people who are puzzled about what > something means are most likely to be puzzled by the acronym. So I > would put the acronym first, where there is an acronym or acronym-like > term to use, then the expansion in parenthesis or in the body of the > definition. This done for a couple of entries like CMAC and CKDF but > most are the other way. Too much original cutting and pasting from multiple sources.  Good comment. > > Section 3 last paragraph and Section 12.10 5th bullet: "to use" -> "use of" > > I think OGA and KEYMAT should be in the Definitions list and KEYMAT, > which I assume just is short for "keying material", should be expanded > on first use in Section 6.3. Alternatively, you could just replace all > occurrences of KEYMAT with "Keying Material". > > Section 5.3.2, page 23. The first sentence of the first paragraph > starting on that page has problems. Maybe "chose" should be "choses" > but I'm not sure: > "The DH_GROUP_LIST parameter contains the Responder's order of > preference based on which the Responder chose the ECDH key contained > in the HOST_ID parameter (see below)." > > Appendix A, first sentence, "allows to identify" -> "allows identifying" > > Appendix B, "IEDG" -> "IESG" > > Appendix B, around the middle of page 51, right after the line > beginning with "Section 6," there are three line with a blank line > before and after. I found this confusing at first. I suggest those > three line also be indented. > > Appendix B, page 52, "SHOUDS" -> "SHOUDs" > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e3e3@gmail.com -- Standard Robert Moskowitz Owner HTT Consulting C:248-219-2059 F:248-968-2824 E:rgm@labs.htt-consult.com There's no limit to what can be accomplished if it doesn't matter who gets the credit --------------E35558D7E8181E59D64AABE0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit thanks I am overdue to finish my editing.

    I will add these....

    On 1/20/20 11:18 PM, Donald Eastlake wrote:
    I have reviewed this document as (a very late) part of the security
directorate's ongoing effort to review all IETF documents being
processed by the IESG.

The summary of the review is Ready with Nits.

Sorry to get this review in so late but, while approved by the IESG,
the draft is still in revised draft needed state so this may do some
good. On the security front, although the draft is pretty complex and
I am not that familiar with HIP, I did not see any significant
security issues that were not already called out in the draft. So I
concentrated on possible editorial issues.

Editorial:

Section 1.1, 3rd paragraph, page 5. Delete "However," a the beginning
of the 2nd sentence. It doesn't make sense.

Section 2.3, Definitions should be in alphabetic order.

Section 2.3: It seems to me that people who are puzzled about what
something means are most likely to be puzzled by the acronym. So I
would put the acronym first, where there is an acronym or acronym-like
term to use, then the expansion in parenthesis or in the body of the
definition. This done for a couple of entries like CMAC and CKDF but
most are the other way.

    Too much original cutting and pasting from multiple sources.  Good comment.


    
Section 3 last paragraph and Section 12.10 5th bullet: "to use" -> "use of"

I think OGA  and KEYMAT should be in the Definitions list and KEYMAT,
which I assume just is short for "keying material", should be expanded
on first use in Section 6.3. Alternatively, you could just replace all
occurrences of KEYMAT with "Keying Material".

Section 5.3.2, page 23. The first sentence of the first paragraph
starting on that page has problems. Maybe "chose" should be "choses"
but I'm not sure:
  "The DH_GROUP_LIST parameter contains the Responder's order of
   preference based on which the Responder chose the ECDH key contained
   in the HOST_ID parameter (see below)."

Appendix A, first sentence, "allows to identify" -> "allows identifying"

Appendix B, "IEDG" -> "IESG"

Appendix B, around the middle of page 51, right after the line
beginning with "Section 6," there are three line with a blank line
before and after. I found this confusing at first. I suggest those
three line also be indented.

Appendix B, page 52, "SHOUDS" -> "SHOUDs"

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com

    --
    Standard Robert Moskowitz
    Owner
    HTT Consulting
    C:      248-219-2059
    F:      248-968-2824
    E:      rgm@labs.htt-consult.com

    There's no limit to what can be accomplished if it doesn't matter who gets the credit
    --------------E35558D7E8181E59D64AABE0-- From nobody Tue Jan 21 23:42:13 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C49120013; Tue, 21 Jan 2020 23:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frTnKkY4fqov; Tue, 21 Jan 2020 23:42:04 -0800 (PST) Received: from mailout31.telekom.de (mailout31.telekom.de [194.25.225.143]) (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 72057120052; Tue, 21 Jan 2020 23:42:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1579678924; x=1611214924; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3kv12OAq/EI0EB3fy0+ZXewikyfGcNRF1m3cs2Oi7uo=; b=Yie1dUWsrbSP71vjG+ciD9HupFFjm+MYCVgO/fH3Q1+pdlfs4Df1ofVk +rUA4lvPBdx5YjZ09ZzxFXA5DClkNT1MVBXhV6GYc9buMEOP+JdxV3V5F /UXR0a3up1Zkr/iZKV0Wmvln+StgdhdYOrN3RCWqiay1BuDLwYIe4nXSB wj3IBKjd8kiN+kSV6zyskJB3wcw/7i25NzkAprQhbfClDBLEaZLuyuOkw oCJ3cftnEhSl4W69qbJNSDg21ivH3mZod8D6W/99xfJe2hzf1UA/zKwsO g2lAMZUzfP04Oy20mNKbX/B/7aIFPdaW1DFZ2mRS5cTpONYMsDj+upgai g==; IronPort-SDR: k+Qro87l/M3/ryQ1iuLVFDj+J935a9m/z9UAeMPCZXfl/ajkRx4yzz8j6l5L9LVXx25cMcuktS j1qdZFGIVf7Q== Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jan 2020 08:42:01 +0100 IronPort-SDR: y8v9iC7hCKewA/0Y+GLKV4TNC7Sw/nqlmCfGNBx8/gUhPcfHJ0TQgdCSWHvJE0f+dmUvcKnxk0 gkwfEBvrrn69RkTGdo9+ZX09noOZKFf3o= X-IronPort-AV: E=Sophos;i="5.70,348,1574118000"; d="scan'208";a="31466814" X-MGA-submission: =?us-ascii?q?MDEoZuxr+8LZImwRdXtnoAwq1sd09awSqneGxu?= =?us-ascii?q?jaUEN1yTKDOoPZrhmfo+gDRtOHS6kzzMtLPmftQokyinuqk+UMwNL7Ze?= =?us-ascii?q?gYtmTJ6EoO3NzKoxJummroBACkS3k5Gfks298pHBz0iIDk3ZMeqEcyUT?= =?us-ascii?q?jnkDFS1Ixv6L1yKBN7Qqm2+A=3D=3D?= Received: from he199744.emea1.cds.t-internal.com ([10.169.119.52]) by QDEC97.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 22 Jan 2020 08:42:02 +0100 Received: from HE199743.EMEA1.cds.t-internal.com (10.169.119.51) by HE199744.emea1.cds.t-internal.com (10.169.119.52) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 22 Jan 2020 08:42:00 +0100 Received: from HE104163.emea1.cds.t-internal.com (10.171.40.38) by HE199743.EMEA1.cds.t-internal.com (10.169.119.51) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 22 Jan 2020 08:42:00 +0100 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.18) by O365mail05.telekom.de (172.30.0.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 22 Jan 2020 08:42:00 +0100 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=afi0BU7G9P3DsHuuFMlTUN/83lyqJWu3hpgaok6rQUcb0tD5omTocLRAaP7HCzhRpXEyNgQZYVrwXBpY3tzIAP8ygi1l4Zzekz6oFO7bi+3UR/66CGvrIeEAdGYk0UE/Glkpf/vPSIw1PC00Vh0i4tn8w7gmvilcdFVnJApBfVEzBTWnsMwDlnxgmxnqmrBxFHyp3Ti6PzjTY9MJsZIQdTzj1mGvadLqCACtFHINtwgdPvJpF/stet7jVzQjuOb43QtB5Ur+OP34uwsY5CVu9dXQWjvoHG7V8NvuXAPxtYpFEwnpgrb/EiIkSSRLAA0mEs0IxAlhYMPdd0dnv+QXOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3kv12OAq/EI0EB3fy0+ZXewikyfGcNRF1m3cs2Oi7uo=; b=oEB5v6Zvq8sF2e5rOL6VcAsqKe3A0rl7f/YODVVwj8ljv/uBH2Rr3PyEcGBCBAiP50Y69Dsls0EWzL9iT6CjKLn0uWkzMUZBilwMOw8fwhYT3SzQWl4u64cjmZ+91mQoEe3BGbKfw4R6tJGfELXCO59+bNPyfDhXMM8Uhy0dOv/WwH9kukQ/oQ8iNtYw8PFKF5Gu3DQvaz/tNN9gEikLRVXFbOA2MtSZqJxundU2ei/3D3RbA/Hpl7QyEUkB1WuuZXEJqthcOLLQV0nLOTsdzX8TAla+iWQZgknRzN8ADg+zTbr2Xm0BR93R8ziuSlwF9JPjiauOTBJQapk8gusQNw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telekom.de; dmarc=pass action=none header.from=telekom.de; dkim=pass header.d=telekom.de; arc=none Received: from LEXPR01MB0045.DEUPRD01.PROD.OUTLOOK.DE (10.158.162.143) by LEXPR01MB0704.DEUPRD01.PROD.OUTLOOK.DE (10.158.167.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.25; Wed, 22 Jan 2020 07:42:00 +0000 Received: from LEXPR01MB0045.DEUPRD01.PROD.OUTLOOK.DE ([fe80::c111:a5e1:795:5c35]) by LEXPR01MB0045.DEUPRD01.PROD.OUTLOOK.DE ([fe80::c111:a5e1:795:5c35%6]) with mapi id 15.20.2644.027; Wed, 22 Jan 2020 07:42:00 +0000 From: To: , CC: , , Thread-Topic: Secdir last call review of draft-ietf-sipcore-locparam-04 Thread-Index: AQHVz7XOKkXn5J5ExEmDUjO7zxC7bqf2SpxQ Date: Wed, 22 Jan 2020 07:42:00 +0000 Message-ID: References: <157954076633.1692.4566366506529807317@ietfa.amsl.com> In-Reply-To: <157954076633.1692.4566366506529807317@ietfa.amsl.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=R.Jesske@telekom.de; x-originating-ip: [164.19.4.101] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 40444fe1-0d8f-4c0a-3969-08d79f0e90c9 x-ms-traffictypediagnostic: LEXPR01MB0704: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 029097202E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(366004)(376002)(346002)(39860400002)(189003)(199004)(2906002)(8936002)(81166006)(478600001)(54906003)(81156014)(316002)(9686003)(55016002)(186003)(86362001)(26005)(66476007)(66946007)(76116006)(7696005)(110136005)(4326008)(71200400001)(8676002)(66556008)(33656002)(64756008)(5660300002)(66446008)(66574012); DIR:OUT; SFP:1101; SCL:1; SRVR:LEXPR01MB0704; H:LEXPR01MB0045.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PevN6ugcL7kLerTmBQzz2flM9COv5VElmyiGfF/Yu3yDjQujk3+2WQAPC9ikJ5t0REzO/HphFf0KOXSQ2Tu62RkoeBp+lsDc6NUzfhmJiZECCCK+cNqlY/JWCV0LcGEBiR0DC7TNV/U0U7L3PEkMPwyc94/jhhsa9mfDKUF5Aez8Tj+6RNq3KW9Hg2osMOJKEcaQdl2xvfMn7k1OOXi2OgC3eBtbPcxSlW12o1IslsYbOKc25nyobvAgJrazX0xzQdbCZQptpRRbl6M/YqdLz8hp6VGi6ytVdu69Tj3FLcw2zkXDr4mH7sLttK1PHgjuRPIKabU2nOWcLWzuCQHFqMt1lrlWka5TNDQrxbLSMF8foL3D7IS3tSUQk4cJ5yC3SgL6ePJCJE7dZp0/SiJTBstMLlDwURQAqaT7RP57yxjRtRYtQ1SNIiCUT7zQnG2Z x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 40444fe1-0d8f-4c0a-3969-08d79f0e90c9 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2020 07:42:00.2660 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: kFXIfFr0ig9wtj/YmnEJ+mhopa5Lf4log1iiWgGTf+ti6l6SSwoSBklZ3N/IHar0MptutmEmYxlesbrEl6Lf4w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEXPR01MB0704 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-sipcore-locparam-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 07:42:07 -0000 SGVsbG8sDQpUaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMgd2hpY2ggSSBoYXZlIGluY29ycG9y YXRlZCBpbnRvIHRoZSBkcmFmdC4NCg0KRm9yIHNlY3Rpb24gNjogU0lQIHByb3hpZXMgZG8gYWRk IHRoZW1zZWx2ZXMgaW50byB0aGUgUmVjb3JkLVJvdXRlIG9ubHkgd2hlbiB0aGV5IHdhbnQgdG8g c3RheSB3aXRoaW4gdGhlIFNJUCBzaWduYWxsaW5nIHBhdGggYmV5b25kIHRoZSBTSVAgSU5WSVRF LiBTbyBpdCBpcyBub3QgYSB1c3VhbCBwcm9jZWR1cmUgZG9uZSBpbiBlYWNoIHVzZSBjYXNlLiBU aGlzIGlzIHVzZWQgd2hlbiB0aGUgcHJveHkgcHJvdmlkZSBtaWQtY2FsbCBmZWF0dXJlcy4NCg0K QmVzdCBSZWdhcmRzDQoNClJvbGFuZA0KDQoNCg0KLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmlj aHQtLS0tLQ0KVm9uOiBSaWNoIFNhbHogdmlhIERhdGF0cmFja2VyIDxub3JlcGx5QGlldGYub3Jn PiANCkdlc2VuZGV0OiBNb250YWcsIDIwLiBKYW51YXIgMjAyMCAxODoxOQ0KQW46IHNlY2RpckBp ZXRmLm9yZw0KQ2M6IGxhc3QtY2FsbEBpZXRmLm9yZzsgc2lwY29yZUBpZXRmLm9yZzsgZHJhZnQt aWV0Zi1zaXBjb3JlLWxvY3BhcmFtLmFsbEBpZXRmLm9yZw0KQmV0cmVmZjogU2VjZGlyIGxhc3Qg Y2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1zaXBjb3JlLWxvY3BhcmFtLTA0DQoNClJldmlld2Vy OiBSaWNoIFNhbHoNClJldmlldyByZXN1bHQ6IEhhcyBOaXRzDQoNClRoaXMgaXMgdGhlIHNlY3Vy aXR5IGRpcmVjdG9yYXRlIChzZWNkaXIpIHJldmlldyBmb3IgdGhlIHNpcGNvcmUtbG9jcGFyYW0g ZHJhZnQuIFNlY2RpciB0cmllcyB0byByZXZpZXcgYWxsIGRvY3VtZW50cy4gVGhlIHByaW1hcnkg aW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgcmV2aWV3IGlmIHRoZSBzZWN1cml0eSBBRCdzOyBh bGwgb3RoZXJzIHNob3VsZCBjb25zaWRlciB0aGlzIHRvIGJlIGxpa2UgYW55IG90aGVyIGxhc3Qt Y2FsbCByZXZpZXcuDQoNClN1bW1hcnk6IHJlYWR5IHdpdGggbml0cy4NCg0KRW5kIG9mIFNlYyAx IGhhcyBhIHF1b3RlLWJhc2VkIHR5cG8uDQoNCkluIFNlYyAzLCAiVGhpcyBkb2N1bWVudCBkb2Vz IG5vdCBjb21tZW50Li4uIiBwYXJhZ3JhcGggaXMgYSBiZWF1dGlmdWwgYWNjZXB0YW5jZSBvZiBy ZWFsaXR5Lg0KDQpJbiBTZWMgNiwgZG8gcHJveGllcyBub3JtYWxseSBhZGQgdGhlbXNlbHZlcyB0 byB0aGUgUmVjb3JkLVJvdXRlIGZpZWxkPyAgSWYgc28sIHRoYXQgbWlnaHQgYmUgd29ydGggbWVu dGlvbmluZyBleHBsaWNpdGx5Lg0KDQpJbiBTZWMgNywgbG9va3MgZ29vZC4gIEEgY291cGxlIG9m IHR5cG8ncyAibXVsdGlwbGUqUyogbG9jYXRpb25zIiBhbmQgImhvcC08U1BBQ0U+YnktaG9wIiBh bmQgImFuPFNQQUNFPm90aGVyIGRvbWFpbi4iDQoNCg0K From nobody Thu Jan 23 03:07:00 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 82EF6120024 for ; Thu, 23 Jan 2020 03:06:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <157977761953.22613.9497772518283803565.idtracker@ietfa.amsl.com> Date: Thu, 23 Jan 2020 03:06:59 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 11:06:59 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2020-01-23 Reviewer LC end Draft Shaun Cooley 2019-11-12 draft-ietf-regext-login-security-07 Aanchal Malhotra 2019-12-23 draft-ietf-pce-stateful-flags-00 For telechat 2020-02-06 Reviewer LC end Draft Roman Danyliw 2019-11-12 draft-ietf-dtn-bpbis-19 Last calls: Reviewer LC end Draft Shaun Cooley 2019-11-12 draft-ietf-regext-login-security-07 Roman Danyliw 2019-11-12 draft-ietf-dtn-bpbis-19 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-08 Aanchal Malhotra 2019-12-23 draft-ietf-pce-stateful-flags-00 Russ Mundy 2020-01-02 draft-ietf-dprive-bcp-op-07 Sandra Murphy 2019-10-04 draft-ietf-mpls-ldp-yang-06 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-09 Radia Perlman 2020-01-31 draft-ietf-uta-tls-for-email-03 Derrell Piper 2020-01-31 draft-ietf-6lo-minimal-fragment-07 Tirumaleswar Reddy.K 2020-01-30 draft-ietf-6lo-fragment-recovery-08 Vincent Roca 2020-01-30 draft-ietf-pim-msdp-yang-11 Kyle Rose 2020-01-29 draft-ietf-emu-rfc5448bis-06 Rich Salz 2020-02-17 draft-cheshire-sudn-ipv4only-dot-arpa-15 Stefan Santesson 2020-01-27 draft-ietf-dots-architecture-15 Yaron Sheffer 2020-01-27 draft-ietf-nfsv4-rpcrdma-cm-pvt-data-06 Takeshi Takahashi 2019-11-04 draft-ietf-netmod-yang-data-ext-05 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Next in the reviewer rotation: Joseph Salowey Rich Salz Stefan Santesson Yaron Sheffer Rifaat Shekh-Yusef Melinda Shore Valery Smyslov Robert Sparks Takeshi Takahashi Tina Tsou From nobody Thu Jan 23 09:11:19 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAC812093B; Thu, 23 Jan 2020 09:11:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rich Salz via Datatracker To: Cc: last-call@ietf.org, draft-cheshire-sudn-ipv4only-dot-arpa.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Rich Salz Message-ID: <157979947223.22606.1389820328667672093@ietfa.amsl.com> Date: Thu, 23 Jan 2020 09:11:12 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-cheshire-sudn-ipv4only-dot-arpa-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 17:11:12 -0000 Reviewer: Rich Salz Review result: Ready This is the security directorate review done on behalf of the Security AD's. Others should treat this like a regular last-call review. This document fills in a hole: RFC 7050 reserved the special DNS name "ipv4only.arpa" for determining how a client can find out its local network NAT64 prefix, but did not finish the job by not registering that name in the Special-Use Domain Name registry (SUDN). I was surprised to see that this was an AD-sponsored document; various AD's may wish to discuss the rationale during IESG review. The paranoic in me finds it interesting that https://datatracker.ietf.org/doc/draft-cheshire-sudn-ipv4only-dot-arpa/shepherdwriteup/ has no answer to question 9. :) This is a good document plugging a hole, and explaining the impact on DNS in a variety of configurations. Ship it. Sec 3 discusses the intent and why ipv4only.arpa is special. Sec 4 discusses what happens when software doesn't do the implied/required special-casing. It covers several types of deployments. Sec 5 provides what is missing from RFC 7050, but arguably is "better" because of the experience learned. There is interaction between DNS64 and DNSSEC that is described in Sec 6. A variety of mechanisms are discussed and a migration path is proposed, ultimately justifying why the zone must be insecure. Sec 8, the SUDN registration section, recapitulates the previous sections without rationale or side-notes: if you read only one setion, read this. From nobody Sun Jan 26 12:26:37 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A1E120043; Sun, 26 Jan 2020 12:26:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yaron Sheffer via Datatracker To: Cc: last-call@ietf.org, nfsv4@ietf.org, draft-ietf-nfsv4-rpcrdma-cm-pvt-data.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Yaron Sheffer Message-ID: <158007038921.30641.13334124837519126164@ietfa.amsl.com> Date: Sun, 26 Jan 2020 12:26:29 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-nfsv4-rpcrdma-cm-pvt-data-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2020 20:26:30 -0000 Reviewer: Yaron Sheffer Review result: Has Issues The document defines limited parameter negotiation for RPC-RDMAv1, using a private message sent over the underlying transport protocol (e.g., InfiniBand). The document is clear enough, until it comes to the Security Considerations. As a newcomer to this domain, there are several points that I fail to understand: - The CM Private Data described here is not one of the messages of the RPC-RDMA protocol. So how can it "inherit the security considerations of the protocols it extends," - where this refers to RPC-RDMA? - The next paragraph explains that the integrity is ensured by use of RC QP (whatever that is). But there's no mention of this entity in RFC 8166, which is supposed to define the security for this protocol. (Or in RFC 5042, for that matter). - I am usually suspicious of pre-2010 RFCs that recommend IPsec as a per-protocol solution (RFC 5042, Sec. 5.4.3). Is IPsec deployed in real life to protect these protocols, and if so, does it also protect the new CM Private Data? - And then after saying that integrity protection is ensured, we say that even if integrity was compromised and the parameters were modified anyway, no problem, this would only result in "self imposed denial of service". Even if true for the currently negotiated parameters, this cannot be true for every conceivable parameter that may be added in the future. From nobody Mon Jan 27 07:01:32 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BD4120821; Mon, 27 Jan 2020 07:01:22 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 mdON_ooAjIm5; Mon, 27 Jan 2020 07:01:20 -0800 (PST) Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 81D3A120845; Mon, 27 Jan 2020 07:01:17 -0800 (PST) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id 00RErVxM181443; Mon, 27 Jan 2020 15:01:16 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2019-08-05; bh=L5U+h9heGm7hvAm6g7e1ZPzE3h793on2YQAJ3P3YUgg=; b=p8aNt7FIWVTpnNJPv/Dd328S4/v+A+84CzqMtSH56Tc/ZrQ+OU1V8K72IJKwwIr8bLfE 0b0Eqv46YIfRU2qNc+lCJXlYoetDcss8ph66JVOSk1cBbgu9BAYqRYMOGNoDHziXOAe/ zfBoX3QHldTCv63oDQxzvsq1IFCq9fNa1x6Dv7qxabDq+VPBFFWz8sYr1R2IlfQGm01U xKJ5X5xhJr94AsFVq4H2HwYzXYURYjd3WP4y8V5XQIIefjycbY1DOnkZ2ihuWxItLvMv H3hhseJz6DF1dGqyFO6nVxzYB1kRy4mNSYu1+WNInuRr/uMK792PInOx13j3e8YFTQHM rQ== Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2130.oracle.com with ESMTP id 2xrd3tyvc3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 27 Jan 2020 15:01:16 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id 00REraQW175095; Mon, 27 Jan 2020 15:01:15 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3030.oracle.com with ESMTP id 2xry4uhtg1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 27 Jan 2020 15:01:15 +0000 Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 00RF1Dun014902; Mon, 27 Jan 2020 15:01:13 GMT Received: from anon-dhcp-152.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 27 Jan 2020 07:01:13 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Chuck Lever In-Reply-To: <158007038921.30641.13334124837519126164@ietfa.amsl.com> Date: Mon, 27 Jan 2020 10:01:12 -0500 Cc: secdir@ietf.org, last-call@ietf.org, nfsv4@ietf.org, draft-ietf-nfsv4-rpcrdma-cm-pvt-data.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <80F557DD-BD17-4119-98B9-614B7A9FDDFB@oracle.com> References: <158007038921.30641.13334124837519126164@ietfa.amsl.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.3445.104.11) X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9512 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2001270127 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9512 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2001270127 Archived-At: Subject: Re: [secdir] [nfsv4] Secdir last call review of draft-ietf-nfsv4-rpcrdma-cm-pvt-data-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2020 15:01:26 -0000 Hello Yaron- Thanks for your review and comments. I will respond to your comments below, then we can determine how to clarify the text to improve matters. > On Jan 26, 2020, at 3:26 PM, Yaron Sheffer via Datatracker = wrote: >=20 > Reviewer: Yaron Sheffer > Review result: Has Issues >=20 > The document defines limited parameter negotiation for RPC-RDMAv1, = using a > private message sent over the underlying transport protocol (e.g., = InfiniBand). >=20 > The document is clear enough, until it comes to the Security = Considerations. As > a newcomer to this domain, there are several points that I fail to = understand: >=20 > - The CM Private Data described here is not one of the messages of the = RPC-RDMA > protocol. So how can it "inherit the security considerations of the = protocols > it extends," - where this refers to RPC-RDMA? The private data is conveyed on the same transport connection as the other messages in RPC-over-RDMA. The exchange of private data is part of the connection handshake, and does not appear after the connection is established. The intended purpose of this paragraph is introductory, referring the reader to the Security Considerations section of RFC 8166 as background material. > - The next paragraph explains that the integrity is ensured by use of = RC QP > (whatever that is). But there's no mention of this entity in RFC 8166, = which is > supposed to define the security for this protocol. (Or in RFC 5042, = for that > matter). That does seem to be an omission of background material in these = documents. The queue pair (QP) type used for RPC-over-RDMA is Reliable Connected = (RC). This is part of the RDMA Verbs API, thus it is not defined in any published IETF document. However, a relevant definition can be found in Section 9.7.7 of InfiniBand Trade Association, "InfiniBand Architecture Specification = Volume 1", Release 1.3, March 2015. Available from = https://www.infinibandta.org/ Section 8.1.1 of RFC 8166 discusses one aspect of Reliable Connected = behavior but does not provide an adequate citation. The document as a whole does = not make a specific compliance statement about the use of RC QPs. draft-ietf-nfsv4-rpcrdma-version-two rectifies that omission. However, the protocol framework depends on the semantics of RC QPs, thus RPC-over-RDMA version one implementations to date use only the RC QP = type. That makes it rather a de facto requirement up to this point. > - I am usually suspicious of pre-2010 RFCs that recommend IPsec as a > per-protocol solution (RFC 5042, Sec. 5.4.3). Is IPsec deployed in = real life to > protect these protocols, and if so, does it also protect the new CM = Private > Data? IPsec is appropriate for iWARP (defined in the RFC 504x series), as = iWARP can operate on public untrusted networks. Typically IPsec is implemented along side iWARP in NIC hardware, and thus is relatively transparent to the host (aside from initial configuration). When deployed, IPsec would establish a protected channel before iWARP operations are exchanged, and thus would protect the exchange of private data that occurs as each QP connection is established. IPsec is not used for InfiniBand or RoCE. Deployment of these fabrics is typically in monolithic security environments. > - And then after saying that integrity protection is ensured, we say = that even > if integrity was compromised and the parameters were modified anyway, = no > problem, this would only result in "self imposed denial of service". = Even if > true for the currently negotiated parameters, this cannot be true for = every > conceivable parameter that may be added in the future. That's correct. Practically speaking, even though we made this private data mechanism extensible, we are already busy creating an RPC-over-RDMA version two, where the same exchange is done via RPC-over-RDMA messages rather than via CM Private Data. It's not likely that cm-pvt-data itself will ever be extended. -- Chuck Lever From nobody Tue Jan 28 04:46:38 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A14120059; Tue, 28 Jan 2020 04:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2_NzUHvoi5yr; Tue, 28 Jan 2020 04:46:33 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1781412004F; Tue, 28 Jan 2020 04:46:29 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 892CD1E2F8; Tue, 28 Jan 2020 07:51:44 -0500 (EST) Date: Tue, 28 Jan 2020 07:51:44 -0500 From: Jeffrey Haas To: "Shawn M. Emery" Cc: draft-ietf-bfd-vxlan.all@ietf.org, secdir Message-ID: <20200128125144.GC17622@pfrc.org> References: <20191210155221.GB29250@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [secdir] Review of draft-ietf-bfd-vxlan-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 12:46:36 -0000 Shawn, Since we are clearing through open discuss/comments from the IESG, I'd appreciated a response to the final point in this mail chain: Basically, while your concern is that BFD for vxlan doesn't spell out privacy considerations, your issue is with the core of BFD. Thus, it's a poor fit for a simple extension document to contain the privacy considerations. -- Jeff On Tue, Dec 10, 2019 at 05:00:18PM -0500, Jeffrey Haas wrote: > Shawn, > > The fundamental issue you're running into is you don't implement bfd for vxlan without also implementing base BFD (RFC 5880). IETF specs don't typically try to spell out all considerations from the base specification in each extension. And yes, it's a common criticism of IETF documents vs. other SDO docs such as IEEE or ITU-T. > > Given this [see below] > > > On Dec 10, 2019, at 4:36 PM, Shawn M. Emery wrote: > > > > Hi Jeff, > > > > Comments begin with SME... > > > > On Tue, Dec 10, 2019 at 8:48 AM Jeffrey Haas > wrote: > > Shawn, > > > > On Mon, Dec 09, 2019 at 05:51:30PM -0700, Shawn M. Emery wrote: > > > Reviewer: Shawn M. Emery > > > Review result: Ready with nits > > > > [...] > > > > > 1. Relating to privacy: > > > I believe that this section [security considerations] should also document > > > the security impact of deploying BFD on VXLANs for monitoring tunnel > > > traffic. > > > Which additional information, if any, can now be obtained with BFD usage? > > > > BFD protects transport between two systems and, in the profile envisaged in > > this document, does not typically involve itself in protecting user-managed > > endpoints. (In such circumstances, they might consider standard RFC > > 5880/5881 BFD as a user-provisioned mechanism.) > > > > The traffic for this mechanism is thus between two systems at the tunnel > > level and only covers the information necessary to permit the BFD protocol > > to execute, including any BFD security mechanisms that may be applied to > > that session. There are thus no end user privacy considerations for this > > mechanism. > > > > SME: This was not clear to me when reading the draft and think that the text above would help in defending that there are no privacy concerns that this specification introduces. > > Adding in these considerations in an extension document to base BFD seems weird. > > > > > > 2. Editorial: > > > Echo BFD is out of scope for the document, but does not describe the > > > reason for this or why state this at all? > > > > This is covered by RFC 5880 section 5. Similar to most other IETF > > documents, when documenting extensions and we do not conflict with the base > > behavior, we don't try to copy and paste the motivations as it waters down > > the normative text. (If we were IEEE, we'd reissue the entire suite every > > time we touched something...) > > > > Our preference is to leave it alone. > > > > At best, we could say "See RFC 5880, section 5." > > > > SME: This was also not clear to me, as my initial investigation did not lead me to this text. > > Understood. But again, spelling out all such considerations from the base document in the extension document isn't very IETF. > > My request would be to review RFC 5880 and see if you come to the same conclusions. > > -- Jeff > > > > > Shawn. > > -- > From nobody Tue Jan 28 09:48:22 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC57C1200FB; Tue, 28 Jan 2020 09:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.614 X-Spam-Level: X-Spam-Status: No, score=-1.614 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.275, T_SPF_PERMERROR=0.01] 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 2ONiV16P3POC; Tue, 28 Jan 2020 09:48:16 -0800 (PST) Received: from exchange.uccs.edu (uccs-ex1.uccs.edu [128.198.1.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FE641200B3; Tue, 28 Jan 2020 09:48:16 -0800 (PST) Received: from mail-ed1-f41.google.com (209.85.208.41) by UCCS-EX1.uccs.edu (128.198.1.101) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 28 Jan 2020 10:48:14 -0700 Received: by mail-ed1-f41.google.com with SMTP id m8so15566396edi.13; Tue, 28 Jan 2020 09:48:14 -0800 (PST) X-Gm-Message-State: APjAAAWnCjIs8XL27Yei4XOU1+aJVPkXaLFefBa+qzorVKFhH99pJNoM bM9VRuiVfGVvDn6oQJ/DxJFfQ6ott5teYtkliHQ= X-Google-Smtp-Source: APXvYqw32rlcSYva32cnSITguOBlirO4pIq/mlCzxob5Vh6/MTEw2oA0vL/LjvrUGnRa2W9QaerIAL/HdqUgnDatPt0= X-Received: by 2002:a17:906:bfe7:: with SMTP id vr7mr4300729ejb.177.1580233692849; Tue, 28 Jan 2020 09:48:12 -0800 (PST) MIME-Version: 1.0 References: <20191210155221.GB29250@pfrc.org> <20200128125144.GC17622@pfrc.org> In-Reply-To: <20200128125144.GC17622@pfrc.org> From: "Shawn M. Emery" Date: Tue, 28 Jan 2020 10:48:01 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Jeffrey Haas CC: , secdir Content-Type: multipart/alternative; boundary="000000000000ecac26059d36d307" X-Originating-IP: [209.85.208.41] X-ClientProxiedBy: UCCS-EX4.uccs.edu (128.198.1.104) To UCCS-EX1.uccs.edu (128.198.1.101) Archived-At: Subject: Re: [secdir] Review of draft-ietf-bfd-vxlan-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 17:48:20 -0000 --000000000000ecac26059d36d307 Content-Type: text/plain; charset="UTF-8" Jeff, Thank you for your follow up. I'm fine with this draft given the fact that BFD for vxlan does not raise any additional privacy concerns over the base specification. Shawn. -- On Tue, Jan 28, 2020 at 5:46 AM Jeffrey Haas wrote: > Shawn, > > Since we are clearing through open discuss/comments from the IESG, I'd > appreciated a response to the final point in this mail chain: Basically, > while your concern is that BFD for vxlan doesn't spell out privacy > considerations, your issue is with the core of BFD. Thus, it's a poor fit > for a simple extension document to contain the privacy considerations. > > -- Jeff > > On Tue, Dec 10, 2019 at 05:00:18PM -0500, Jeffrey Haas wrote: > > Shawn, > > > > The fundamental issue you're running into is you don't implement bfd for > vxlan without also implementing base BFD (RFC 5880). IETF specs don't > typically try to spell out all considerations from the base specification > in each extension. And yes, it's a common criticism of IETF documents vs. > other SDO docs such as IEEE or ITU-T. > > > > Given this [see below] > > > > > On Dec 10, 2019, at 4:36 PM, Shawn M. Emery wrote: > > > > > > Hi Jeff, > > > > > > Comments begin with SME... > > > > > > On Tue, Dec 10, 2019 at 8:48 AM Jeffrey Haas jhaas@pfrc.org>> wrote: > > > Shawn, > > > > > > On Mon, Dec 09, 2019 at 05:51:30PM -0700, Shawn M. Emery wrote: > > > > Reviewer: Shawn M. Emery > > > > Review result: Ready with nits > > > > > > [...] > > > > > > > 1. Relating to privacy: > > > > I believe that this section [security considerations] should also > document > > > > the security impact of deploying BFD on VXLANs for monitoring tunnel > > > > traffic. > > > > Which additional information, if any, can now be obtained with BFD > usage? > > > > > > BFD protects transport between two systems and, in the profile > envisaged in > > > this document, does not typically involve itself in protecting > user-managed > > > endpoints. (In such circumstances, they might consider standard RFC > > > 5880/5881 BFD as a user-provisioned mechanism.) > > > > > > The traffic for this mechanism is thus between two systems at the > tunnel > > > level and only covers the information necessary to permit the BFD > protocol > > > to execute, including any BFD security mechanisms that may be applied > to > > > that session. There are thus no end user privacy considerations for > this > > > mechanism. > > > > > > SME: This was not clear to me when reading the draft and think that > the text above would help in defending that there are no privacy concerns > that this specification introduces. > > > > Adding in these considerations in an extension document to base BFD > seems weird. > > > > > > > > > 2. Editorial: > > > > Echo BFD is out of scope for the document, but does not describe the > > > > reason for this or why state this at all? > > > > > > This is covered by RFC 5880 section 5. Similar to most other IETF > > > documents, when documenting extensions and we do not conflict with the > base > > > behavior, we don't try to copy and paste the motivations as it waters > down > > > the normative text. (If we were IEEE, we'd reissue the entire suite > every > > > time we touched something...) > > > > > > Our preference is to leave it alone. > > > > > > At best, we could say "See RFC 5880, section 5." > > > > > > SME: This was also not clear to me, as my initial investigation did > not lead me to this text. > > > > Understood. But again, spelling out all such considerations from the > base document in the extension document isn't very IETF. > > > > My request would be to review RFC 5880 and see if you come to the same > conclusions. > > > > -- Jeff > > > > > > > > Shawn. > > > -- > > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > --000000000000ecac26059d36d307 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Jeff,

    Thank you for your follow up.=C2= =A0 I'm fine with this draft given the fact that BFD for vxlan does not= raise any additional privacy concerns over the base specification.

    Shawn.
    --

    On Tue, Jan 28, 2020 at 5:46 AM = Jeffrey Haas <jhaas@pfrc.org> w= rote:
    Shawn,

    Since we are clearing through open discuss/comments from the IESG, I'd<= br> appreciated a response to the final point in this mail chain:=C2=A0 Basical= ly,
    while your concern is that BFD for vxlan doesn't spell out privacy
    considerations, your issue is with the core of BFD.=C2=A0 Thus, it's a = poor fit
    for a simple extension document to contain the privacy considerations.

    -- Jeff

    On Tue, Dec 10, 2019 at 05:00:18PM -0500, Jeffrey Haas wrote:
    > Shawn,
    >
    > The fundamental issue you're running into is you don't impleme= nt bfd for vxlan without also implementing base BFD (RFC 5880).=C2=A0 IETF = specs don't typically try to spell out all considerations from the base= specification in each extension.=C2=A0 And yes, it's a common criticis= m of IETF documents vs. other SDO docs such as IEEE or ITU-T.
    >
    > Given this [see below]
    >
    > > On Dec 10, 2019, at 4:36 PM, Shawn M. Emery <semery@uccs.edu> wrote:
    > >
    > > Hi Jeff,
    > >
    > > Comments begin with SME...
    > >
    > > On Tue, Dec 10, 2019 at 8:48 AM Jeffrey Haas <jhaas@pfrc.org <mailto:jhaas@pfrc.org>> wro= te:
    > > Shawn,
    > >
    > > On Mon, Dec 09, 2019 at 05:51:30PM -0700, Shawn M. Emery wrote: > > > Reviewer: Shawn M. Emery
    > > > Review result: Ready with nits
    > >
    > > [...]
    > >
    > > > 1. Relating to privacy:
    > > > I believe that this section [security considerations] should= also document
    > > > the security impact of deploying BFD on VXLANs for monitorin= g tunnel
    > > > traffic.
    > > > Which additional information, if any, can now be obtained wi= th BFD usage?
    > >
    > > BFD protects transport between two systems and, in the profile en= visaged in
    > > this document, does not typically involve itself in protecting us= er-managed
    > > endpoints.=C2=A0 (In such circumstances, they might consider stan= dard RFC
    > > 5880/5881 BFD as a user-provisioned mechanism.)
    > >
    > > The traffic for this mechanism is thus between two systems at the= tunnel
    > > level and only covers the information necessary to permit the BFD= protocol
    > > to execute, including any BFD security mechanisms that may be app= lied to
    > > that session.=C2=A0 There are thus no end user privacy considerat= ions for this
    > > mechanism.
    > >
    > > SME: This was not clear to me when reading the draft and think th= at the text above would help in defending that there are no privacy concern= s that this specification introduces.
    >
    > Adding in these considerations in an extension document to base BFD se= ems weird.
    >
    > >=C2=A0
    > > > 2. Editorial:
    > > > Echo BFD is out of scope for the document, but does not desc= ribe the
    > > > reason for this or why state this at all?
    > >
    > > This is covered by RFC 5880 section 5.=C2=A0 Similar to most othe= r IETF
    > > documents, when documenting extensions and we do not conflict wit= h the base
    > > behavior, we don't try to copy and paste the motivations as i= t waters down
    > > the normative text.=C2=A0 (If we were IEEE, we'd reissue the = entire suite every
    > > time we touched something...)
    > >
    > > Our preference is to leave it alone.
    > >
    > > At best, we could say "See RFC 5880, section 5."
    > >
    > > SME: This was also not clear to me, as my initial investigation d= id not lead me to this text.
    >
    > Understood.=C2=A0 But again, spelling out all such considerations from= the base document in the extension document isn't very IETF.
    >
    > My request would be to review RFC 5880 and see if you come to the same= conclusions.
    >
    > -- Jeff
    >
    > >
    > > Shawn.
    > > --
    >

    _______________________________________________
    secdir mailing list
    secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir
    wiki: http://tools.ietf.org/area/sec/trac/wiki/= SecDirReview
    --000000000000ecac26059d36d307-- From nobody Tue Jan 28 10:57:20 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4438F12003F; Tue, 28 Jan 2020 10:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 rvojyiyVSh-s; Tue, 28 Jan 2020 10:57:13 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2040F12003E; Tue, 28 Jan 2020 10:57:13 -0800 (PST) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 076851E2F7; Tue, 28 Jan 2020 14:02:27 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_4A735AF1-E62B-4834-A116-5E6A283BD43C" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Jeffrey Haas In-Reply-To: Date: Tue, 28 Jan 2020 13:57:11 -0500 Cc: draft-ietf-bfd-vxlan.all@ietf.org, secdir Message-Id: <3CA6AA8C-5E15-403C-A53B-27EF01A004E0@pfrc.org> References: <20191210155221.GB29250@pfrc.org> <20200128125144.GC17622@pfrc.org> To: "Shawn M. Emery" X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [secdir] Review of draft-ietf-bfd-vxlan-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 18:57:16 -0000 --Apple-Mail=_4A735AF1-E62B-4834-A116-5E6A283BD43C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Shawn, Thank you for closing the loop on this point. I believe there are no = further open issues raised by security directorate review. -- Jeff > On Jan 28, 2020, at 12:48 PM, Shawn M. Emery wrote: >=20 > Jeff, >=20 > Thank you for your follow up. I'm fine with this draft given the fact = that BFD for vxlan does not raise any additional privacy concerns over = the base specification. >=20 > Shawn. > -- >=20 > On Tue, Jan 28, 2020 at 5:46 AM Jeffrey Haas > wrote: > Shawn, >=20 > Since we are clearing through open discuss/comments from the IESG, I'd > appreciated a response to the final point in this mail chain: = Basically, > while your concern is that BFD for vxlan doesn't spell out privacy > considerations, your issue is with the core of BFD. Thus, it's a poor = fit > for a simple extension document to contain the privacy considerations. >=20 > -- Jeff >=20 > On Tue, Dec 10, 2019 at 05:00:18PM -0500, Jeffrey Haas wrote: > > Shawn, > >=20 > > The fundamental issue you're running into is you don't implement bfd = for vxlan without also implementing base BFD (RFC 5880). IETF specs = don't typically try to spell out all considerations from the base = specification in each extension. And yes, it's a common criticism of = IETF documents vs. other SDO docs such as IEEE or ITU-T. > >=20 > > Given this [see below] > >=20 > > > On Dec 10, 2019, at 4:36 PM, Shawn M. Emery > wrote: > > >=20 > > > Hi Jeff, > > >=20 > > > Comments begin with SME... > > >=20 > > > On Tue, Dec 10, 2019 at 8:48 AM Jeffrey Haas >> = wrote: > > > Shawn, > > >=20 > > > On Mon, Dec 09, 2019 at 05:51:30PM -0700, Shawn M. Emery wrote: > > > > Reviewer: Shawn M. Emery > > > > Review result: Ready with nits > > >=20 > > > [...] > > >=20 > > > > 1. Relating to privacy: > > > > I believe that this section [security considerations] should = also document > > > > the security impact of deploying BFD on VXLANs for monitoring = tunnel > > > > traffic. > > > > Which additional information, if any, can now be obtained with = BFD usage? > > >=20 > > > BFD protects transport between two systems and, in the profile = envisaged in > > > this document, does not typically involve itself in protecting = user-managed > > > endpoints. (In such circumstances, they might consider standard = RFC > > > 5880/5881 BFD as a user-provisioned mechanism.) > > >=20 > > > The traffic for this mechanism is thus between two systems at the = tunnel > > > level and only covers the information necessary to permit the BFD = protocol > > > to execute, including any BFD security mechanisms that may be = applied to > > > that session. There are thus no end user privacy considerations = for this > > > mechanism. > > >=20 > > > SME: This was not clear to me when reading the draft and think = that the text above would help in defending that there are no privacy = concerns that this specification introduces. > >=20 > > Adding in these considerations in an extension document to base BFD = seems weird. > >=20 > > > =20 > > > > 2. Editorial: > > > > Echo BFD is out of scope for the document, but does not describe = the > > > > reason for this or why state this at all? > > >=20 > > > This is covered by RFC 5880 section 5. Similar to most other IETF > > > documents, when documenting extensions and we do not conflict with = the base > > > behavior, we don't try to copy and paste the motivations as it = waters down > > > the normative text. (If we were IEEE, we'd reissue the entire = suite every > > > time we touched something...) > > >=20 > > > Our preference is to leave it alone. > > >=20 > > > At best, we could say "See RFC 5880, section 5." > > >=20 > > > SME: This was also not clear to me, as my initial investigation = did not lead me to this text. > >=20 > > Understood. But again, spelling out all such considerations from = the base document in the extension document isn't very IETF. > >=20 > > My request would be to review RFC 5880 and see if you come to the = same conclusions. > >=20 > > -- Jeff > >=20 > > >=20 > > > Shawn. > > > -- > >=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 = --Apple-Mail=_4A735AF1-E62B-4834-A116-5E6A283BD43C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Shawn,

    Thank you for closing the loop on this point.  I believe = there are no further open issues raised by security directorate = review.

    -- = Jeff


    On Jan 28, 2020, at 12:48 PM, = Shawn M. Emery <semery@uccs.edu> wrote:

    Jeff,

    Thank= you for your follow up.  I'm fine with this draft given the fact = that BFD for vxlan does not raise any additional privacy concerns over = the base specification.

    Shawn.
    --

    On Tue, Jan = 28, 2020 at 5:46 AM Jeffrey Haas <jhaas@pfrc.org> wrote:
    Shawn,

    Since we are clearing through open discuss/comments from the IESG, = I'd
    appreciated a response to the final point in this mail chain:  = Basically,
    while your concern is that BFD for vxlan doesn't spell out privacy
    considerations, your issue is with the core of BFD.  Thus, it's a = poor fit
    for a simple extension document to contain the privacy = considerations.

    -- Jeff

    On Tue, Dec 10, 2019 at 05:00:18PM -0500, Jeffrey Haas wrote:
    > Shawn,
    >
    > The fundamental issue you're running into is you don't implement = bfd for vxlan without also implementing base BFD (RFC 5880).  IETF = specs don't typically try to spell out all considerations from the base = specification in each extension.  And yes, it's a common criticism = of IETF documents vs. other SDO docs such as IEEE or ITU-T.
    = >
    > Given this [see below]
    >
    > > On Dec 10, 2019, at 4:36 PM, Shawn M. Emery <semery@uccs.edu> wrote:
    > >
    > > Hi Jeff,
    > >
    > > Comments begin with SME...
    > >
    > > On Tue, Dec 10, 2019 at 8:48 AM Jeffrey Haas <jhaas@pfrc.org <mailto:jhaas@pfrc.org>> wrote:
    > > Shawn,
    > >
    > > On Mon, Dec 09, 2019 at 05:51:30PM -0700, Shawn M. Emery = wrote:
    > > > Reviewer: Shawn M. Emery
    > > > Review result: Ready with nits
    > >
    > > [...]
    > >
    > > > 1. Relating to privacy:
    > > > I believe that this section [security considerations] = should also document
    > > > the security impact of deploying BFD on VXLANs for = monitoring tunnel
    > > > traffic.
    > > > Which additional information, if any, can now be obtained = with BFD usage?
    > >
    > > BFD protects transport between two systems and, in the profile = envisaged in
    > > this document, does not typically involve itself in protecting = user-managed
    > > endpoints.  (In such circumstances, they might consider = standard RFC
    > > 5880/5881 BFD as a user-provisioned mechanism.)
    > >
    > > The traffic for this mechanism is thus between two systems at = the tunnel
    > > level and only covers the information necessary to permit the = BFD protocol
    > > to execute, including any BFD security mechanisms that may be = applied to
    > > that session.  There are thus no end user privacy = considerations for this
    > > mechanism.
    > >
    > > SME: This was not clear to me when reading the draft and think = that the text above would help in defending that there are no privacy = concerns that this specification introduces.
    >
    > Adding in these considerations in an extension document to base BFD = seems weird.
    >
    > > 
    > > > 2. Editorial:
    > > > Echo BFD is out of scope for the document, but does not = describe the
    > > > reason for this or why state this at all?
    > >
    > > This is covered by RFC 5880 section 5.  Similar to most = other IETF
    > > documents, when documenting extensions and we do not conflict = with the base
    > > behavior, we don't try to copy and paste the motivations as it = waters down
    > > the normative text.  (If we were IEEE, we'd reissue the = entire suite every
    > > time we touched something...)
    > >
    > > Our preference is to leave it alone.
    > >
    > > At best, we could say "See RFC 5880, section 5."
    > >
    > > SME: This was also not clear to me, as my initial = investigation did not lead me to this text.
    >
    > Understood.  But again, spelling out all such considerations = from the base document in the extension document isn't very IETF.
    >
    > My request would be to review RFC 5880 and see if you come to the = same conclusions.
    >
    > -- Jeff
    >
    > >
    > > Shawn.
    > > --
    >

    _______________________________________________
    secdir mailing list
    secdir@ietf.org
    https://www.ietf.org/mailman/listinfo/secdir
    = wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

    = --Apple-Mail=_4A735AF1-E62B-4834-A116-5E6A283BD43C-- From nobody Wed Jan 29 00:18:15 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 64EFA12022D; Wed, 29 Jan 2020 00:18:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Vincent Roca via Datatracker To: Cc: last-call@ietf.org, draft-ietf-pim-msdp-yang.all@ietf.org, pim@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Vincent Roca Message-ID: <158028589133.2819.6239221909447380902@ietfa.amsl.com> Date: Wed, 29 Jan 2020 00:18:11 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-pim-msdp-yang-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 08:18:11 -0000 Reviewer: Vincent Roca Review result: Has Nits Hello, I have reviewed this document as part of the security directorate’s ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: Ready with nits The security considerations section is globally well writen and addresses important topics. I don't have major comments. Details: - it is said that "(i.e., config true, which is the default)". I've searched in the YANG model and only found "config false" entries which seems to contradict what is said in section 5. - Section 2.1 says: "This model can be used to configure and manage MSDP protocols." (with a final "s") which suggests there could be several MSDP protocols. I think it's a mistake. Cheers, Vincent From nobody Wed Jan 29 07:39:05 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9AD1200B8; Wed, 29 Jan 2020 07:38:55 -0800 (PST) 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 header.b=jli5lBZd; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Md8G8N9W Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krJUlawpC8rG; Wed, 29 Jan 2020 07:38:52 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6907E120090; Wed, 29 Jan 2020 07:38:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5062; q=dns/txt; s=iport; t=1580312332; x=1581521932; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=DEN9HXtMacGEHfNaEUJYD4hUzWBfuXOQc5PdifnNKZE=; b=jli5lBZdqb+1zEuuqfKBN064wgTko7GXH/vJpGg3KVQY8YXu+/pEdgYy W3944zbLexom4YepxR7Khr0aYzzQBLZ+aq1hBul1p4/UU4R5Odb/+9OP1 4I7xzXKH1xURhY81ybiTY2AEUOYhjJQxd4uaaQkkw48Q8t1zoz9++t+Cu s=; IronPort-PHdr: =?us-ascii?q?9a23=3A/TqGTBL2J8qLi5sFeNmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXFXnLOPgYjYmNM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANCADHpjFe/5hdJa1mHQEBAQkBEQU?= =?us-ascii?q?FAYF7gVRQBYFEIAQLKoQUg0YDinKaboJSA1QJAQEBDAEBLQIBAYRAAheCEyQ?= =?us-ascii?q?4EwIDDQEBBAEBAQIBBQRthTcMhV8CAQMSEREMAQE3AQ8CAQYCGgImAgICMBU?= =?us-ascii?q?FCwIEAQ0NGoVPAy4BApEskGYCgTmIYnWBMoJ/AQEFhH4YggwJgQ4qhR6FP4F?= =?us-ascii?q?DGoFBP4ERR4JMPoRLgw4ygiyNYII6O49TjkRwCoI5llKCSIgKhEeHIYRFg0m?= =?us-ascii?q?LF5sNAgQCBAUCDgEBBYFpIoFYcBWDJ1AYDY4dCRoVgzuKU3SBKYpdLYIUAQE?= X-IronPort-AV: E=Sophos;i="5.70,378,1574121600"; d="scan'208";a="438843210" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Jan 2020 15:38:51 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 00TFcpQ6019568 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Jan 2020 15:38:51 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 29 Jan 2020 09:38:50 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 29 Jan 2020 09:38:49 -0600 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 29 Jan 2020 10:38:49 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=grZFYxQKGD2lvPNUOE9qpm2chOZBkbuOs+vrm8poAw74rR3fXOY0cUW0mQKrnK8leK2MBx9tF/IGi25XNkqDtb3FznGOpnhid2W/pxhUa6CzXPeRXdMaKEE3YZ9ZNDMdoefFlMH8p5LUYmGJy+Iv1MijIkh+XIJ6SnKrhYejTJdFEcoixRuGa1fEffAAMSQ0RzUtZM/7iYkSCsxtzOEqv3t9zW81yuNnt9AJYFJMjpHaC1Q/fMVmlnFupqEmlfp4DNTsq6rUEIJHDLhjofftyZJwBWVUKFq/dEZROj2SjJdiuMcPO+ZztrNzTxCFqqHWCtIeNAeaimc+0ENnZpPaFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DEN9HXtMacGEHfNaEUJYD4hUzWBfuXOQc5PdifnNKZE=; b=EYK041k069/nn3hGxCVpmnWlyHM65d4JRCCLTpicV0uQycNoXRTCbgiVFDz8nxGBPYFLfU7ePrkcw05FqsC3U60rI+QibhEvxtxLoJp6jG9hTPlVjuU5DsXDB1Mc1E5/KCb5LZwywHR74v33Dluwhl9zFQ79qtZ9rT0N/TNHJG8mrP1VAghkrXm7UK+TsxGtkU6POFZB/LvEfOeONf7vWHbh1K+K6qGYKQYPy8U77F3lkZeSCJZA6C5El8Pkk9cXCPFx4h5Jl/phqdRi+CkYf6t2u2NfUUsLCZLFNwYKrcU2riVK9rjWaCMQHRvb4wG0x68oeu6fkVM30oLKHHaf6Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DEN9HXtMacGEHfNaEUJYD4hUzWBfuXOQc5PdifnNKZE=; b=Md8G8N9WsH2gofUR+b7ovMRu2BLuCL3mdkpLxvhyHgB0dW1HzdDvsa3VTQqNjPba/vqhnOhH/27LmOSLVPzvokxkGAO4LpEfCS53ui6xg0VDIsJ8Vowk91Ue92q2hGD0EBX68ymHoOkxtJIjW+ZwvtcPDt45xvftFGSDQ25tUGU= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4383.namprd11.prod.outlook.com (52.135.36.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.24; Wed, 29 Jan 2020 15:38:47 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a%3]) with mapi id 15.20.2665.027; Wed, 29 Jan 2020 15:38:47 +0000 From: "Pascal Thubert (pthubert)" To: "Eric Vyncke (evyncke)" , The IESG CC: "draft-ietf-6lo-ap-nd@ietf.org" , "Shwetha Bhandari (shwethab)" , "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>, "secdir@ietf.org" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLTZsby1hcC1u?= =?utf-8?Q?d-13:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHV1q8ObZjsSNLsNE+ME5HgTzGBvKgBtsSw Date: Wed, 29 Jan 2020 15:38:26 +0000 Deferred-Delivery: Wed, 29 Jan 2020 15:37:25 +0000 Message-ID: References: <158030752268.2728.2544838912831012540.idtracker@ietfa.amsl.com> In-Reply-To: <158030752268.2728.2544838912831012540.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:44f3:1300:41e7:7725:e525:b2e8] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c947e41d-0c6f-495a-5da0-08d7a4d15522 x-ms-traffictypediagnostic: MN2PR11MB4383: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(366004)(376002)(396003)(346002)(136003)(189003)(199004)(86362001)(450100002)(76116006)(64756008)(4326008)(7696005)(66446008)(71200400001)(66946007)(9686003)(66556008)(66476007)(8936002)(55016002)(478600001)(33656002)(6666004)(186003)(5660300002)(224303003)(81166006)(54906003)(2906002)(316002)(52536014)(6506007)(110136005)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4383; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0luNVA8EpyH8/422ibbRbOj/GF8XPmmwoj1IHLYjzLHjPU+sSAvg1P8uiXls8DFqCWVk9rR2pXsyY3T4U/sUIPX1SM1yawhOxIfbq6cVzitx+sfPOBY5HBFi84D4REClqfUFRsiSz+JHjt5KkzSyiagWamblGvhPow16JtjwLnXZ2oDyxJ20WaDMvqJtrsOW3NmLKJCqAnHK1XhdSpBa46FWZs/S0+6yaE7ImJArCMY9MJZS4cC91luJsBBAUmkS8Ag3nV8BMQefc7GezrCz61V+0OOUY34fCJl5LgeRsdH650LcWhmh6PoiVYr70Be5N0S9RaZjxj4gVajY0SV0oRGM5aLhiCD27VPEXYyIVdpa7SZNAld6KbJlRn0mUKggayaea3O3waYHpgznM/qvnAmJjgZXrtWavhP11ap3ZeGDtMizgAJGMnDPOYUkckrj x-ms-exchange-antispam-messagedata: 1OiQKIzL4QYqRnlYf0BSaENbUq5i8yWwooY2gd0dtg2xrGKrDhiGp53Ymm7hpoAS53Pruqu1Vh2KWbKOScAiBQj+6VrulTZfns6TsvY3XT0JhgNvUnmNQxKThIOzNBi5JOapCjZiKjxfDLnqZ0Kjr32E2VG4YZYd1pYFg5oR9WIReq+BUXtenCHrKQVFXptyNkkwUP3F0eY++OIvWXlb1A== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c947e41d-0c6f-495a-5da0-08d7a4d15522 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2020 15:38:47.8810 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: POUq1JJ5ZvMV/9nEvZd08MBAtJx4n99oq/5DzCoqMoWmjvfsqLIGyz7QbMqiVva3GId7I5I8MLkEX0S7eAqWfA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4383 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.18, xch-rcd-008.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [secdir] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-6l?= =?utf-8?q?o-ap-nd-13=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 15:38:56 -0000 SGVsbG8gRXJpYyA6ICkNCg0KTWFueSB0aGFua3MgZm9yIHlvdXIgcmV2aWV3ISBJIGNjJ2VkIFNF Qy1ESVIgYmVjYXVzZSB3ZSBjb3VsZCByZWFsbHkgdXNlIHRoZWlyIHJlY29tbWVuZGF0aW9uIHRv IHNvbHZlIHNvbWUgb2YgeW91ciBxdWVzdGlvbnMsIG1vcmUgYmVsb3cuDQoNClBsZWFzZSBzZWUg YmVsb3c6DQogDQo+ID09IERJU0NVU1MgPT0NCj4gDQo+IC0tIFNlY3Rpb24gNC40IC0tDQo+IFRo ZSBsZW5ndGggb2YgdGhlIHJlc2VydmVkIGZpZWxkIGlzIG5vdCBzcGVjaWZpZWQuIE9yIGFtIEkg bWlzc2luZyBzb21ldGhpbmcNCj4gb2J2aW91cyA/DQoNCkkgY29uY2F0ZW5hdGVkIHRoZSByZXNl cnZlZCBmaWVsZHMgaW4gdGhlIHBpY3R1cmUgYW5kIGRlY2xhcmVkIGl0IGFzIDQwIGJpdHMuIA0K QWxzbyBhZGRlZCB0aGUgbnVtYmVyIG9mIGJpdHMgaW4gdGhlIHJlc2VydmVkIGZpZWxkcyBvZiBv dGhlciBzdHJ1Y3R1cmVzLg0KDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiANCj4gPT0gQ09NTUVOVFMgPT0NCj4gDQo+IC0tIFNlY3Rpb24gNC4yIC0tDQo+ IFdoaWxlIHN0YXR1cyBpcyBzZXQgdG8gMCB3aGVuIHNlbmRpbmcgYSBOUywgd2hhdCBpcyB0aGUg ZXhwZWN0ZWQgYmVoYXZpb3Igb2YgYQ0KPiByZWNlaXZlciA/DQoNCkNoYW5nZWQgdG8gDQoiDQpJ biBOUyBtZXNzYWdlcyBpdCBNVVNUIGJlIHNldCB0byAwIGJ5IHRoZSBzZW5kZXIgYW5kIGlnbm9y ZWQgYnkgdGhlIHJlY2VpdmVyLg0KIg0KIA0KPiAtLSBTZWN0aW9uIDQuMyBhbmQgNC40IC0tDQo+ IFdoeSBpcyB0aGUgUGFkIExlbmd0aCBmaWVsZCBhIDgtYml0IGZpZWxkIHdoaWxlIHRoZSBhY3R1 YWwgcGFkZGluZyB3aWxsIGFsd2F5cyBiZQ0KPiBsZXNzIHRoYW4gOCBieXRlcy4gU3VnZ2VzdCB0 byBtYWtlIGl0IGEgMyBvciA0IGJpdHMgZmllbGQgYW5kIGV4dGVuZCB0aGUgcmVzZXJ2ZWQNCj4g ZmllbGQuDQoNCkFjdHVhbGx5IEkgdGhvdWdodCB0aGF0IGlmIHdlIHdhbnQgdG8gZXh0ZW5kIHRo ZSBvcHRpb24gaW4gdGhlIGZ1dHVyZSwgaXQgaXMgYmV0dGVyIHRvIGluZGljYXRlIHRoZSBsZW5n dGggb2YgdGhlIHB1YmxpYyBrZXkgYXMgZm9sbG93czoNCg0KICAgfCAgICAgVHlwZSAgICAgIHwg ICAgTGVuZ3RoICAgICB8IFJlc2VydmVkfCAgUHVibGljIEtleSBMZW5ndGggIHwNCg0KV2hlcmU6 DQoNClB1YmxpYyBLZXkgTGVuZ3RoOiAxMy1iaXQgdW5zaWduZWQgaW50ZWdlci4gVGhlIGxlbmd0 aCBvZiB0aGUgUHVibGljIEtleSBmaWVsZCBpbiBieXRlcy4NClB1YmxpYyBLZXk6ICBBIHZhcmlh YmxlLWxlbmd0aCBmaWVsZCwgc2l6ZSBpbmRpY2F0ZWQgaW4gdGhlIFB1YmxpYyBLZXkgTGVuZ3Ro IGZpZWxkLg0KICAgICAgIAkgICAgIEpXSy1FbmNvZGVkIFB1YmxpYyBLZXkgW1JGQzc1MTddDQo+ UGFkZGluZzogIEEgdmFyaWFibGUtbGVuZ3RoIGZpZWxkIGNvbXBsZXRpbmcgdGhlIFB1YmxpYyBL ZXkgZmllbGQgdG8gYWxpZ24gdG8gdGhlIG5leHQgOC1ieXRlcyBib3VuZGFyeS4NCg0KDQpXb3Jr cz8NCg0KDQoNCj4gDQo+IC0tIFNlY3Rpb24gNi4xIC0tDQo+IEFib3V0ICJOb25jZSBvcHRpb24g TVVTVCBjb250YWluIGEgcmFuZG9tIE5vbmNlIHZhbHVlIHRoYXQgd2FzIG5ldmVyIHVzZWQNCj4g d2l0aCB0aGlzIGRldmljZSIsIGhvdyBjYW4gaXQgYmUgZG9uZT8gS2VlcGluZyBhIGxvY2FsIGhp c3Rvcnk/IEdpdmluZyBzb21lDQo+IG9wZXJhdGlvbmFsIGhpbnRzIHdvdWxkIGJlZSB3ZWxjb21l LiBFc3BlY2lhbGx5LCB3aGVuIHRoZXJlIGFyZSBtdWx0aXBsZSA2TFIgaW4NCj4gdGhlIExMTjog aG93IGNhbiB0aGV5IHN5bmNocm9uaXplIHRoZSBub25jZT8NCg0KVGhlIG5vbmNlIGlzIHVzZWQg b25jZSwgc28gdGhlcmUncyBubyBzeW5jaHJvbml6YXRpb24uIEEgbmV3IHBhaXIgaXMgZm9ybWVk IGFuZCBleGNoYW5nZWQgYXQgZWFjaCB2YWxpZGF0aW9uLg0KDQpUaGUgbm9uY2UgZ2FtZSB1c2Vk IGhlcmUgYXBwZWFyIHRvIGJlIGNvbW1vbiBwcmFjdGljZS4gWWVzLCB0aGVyZSdzIHVzdWFsbHkg YSBuZWVkIG9mIGxvY2FsIGhpc3RvcnksIGFuZCB0aGUgZmFjdCB0aGF0IHdlIGdldCBhIG5vbmNl IGZyb20gYm90aCBzaWRlLCBhcGFydCBmcm9tIGd1YXJhbnRlZWluZyB0aGF0IHRoZSByZXN1bHQg aXMgZWZmZWN0aXZlbHkgdW5pcXVlIHRvIGJvdGggcGFydGllcywgYWxzbyBtYWtlcyB0aGUgY2hh bmNlcyBmb3IgaGlzdG9yeSB0byByZXBlYXQgdmVyeSBsb3cuIA0KDQpDQydpbmcgU0VDLURJUjog UGxlYXNlIGhlbHA6IGlmIHRoZXJlIGlzIGEgcmVmZXJlbmNlIGZvciB0aGF0IHByYWN0aWNlLCB3 aGF0IGl0IHRha2VzIHRvIG1haW50YWluIGEgbm9uY2UsIGFuZCB3aHkgd2UgaGF2ZSBhIG5vbmNl IGZyb20gYm90aCBzaWRlcz8gVHJ5aW5nIHRvIHJlaW52ZW50IHRoYXQgdGV4dCBkb2VzIG5vdCBs b29rIGxpa2UgYSBnb29kIGlkZWEgZm9yIHRoaXMgZHJhZnQuDQoNCg0KDQo+IA0KPiAtLSBSZWZl cmVuY2VzIC0tDQo+IElzIHRoZXJlIGEgcmVhc29uIHdoeSB0aGUgY3J5cHRvIGFsZ29yaXRobXMg UkZDIDc3NDggYW5kIDgwMzIgYXJlIG5vdA0KPiBub3JtYXRpdmU/DQoNCkludGVyZXN0aW5nbHkg dGhleSBhcmUgaW5mb3JtYXRpb25hbC4gU28gdGhhdCB3b3VsZCBiZSBhIGRvd25yZWYuIA0KDQpD QydpbmcgU0VDLURJUjogUGxlYXNlIGhlbHA6IHNob3VsZCB3ZSBtYWtlIHRoZXNlIHJlZnMgbm9y bWF0aXZlPyANCg0KDQo+IA0KPiA9PSBOSVRTID09DQo+IA0KPiAtLSBTZWN0aW9uIDIuMiAtLQ0K PiBUbyBiZSBob25lc3QsIEkgYW0gbm90IGEgYmlnIGZhbiBvZiBzaW1wbHkgYW5ub3VuY2luZyBj b25jZXB0cyBhbmQgcmVmZXJyaW5nIHRvDQo+IG1hbnkgb3RoZXIgUkZDcy4gU3VnZ2VzdCB0byBt ZW50aW9uIHdoaWNoIHRlcm1zIGFuZCBjb25jZXB0cyBhcmUgZGVmaW5lZCBpbg0KPiBlYWNoIGRv Y3VtZW50LiBFbHNlLCB0aGUgY3VycmVudCBzZWN0aW9uIDIuMiBtb3N0bHkgZm9yY2VzIHRoZSBy ZWFkZXJzIHRvIHJlYWQNCj4gYWxsIHRoZSByZWZlcmVuY2VzLg0KDQpZZXMgYW5kIHRoZXkgYXJl IHJlYWxseSB0aGVyZSBhcyBhZGRpdGlvbmFsIHJlYWRpbmcsIG5vdCBub3JtYXRpdmUuDQpJIGNo YW5nZWQgdGhlIHRleHQgdG8gDQoiIFRoZSByZWFkZXIgbWF5IGdldCBhZGRpdGlvbmFsIGNvbnRl eHQgZm9yIHRoaXMgc3BlY2lmaWNhdGlvbiBmcm9tIHRoZSBmb2xsb3dpbmcgcmVmZXJlbmNlcyIN CkkgYWxzbyBtb3ZlZCBjbGFzc2ljYWwgTkQgYW5kIFNFTkQgcmVmZXJlbmNlcyB0byBpbmZvcm1h dGlvbmFsIHJlZmVyZW5jZXMuDQoNCldvcmtzPw0KDQo+IC0tIFNlY3Rpb24gNiAtLQ0KPiBzL21h eSB1c2UgYSBzYW1lIENyeXB0by1JRC9tYXkgdXNlIHRoZSBzYW1lIENyeXB0by1JRC8gPw0KDQpE b25lDQoNCk1hbnkgdGhhbmtzIGFnYWluIEVyaWMhDQoNCkxldCdzIHNlZSB3aGF0IFNFQy1ESVIg dGhpbmtzDQoNCkFuZCBhIHZlcnkgaGFwcHkgbmV3IHllYXIgKGluIEZyYW5jZSB3ZSBoYXZlIHRp bGwgSmFuIDMxc3QgdG8gc2VuZCB3aXNoZXMg8J+YiSkNCg0KUGFzY2FsDQoNCiANCg0K From nobody Wed Jan 29 07:47:00 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AECE120020; Wed, 29 Jan 2020 07:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.498 X-Spam-Level: X-Spam-Status: No, score=-14.498 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.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=JCLXS36+; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=JkTl6cuV Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pLsO96sFxPB; Wed, 29 Jan 2020 07:46:38 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 907D81200BA; Wed, 29 Jan 2020 07:46:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6294; q=dns/txt; s=iport; t=1580312797; x=1581522397; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=iK9S74OxUIUo3KL79ihLgoIFNimjFrpcyELqqCeuYXQ=; b=JCLXS36++BwpzSHBR2kjKvrzjoIGG4o92A8y6p2vH7Eh2r/7tQyp6RPU 2jXnz3JscRkty05M44uAMilNBHYdSG3aDRgkdUirVFBQhoXogIzPGJSIJ C4tuUns+Fv4e2rfXUhN+AKFSTQ/Cx1I3498rzu/YQA1atJcVLgrvVUIm5 4=; IronPort-PHdr: =?us-ascii?q?9a23=3AyGyN+hex39W9Y5sZCg1o8rmplGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGRD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/YjIrGs9BWXdu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CfBQDjpzFe/5NdJa1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuBVFAFgTwIIAQLKgqECoNGA4pymm6CUgNUCQEBAQwBAS0CAQG?= =?us-ascii?q?EQAIXghMkOBMCAw0BAQQBAQECAQUEbYU3DIVfAgEDEhERDAEBNwEPAgEGAho?= =?us-ascii?q?CJgICAjAVBQsCBAENBSKDBIJLAy4BA5EgkGYCgTmIYnWBMoJ/AQEFhH0Yggw?= =?us-ascii?q?JgQ4qhR6FP4FDGoFBP4ERJyCCTD6EYIJ5MoIsjWCCOjuPU45EcAqCOZY3G4J?= =?us-ascii?q?IiAqER4chhEWDSYsXmw0CBAIEBQIOAQEFgWkigVhwFWUBgkFQGA2OHQkaFYM?= =?us-ascii?q?7ilN0gSmKXS2BBAGBDwEB?= X-IronPort-AV: E=Sophos;i="5.70,378,1574121600"; d="scan'208";a="712085613" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Jan 2020 15:46:36 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 00TFkaif002728 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Jan 2020 15:46:36 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 29 Jan 2020 09:46:35 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 29 Jan 2020 09:46:35 -0600 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 29 Jan 2020 10:46:35 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bcPvyEhIfgBvQgGwuz0hNURLoj2ig/p9BBGprMc1kHwbCZ/vTTgQ+e4+CLIVExRTYwMwNduHNZH+WMLcVLRK3Z+0USNnPn8LXUCnnTIHVL4BC5CIqzssBvyCzL7SQ5IZeQZqdy+CzDJ9eYYzmY7NGI3wStaDZYHPtmVnZnKb3HvsDrvcO+u25rH3B2GzsFOTyNg/XSf15OLzBpSclw1UI85opdijqrGyaiTDz2J7C02FFNLs7fg/k0bFXWiUTEQXqSUvz2G7TZ4JTLd53aRRkp67w8ZTZcKVHOearH8bAufmHgSmefYK9od5j2OtXsf9c8K99GSuoh1hlEGjqp/uUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iK9S74OxUIUo3KL79ihLgoIFNimjFrpcyELqqCeuYXQ=; b=GjDdWr3INucGPP6eZkCgJ6jvOAL1eo20A7Mm6nTWVeNF8dzSr1gOTMXijNyNVGsQlSY7ns0hZqm7laAKfbpmL0JLh7tfi9+OJhtBXgVZhUbYyM+ZB26rptS+SXo+fRqFLPbvEBG7Ey0yKqw6lCZIoMYTHZWz5LbNVI8S2qp2QloyIHFOfhHmdzFcI3I/QhMfjYBatV8i+RTVgxTW4UNSttcXkX5DQqqFys8ZJLiO79ABy67NvwhAHPj4OpRYYEZJulUWDe4kXVvm81pyML6YTcJpGad61AndBqDJziKBfWXHSyB97pHm8FLDLkytUAN9KYudPtPUiM7oR48POMJ8SQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iK9S74OxUIUo3KL79ihLgoIFNimjFrpcyELqqCeuYXQ=; b=JkTl6cuVstXKAMYUfvEfWjo3EOqGsGdYSY2UT2eyfdeOfnpTuhk7+e5EPSB/4tGTUmOlxHqi9k9PeVgb7mySZde0QjMpkQccgAfyHswnmoD9laS7v8OjKv3AOo7WuXV64PbusbAv+CrSick0yDuJCR9mHGkW1TIAQOi/U+QFdgo= Received: from DM5PR11MB1753.namprd11.prod.outlook.com (10.175.88.141) by DM5PR11MB1530.namprd11.prod.outlook.com (10.172.38.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.24; Wed, 29 Jan 2020 15:46:34 +0000 Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::bcaa:91e6:c27b:b8ff]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::bcaa:91e6:c27b:b8ff%11]) with mapi id 15.20.2665.026; Wed, 29 Jan 2020 15:46:34 +0000 From: "Eric Vyncke (evyncke)" To: "Pascal Thubert (pthubert)" , The IESG CC: "draft-ietf-6lo-ap-nd@ietf.org" , "Shwetha Bhandari (shwethab)" , "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>, "secdir@ietf.org" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLTZsby1hcC1u?= =?utf-8?Q?d-13:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHV1rol7hp9w1bEa06QELjbj0JyDqgB2d0A Date: Wed, 29 Jan 2020 15:46:33 +0000 Message-ID: References: <158030752268.2728.2544838912831012540.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [194.179.44.108] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d8a6580e-58db-4669-13ce-08d7a4d26aff x-ms-traffictypediagnostic: DM5PR11MB1530: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(346002)(396003)(376002)(136003)(366004)(199004)(189003)(81156014)(8936002)(81166006)(478600001)(316002)(110136005)(54906003)(2616005)(36756003)(186003)(4326008)(86362001)(450100002)(6506007)(2906002)(26005)(224303003)(6486002)(33656002)(6512007)(76116006)(66556008)(66446008)(66476007)(66946007)(71200400001)(91956017)(64756008)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1530; H:DM5PR11MB1753.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xpCEGdVnzje03OzDx/76IRHBo5xDTNAJm6VNYVAvhFfmp/X0p4e6HzMqETVN/CUNo+yWk371fzqD1k8OeTUF+RzVwZWE/Q8MGWFqUMjzP/nSsPcocA/HbVTD/wUhAreZumAzKjisph05mjZrUJCWPUoIsFvtwU1/pwURFNSdL5X0Dqd+OTFugk7nVT0x16xpww8KtChZz6wLckq/RQpdbpW2oscuoKkZHck+cjcufNuRRC7APwqqEXKe8NP3IF0Urph+Pe7uK6+VcWA2S0PVR2IE1VGVNni4XJ/jebYKnn4v973Q4GkkRRqi4mQbzGOgnf7wYOlfhzCkiF5Xh2QTkXCrappvzYsCejHt9YkJfkKY7wsnvnOqKCa5ItmW4jovC8ixUcGAVf6E9/EcbbK+uc6ErT1cQlYcLfwmKcrrL2RtBLNH9W0wBjW0hFnXSEKN x-ms-exchange-antispam-messagedata: PPHOB2J04ULCD8l7kLwbeglJibkDW+Xt23zDhqxoRUu/ADiJU5eoCBn0NXgPeYxBtLhyRW7N3J9r7L9pwXb5FBqlyuB//QNlaR+AZ9xRWAvGkHWmsgnTNPyQQkJ3jifSA6QHWLLZUwJsyOikZMYCNw== Content-Type: text/plain; charset="utf-8" Content-ID: <24E6669F14DC504F8F7136E8AC28D195@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d8a6580e-58db-4669-13ce-08d7a4d26aff X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2020 15:46:33.8175 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: OiewU1Cp5BEDpdGzNYszG9mvY1tUQforpjavCNYH+QcmM1aTIy8v4j/cQdbnKqWuOU34BbkDkJDvSxHRvUdAew== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1530 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [secdir] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-6l?= =?utf-8?q?o-ap-nd-13=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 15:46:50 -0000 UGFzY2FsDQoNClRoYW5rIHlvdSBmb3IgeW91ciBwcm9tcHQgcmVwbHkuIEkgd2lsbCBjbGVhciBt eSBESVNDVVNTIGluIGEgbW9tZW50IGFzIHlvdSB3aWxsIGNoYW5nZSB0aGUgdGV4dC4NCg0KQWdy ZWVkIG9uIGFsbCB0aGUgcG9pbnRzIGV4Y2VwdCBmb3IgdGhlICdub25jZScuIEkga25vdyB0aGUg Y29uY2VwdCBvZiBjb3Vyc2UgYnV0IHRoZSBzZW50ZW5jZSAid2FzIG5ldmVyIHVzZWQgd2l0aCB0 aGlzIGRldmljZSIgaXMgc3RpbGwgdG9vIHN0cm9uZyBJTUhPLiBUbyBjb21wbHksIGl0IHdvdWxk IHJlcXVpcmUgdG8ga2VlcCB0aGUgaGlzdG9yeSBmb3IgZXZlci4uLiBJIHdvdWxkIHByZWZlciBh IGxlc3Mgc3RyaW5nZW50IHdvcmRpbmcuDQoNCi3DqXJpYw0KDQrvu79PbiAyOS8wMS8yMDIwLCAx NjozOCwgIlBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkiIDxwdGh1YmVydEBjaXNjby5jb20+IHdy b3RlOg0KDQogICAgSGVsbG8gRXJpYyA6ICkNCiAgICANCiAgICBNYW55IHRoYW5rcyBmb3IgeW91 ciByZXZpZXchIEkgY2MnZWQgU0VDLURJUiBiZWNhdXNlIHdlIGNvdWxkIHJlYWxseSB1c2UgdGhl aXIgcmVjb21tZW5kYXRpb24gdG8gc29sdmUgc29tZSBvZiB5b3VyIHF1ZXN0aW9ucywgbW9yZSBi ZWxvdy4NCiAgICANCiAgICBQbGVhc2Ugc2VlIGJlbG93Og0KICAgICANCiAgICA+ID09IERJU0NV U1MgPT0NCiAgICA+IA0KICAgID4gLS0gU2VjdGlvbiA0LjQgLS0NCiAgICA+IFRoZSBsZW5ndGgg b2YgdGhlIHJlc2VydmVkIGZpZWxkIGlzIG5vdCBzcGVjaWZpZWQuIE9yIGFtIEkgbWlzc2luZyBz b21ldGhpbmcNCiAgICA+IG9idmlvdXMgPw0KICAgIA0KICAgIEkgY29uY2F0ZW5hdGVkIHRoZSBy ZXNlcnZlZCBmaWVsZHMgaW4gdGhlIHBpY3R1cmUgYW5kIGRlY2xhcmVkIGl0IGFzIDQwIGJpdHMu IA0KICAgIEFsc28gYWRkZWQgdGhlIG51bWJlciBvZiBiaXRzIGluIHRoZSByZXNlcnZlZCBmaWVs ZHMgb2Ygb3RoZXIgc3RydWN0dXJlcy4NCiAgICANCiAgICA+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICA+ IENPTU1FTlQ6DQogICAgPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPiANCiAgICA+ID09IENPTU1FTlRT ID09DQogICAgPiANCiAgICA+IC0tIFNlY3Rpb24gNC4yIC0tDQogICAgPiBXaGlsZSBzdGF0dXMg aXMgc2V0IHRvIDAgd2hlbiBzZW5kaW5nIGEgTlMsIHdoYXQgaXMgdGhlIGV4cGVjdGVkIGJlaGF2 aW9yIG9mIGENCiAgICA+IHJlY2VpdmVyID8NCiAgICANCiAgICBDaGFuZ2VkIHRvIA0KICAgICIN CiAgICBJbiBOUyBtZXNzYWdlcyBpdCBNVVNUIGJlIHNldCB0byAwIGJ5IHRoZSBzZW5kZXIgYW5k IGlnbm9yZWQgYnkgdGhlIHJlY2VpdmVyLg0KICAgICINCiAgICAgDQogICAgPiAtLSBTZWN0aW9u IDQuMyBhbmQgNC40IC0tDQogICAgPiBXaHkgaXMgdGhlIFBhZCBMZW5ndGggZmllbGQgYSA4LWJp dCBmaWVsZCB3aGlsZSB0aGUgYWN0dWFsIHBhZGRpbmcgd2lsbCBhbHdheXMgYmUNCiAgICA+IGxl c3MgdGhhbiA4IGJ5dGVzLiBTdWdnZXN0IHRvIG1ha2UgaXQgYSAzIG9yIDQgYml0cyBmaWVsZCBh bmQgZXh0ZW5kIHRoZSByZXNlcnZlZA0KICAgID4gZmllbGQuDQogICAgDQogICAgQWN0dWFsbHkg SSB0aG91Z2h0IHRoYXQgaWYgd2Ugd2FudCB0byBleHRlbmQgdGhlIG9wdGlvbiBpbiB0aGUgZnV0 dXJlLCBpdCBpcyBiZXR0ZXIgdG8gaW5kaWNhdGUgdGhlIGxlbmd0aCBvZiB0aGUgcHVibGljIGtl eSBhcyBmb2xsb3dzOg0KICAgIA0KICAgICAgIHwgICAgIFR5cGUgICAgICB8ICAgIExlbmd0aCAg ICAgfCBSZXNlcnZlZHwgIFB1YmxpYyBLZXkgTGVuZ3RoICB8DQogICAgDQogICAgV2hlcmU6DQog ICAgDQogICAgUHVibGljIEtleSBMZW5ndGg6IDEzLWJpdCB1bnNpZ25lZCBpbnRlZ2VyLiBUaGUg bGVuZ3RoIG9mIHRoZSBQdWJsaWMgS2V5IGZpZWxkIGluIGJ5dGVzLg0KICAgIFB1YmxpYyBLZXk6 ICBBIHZhcmlhYmxlLWxlbmd0aCBmaWVsZCwgc2l6ZSBpbmRpY2F0ZWQgaW4gdGhlIFB1YmxpYyBL ZXkgTGVuZ3RoIGZpZWxkLg0KICAgICAgICAgICAJICAgICBKV0stRW5jb2RlZCBQdWJsaWMgS2V5 IFtSRkM3NTE3XQ0KICAgID5QYWRkaW5nOiAgQSB2YXJpYWJsZS1sZW5ndGggZmllbGQgY29tcGxl dGluZyB0aGUgUHVibGljIEtleSBmaWVsZCB0byBhbGlnbiB0byB0aGUgbmV4dCA4LWJ5dGVzIGJv dW5kYXJ5Lg0KICAgIA0KICAgIA0KICAgIFdvcmtzPw0KICAgIA0KICAgIA0KICAgIA0KICAgID4g DQogICAgPiAtLSBTZWN0aW9uIDYuMSAtLQ0KICAgID4gQWJvdXQgIk5vbmNlIG9wdGlvbiBNVVNU IGNvbnRhaW4gYSByYW5kb20gTm9uY2UgdmFsdWUgdGhhdCB3YXMgbmV2ZXIgdXNlZA0KICAgID4g d2l0aCB0aGlzIGRldmljZSIsIGhvdyBjYW4gaXQgYmUgZG9uZT8gS2VlcGluZyBhIGxvY2FsIGhp c3Rvcnk/IEdpdmluZyBzb21lDQogICAgPiBvcGVyYXRpb25hbCBoaW50cyB3b3VsZCBiZWUgd2Vs Y29tZS4gRXNwZWNpYWxseSwgd2hlbiB0aGVyZSBhcmUgbXVsdGlwbGUgNkxSIGluDQogICAgPiB0 aGUgTExOOiBob3cgY2FuIHRoZXkgc3luY2hyb25pemUgdGhlIG5vbmNlPw0KICAgIA0KICAgIFRo ZSBub25jZSBpcyB1c2VkIG9uY2UsIHNvIHRoZXJlJ3Mgbm8gc3luY2hyb25pemF0aW9uLiBBIG5l dyBwYWlyIGlzIGZvcm1lZCBhbmQgZXhjaGFuZ2VkIGF0IGVhY2ggdmFsaWRhdGlvbi4NCiAgICAN CiAgICBUaGUgbm9uY2UgZ2FtZSB1c2VkIGhlcmUgYXBwZWFyIHRvIGJlIGNvbW1vbiBwcmFjdGlj ZS4gWWVzLCB0aGVyZSdzIHVzdWFsbHkgYSBuZWVkIG9mIGxvY2FsIGhpc3RvcnksIGFuZCB0aGUg ZmFjdCB0aGF0IHdlIGdldCBhIG5vbmNlIGZyb20gYm90aCBzaWRlLCBhcGFydCBmcm9tIGd1YXJh bnRlZWluZyB0aGF0IHRoZSByZXN1bHQgaXMgZWZmZWN0aXZlbHkgdW5pcXVlIHRvIGJvdGggcGFy dGllcywgYWxzbyBtYWtlcyB0aGUgY2hhbmNlcyBmb3IgaGlzdG9yeSB0byByZXBlYXQgdmVyeSBs b3cuIA0KICAgIA0KICAgIENDJ2luZyBTRUMtRElSOiBQbGVhc2UgaGVscDogaWYgdGhlcmUgaXMg YSByZWZlcmVuY2UgZm9yIHRoYXQgcHJhY3RpY2UsIHdoYXQgaXQgdGFrZXMgdG8gbWFpbnRhaW4g YSBub25jZSwgYW5kIHdoeSB3ZSBoYXZlIGEgbm9uY2UgZnJvbSBib3RoIHNpZGVzPyBUcnlpbmcg dG8gcmVpbnZlbnQgdGhhdCB0ZXh0IGRvZXMgbm90IGxvb2sgbGlrZSBhIGdvb2QgaWRlYSBmb3Ig dGhpcyBkcmFmdC4NCiAgICANCiAgICANCiAgICANCiAgICA+IA0KICAgID4gLS0gUmVmZXJlbmNl cyAtLQ0KICAgID4gSXMgdGhlcmUgYSByZWFzb24gd2h5IHRoZSBjcnlwdG8gYWxnb3JpdGhtcyBS RkMgNzc0OCBhbmQgODAzMiBhcmUgbm90DQogICAgPiBub3JtYXRpdmU/DQogICAgDQogICAgSW50 ZXJlc3RpbmdseSB0aGV5IGFyZSBpbmZvcm1hdGlvbmFsLiBTbyB0aGF0IHdvdWxkIGJlIGEgZG93 bnJlZi4gDQogICAgDQogICAgQ0MnaW5nIFNFQy1ESVI6IFBsZWFzZSBoZWxwOiBzaG91bGQgd2Ug bWFrZSB0aGVzZSByZWZzIG5vcm1hdGl2ZT8gDQogICAgDQogICAgDQogICAgPiANCiAgICA+ID09 IE5JVFMgPT0NCiAgICA+IA0KICAgID4gLS0gU2VjdGlvbiAyLjIgLS0NCiAgICA+IFRvIGJlIGhv bmVzdCwgSSBhbSBub3QgYSBiaWcgZmFuIG9mIHNpbXBseSBhbm5vdW5jaW5nIGNvbmNlcHRzIGFu ZCByZWZlcnJpbmcgdG8NCiAgICA+IG1hbnkgb3RoZXIgUkZDcy4gU3VnZ2VzdCB0byBtZW50aW9u IHdoaWNoIHRlcm1zIGFuZCBjb25jZXB0cyBhcmUgZGVmaW5lZCBpbg0KICAgID4gZWFjaCBkb2N1 bWVudC4gRWxzZSwgdGhlIGN1cnJlbnQgc2VjdGlvbiAyLjIgbW9zdGx5IGZvcmNlcyB0aGUgcmVh ZGVycyB0byByZWFkDQogICAgPiBhbGwgdGhlIHJlZmVyZW5jZXMuDQogICAgDQogICAgWWVzIGFu ZCB0aGV5IGFyZSByZWFsbHkgdGhlcmUgYXMgYWRkaXRpb25hbCByZWFkaW5nLCBub3Qgbm9ybWF0 aXZlLg0KICAgIEkgY2hhbmdlZCB0aGUgdGV4dCB0byANCiAgICAiIFRoZSByZWFkZXIgbWF5IGdl dCBhZGRpdGlvbmFsIGNvbnRleHQgZm9yIHRoaXMgc3BlY2lmaWNhdGlvbiBmcm9tIHRoZSBmb2xs b3dpbmcgcmVmZXJlbmNlcyINCiAgICBJIGFsc28gbW92ZWQgY2xhc3NpY2FsIE5EIGFuZCBTRU5E IHJlZmVyZW5jZXMgdG8gaW5mb3JtYXRpb25hbCByZWZlcmVuY2VzLg0KICAgIA0KICAgIFdvcmtz Pw0KICAgIA0KICAgID4gLS0gU2VjdGlvbiA2IC0tDQogICAgPiBzL21heSB1c2UgYSBzYW1lIENy eXB0by1JRC9tYXkgdXNlIHRoZSBzYW1lIENyeXB0by1JRC8gPw0KICAgIA0KICAgIERvbmUNCiAg ICANCiAgICBNYW55IHRoYW5rcyBhZ2FpbiBFcmljIQ0KICAgIA0KICAgIExldCdzIHNlZSB3aGF0 IFNFQy1ESVIgdGhpbmtzDQogICAgDQogICAgQW5kIGEgdmVyeSBoYXBweSBuZXcgeWVhciAoaW4g RnJhbmNlIHdlIGhhdmUgdGlsbCBKYW4gMzFzdCB0byBzZW5kIHdpc2hlcyDwn5iJKQ0KICAgIA0K ICAgIFBhc2NhbA0KICAgIA0KICAgICANCiAgICANCiAgICANCg0K From nobody Wed Jan 29 08:52:08 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E061201B7; Wed, 29 Jan 2020 08:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=QzhppUv2; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=rENiX4zC Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70S_osx6jnWO; Wed, 29 Jan 2020 08:51:52 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6458412009C; Wed, 29 Jan 2020 08:51:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10146; q=dns/txt; s=iport; t=1580316712; x=1581526312; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=oqdILpxp/pxFuPdR4ddQXByNJX4qKUN6q9EGCCwCcrI=; b=QzhppUv2IdDIGGGOcKVxcVHxu4J3S3ts8pF28LBD+nj1rCZdjCRhGT+D 8RZhE9nppVYOdqKmm5VWmgwyT8SnY2JqzlPLqddjcERW/EwtgXdROZI4F lMkOVni/jkGz9GYbKxqF87YGAURiulohlhNu6SY2NsXeLynHJlVlCa5pv I=; IronPort-PHdr: =?us-ascii?q?9a23=3A1G33ABLBIUasdrA0otmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXFXnLOPgYjYmNM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CxAAATtzFe/4MNJK1mGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYF7gVQkLAVsWCAECyqEFINGA4pygl+YD4JSA1Q?= =?us-ascii?q?JAQEBDAEBIwoCAQGEQAIXghMkOBMCAw0BAQQBAQECAQUEbYU3DIVeAQEBAQM?= =?us-ascii?q?SEREMAQE3AQsEAgEGAhEEAQEBAgImAgICMBUFAwgCBAENBQgagwWCSgMuAQI?= =?us-ascii?q?MkUmQZgKBOYhidYEygn8BAQWEfRiCDAMGgQ4qhR6FP4FDGoFBP4ERR4FOfj6?= =?us-ascii?q?CZAEBAQKBTBYVgnkygiyNYII6O54RBnAKgjmHQo8QgkiICoRHhyGERYNJixe?= =?us-ascii?q?IZJIpAgQCBAUCDgEBBYFpIoFYcBWDJ1AYDY4dCQMXFYM7hRSFP3QCgSeKXAE?= =?us-ascii?q?mB4IUAQE?= X-IronPort-AV: E=Sophos;i="5.70,378,1574121600"; d="scan'208";a="438907994" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Jan 2020 16:51:51 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 00TGppIZ023254 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Jan 2020 16:51:51 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 29 Jan 2020 10:51:50 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 29 Jan 2020 10:51:49 -0600 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 29 Jan 2020 10:51:49 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c5nzbyFyCZpy2dSt9CIJ0XKv1/ywsz30M49DtKOT1OVBopC2WWfVSj55t8d04nlDWPgijqKB/dbRXyBUfQBdltIJEX+w4VAJkw6IiORjD57IjLq1yz+9zW9qspyu8+XcVrdyKJyM12kkReaymt1nbbFNsBqiTcaWMypLPYR1icu9LtzJEkdzPX/ecxFCpbjYPUczHRg927R/vjc58dKWVzy1eagQlRkoLr8w5YrogbqcII+Gwql9I7DcP8IRQODb/RdZ35l7N3xJSEfc1vV/KRqWzUiapKTXRI3DLxfG0G4lDeHNF7fAtJDiaYzHDJ4AABCE5dcsoAkffR7aXD7QdA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oqdILpxp/pxFuPdR4ddQXByNJX4qKUN6q9EGCCwCcrI=; b=D7aXbuMAun2/Id2r69fTLR+lqVOFhnc+QQz+EnLFWSjC/zYUWIEuH0etcJu0lSZyxa8+LhD7qY/ENEBelrsC2UZG8VHhu3h39hlj8DR3lrdRWu6hijftEYpv5705huLjkvbJJ1nLrfX13XXMpgnolv/al1i3bNbPdfvBQTDDrL5231muaFKzgKtLRKju/WoslPK/m+AnL4eVp4QaYS2iHN11n+HUcr/80QScSZbI0SadejqP+E0aSHkuA4mZMINNKNEOOuz87sEMD7Y+THS0oTwlrR15YYvumjPmleZqXGf04MWPAvHD4C3vtOL2NS7hppsB+Vy0ymPozbb4KXcx8w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oqdILpxp/pxFuPdR4ddQXByNJX4qKUN6q9EGCCwCcrI=; b=rENiX4zC7N3DSRdSGmVMFFDZmNW/R8F0QWwt3bWCjlXo0dDPkuHsHx7XGgb64QMeDYoAdEMMuaxMM0UQGCe/9un9cpNTIETFVJmz6f2N5iGR91C56WGK8qlgalHluCQ+98AK5IRWM1zW/AfYOns9WO2fO7lotiXuBIkTPXibdDs= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4478.namprd11.prod.outlook.com (52.135.36.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.23; Wed, 29 Jan 2020 16:51:48 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a%3]) with mapi id 15.20.2665.027; Wed, 29 Jan 2020 16:51:48 +0000 From: "Pascal Thubert (pthubert)" To: "Eric Vyncke (evyncke)" , The IESG CC: "draft-ietf-6lo-ap-nd@ietf.org" , "Shwetha Bhandari (shwethab)" , "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>, "secdir@ietf.org" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLTZsby1hcC1u?= =?utf-8?Q?d-13:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHV1q8ObZjsSNLsNE+ME5HgTzGBvKgBtsSwgAASbYCAAAcrkA== Date: Wed, 29 Jan 2020 16:51:36 +0000 Deferred-Delivery: Wed, 29 Jan 2020 16:50:44 +0000 Message-ID: References: <158030752268.2728.2544838912831012540.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:44f3:1300:41e7:7725:e525:b2e8] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1d344c20-abd5-45f1-e2ee-08d7a4db87d7 x-ms-traffictypediagnostic: MN2PR11MB4478: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(346002)(136003)(366004)(376002)(189003)(199004)(71200400001)(224303003)(81156014)(81166006)(9686003)(33656002)(86362001)(55016002)(6666004)(7696005)(2906002)(8936002)(316002)(54906003)(52536014)(5660300002)(110136005)(4326008)(66476007)(76116006)(66946007)(66446008)(53546011)(450100002)(186003)(6506007)(64756008)(66556008)(966005)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4478; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: hotXcDCJp5rTidZYErPN4waT0xqbOyic32WrENEG2u6fSse/4EJ13GDDfBUUBpHWvVDerEBPjqh96ZACGeTF65YsVR+C44Yq7AOEVXGThIy9WN87VatNNdxtnjTTn6Qcaj9On4wHQmIdmgbWB2dMh18H42hc32SEJedFpTn6uY9jXmXEw0q400JMnrJ4Un9w6BAYlvhFOFjNbCGfVm3OhlYHWjyAQbwd88WWSZ2jRTdkMVsXFAGlWY3u0h9HjQJYJSf8WPRtbIdXo5kMg64daBTEpvTLQi6VXbtgmumKiPqQZ76Fisp6uCNoY7uffoEzyi0RH/F7EGgId93P86IfOEJl44ocQn8Zxa8VvKonXv8uGfEvouxjo0lOOSQdF4pXHIMOj6dvDF1rAExIntAuK9jpMMig2Uv5YXhvTF9sucxRFMlntLmXcLnXwhQESWoUEhhx1Zxj7nmthITwHiqiYozwOTekzT5RAv6+7mzewQmbXMg+I1zRQ4clQ0IjQItAhB6RoFTI8A5/0ByobmP7Mg== x-ms-exchange-antispam-messagedata: MliatNI0DT2xpkOf3VgpPfvdcpieFXUhLWWVn9AOaPwpdwJfbo7Abx5ylP8zWGn/2buYpfp940GJNyfA/Y/Mo7AqWluzQU+M51t8mw7gkQlAhU2lZ4m00v0CttQFckbUnxcVQL9OJ3X7q3NA7LIBkRa47+tCvFE/9I7AxdIdnk3J7AWrTHqkCls/oG0ZeH/o4kZLMsgH2Gt2CC/jlVJjQg== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 1d344c20-abd5-45f1-e2ee-08d7a4db87d7 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2020 16:51:47.8750 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yMy1QNkxQrjr4fJC5/qa+eMX+Mo1Sefj1me9+zyYMhPZGIpldkcrqyWSIM0m2bib70BCEF2DCHwvigapCseRpQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4478 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [secdir] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-6l?= =?utf-8?q?o-ap-nd-13=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 16:51:59 -0000 SGVsbG8gRXJpYzoNCg0KRmlyc3Qgb2YgYWxsLCAiIHdhcyBuZXZlciB1c2VkIHdpdGggdGhpcyBk ZXZpY2UgIiBzaG91bGQgcmVhbGx5IGJlICIgd2FzIG5ldmVyIHVzZWQgd2l0aCB0aGlzIGtleXBh aXIgIi4gQW5kIHRoZW4gd2UgY291bGQgYWRkICJ0byB0aGUgZXh0ZW50IHBvc3NpYmxlIGZvciB0 aGUgaW1wbGVtZW50YXRpb24iLiBBbmQgdGhlbiBJIGFncmVlLCAicmFuZG9tIiBjYW5ub3QgYmUg YXNzZXJ0ZWQgZm9yICJuZXZlciB1c2VkIi4NCg0KSSBkaWQgc29tZSBob21ld29yayBvbiB0aGUg bm9uY2UgYnV0IHN0aWxsIHdvdWxkIHByZWZlciB0byBnZXQgcmVjb21tZW5kYXRpb24gYnkgU0VD IERJUjsgSSdsbCBub3RlIHRoYXQgYSBtb3RlIGNhbm5vdCBub3QgbmVjZXNzYXJpbHkgcHJvZHVj ZSBnb29kIHJhbmRvbXMgZWFzaWx5IGFuZCB0aGF0IHRvIG15IGJlc3QgdW5kZXJzdGFuZGluZyBh biBpbmNyZW1lbnRpbmcgbnVtYmVyIHN0b3JlZCB3aXRoIHRoZSBrZXlzIHNob3VsZCBkbyBhcyBs b25nIGFzIHRoZSBrZXlzIGFyZSByZWdlbmVyYXRlZCB3aGVuIHRoZSBzdG9yYWdlIGlzIGxvc3Qu DQoNCkJhc2VkIG9uIHRoYXQgaG9tZXdvcmsgSSBzdWdnZXN0Og0KDQoiDQogICBUaGUgTm9uY2Ug b3B0aW9uIE1VU1QgY29udGFpbiBhIE5vbmNlIHZhbHVlIHRoYXQsIHRvIHRoZSBleHRlbnQgcG9z c2libGUNCiAgIGZvciB0aGUgaW1wbGVtZW50YXRpb24sIHdhcyBuZXZlciBlbXBsb3llZCBpbiBh c3NvY2lhdGlvbiB3aXRoIHRoZQ0KICAga2V5IHBhaXIgdXNlZCB0byBnZW5lcmF0ZSB0aGUgUk9W Ui4gIEFuIGltcGxlbWVudGF0aW9uIG1heSBmb3IgaW5zdGFuY2UNCiAgdXNlIGFuICB1bnByZWRp Y3RhYmxlIGNyeXB0b2dyYXBoaWNhbGx5IHJhbmRvbSB2YWx1ZSBbUkZDNDA4Nl0sIG9yIGFuDQog ICBpbmNyZW1lbnRpbmcgdmFsdWUgc2F2ZWQgaW4gc3RhYmxlIHN0b3JhZ2UuDQoiDQoNCldoYXQg SSBmb3VuZCBpcyB0aGlzOg0KDQpXZSBpbmhlcml0IGZyb20gUkZDIDM5NzEgd2hpY2ggc2F5czoN CiINCiAgIE5vbmNlDQoNCiAgICAgIEEgZmllbGQgY29udGFpbmluZyBhIHJhbmRvbSBudW1iZXIg c2VsZWN0ZWQgYnkgdGhlIHNlbmRlciBvZiB0aGUNCiAgICAgIHNvbGljaXRhdGlvbiBtZXNzYWdl LiAgVGhlIGxlbmd0aCBvZiB0aGUgcmFuZG9tIG51bWJlciBNVVNUIGJlIGF0DQogICAgICBsZWFz dCA2IGJ5dGVzLiAgVGhlIGxlbmd0aCBvZiB0aGUgcmFuZG9tIG51bWJlciBNVVNUIGJlIHNlbGVj dGVkDQogICAgICBzbyB0aGF0IHRoZSBsZW5ndGggb2YgdGhlIG5vbmNlIG9wdGlvbiBpcyBhIG11 bHRpcGxlIG9mIDggb2N0ZXRzLg0KDQoiDQoNCkFsc286DQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM2NzQ0IHJlcXVpcmVzIGEgcmFuZG9tIG5vbmNlIGFuZCByZWxpZXMgb24gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQwODYgdG8gZGVmaW5lIHJhbmRvbW5lc3MuIFdl IGNvdWxkIG1ha2UgdGhhdCBhbiBvcHRpb24uDQpodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9y ZmMvcmZjNzgwNC5odG1sIHVzZXMgU0NSQU0gKGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3Jm Yy9yZmM1ODAyKSB3aGljaCBnZW5lcmF0ZXMgbm9uY2VzIGJhc2VkIG9uIHJhbmRvbSBzdHJpbmdz DQogQW4gYWx3YXlzIGluY3JlbWVudGluZyB2YWx1ZSBpcyBzaW1wbGVyIGJ1dCByZXF1aXJlcyBz dGFibGUgc3RvcmFnZS4gV2hlbiBpdCB3cmFwcyB0aGUgYWRkcmVzcyBtdXN0IGJlIGRlcmVnaXN0 ZXJlZCBhbmQgcmVyZWdpc3RlcmVkIHdpdGggYSBuZXcga2V5cGFpci4gVGhhdCdzIHJlYWxpc3Rp Y2FsbHkgbmV2ZXIgd2l0aCBjdXJyZW50IHRlY2hzLCBidXQgd2hvIGtub3dzPy4NCmh0dHBzOi8v d3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmMyNjE3Lmh0bWwgc2F5cyAiDQogICAgIFRoZSBjb250 ZW50cyBvZiB0aGUgbm9uY2UgYXJlIGltcGxlbWVudGF0aW9uIGRlcGVuZGVudC4gVGhlIHF1YWxp dHkNCiAgICAgb2YgdGhlIGltcGxlbWVudGF0aW9uIGRlcGVuZHMgb24gYSBnb29kIGNob2ljZS4g QSBub25jZSBtaWdodCwgZm9yDQogICAgIGV4YW1wbGUsIGJlIGNvbnN0cnVjdGVkIGFzIHRoZSBi YXNlIDY0IGVuY29kaW5nIG9mDQogICAgICAgICB0aW1lLXN0YW1wIEgodGltZS1zdGFtcCAiOiIg RVRhZyAiOiIgcHJpdmF0ZS1rZXkNCiINCg0KV2hhdCBkbyB5b3UgYWxsIHRoaW5rPw0KDQpQYXNj YWwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBFcmljIFZ5bmNrZSAo ZXZ5bmNrZSkgPGV2eW5ja2VAY2lzY28uY29tPg0KPiBTZW50OiBtZXJjcmVkaSAyOSBqYW52aWVy IDIwMjAgMTY6NDcNCj4gVG86IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgPHB0aHViZXJ0QGNp c2NvLmNvbT47IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KPiBDYzogZHJhZnQtaWV0Zi02bG8t YXAtbmRAaWV0Zi5vcmc7IFNod2V0aGEgQmhhbmRhcmkgKHNod2V0aGFiKQ0KPiA8c2h3ZXRoYWJA Y2lzY28uY29tPjsgNmxvLWNoYWlyc0BpZXRmLm9yZzsgNmxvQGlldGYub3JnOyBzZWNkaXJAaWV0 Zi5vcmcNCj4gU3ViamVjdDogUmU6IMOJcmljIFZ5bmNrZSdzIERpc2N1c3Mgb24gZHJhZnQtaWV0 Zi02bG8tYXAtbmQtMTM6ICh3aXRoIERJU0NVU1MgYW5kDQo+IENPTU1FTlQpDQo+IA0KPiBQYXNj YWwNCj4gDQo+IFRoYW5rIHlvdSBmb3IgeW91ciBwcm9tcHQgcmVwbHkuIEkgd2lsbCBjbGVhciBt eSBESVNDVVNTIGluIGEgbW9tZW50IGFzIHlvdQ0KPiB3aWxsIGNoYW5nZSB0aGUgdGV4dC4NCj4g DQo+IEFncmVlZCBvbiBhbGwgdGhlIHBvaW50cyBleGNlcHQgZm9yIHRoZSAnbm9uY2UnLiBJIGtu b3cgdGhlIGNvbmNlcHQgb2YgY291cnNlIGJ1dA0KPiB0aGUgc2VudGVuY2UgIndhcyBuZXZlciB1 c2VkIHdpdGggdGhpcyBkZXZpY2UiIGlzIHN0aWxsIHRvbyBzdHJvbmcgSU1ITy4gVG8NCj4gY29t cGx5LCBpdCB3b3VsZCByZXF1aXJlIHRvIGtlZXAgdGhlIGhpc3RvcnkgZm9yIGV2ZXIuLi4gSSB3 b3VsZCBwcmVmZXIgYSBsZXNzDQo+IHN0cmluZ2VudCB3b3JkaW5nLg0KPiANCj4gLcOpcmljDQo+ IA0KPiDvu79PbiAyOS8wMS8yMDIwLCAxNjozOCwgIlBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCki IDxwdGh1YmVydEBjaXNjby5jb20+DQo+IHdyb3RlOg0KPiANCj4gICAgIEhlbGxvIEVyaWMgOiAp DQo+IA0KPiAgICAgTWFueSB0aGFua3MgZm9yIHlvdXIgcmV2aWV3ISBJIGNjJ2VkIFNFQy1ESVIg YmVjYXVzZSB3ZSBjb3VsZCByZWFsbHkgdXNlDQo+IHRoZWlyIHJlY29tbWVuZGF0aW9uIHRvIHNv bHZlIHNvbWUgb2YgeW91ciBxdWVzdGlvbnMsIG1vcmUgYmVsb3cuDQo+IA0KPiAgICAgUGxlYXNl IHNlZSBiZWxvdzoNCj4gDQo+ICAgICA+ID09IERJU0NVU1MgPT0NCj4gICAgID4NCj4gICAgID4g LS0gU2VjdGlvbiA0LjQgLS0NCj4gICAgID4gVGhlIGxlbmd0aCBvZiB0aGUgcmVzZXJ2ZWQgZmll bGQgaXMgbm90IHNwZWNpZmllZC4gT3IgYW0gSSBtaXNzaW5nIHNvbWV0aGluZw0KPiAgICAgPiBv YnZpb3VzID8NCj4gDQo+ICAgICBJIGNvbmNhdGVuYXRlZCB0aGUgcmVzZXJ2ZWQgZmllbGRzIGlu IHRoZSBwaWN0dXJlIGFuZCBkZWNsYXJlZCBpdCBhcyA0MCBiaXRzLg0KPiAgICAgQWxzbyBhZGRl ZCB0aGUgbnVtYmVyIG9mIGJpdHMgaW4gdGhlIHJlc2VydmVkIGZpZWxkcyBvZiBvdGhlciBzdHJ1 Y3R1cmVzLg0KPiANCj4gICAgID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAgICAgPiBDT01NRU5UOg0KPiAg ICAgPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+ICAgICA+DQo+ICAgICA+ID09IENPTU1FTlRTID09DQo+ICAg ICA+DQo+ICAgICA+IC0tIFNlY3Rpb24gNC4yIC0tDQo+ICAgICA+IFdoaWxlIHN0YXR1cyBpcyBz ZXQgdG8gMCB3aGVuIHNlbmRpbmcgYSBOUywgd2hhdCBpcyB0aGUgZXhwZWN0ZWQgYmVoYXZpb3Ig b2YNCj4gYQ0KPiAgICAgPiByZWNlaXZlciA/DQo+IA0KPiAgICAgQ2hhbmdlZCB0bw0KPiAgICAg Ig0KPiAgICAgSW4gTlMgbWVzc2FnZXMgaXQgTVVTVCBiZSBzZXQgdG8gMCBieSB0aGUgc2VuZGVy IGFuZCBpZ25vcmVkIGJ5IHRoZSByZWNlaXZlci4NCj4gICAgICINCj4gDQo+ICAgICA+IC0tIFNl Y3Rpb24gNC4zIGFuZCA0LjQgLS0NCj4gICAgID4gV2h5IGlzIHRoZSBQYWQgTGVuZ3RoIGZpZWxk IGEgOC1iaXQgZmllbGQgd2hpbGUgdGhlIGFjdHVhbCBwYWRkaW5nIHdpbGwgYWx3YXlzDQo+IGJl DQo+ICAgICA+IGxlc3MgdGhhbiA4IGJ5dGVzLiBTdWdnZXN0IHRvIG1ha2UgaXQgYSAzIG9yIDQg Yml0cyBmaWVsZCBhbmQgZXh0ZW5kIHRoZQ0KPiByZXNlcnZlZA0KPiAgICAgPiBmaWVsZC4NCj4g DQo+ICAgICBBY3R1YWxseSBJIHRob3VnaHQgdGhhdCBpZiB3ZSB3YW50IHRvIGV4dGVuZCB0aGUg b3B0aW9uIGluIHRoZSBmdXR1cmUsIGl0IGlzDQo+IGJldHRlciB0byBpbmRpY2F0ZSB0aGUgbGVu Z3RoIG9mIHRoZSBwdWJsaWMga2V5IGFzIGZvbGxvd3M6DQo+IA0KPiAgICAgICAgfCAgICAgVHlw ZSAgICAgIHwgICAgTGVuZ3RoICAgICB8IFJlc2VydmVkfCAgUHVibGljIEtleSBMZW5ndGggIHwN Cj4gDQo+ICAgICBXaGVyZToNCj4gDQo+ICAgICBQdWJsaWMgS2V5IExlbmd0aDogMTMtYml0IHVu c2lnbmVkIGludGVnZXIuIFRoZSBsZW5ndGggb2YgdGhlIFB1YmxpYyBLZXkgZmllbGQgaW4NCj4g Ynl0ZXMuDQo+ICAgICBQdWJsaWMgS2V5OiAgQSB2YXJpYWJsZS1sZW5ndGggZmllbGQsIHNpemUg aW5kaWNhdGVkIGluIHRoZSBQdWJsaWMgS2V5IExlbmd0aCBmaWVsZC4NCj4gICAgICAgICAgICAJ ICAgICBKV0stRW5jb2RlZCBQdWJsaWMgS2V5IFtSRkM3NTE3XQ0KPiAgICAgPlBhZGRpbmc6ICBB IHZhcmlhYmxlLWxlbmd0aCBmaWVsZCBjb21wbGV0aW5nIHRoZSBQdWJsaWMgS2V5IGZpZWxkIHRv IGFsaWduIHRvDQo+IHRoZSBuZXh0IDgtYnl0ZXMgYm91bmRhcnkuDQo+IA0KPiANCj4gICAgIFdv cmtzPw0KPiANCj4gDQo+IA0KPiAgICAgPg0KPiAgICAgPiAtLSBTZWN0aW9uIDYuMSAtLQ0KPiAg ICAgPiBBYm91dCAiTm9uY2Ugb3B0aW9uIE1VU1QgY29udGFpbiBhIHJhbmRvbSBOb25jZSB2YWx1 ZSB0aGF0IHdhcyBuZXZlcg0KPiB1c2VkDQo+ICAgICA+IHdpdGggdGhpcyBkZXZpY2UiLCBob3cg Y2FuIGl0IGJlIGRvbmU/IEtlZXBpbmcgYSBsb2NhbCBoaXN0b3J5PyBHaXZpbmcgc29tZQ0KPiAg ICAgPiBvcGVyYXRpb25hbCBoaW50cyB3b3VsZCBiZWUgd2VsY29tZS4gRXNwZWNpYWxseSwgd2hl biB0aGVyZSBhcmUgbXVsdGlwbGUNCj4gNkxSIGluDQo+ICAgICA+IHRoZSBMTE46IGhvdyBjYW4g dGhleSBzeW5jaHJvbml6ZSB0aGUgbm9uY2U/DQo+IA0KPiAgICAgVGhlIG5vbmNlIGlzIHVzZWQg b25jZSwgc28gdGhlcmUncyBubyBzeW5jaHJvbml6YXRpb24uIEEgbmV3IHBhaXIgaXMgZm9ybWVk DQo+IGFuZCBleGNoYW5nZWQgYXQgZWFjaCB2YWxpZGF0aW9uLg0KPiANCj4gICAgIFRoZSBub25j ZSBnYW1lIHVzZWQgaGVyZSBhcHBlYXIgdG8gYmUgY29tbW9uIHByYWN0aWNlLiBZZXMsIHRoZXJl J3MgdXN1YWxseQ0KPiBhIG5lZWQgb2YgbG9jYWwgaGlzdG9yeSwgYW5kIHRoZSBmYWN0IHRoYXQg d2UgZ2V0IGEgbm9uY2UgZnJvbSBib3RoIHNpZGUsIGFwYXJ0DQo+IGZyb20gZ3VhcmFudGVlaW5n IHRoYXQgdGhlIHJlc3VsdCBpcyBlZmZlY3RpdmVseSB1bmlxdWUgdG8gYm90aCBwYXJ0aWVzLCBh bHNvDQo+IG1ha2VzIHRoZSBjaGFuY2VzIGZvciBoaXN0b3J5IHRvIHJlcGVhdCB2ZXJ5IGxvdy4N Cj4gDQo+ICAgICBDQydpbmcgU0VDLURJUjogUGxlYXNlIGhlbHA6IGlmIHRoZXJlIGlzIGEgcmVm ZXJlbmNlIGZvciB0aGF0IHByYWN0aWNlLCB3aGF0IGl0DQo+IHRha2VzIHRvIG1haW50YWluIGEg bm9uY2UsIGFuZCB3aHkgd2UgaGF2ZSBhIG5vbmNlIGZyb20gYm90aCBzaWRlcz8gVHJ5aW5nIHRv DQo+IHJlaW52ZW50IHRoYXQgdGV4dCBkb2VzIG5vdCBsb29rIGxpa2UgYSBnb29kIGlkZWEgZm9y IHRoaXMgZHJhZnQuDQo+IA0KPiANCj4gDQo+ICAgICA+DQo+ICAgICA+IC0tIFJlZmVyZW5jZXMg LS0NCj4gICAgID4gSXMgdGhlcmUgYSByZWFzb24gd2h5IHRoZSBjcnlwdG8gYWxnb3JpdGhtcyBS RkMgNzc0OCBhbmQgODAzMiBhcmUgbm90DQo+ICAgICA+IG5vcm1hdGl2ZT8NCj4gDQo+ICAgICBJ bnRlcmVzdGluZ2x5IHRoZXkgYXJlIGluZm9ybWF0aW9uYWwuIFNvIHRoYXQgd291bGQgYmUgYSBk b3ducmVmLg0KPiANCj4gICAgIENDJ2luZyBTRUMtRElSOiBQbGVhc2UgaGVscDogc2hvdWxkIHdl IG1ha2UgdGhlc2UgcmVmcyBub3JtYXRpdmU/DQo+IA0KPiANCj4gICAgID4NCj4gICAgID4gPT0g TklUUyA9PQ0KPiAgICAgPg0KPiAgICAgPiAtLSBTZWN0aW9uIDIuMiAtLQ0KPiAgICAgPiBUbyBi ZSBob25lc3QsIEkgYW0gbm90IGEgYmlnIGZhbiBvZiBzaW1wbHkgYW5ub3VuY2luZyBjb25jZXB0 cyBhbmQNCj4gcmVmZXJyaW5nIHRvDQo+ICAgICA+IG1hbnkgb3RoZXIgUkZDcy4gU3VnZ2VzdCB0 byBtZW50aW9uIHdoaWNoIHRlcm1zIGFuZCBjb25jZXB0cyBhcmUgZGVmaW5lZA0KPiBpbg0KPiAg ICAgPiBlYWNoIGRvY3VtZW50LiBFbHNlLCB0aGUgY3VycmVudCBzZWN0aW9uIDIuMiBtb3N0bHkg Zm9yY2VzIHRoZSByZWFkZXJzIHRvDQo+IHJlYWQNCj4gICAgID4gYWxsIHRoZSByZWZlcmVuY2Vz Lg0KPiANCj4gICAgIFllcyBhbmQgdGhleSBhcmUgcmVhbGx5IHRoZXJlIGFzIGFkZGl0aW9uYWwg cmVhZGluZywgbm90IG5vcm1hdGl2ZS4NCj4gICAgIEkgY2hhbmdlZCB0aGUgdGV4dCB0bw0KPiAg ICAgIiBUaGUgcmVhZGVyIG1heSBnZXQgYWRkaXRpb25hbCBjb250ZXh0IGZvciB0aGlzIHNwZWNp ZmljYXRpb24gZnJvbSB0aGUNCj4gZm9sbG93aW5nIHJlZmVyZW5jZXMiDQo+ICAgICBJIGFsc28g bW92ZWQgY2xhc3NpY2FsIE5EIGFuZCBTRU5EIHJlZmVyZW5jZXMgdG8gaW5mb3JtYXRpb25hbCBy ZWZlcmVuY2VzLg0KPiANCj4gICAgIFdvcmtzPw0KPiANCj4gICAgID4gLS0gU2VjdGlvbiA2IC0t DQo+ICAgICA+IHMvbWF5IHVzZSBhIHNhbWUgQ3J5cHRvLUlEL21heSB1c2UgdGhlIHNhbWUgQ3J5 cHRvLUlELyA/DQo+IA0KPiAgICAgRG9uZQ0KPiANCj4gICAgIE1hbnkgdGhhbmtzIGFnYWluIEVy aWMhDQo+IA0KPiAgICAgTGV0J3Mgc2VlIHdoYXQgU0VDLURJUiB0aGlua3MNCj4gDQo+ICAgICBB bmQgYSB2ZXJ5IGhhcHB5IG5ldyB5ZWFyIChpbiBGcmFuY2Ugd2UgaGF2ZSB0aWxsIEphbiAzMXN0 IHRvIHNlbmQgd2lzaGVzIPCfmIkpDQo+IA0KPiAgICAgUGFzY2FsDQo+IA0KPiANCj4gDQo+IA0K DQo= From nobody Wed Jan 29 10:11:30 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B46412004C; Wed, 29 Jan 2020 10:11:26 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 8sr5wYB7JQHi; Wed, 29 Jan 2020 10:11:23 -0800 (PST) Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2E0F120019; Wed, 29 Jan 2020 10:11:23 -0800 (PST) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id 00TI4IDp116160; Wed, 29 Jan 2020 18:11:21 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2019-08-05; bh=q10DjYfEbWXClvG/yTsxHf0dXG4ryu/hDCRwh2KJcwk=; b=T1WFaTqPalBuoGmS9R9EF+rXAKcpy96HNrAN/nLqJXij9X7BqZ39OEiM2IEpcpKIGS9N cKW+5NzWabTeIuqn4kuLj6XjC9B7oqzNVlM+s9Swsq4AtqWGnMC6xppC3gmWSFv8+Fvp KzuIEsZ8+Sh1wkmzbFBhBwwo6L64eHdDka4NXfApZovDo91rF357nk3B6yqm8WpHaOSu J+NxaojwyahGpiOZu/7JWdZBJOlrehFA3x1GgSIMi3aFiCibVmpDcA+2ABVkpashSARd E2v6BOGvn6Zd3zkMc1Ri/PPND2jFCQrc2Ne6AVYczmJqjbSoeRjPv37thNOz5+zJmBSO nQ== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by aserp2120.oracle.com with ESMTP id 2xrdmqq9h3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 29 Jan 2020 18:11:21 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id 00TI8q3W033176; Wed, 29 Jan 2020 18:11:21 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3030.oracle.com with ESMTP id 2xuc2x6s8x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 29 Jan 2020 18:11:21 +0000 Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 00TIBJUW020735; Wed, 29 Jan 2020 18:11:20 GMT Received: from anon-dhcp-152.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 29 Jan 2020 10:11:19 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Chuck Lever In-Reply-To: <80F557DD-BD17-4119-98B9-614B7A9FDDFB@oracle.com> Date: Wed, 29 Jan 2020 13:11:18 -0500 Cc: secdir@ietf.org, last-call@ietf.org, nfsv4@ietf.org, draft-ietf-nfsv4-rpcrdma-cm-pvt-data.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <14AED4E4-E166-4760-8F8D-9DB1CAB5ECD0@oracle.com> References: <158007038921.30641.13334124837519126164@ietfa.amsl.com> <80F557DD-BD17-4119-98B9-614B7A9FDDFB@oracle.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.3445.104.11) X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9514 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2001290147 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9514 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2001290146 Archived-At: Subject: Re: [secdir] [nfsv4] Secdir last call review of draft-ietf-nfsv4-rpcrdma-cm-pvt-data-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 18:11:26 -0000 Following up... > On Jan 27, 2020, at 10:01 AM, Chuck Lever = wrote: >=20 > Hello Yaron- >=20 > Thanks for your review and comments. I will respond to your comments > below, then we can determine how to clarify the text to improve = matters. >=20 >=20 >> On Jan 26, 2020, at 3:26 PM, Yaron Sheffer via Datatracker = wrote: >>=20 >> Reviewer: Yaron Sheffer >> Review result: Has Issues >>=20 >> The document defines limited parameter negotiation for RPC-RDMAv1, = using a >> private message sent over the underlying transport protocol (e.g., = InfiniBand). >>=20 >> The document is clear enough, until it comes to the Security = Considerations. As >> a newcomer to this domain, there are several points that I fail to = understand: >>=20 >> - The CM Private Data described here is not one of the messages of = the RPC-RDMA >> protocol. So how can it "inherit the security considerations of the = protocols >> it extends," - where this refers to RPC-RDMA? >=20 > The private data is conveyed on the same transport connection as the > other messages in RPC-over-RDMA. The exchange of private data is part > of the connection handshake, and does not appear after the connection > is established. >=20 > The intended purpose of this paragraph is introductory, referring the > reader to the Security Considerations section of RFC 8166 as = background > material. >=20 >=20 >> - The next paragraph explains that the integrity is ensured by use of = RC QP >> (whatever that is). But there's no mention of this entity in RFC = 8166, which is >> supposed to define the security for this protocol. (Or in RFC 5042, = for that >> matter). >=20 > That does seem to be an omission of background material in these = documents. >=20 > The queue pair (QP) type used for RPC-over-RDMA is Reliable Connected = (RC). > This is part of the RDMA Verbs API, thus it is not defined in any > published IETF document. >=20 > However, a relevant definition can be found in Section 9.7.7 of >=20 > InfiniBand Trade Association, "InfiniBand Architecture Specification = Volume > 1", Release 1.3, March 2015. Available from = https://www.infinibandta.org/ >=20 > Section 8.1.1 of RFC 8166 discusses one aspect of Reliable Connected = behavior > but does not provide an adequate citation. The document as a whole = does not > make a specific compliance statement about the use of RC QPs. > draft-ietf-nfsv4-rpcrdma-version-two rectifies that omission. >=20 > However, the protocol framework depends on the semantics of RC QPs, = thus > RPC-over-RDMA version one implementations to date use only the RC QP = type. > That makes it rather a de facto requirement up to this point. To address the above two comments, I've updated the Security = Considerations section to read: 6. Security Considerations The Private Data extension specified in the current document inherits the security considerations of RPC-over-RDMA version one [RFC8166]. The reader is directed to the Security Considerations section of that document for further discussion. Additional analysis of RDMA transport security appears in the Security Considerations section of [RFC5042]. Improperly setting one of the fields in a version 1 Private Message can result in an increased risk of disconnection (i.e., self-imposed Denial of Service). There is no additional risk of exposing upper- layer payloads. >> - I am usually suspicious of pre-2010 RFCs that recommend IPsec as a >> per-protocol solution (RFC 5042, Sec. 5.4.3). Is IPsec deployed in = real life to >> protect these protocols, and if so, does it also protect the new CM = Private >> Data? >=20 > IPsec is appropriate for iWARP (defined in the RFC 504x series), as = iWARP > can operate on public untrusted networks. Typically IPsec is = implemented > along side iWARP in NIC hardware, and thus is relatively transparent = to > the host (aside from initial configuration). >=20 > When deployed, IPsec would establish a protected channel before iWARP > operations are exchanged, and thus would protect the exchange of = private > data that occurs as each QP connection is established. >=20 > IPsec is not used for InfiniBand or RoCE. Deployment of these fabrics = is > typically in monolithic security environments. I'm not clear whether this issue is in the scope of cm-pvt-data. >> - And then after saying that integrity protection is ensured, we say = that even >> if integrity was compromised and the parameters were modified anyway, = no >> problem, this would only result in "self imposed denial of service". = Even if >> true for the currently negotiated parameters, this cannot be true for = every >> conceivable parameter that may be added in the future. >=20 > That's correct. >=20 > Practically speaking, even though we made this private data mechanism > extensible, we are already busy creating an RPC-over-RDMA version two, > where the same exchange is done via RPC-over-RDMA messages rather than > via CM Private Data. It's not likely that cm-pvt-data itself will ever > be extended. To address this comment, I've added a paragraph to the end of Section 5 "Updating the Message Format": In addition to describing the structure of a new format version, any document that extends the Private Data format described in the current document must discuss security considerations of new items exchanged between connection peers. -- Chuck Lever From nobody Wed Jan 29 13:01:31 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D91120045; Wed, 29 Jan 2020 13:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 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, MALFORMED_FREEMAIL=1.152, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 hwXgf6ccGsz8; Wed, 29 Jan 2020 13:01:17 -0800 (PST) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 EE47D120024; Wed, 29 Jan 2020 13:01:16 -0800 (PST) Received: by mail-wm1-x32c.google.com with SMTP id p17so1580278wma.1; Wed, 29 Jan 2020 13:01:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=nsnUM8zpuqjxHLncNdMCPxhBCeJ9v/ZqJFagoslDOsk=; b=VrC+E9E1plI3Q2S6l10dB9CzHN54byeoMSbJpXFmRZ4/sZNx6G1QaR7Hfr1mhJVVmD Bjtv7QsOTNugF9Mbocwm+aEQjfzQ/isaQi0I6kV36uH6Jk6Js7ZJX1TnIl32Zri3t0yB NBNwnulw5IPOYNUPpyI2xAWwZ8/9QkfNUjgSWkg8ZTkcOY7ueZptaWBVJyy5m13k5LcX U0yYhF2F5DZlBGElCytngRXEb1diC+9BCTW63+CAHYpuD7YJNdsimd3cNn68tXyGKJfw HEdLgi5raZCr0xnTcDz2ht6PGSFpkh9/8pc/eSMxwCO+UTfHRik67oiTBGqGli7SQuuc oTxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=nsnUM8zpuqjxHLncNdMCPxhBCeJ9v/ZqJFagoslDOsk=; b=H5+AR3258sur0h/6cc4cV4LuWOe0PjqlUN6Z+U3nnc4KTfDlx5JDz5KpTyms/h6cmu SUx+SnMZv/DLzFP/UiD2LKYexLAwRkI1ifbFWE5UR3EuE2yyyhGMF9VeCo/BFWV85jCJ OjR9sXzSiqMIh022QQh+Bd0dSUqUHMwq0qxER/qMzWKf1AnzZSj+B+dwRGrC+ClXzJLg 6fPT64swTm318REoq/Bc/1RcADBq2BKJwG6wPwrGQXEUlghn8lIUyf28JLq9vo7hUGMo 6UMWrqArb0hq8fguv/bHDhu8oI2qa2zoJI1U3rem8OM6tW5yMOKGZp17yX2wdfV5NFAJ 3vsw== X-Gm-Message-State: APjAAAUZLH8HMnJNwHLw8dU6Mho05mpZwXKiujX5jdPEl57A4pr3YMvW Vp5KJWS20l7dj9QpGqAFAdiElZXD X-Google-Smtp-Source: APXvYqzZfxWKZF1jVrJ91qmSz889OVUm5tAYFg8BDoAWgxiCoCaGLt3C0gbKNnoEAUR2AWbxfWJ+LQ== X-Received: by 2002:a05:600c:2409:: with SMTP id 9mr1076414wmp.109.1580331674848; Wed, 29 Jan 2020 13:01:14 -0800 (PST) Received: from [10.0.0.141] (bzq-109-65-61-207.red.bezeqint.net. [109.65.61.207]) by smtp.gmail.com with ESMTPSA id 5sm191413wrc.75.2020.01.29.13.01.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Jan 2020 13:01:13 -0800 (PST) User-Agent: Microsoft-MacOutlook/10.21.0.200113 Date: Wed, 29 Jan 2020 23:01:12 +0200 From: Yaron Sheffer To: Chuck Lever CC: , , , Message-ID: <85F5B476-8720-488B-9262-CBA9B322BFD3@gmail.com> Thread-Topic: [nfsv4] Secdir last call review of draft-ietf-nfsv4-rpcrdma-cm-pvt-data-06 References: <158007038921.30641.13334124837519126164@ietfa.amsl.com> <80F557DD-BD17-4119-98B9-614B7A9FDDFB@oracle.com> In-Reply-To: <80F557DD-BD17-4119-98B9-614B7A9FDDFB@oracle.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [secdir] [nfsv4] Secdir last call review of draft-ietf-nfsv4-rpcrdma-cm-pvt-data-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 21:01:20 -0000 Hi Chuck, Please see below. Sorry for the delay. Thanks, Yaron =EF=BB=BFOn 1/27/20, 17:01, "Chuck Lever" wrote: Hello Yaron- =20 Thanks for your review and comments. I will respond to your comments below, then we can determine how to clarify the text to improve matters= . =20 =20 > On Jan 26, 2020, at 3:26 PM, Yaron Sheffer via Datatracker wrote: >=20 > Reviewer: Yaron Sheffer > Review result: Has Issues >=20 > The document defines limited parameter negotiation for RPC-RDMAv1, us= ing a > private message sent over the underlying transport protocol (e.g., In= finiBand). >=20 > The document is clear enough, until it comes to the Security Consider= ations. As > a newcomer to this domain, there are several points that I fail to un= derstand: >=20 > - The CM Private Data described here is not one of the messages of th= e RPC-RDMA > protocol. So how can it "inherit the security considerations of the p= rotocols > it extends," - where this refers to RPC-RDMA? =20 The private data is conveyed on the same transport connection as the other messages in RPC-over-RDMA. The exchange of private data is part of the connection handshake, and does not appear after the connection is established. =20 The intended purpose of this paragraph is introductory, referring the reader to the Security Considerations section of RFC 8166 as background material. YS: but "inherits the security considerations" is more specific than merely= referring the reader to the RFC. I suggest to reword. =20 =20 > - The next paragraph explains that the integrity is ensured by use of= RC QP > (whatever that is). But there's no mention of this entity in RFC 8166= , which is > supposed to define the security for this protocol. (Or in RFC 5042, f= or that > matter). =20 That does seem to be an omission of background material in these docume= nts. =20 The queue pair (QP) type used for RPC-over-RDMA is Reliable Connected (= RC). This is part of the RDMA Verbs API, thus it is not defined in any published IETF document. =20 However, a relevant definition can be found in Section 9.7.7 of =20 InfiniBand Trade Association, "InfiniBand Architecture Specification Vo= lume 1", Release 1.3, March 2015. Available from https://www.infinibandta.or= g/ =20 Section 8.1.1 of RFC 8166 discusses one aspect of Reliable Connected be= havior but does not provide an adequate citation. The document as a whole does= not make a specific compliance statement about the use of RC QPs. draft-ietf-nfsv4-rpcrdma-version-two rectifies that omission. =20 However, the protocol framework depends on the semantics of RC QPs, thu= s RPC-over-RDMA version one implementations to date use only the RC QP ty= pe. That makes it rather a de facto requirement up to this point. YS: so we can say this is de facto required and include the citation. =20 =20 > - I am usually suspicious of pre-2010 RFCs that recommend IPsec as a > per-protocol solution (RFC 5042, Sec. 5.4.3). Is IPsec deployed in re= al life to > protect these protocols, and if so, does it also protect the new CM P= rivate > Data? =20 IPsec is appropriate for iWARP (defined in the RFC 504x series), as iWA= RP can operate on public untrusted networks. Typically IPsec is implemente= d along side iWARP in NIC hardware, and thus is relatively transparent to the host (aside from initial configuration). =20 When deployed, IPsec would establish a protected channel before iWARP operations are exchanged, and thus would protect the exchange of privat= e data that occurs as each QP connection is established. =20 IPsec is not used for InfiniBand or RoCE. Deployment of these fabrics i= s typically in monolithic security environments. YS: so please mention that, something like: RFC 5042 recommends IPsec as th= e default security solution, however for the InfiniBand and RoCE use cases, = typically no transport-level security protocol is implemented. =20 =20 > - And then after saying that integrity protection is ensured, we say = that even > if integrity was compromised and the parameters were modified anyway,= no > problem, this would only result in "self imposed denial of service". = Even if > true for the currently negotiated parameters, this cannot be true for= every > conceivable parameter that may be added in the future. =20 That's correct. =20 Practically speaking, even though we made this private data mechanism extensible, we are already busy creating an RPC-over-RDMA version two, where the same exchange is done via RPC-over-RDMA messages rather than via CM Private Data. It's not likely that cm-pvt-data itself will ever be extended. YS: I am an outsider to this community, but my own experience is that it's = very difficult to predict these things. So we should maybe qualify this stat= ement by saying it only refers to the data fields defined here, and not to a= ny potential future extensions. =20 =20 -- Chuck Lever =20 =20 =20 =20 From nobody Wed Jan 29 15:21:48 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E01A81208A0; Wed, 29 Jan 2020 12:26:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1580329587; bh=4Rr7j+bQgjSF360/HH3R10SrmBdEgUyZOKYsxWvkePk=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=F36Xb3hbNhvMXMWdjl8r2QKQslkZEgpo0K6z6rlk1wKqYYPiELyTR3BLBi1pB4LyE nrI2lpqleh2HXfNGt/fp8cLfC2MkWruAeDjVB0oLan4JvtEFktrjrIsJE1LpAYqkPo CvkbklOoqvgcKMU9sx1fJue0lrWj+fA3U7jUabaY= X-Mailbox-Line: From new-work-bounces@ietf.org Wed Jan 29 12:26:24 2020 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51AFD120895; Wed, 29 Jan 2020 12:26:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1580329579; bh=4Rr7j+bQgjSF360/HH3R10SrmBdEgUyZOKYsxWvkePk=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=bJSFU47YVSOfUi/Rx2an4KF4sY6jSbKH5BvdngbwOPT9g0g8lwpVXW6jVjVxqlnBg WxjICoqWHQ/aG7TqXrGi2s08VdwQwRnYTFXvFlXDwknbjjH1pzHBeJZXX1tNeNTXpT g3JL733CEQWjEGwlRg6WUjTDZVyHijzizIawfNWg= 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 0E22F120077 for ; Wed, 29 Jan 2020 12:26:11 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply_to: MIME-Version: 1.0 Message-ID: <158032957104.2765.11151186848152934515.idtracker@ietfa.amsl.com> Date: Wed, 29 Jan 2020 12:26:11 -0800 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Wed, 29 Jan 2020 15:21:47 -0800 Subject: [secdir] [new-work] WG Review: Reliable and Available Wireless (raw) 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, 29 Jan 2020 20:26:32 -0000 QSBuZXcgSUVURiBXRyBoYXMgYmVlbiBwcm9wb3NlZCBpbiB0aGUgUm91dGluZyBBcmVhLiBUaGUg SUVTRyBoYXMgbm90IG1hZGUKYW55IGRldGVybWluYXRpb24geWV0LiBUaGUgZm9sbG93aW5nIGRy YWZ0IGNoYXJ0ZXIgd2FzIHN1Ym1pdHRlZCwgYW5kIGlzCnByb3ZpZGVkIGZvciBpbmZvcm1hdGlv bmFsIHB1cnBvc2VzIG9ubHkuIFBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlCklFU0cg bWFpbGluZyBsaXN0IChpZXNnQGlldGYub3JnKSBieSAyMDIwLTAyLTA1LgoKUmVsaWFibGUgYW5k IEF2YWlsYWJsZSBXaXJlbGVzcyAocmF3KQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpDdXJyZW50IHN0YXR1czog UHJvcG9zZWQgV0cKCkNoYWlyczoKICBUQkQKCkFzc2lnbmVkIEFyZWEgRGlyZWN0b3I6CiAgRGVi b3JhaCBCcnVuZ2FyZCA8ZGIzNTQ2QGF0dC5jb20+CgpSb3V0aW5nIEFyZWEgRGlyZWN0b3JzOgog IEFsdmFybyBSZXRhbmEgPGFyZXRhbmEuaWV0ZkBnbWFpbC5jb20+CiAgRGVib3JhaCBCcnVuZ2Fy ZCA8ZGIzNTQ2QGF0dC5jb20+CiAgTWFydGluIFZpZ291cmV1eCA8bWFydGluLnZpZ291cmV1eEBu b2tpYS5jb20+CgpNYWlsaW5nIGxpc3Q6CiAgQWRkcmVzczogcmF3QGlldGYub3JnCiAgVG8gc3Vi c2NyaWJlOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JhdwogIEFyY2hp dmU6IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9icm93c2UvcmF3LwoKR3JvdXAg cGFnZTogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9ncm91cC9yYXcvCgpDaGFydGVyOiBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9jaGFydGVyLWlldGYtcmF3LwoKUmVsaWFi bGUgYW5kIEF2YWlsYWJsZSBXaXJlbGVzcyAoUkFXKSBwcm92aWRlcyBmb3IgaGlnaCByZWxpYWJp bGl0eSBhbmQKYXZhaWxhYmlsaXR5IGZvciBJUCBjb25uZWN0aXZpdHkgb3ZlciBhIHdpcmVsZXNz IG1lZGl1bS4gVGhlIHdpcmVsZXNzIG1lZGl1bQpwcmVzZW50cyBzaWduaWZpY2FudCBjaGFsbGVu Z2VzIHRvIGFjaGlldmUgZGV0ZXJtaW5pc3RpYyBwcm9wZXJ0aWVzIHN1Y2ggYXMKbG93IHBhY2tl dCBlcnJvciByYXRlLCBib3VuZGVkIGNvbnNlY3V0aXZlIGxvc3NlcywgYW5kIGJvdW5kZWQgbGF0 ZW5jeS4gUkFXCmV4dGVuZHMgdGhlIERldE5ldCBXb3JraW5nIEdyb3VwIGNvbmNlcHRzIHRvIHBy b3ZpZGUgZm9yIGhpZ2ggcmVsaWFiaWxpdHkgYW5kCmF2YWlsYWJpbGl0eSBmb3IgYW4gSVAgbmV0 d29yayB1dGlsaXppbmcgc2NoZWR1bGVkIHdpcmVsZXNzIHNlZ21lbnRzIGFuZApvdGhlciBtZWRp YSwgZS5nLiwgZnJlcXVlbmN5L3RpbWUtc2hhcmluZyBwaHlzaWNhbCBtZWRpYSByZXNvdXJjZXMg d2l0aApzdG9jaGFzdGljIHRyYWZmaWM6IElFRUUgU3RkLiA4MDIuMTUuNCB0aW1lc2xvdHRlZCBj aGFubmVsIGhvcHBpbmcgKFRTQ0gpLAozR1BQIDVHIHVsdHJhLXJlbGlhYmxlIGxvdyBsYXRlbmN5 IGNvbW11bmljYXRpb25zIChVUkxMQyksIElFRUUgODAyLjExYXgvYmUsCmFuZCBMLWJhbmQgRGln aXRhbCBBZXJvbmF1dGljYWwgQ29tbXVuaWNhdGlvbnMgU3lzdGVtIChMREFDUyksIGV0Yy4gU2lt aWxhcgp0byBEZXROZXQsIFJBVyB3aWxsIHN0YXkgYWJzdHJhY3QgdG8gdGhlIHJhZGlvIGxheWVy cyB1bmRlcm5lYXRoLCBhZGRyZXNzaW5nCnRoZSBMYXllciAzIGFzcGVjdHMgaW4gc3VwcG9ydCBv ZiBhcHBsaWNhdGlvbnMgcmVxdWlyaW5nIGhpZ2ggcmVsaWFiaWxpdHkgYW5kCmF2YWlsYWJpbGl0 eS4KCldoaWxlIERldE5ldCBzb2x1dGlvbnMgYXBwbHkgdG8gYm90aCB3aXJlbGVzcyBhbmQgd2ly ZWQsIHRoZXJlIGhhcyBiZWVuCnJlY2VudCBpbmR1c3RyeSBpbnRlcmVzdCBmb3Igd2lyZWxlc3Mg YXBwbGljYXRpb25zIHdoaWNoIHdlcmUgbm90IGluaXRpYWxseQppbmNsdWRlZCBpbiB0aGUgRGV0 TmV0IHVzZSBjYXNlcy4gT25lIGNyaXRpY2FsIGFwcGxpY2F0aW9uIGlzIEFlcm9uYXV0aWNhbApE YXRhIENvbW11bmljYXRpb25zLiBUaGUgQWVyb25hdXRpY2FsIHN0YW5kYXJkcyB3b3JrIG9uIGEg cGh5c2ljYWwgbGF5ZXIgYW5kCmRhdGEgbGluayBsYXllciBmb3IgZGF0YSBjb21tdW5pY2F0aW9u cyBpcyByZWFjaGluZyBtYXR1cml0eSBhbmQgdGhlcmUgaXMKc2lnbmlmaWNhbnQgaW50ZXJlc3Qg aW4gSVAgY29ubmVjdGl2aXR5IGFwcGxpY2F0aW9ucy4KCkluIHRoZSBpbnRlcmVzdHMgb2YgcHJv dmlkaW5nIHRpbWVseSBzb2x1dGlvbnMgZm9yIHRoZXNlIG5ld2x5IGlkZW50aWZpZWQKaW5kdXN0 cnkgYXBwbGljYXRpb25zLCBSQVfigJlzIGZvY3VzIHdpbGwgYmUgb24gaWRlbnRpZnlpbmcgdXNl IGNhc2VzIGFuZApyZXF1aXJlbWVudHMgZm9yIHRoZXNlIG5ldyBhcHBsaWNhdGlvbnMuIFJBVyB3 aWxsIHNvbGljaXQgaW5wdXQgb24gZGVwbG95bWVudApwbGFucywgcmVxdWlyZW1lbnRzLCBhbmQg b3BlcmF0aW9uYWwgcHJhY3RpY2VzIChpbmNsdWRpbmcgc2VjdXJpdHkgYW5kCnByaXZhY3kgYXNw ZWN0cykgZm9yIHRoZXNlIG5ld2VyIGluZHVzdHJpYWwgYXBwbGljYXRpb25zLiBSQVfigJlzIHBy aW1hcnkgZm9jdXMKaXMgb24gaWRlbnRpZnlpbmcgYXJlYXMgd2hlcmUgdGhlIERldE5ldCBhZGFw dGF0aW9uIHRvIHdpcmVsZXNzIG5ldHdvcmtzIGFuZApvdGhlciBJRVRGIHRvb2xzIG1heSByZXF1 aXJlIGFkZGl0aW9uYWwgc3VwcG9ydGluZyBtZWNoYW5pc21zLgoKVGhlIFJBVyBXb3JraW5nIEdy b3VwIHdpbGwgYWxzbyBleGFtaW5lIHRoZSBhcHBsaWNhYmlsaXR5IG9mIG90aGVyIGV4aXN0aW5n CklFVEYgd29yaywgZS5nLiwgTUFORVQncyBkeW5hbWljIGxpbmsgZXhjaGFuZ2UgcHJvdG9jb2wg KERMRVApLiBUaGUgUkFXCldvcmtpbmcgR3JvdXAgd2lsbCBwcm92aWRlIGlucHV0IHRvIHRoZSBE ZXROZXQgV29ya2luZyBHcm91cCwgTUFORVQgV29ya2luZwpHcm91cCwgYW5kIG90aGVyIElFVEYg V29ya2luZyBHcm91cHMsIGFuZCBjb29wZXJhdGUgaW4gcmV2aWV3aW5nIHNvbHV0aW9ucyB0bwpS QVfigJlzIGlkZW50aWZpZWQgZGVwbG95bWVudCBwcm9ibGVtcy4gUkFXIGlzIG5vdCBjaGFydGVy ZWQgdG8gd29yayBvbiBhCnNvbHV0aW9uLiBJZiBzb2x1dGlvbiB3b3JrIGlzIG5lZWRlZCwgaXQg d2lsbCBiZSBjb29yZGluYXRlZCBvbiB3aGVyZSB0aGUKd29yayB3aWxsIGJlIGRvbmUuIElmIFJB VyBpcyBjaG9zZW4gZm9yIHRoZSBzb2x1dGlvbiB3b3JrLCB0aGUgV29ya2luZyBHcm91cAp3aWxs IHJlY2hhcnRlci4KClRoZSBSQVcgV29ya2luZyBHcm91cCBpcyBwbGFubmVkIHRvIGJlIGEgc2hv cnQgdGltZWZyYW1lICgxMi0xOCBtb250aHMpCldvcmtpbmcgR3JvdXAgdG8gcXVpY2tseSBhZGRy ZXNzIHRoZXNlIG5ld2VyIGluZHVzdHJ5IGFwcGxpY2F0aW9ucy4gVGhlCmluaXRpYWwgbWlsZXN0 b25lcyB3aWxsIGJlIHB1Ymxpc2hlZCBhcyBJbmZvcm1hdGlvbmFsIGRvY3VtZW50czogVXNlIENh c2VzLApSZXF1aXJlbWVudHMsIEFyY2hpdGVjdHVyZS9GcmFtZXdvcmsgQXNwZWN0cyBmb3IgYSBX aXJlbGVzcyBOZXR3b3JrLCBhbmQgYW4KRXZhbHVhdGlvbiBvZiBFeGlzdGluZyBJRVRGIFRvb2xz IGFuZCBHYXAgQW5hbHlzaXMuIEFkZGl0aW9uYWwgZG9jdW1lbnRzIG1heQpiZSBwdWJsaXNoZWQg b3IgZXhpc3Qgb24gYSBnaXQgcmVwb3NpdG9yeSwgdGhlIHB1YmxpY2F0aW9uIGZvcm1hdCB3aWxs IGJlCmFncmVlZCBieSB0aGUgV29ya2luZyBHcm91cCBhdCB0aGUgdGltZSB0aGUgZG9jdW1lbnQg aXMgYWRvcHRlZCBieSB0aGUgZ3JvdXAuClRoZSBVc2UgQ2FzZSBkb2N1bWVudCBtYXkgY29uc2lz dCBvZiBvbmUgb3IgbW9yZSBkb2N1bWVudHMgdG8gYWxsb3cKdXNlcnMvb3BlcmF0b3JzIHRoZSBv cHBvcnR1bml0eSB0byBwcm92aWRlIGNvbXByZWhlbnNpdmUgZGVwbG95bWVudCBwbGFucyBmb3IK dGhlc2UgbmV3ICh0byBJRVRGKSB0ZWNobm9sb2dpZXMsIGUuZy4sIHRoZSBBZXJvbmF1dGljYWwg RGF0YSBDb21tdW5pY2F0aW9uCmFwcGxpY2F0aW9ucy4gVGhlIGdyb3VwIHdpbGwgY2xvc2VseSBj b29yZGluYXRlIHdpdGggdGhlIERldE5ldCBhbmQgTUFORVQKV29ya2luZyBHcm91cHMuIFRoZSB3 b3JrIHByb2R1Y2VkIGJ5IHRoaXMgZ3JvdXAgbWF5IGJlIG9mIGludGVyZXN0IHRvIG90aGVyClNE T3MsIDNHUFAsIElFRUUsIGFuZCB0aGUgQWVyb25hdXRpY2FsIGluZHVzdHJ5LgoKTWlsZXN0b25l czoKClRCRAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K bmV3LXdvcmsgbWFpbGluZyBsaXN0Cm5ldy13b3JrQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV3LXdvcmsK From nobody Thu Jan 30 04:30:47 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D20D6120115 for ; Thu, 30 Jan 2020 04:30:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <158038744585.10307.2590544270922527205.idtracker@ietfa.amsl.com> Date: Thu, 30 Jan 2020 04:30:45 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 12:30:46 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2020-02-06 Reviewer LC end Draft Roman Danyliw 2019-11-12 draft-ietf-dtn-bpbis-20 Russ Mundy 2020-01-02 draft-ietf-dprive-bcp-op-08 Last calls: Reviewer LC end Draft Shaun Cooley 2019-11-12 draft-ietf-regext-login-security-07 Roman Danyliw 2019-11-12 draft-ietf-dtn-bpbis-20 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-08 Aanchal Malhotra 2019-12-23 draft-ietf-pce-stateful-flags-01 Russ Mundy 2020-01-02 draft-ietf-dprive-bcp-op-08 Sandra Murphy 2019-10-04 draft-ietf-mpls-ldp-yang-06 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-09 Radia Perlman 2020-01-31 draft-ietf-uta-tls-for-email-04 Derrell Piper 2020-01-31 draft-ietf-6lo-minimal-fragment-08 Tirumaleswar Reddy.K 2020-01-30 draft-ietf-6lo-fragment-recovery-08 Kyle Rose 2020-01-29 draft-ietf-emu-rfc5448bis-06 Rich Salz 2020-02-21 draft-halpern-gendispatch-consensusinformational-02 Stefan Santesson 2020-01-27 draft-ietf-dots-architecture-16 Yaron Sheffer 2020-02-12 draft-ietf-dnssd-prireq-04 Rifaat Shekh-Yusef 2020-02-06 draft-ietf-mmusic-t140-usage-data-channel-11 Melinda Shore 2020-02-06 draft-ietf-6lo-backbone-router-13 Takeshi Takahashi 2019-11-04 draft-ietf-netmod-yang-data-ext-05 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Next in the reviewer rotation: Joseph Salowey Rich Salz Stefan Santesson Yaron Sheffer Rifaat Shekh-Yusef Melinda Shore Valery Smyslov Robert Sparks Takeshi Takahashi Tina Tsou From nobody Thu Jan 30 04:34:11 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4B7120125 for ; Thu, 30 Jan 2020 04:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlmXXqTdiiDj for ; Thu, 30 Jan 2020 04:34:08 -0800 (PST) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [212.16.98.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12ECC120115 for ; Thu, 30 Jan 2020 04:34:08 -0800 (PST) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 83EF01B0028C; Thu, 30 Jan 2020 14:34:04 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1580387644; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=D5ti3k4qUDRzRh/VeHwsWghyvZ8vp6mZ0VThvFHr5jM=; b=eSpyyBmwZyAjFcfxdRlYQMW86bIfUcMXJvLYowkv5CxljJTCbHERLah12HfnYnWo1UOsZM FIKYmJQ6e7M1/+JBsu3FO5jsnaMD4oXCCf/Rx5vxDqmoitSwp/MzY/02Tf4ttJya8wojAL zqWdLgMkeR5IXSjQmDDwEHz+lVGZQH9OdWFxwI6xOMC6tGJYKokSWQU/40HpfzUcPf8CNb XpU2yvEioGOp4+9RovK/axTSGKchRXAT0IuNUwOJGet2nusfV3WtD3PH5a07yoWfMKKHNx /gmj5u/8dIpxTyTq9bgVOH5ue7cfeWUZf+v+Ry2NXa2Q2oHvhbBNCyfhGQQFTw== Received: by fireball.acr.fi (Postfix, from userid 15204) id 99AF825C1368; Thu, 30 Jan 2020 14:34:03 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24114.52539.601466.797810@fireball.acr.fi> Date: Thu, 30 Jan 2020 14:34:03 +0200 From: Tero Kivinen To: Cc: secdir-secretary@mit.edu In-Reply-To: <158038744585.10307.2590544270922527205.idtracker@ietfa.amsl.com> References: <158038744585.10307.2590544270922527205.idtracker@ietfa.amsl.com> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 0 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1580387644; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=D5ti3k4qUDRzRh/VeHwsWghyvZ8vp6mZ0VThvFHr5jM=; b=KBYJclLgrjid/HK7bVoy0p5L9ppIeO6vtm+hZrUvi+5cLX/hWY+Senp5dml7tdWpchsu/7 +yC/xNgOUXYytk4ak3n0f3JMnun66Hybv4nNy2JtUSPltwiX/g6Gg1r0jtPygJyFfNpEgu fpb3PUAvg+l6X45VO2Wda56h9D+0ifaZtAd+kYsIPScT7KTRe5aTrbQ+jIX6Jr9a+0ApMr +FpuXEd5m+ErtM/q7MwHkIA8hgGgVh0UTNWfEkoHt7/0UpMzK4ujeL0YQRTr/0XgqEpc3V 11YDVKa0yxZKK5xEPbbP5ukPD/nvgdxQVvVKPk6ZC1un9cyzZ7rXE3a6pPTJ7w== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1580387644; a=rsa-sha256; cv=none; b=kudwXDNOeKte9zsz+hxwKdBxHxPj/O4eWhKtJNQ5XDhIioaeaqZ0THYrlKyPRSAASFOvaG /JfqabAor8mM4y1Mnc334YnnjP2L/kb4MP/HU7sHXuKg6GxujXtjqv+HaK5pFmZC733oj9 PHiv8BsyAUhQNcDOkeS5DSd3B4Wz25agKKO3dCEeqU9RX7bYPoZyWcr9JmXi4sRmmcD66d 1NHQuSl5b+hhVZFPE6tEN8mmeYQXNrIgwRc3zCiNvVb/N7Kv/S8p/TK6vWQrSsXDb8WaVe 6ZPJK1bIpaOM1YVNqxlvZwxNi87EZrRJo+lCd8+7Y1vV0v2Mzj8XDCwDFMu4gg== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 12:34:10 -0000 Ignore this assignment. The datatracker is again stuck in rotation, I do not know why, but I will withdraw these assignments, and redo them. Tero Kivinen via Datatracker writes: > Review instructions and related resources are at: > http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > For telechat 2020-02-06 > > Reviewer LC end Draft > Roman Danyliw 2019-11-12 draft-ietf-dtn-bpbis-20 > Russ Mundy 2020-01-02 draft-ietf-dprive-bcp-op-08 > > Last calls: > > Reviewer LC end Draft > Shaun Cooley 2019-11-12 draft-ietf-regext-login-security-07 > Roman Danyliw 2019-11-12 draft-ietf-dtn-bpbis-20 > Alan DeKok 2019-06-04 draft-ietf-netvc-testing-08 > Aanchal Malhotra 2019-12-23 draft-ietf-pce-stateful-flags-01 > Russ Mundy 2020-01-02 draft-ietf-dprive-bcp-op-08 > Sandra Murphy 2019-10-04 draft-ietf-mpls-ldp-yang-06 > Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-09 > Radia Perlman 2020-01-31 draft-ietf-uta-tls-for-email-04 > Derrell Piper 2020-01-31 draft-ietf-6lo-minimal-fragment-08 > Tirumaleswar Reddy.K 2020-01-30 draft-ietf-6lo-fragment-recovery-08 > Kyle Rose 2020-01-29 draft-ietf-emu-rfc5448bis-06 > Rich Salz 2020-02-21 draft-halpern-gendispatch-consensusinformational-02 > Stefan Santesson 2020-01-27 draft-ietf-dots-architecture-16 > Yaron Sheffer 2020-02-12 draft-ietf-dnssd-prireq-04 > Rifaat Shekh-Yusef 2020-02-06 draft-ietf-mmusic-t140-usage-data-channel-11 > Melinda Shore 2020-02-06 draft-ietf-6lo-backbone-router-13 > Takeshi Takahashi 2019-11-04 draft-ietf-netmod-yang-data-ext-05 > Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 > > Next in the reviewer rotation: > > Joseph Salowey > Rich Salz > Stefan Santesson > Yaron Sheffer > Rifaat Shekh-Yusef > Melinda Shore > Valery Smyslov > Robert Sparks > Takeshi Takahashi > Tina Tsou > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- kivinen@iki.fi From nobody Thu Jan 30 05:00:25 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 49CD01200DF for ; Thu, 30 Jan 2020 05:00:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <158038922429.10319.2550317322935038886.idtracker@ietfa.amsl.com> Date: Thu, 30 Jan 2020 05:00:24 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 13:00:24 -0000 This is the correct assignment list for this week. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2020-02-06 Reviewer LC end Draft Roman Danyliw 2019-11-12 draft-ietf-dtn-bpbis-20 Russ Mundy 2020-01-02 draft-ietf-dprive-bcp-op-08 Last calls: Reviewer LC end Draft Shaun Cooley 2019-11-12 draft-ietf-regext-login-security-07 Roman Danyliw 2019-11-12 draft-ietf-dtn-bpbis-20 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-08 Aanchal Malhotra 2019-12-23 draft-ietf-pce-stateful-flags-01 Russ Mundy 2020-01-02 draft-ietf-dprive-bcp-op-08 Sandra Murphy 2019-10-04 draft-ietf-mpls-ldp-yang-06 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-09 Radia Perlman 2020-01-31 draft-ietf-uta-tls-for-email-04 Derrell Piper 2020-01-31 draft-ietf-6lo-minimal-fragment-08 Tirumaleswar Reddy.K 2020-01-30 draft-ietf-6lo-fragment-recovery-08 Kyle Rose 2020-01-29 draft-ietf-emu-rfc5448bis-06 Stefan Santesson 2020-01-27 draft-ietf-dots-architecture-16 Valery Smyslov 2020-02-21 draft-halpern-gendispatch-consensusinformational-02 Robert Sparks 2020-02-12 draft-ietf-dnssd-prireq-04 Takeshi Takahashi 2020-02-06 draft-ietf-mmusic-t140-usage-data-channel-11 Takeshi Takahashi 2019-11-04 draft-ietf-netmod-yang-data-ext-05 Tina Tsou 2020-02-06 draft-ietf-6lo-backbone-router-13 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Next in the reviewer rotation: Sean Turner Mališa Vučinić Carl Wallace David Waltermire Samuel Weiler Brian Weis Klaas Wierenga Christopher Wood Paul Wouters Liang Xia From nobody Thu Jan 30 07:10:31 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2598D12018D; Thu, 30 Jan 2020 07:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 hxJi25NEcnVe; Thu, 30 Jan 2020 07:10:23 -0800 (PST) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 8EF39120180; Thu, 30 Jan 2020 07:10:23 -0800 (PST) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id 00UF83OV127543; Thu, 30 Jan 2020 15:10:22 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2019-08-05; bh=Cm847tvq4HUlYEXLz/q2SUCOXt5uakoPrRljyt2dqB4=; b=CDk0OX8wPkEmUPRfvBGG4aX+reeRpzBIkhT3A/fc7CnAlkjY7xags4iUpGUK5IJy+d9k dpyhZEpr/ko0kfoHt3KiBDyfn8AXAHkHQ+K7lx/p4nPpPy+j1Q2BTAhFwbo0/22w4vu2 mzCq80CoIOQGVX9e6RJrCxBpUDkBCoG6kDyl1nhsN5R14KdD24Qoeyw4x5eI+Pi+zg+y YyPscQwTD+jbnSv9gz11VAIWiLkZ/1mUT6Kd5wnEqjs8NGpTmI5G5/cgwfyG24Ayq67L f9wITyA9CxeSWq0iEA6btYa3PgQLaAl9iO8JmZDL+WzBjFEoBqEdPw2OwFiKT3LTN4bn Vg== Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2120.oracle.com with ESMTP id 2xrearmhkv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 30 Jan 2020 15:10:22 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id 00UF9N84178426; Thu, 30 Jan 2020 15:10:21 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3020.oracle.com with ESMTP id 2xu8e8udjt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 30 Jan 2020 15:10:21 +0000 Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 00UFAG7k010902; Thu, 30 Jan 2020 15:10:16 GMT Received: from anon-dhcp-152.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 30 Jan 2020 07:09:15 -0800 MIME-Version: 1.0 Message-ID: Date: Thu, 30 Jan 2020 07:09:14 -0800 (PST) From: Chuck Lever To: Yaron Sheffer Cc: secdir@ietf.org, last-call@ietf.org, nfsv4@ietf.org, draft-ietf-nfsv4-rpcrdma-cm-pvt-data.all@ietf.org References: <158007038921.30641.13334124837519126164@ietfa.amsl.com> <80F557DD-BD17-4119-98B9-614B7A9FDDFB@oracle.com> <85F5B476-8720-488B-9262-CBA9B322BFD3@gmail.com> In-Reply-To: <85F5B476-8720-488B-9262-CBA9B322BFD3@gmail.com> X-Mailer: Apple Mail (2.3445.104.11) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9515 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2001300110 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9515 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2001300110 Archived-At: Subject: Re: [secdir] [nfsv4] Secdir last call review of draft-ietf-nfsv4-rpcrdma-cm-pvt-data-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 15:10:25 -0000 Hello Yaron- The Security Considerations section now reads as follows: 6. Security Considerations The reader is directed to the Security Considerations section of [RFC8166] for background and further discussion. The RPC-over-RDMA version 1 protocol framework depends on the semantics of the Reliable Connected (RC) queue pair (QP) type, as defined in Section 9.7.7 of [IBA]. The integrity of CM Private Data and the authenticity of its source are ensured by the exclusive use of RC queue pairs. Any attempt to interfere with or hijack data in transit on an RC connection results in the RDMA provider terminating the connection. Additional analysis of RDMA transport security appears in the Security Considerations section of [RFC5042]. That document recommends IPsec as the default transport layer security solution. When deployed with iWARP, IPsec establishes a protected channel before any iWARP operations are exchanged, thus it protects the exchange of Private Data that occurs as each QP is established. However, IPsec is not available for InfiniBand or RoCE deployments. Those fabrics rely on physical security and cyclic redundancy checks to protect network traffic. Improperly setting one of the fields in a version 1 Private Message can result in an increased risk of disconnection (i.e., self-imposed Denial of Service). There is no additional risk of exposing upper- layer payloads after exchanging the Private Message format defined in the current document. In addition to describing the structure of a new format version, any document that extends the Private Data format described in the current document must discuss security considerations of new data items exchanged between connection peers. -- Chuck Lever From nobody Thu Jan 30 08:29:07 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7830612016E; Thu, 30 Jan 2020 08:28:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.877 X-Spam-Level: X-Spam-Status: No, score=-0.877 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, MALFORMED_FREEMAIL=1.122, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 E8tbZ1W21vd1; Thu, 30 Jan 2020 08:28:50 -0800 (PST) Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21A8212018D; Thu, 30 Jan 2020 08:28:50 -0800 (PST) Received: by mail-wr1-x444.google.com with SMTP id a6so4786783wrx.12; Thu, 30 Jan 2020 08:28:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=V879YMpEhCVpGtsHHJoWXyQaBEut19OgULvnWa4Rs9M=; b=aOGeU4l9pt6zKTiWMSfpY7zyw80sC/oLaiZKIZbza/7wJXvmDZHpLT4dStLP9p1+Wu pM37VA6Qy94NqkZU4gYqnPZ64QZYVDv9BKY3uojpMZuVNCXT6sCAScHQZtTTezC91owk J0LNuFzIAM2LuijbOT7V6B7+E1cod6c4+FwvKQsu1QQbwxDBWyelxHX9we/9L/lCR/dC 9S3ZenNLMKnpZBvkW9kwpJn6FkEIUWQaLCrxcGGMF+tP8dAtzjOU2xQJKWnx1zvN+wHO OohzJaywX7bwruwmSSZdsmXSBWOu/wVj5S67xWvAsCnYbfSa9CaWsBMHB8DYzRl86I20 +EDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=V879YMpEhCVpGtsHHJoWXyQaBEut19OgULvnWa4Rs9M=; b=LeyWjoq1equrKRExwnHHKgEjaw1Vs948/LWVYYSof3zRBu3KSxp0jvt0/PB8S2ek10 TeLcJoVYnfSoRX0MjRIzlcz9uxEfF+jK+QmaVBPsLQFmQJFTiusq6wX/f49CRLEh6jye vOA7rQ44Bl5QVhe3XK30H1Anjg7LQW61HwYXA/geWl5yOKXnzHfVWL1LObYSKUMN/ISB fApiEENJ0iPgwrPp3Gwc09xSbR1AeEcPWAFX8lhLJEqI3XK18f9vs5YjBZnkNk2InZEl abf8D4qx7DT0VW/ZbdH3DPIdWO8OLFE6n/l9wd9P1fvIKHKjyDSIN62SOGLmFjSwQGZV Nlyw== X-Gm-Message-State: APjAAAWij5ZFUQ26cFQlhvaxHTS+69pp2Fi5EEDGzUW6AL9x7Y0UG6rb g5DoSVL3hN9el3sYWqGDy5I= X-Google-Smtp-Source: APXvYqzrQ/pxG0sJ/P+z83DsVrPXSQh0F9smbT93x6r9VhTCI5eqMpfNZlH+WizyXuFVAI25WlkVdA== X-Received: by 2002:adf:ea0f:: with SMTP id q15mr6627523wrm.324.1580401728604; Thu, 30 Jan 2020 08:28:48 -0800 (PST) Received: from [172.28.128.167] (pub-corp-42-8.intuit.com. [91.102.42.8]) by smtp.gmail.com with ESMTPSA id q1sm2496695wrw.5.2020.01.30.08.28.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Jan 2020 08:28:47 -0800 (PST) User-Agent: Microsoft-MacOutlook/10.21.0.200113 Date: Thu, 30 Jan 2020 18:28:45 +0200 From: Yaron Sheffer To: Chuck Lever CC: , , , Message-ID: <335110AE-F983-4151-8CEB-6C06586176BD@gmail.com> Thread-Topic: [nfsv4] Secdir last call review of draft-ietf-nfsv4-rpcrdma-cm-pvt-data-06 References: <158007038921.30641.13334124837519126164@ietfa.amsl.com> <80F557DD-BD17-4119-98B9-614B7A9FDDFB@oracle.com> <85F5B476-8720-488B-9262-CBA9B322BFD3@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [secdir] [nfsv4] Secdir last call review of draft-ietf-nfsv4-rpcrdma-cm-pvt-data-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 16:28:52 -0000 Looks good. Thank you very much! Yaron =EF=BB=BFOn 1/30/20, 17:10, "Chuck Lever" wrote: Hello Yaron- =20 The Security Considerations section now reads as follows: =20 6. Security Considerations =20 The reader is directed to the Security Considerations section of [RFC8166] for background and further discussion. =20 The RPC-over-RDMA version 1 protocol framework depends on the semantics of the Reliable Connected (RC) queue pair (QP) type, as defined in Section 9.7.7 of [IBA]. The integrity of CM Private Data and the authenticity of its source are ensured by the exclusive use of RC queue pairs. Any attempt to interfere with or hijack data in transit on an RC connection results in the RDMA provider terminating the connection. =20 Additional analysis of RDMA transport security appears in the Security Considerations section of [RFC5042]. That document recommends IPsec as the default transport layer security solution. When deployed with iWARP, IPsec establishes a protected channel before any iWARP operations are exchanged, thus it protects the exchange of Private Data that occurs as each QP is established. However, IPsec is not available for InfiniBand or RoCE deployments. Those fabrics rely on physical security and cyclic redundancy checks to protect network traffic. =20 Improperly setting one of the fields in a version 1 Private Message can result in an increased risk of disconnection (i.e., self-imposed Denial of Service). There is no additional risk of exposing upper- layer payloads after exchanging the Private Message format defined i= n the current document. =20 In addition to describing the structure of a new format version, any document that extends the Private Data format described in the current document must discuss security considerations of new data items exchanged between connection peers. =20 =20 -- Chuck Lever =20 =20 =20 =20 From nobody Thu Jan 30 08:30:48 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFA21208B6; Thu, 30 Jan 2020 08:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Z7617-aYY8A; Thu, 30 Jan 2020 08:30:37 -0800 (PST) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2B55120851; Thu, 30 Jan 2020 08:30:30 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id c23so2701049lfi.7; Thu, 30 Jan 2020 08:30:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=vPIln/F/NFGtDToaj1FvtBSR4TYeSFZA9TzdLn6nPOw=; b=B/Z2Koe8CXmJZwq4l59dbo1pFI/LfapdM6R8C/EMhjqKkwvigNlxqTZqp3rJmtLGa4 9lIH79WBVShCL7aIGiTAdT1Vg1U1lK6ZUaTnGSZBuM+phL+IDz2V4DiI/UDkKbxzX8cH g2VL4EepNz1PL3ptpPornh/cel4c/JQnx7/CVwIbxH5uJsAZme9gHuVrIrWOKIzD20Mp m+cduQeDZlQ4uZbQvwuTiP1T559YahHwFaj81qbFc/uM3gLG+B0c+jf6SVDMPcXChh0h HEV5r7JhKQTst2GXvnbVUjMo8HHJ8KG2cR4jj8wbJZ43i3BXK5aQzqUbChxfQ4dZsrJA 3W9Q== 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=vPIln/F/NFGtDToaj1FvtBSR4TYeSFZA9TzdLn6nPOw=; b=Sq8bbR0DmOZox+KzWJC/Hy1LvhexXCvrW6kA7PV5dz1nO5p9AhCPu3L/1pmCgGZWk2 U7ScpxothVl4dS7ye/0VGqdlIVDYIaJnf1a2y1lJqzyuLufTDEK2/bWFK5m1ytzPbYMb zIZo6veC1d6bRymeTr8XPH7ZvU4BLtBqYruH2M5PAzAiQx7I1V7rGFajx5UUxT89NlGq kPLjHofkaIgNRvjXVmuiO9g9k6gWgVkVP1Sly3AoBUbRUOxgD64mq7+Kbim4PAJUIBfM IM3dRXdLWwj1CoKYipP6iZA2ze/Lq3JyJTBWzME/tYsZQtGc+LX0dXNtX4of3rm4ZfLg 1uTQ== X-Gm-Message-State: APjAAAX83CsvqfNRaegTL60rdgWOK/tc1GYgevxR1I+O1gFbT3ANtFDy JICaa0m+8I/zOvs+6sTzac9cpQlQgOsTI1VnpgEGyPzTpqs= X-Google-Smtp-Source: APXvYqw3Ex2Pr8PIPKV7WQ8AVwFeFKc3Hyxg6AOYHxywN9nzu3jHuVXELAdohKBNZ3k0xwbCgc/addtgTFqdcx8aY/4= X-Received: by 2002:a19:5201:: with SMTP id m1mr2990696lfb.114.1580401828238; Thu, 30 Jan 2020 08:30:28 -0800 (PST) MIME-Version: 1.0 From: Radia Perlman Date: Thu, 30 Jan 2020 08:30:15 -0800 Message-ID: To: secdir@ietf.org, The IESG , draft-ietf-uta-tls-for-email.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000931a3f059d5df905" Archived-At: Subject: [secdir] Secdir review of draft-ietf-uta-tls-for-email-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 16:30:42 -0000 --000000000000931a3f059d5df905 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 is an utterly trivial and non-controversial update to RFC8314 changing references to TLS v1.1 to TLSv1.2 as the minimum acceptable version of TLS to use for this purpose. While there is nothing to debate with respect to security, I do question whether it's better to release a document like this which specifies changes to RFC8314 or whether it would be better to update (and obsolete) that document so that this one would stand alone. Better yet would be to come up with a replacement version of RFC8314 that would not need to be updated again when TLSv1.2 needs to be replaced with TLSv1.3. Introducing new versions of TLS and obsoleting old ones should happen without having to update the - likely hundreds of - RFCs that refer to TLS. Radia --000000000000931a3f059d5df905 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I have reviewed this document as part of the security dire= ctorate's ongoing effort to review all IETF documents being processed b= y the IESG.=C2=A0 These comments were written primarily for the benefit of = the security area directors.=C2=A0 Document editors and WG chairs should tr= eat these comments just like any other last call comments.

    This is a= n utterly trivial and non-controversial update to RFC8314 changing referenc= es to TLS v1.1 to TLSv1.2 as the minimum acceptable version of TLS to use f= or this purpose.

    While there is nothing to debate with respect to se= curity, I do question whether it's better to release a document like th= is which specifies changes to RFC8314 or whether it would be better to upda= te (and obsolete) that document so that this one would stand alone. Better = yet would be to come up with a replacement version of RFC8314 that would no= t need to be updated again when TLSv1.2 needs to be replaced with TLSv1.3. = Introducing new versions of TLS and obsoleting old ones should happen witho= ut having to update the - likely hundreds of - RFCs that refer to TLS.
    <= div>
    Radia
    --000000000000931a3f059d5df905-- From nobody Thu Jan 30 08:42:00 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29BB21200DE; Thu, 30 Jan 2020 08:41:55 -0800 (PST) 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dl5B9_Aix1LR; Thu, 30 Jan 2020 08:41:52 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C235120090; Thu, 30 Jan 2020 08:41:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BFE85BE20; Thu, 30 Jan 2020 16:41:49 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ToWCutnBNfh; Thu, 30 Jan 2020 16:41:49 +0000 (GMT) Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 79F73BDCF; Thu, 30 Jan 2020 16:41:49 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1580402509; bh=TKJQMWKCS4sMa1bjPHfTnPGcBWVzYuSARuTt0Oshmug=; h=Subject:To:References:From:Date:In-Reply-To:From; b=dCGbSXs96n1F6HDVoiofagw0OBTKnXcZSdvxXVWkcqCoUXq66V2pfCxhTnxyMDhZ4 StRdROL8XHSW51ZzzxwJkMLg11KnoYoLygDHjbdXtrkUys6DdTqX51O2QdvlaF1RfB fZ8ZG6vY3ZIhngy692rNkun5BwcpJCDUt3KM/b4c= To: Radia Perlman , secdir@ietf.org, The IESG , draft-ietf-uta-tls-for-email.all@ietf.org References: From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <1e558a24-28ce-8957-32f9-e054bec697ba@cs.tcd.ie> Date: Thu, 30 Jan 2020 16:41:48 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="SXIDzmYtIvTiMTYOa6KTku9WP0G0JILQU" Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-uta-tls-for-email-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 16:41:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SXIDzmYtIvTiMTYOa6KTku9WP0G0JILQU Content-Type: multipart/mixed; boundary="QiZIia9wFFPNl1nHXt5fTBTgVtrGRqJAc"; protected-headers="v1" From: Stephen Farrell To: Radia Perlman , secdir@ietf.org, The IESG , draft-ietf-uta-tls-for-email.all@ietf.org Message-ID: <1e558a24-28ce-8957-32f9-e054bec697ba@cs.tcd.ie> Subject: Re: [secdir] Secdir review of draft-ietf-uta-tls-for-email-03 References: In-Reply-To: --QiZIia9wFFPNl1nHXt5fTBTgVtrGRqJAc Content-Type: multipart/mixed; boundary="------------6926718219734A41D307BA4C" Content-Language: en-US This is a multi-part message in MIME format. --------------6926718219734A41D307BA4C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Radia, Thanks for the review. On 30/01/2020 16:30, Radia Perlman wrote: > While there is nothing to debate with respect to security, I do questio= n > whether it's better to release a document like this which specifies cha= nges > to RFC8314 or whether it would be better to update (and obsolete) that > document so that this one would stand alone. Better yet would be to com= e up > with a replacement version of RFC8314 that would not need to be updated= > again when TLSv1.2 needs to be replaced with TLSv1.3. Introducing new > versions of TLS and obsoleting old ones should happen without having to= > update the - likely hundreds of - RFCs that refer to TLS. I wish! Take a peek at the header of [1] for example:-) Avoiding those issues in future was part of the logic behind BCP195/RFC7525 [2] so if in future consumers of TLS refer to BCP195, then we'll be in a good position as BCP195 can just be updated to point to whatever RFC has the current guidance for TLS1.3 and the RFCs that refer to BCP195 won't need to change. That is happening already to some extent, and the more the better I'd say (hence this mail:-). In the meantime, I think we gotta do this kind of deprecation draft, even if it's a small pain in this case (and a big pain for [1]). Cheers, S. [1] https://tools.ietf.org/html/draft-ietf-tls-oldversions-deprecate-06 [2] https://tools.ietf.org/html/rfc7525 --------------6926718219734A41D307BA4C Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------6926718219734A41D307BA4C-- --QiZIia9wFFPNl1nHXt5fTBTgVtrGRqJAc-- --SXIDzmYtIvTiMTYOa6KTku9WP0G0JILQU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl4zB0wACgkQWrL68XsX K+oPQw/+Pm191bybo+yMAfj15Ebxf71VRNJSTQ5BXbORfOdqGZMud8Y6QJmbuV5H /C92BLBhTc0J4ToF8+5zIyS/D/wnMjycvIWkXGejWYZGJdAY5a/qRdsiGTVTFJUD mW2bFB8tSkLr+ZK9e6ah0kUMUMgKERqEgatuxhjsmvjK5FqBMFGQnC8QIPlzu6q9 EXT/6VDp4MJePZCW6dQBbqO/nZ+0qsO7mwczWTOYuO6BZxl+wCf1Gm6iwKXD/Hwo woaG/yCcvvUgtw066CqYAAwFs/QobQBKmde7Dw6no2DndA5EimnKU+NpRBARCrkt uNMJhz8aq5GPN/raYrGtULXC/Dq6hpf/xTHOFkwFGU6QVeTsHbfNjfDQoIzXxYXi kqAc4mML9SDA54uvmZ8z6wNwZ/5hD2TTIFr5nPu55tLWL9lg3jc7Y43oBEFitl0j k8BJciMFJqetEE4Vwow4rDeVw/P6EUvb+pEWJK7OEa7c1AY9q5YpIMHjZyGPKTA5 fkiPrrCPwh3BkYVxZ1jS7SKmxe9mrqUvS4uF6UjRC2zek+C9O5w2spkWtOoE/SDp ai5GuiivaXIimRYQ6R36oUrx11xBgsyt9LNqAkiGMHODP0s4w8M251EHg1mYj8Pe 4LTHZeeQy/C0jaIJyNoHKUflENx4f4w4z8muxU9Ic3cdq8qjOvE= =R9uB -----END PGP SIGNATURE----- --SXIDzmYtIvTiMTYOa6KTku9WP0G0JILQU-- From nobody Fri Jan 31 02:23:06 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800631200E9; Fri, 31 Jan 2020 02:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.498 X-Spam-Level: X-Spam-Status: No, score=-14.498 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.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=eXclXFtA; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=EQkAVJhR Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVUR88xuiFVC; Fri, 31 Jan 2020 02:22:57 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33DA1120098; Fri, 31 Jan 2020 02:22:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8282; q=dns/txt; s=iport; t=1580466177; x=1581675777; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=s8JdGgJSFmiYHHhQS6O5p8Ik1InjhnAAiV/Pvu9lwGk=; b=eXclXFtAKEXjh9u+0l8TYVnmv/yZJG3FvWKOpBDUjAQJvWHaNuAZhTaA mgzsUa+LVRw49t11Gww7zvjSFqbp+EX2Nm6eeJUc/9ctskmcx8Wkb2E8G IVW+KXYz4tuEaebbbBxYfgP6fdHuNEkxrQaVL9fYiciFol2n+Bke12+4b c=; IronPort-PHdr: =?us-ascii?q?9a23=3A1hcWZxG63ZpxxLNI6LecSp1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeb2bzEwEd5efFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CxAAC8/zNe/49dJa1lGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYF7gVRQBWxYIAQLKoQUg0YDinOCX5gPglIDVAk?= =?us-ascii?q?BAQEMAQEjCgIBAYRAAheCGCQ4EwIDDQEBBAEBAQIBBQRthTcMhV4BAQEBAxI?= =?us-ascii?q?REQwBATcBCwQCAQYCEQQBAQECAiYCAgIwFQUDCAIEAQ0FCBqDBYJKAy4BAgy?= =?us-ascii?q?QZ5BmAoE5iGJ1gTKCfwEBBYEzAoNVGIIMAwaBDiqFHoU/gUMagUE/gRFHgkw?= =?us-ascii?q?+gmQCAhqBSRWCeTKCLI1hgjo7nhtwCoI7lliCSIgNhEiHI4RFg0mLF5sWAgQ?= =?us-ascii?q?CBAUCDgEBBYFpIoFYcBWDJ1AYDY4dCRoVgzuFFIU/dIEpilwtghQBAQ?= X-IronPort-AV: E=Sophos;i="5.70,385,1574121600"; d="scan'208";a="698830416" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 31 Jan 2020 10:22:50 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 00VAMoDK025359 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 31 Jan 2020 10:22:50 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 31 Jan 2020 04:22:50 -0600 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 31 Jan 2020 05:22:49 -0500 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 31 Jan 2020 05:22:48 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TrXY8ppZZg3mTrWxTwmIT1Y/YbWYO03fQtfEbDpVQb3bbEZXPjL5ZCs9vTOJB77aovzy7u3N4NFUGIR+ckjP4N9rKmBXdIiOjOcuSiA5/lpSxe3fa8hlgWY6+EWtD84kK2O6ZC2sgvOHDzgDZu11I4JhGOYlzz6JbshgKmuckbIs92jAfifutucPBUbsn1yZZ2lQwVXe3WilfZnWp25f65bUybUPRV5J23x4ADW7lYs7l18uIwClNgTNYJMU+O8k1tGSWGQ0qnaZruU6VWN6BVCudbh0w7NKpg5dOfaLlbVokHbY7TtGfc8nIieaNNtlyfCgc/guMEgA+jvJ9LTxfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=s8JdGgJSFmiYHHhQS6O5p8Ik1InjhnAAiV/Pvu9lwGk=; b=oexvc7qsMiFm1vOYk8boZ8531IeDqOj5r3I3gXVQ44R2lAJT8YJkjJDEe9gZ81R3gTOeNJAdBjrrJYvb22gPzo6iVwXFOYv6naFHy2thdQxq0snHcBAyublMm3SFnePD4NdV+5LYuAq+UAfliy4K0PDJVOmD5gUl6dFx1eecg2avwskrdkS/uLpehdZL6wd1iLqZctCLf2U2skMeJQ6ZIvqzjBFzm7rviES4/3iOkkUSHtoizNEe0ANNt5IFYo5RMevGS71FVBdlGagE9Ld0+IKGwTdC+1JIASmNg0QozcgkZeSJbDpv+zjJTNSmbTs7xiGBereyrMQaPTq/EcXJxw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=s8JdGgJSFmiYHHhQS6O5p8Ik1InjhnAAiV/Pvu9lwGk=; b=EQkAVJhRfFofBtGR1J7zJ2cm2o2B0mPtW8nYkYb2Y2PAnDDjjUIuOey2Zzq8X7Qg/e8ueKiqiDh1sjTIMW1t9kmZXSIwu6eh5opRDcgyJISkBiJ2oKMV33Jk7Chy6erZmHNiiDcwqhRD36mR0MW5mz0p3pnXIhAX+GmIplNm5fc= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4125.namprd11.prod.outlook.com (10.255.181.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.29; Fri, 31 Jan 2020 10:22:47 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a%3]) with mapi id 15.20.2665.027; Fri, 31 Jan 2020 10:22:47 +0000 From: "Pascal Thubert (pthubert)" To: "Eric Vyncke (evyncke)" , The IESG CC: "draft-ietf-6lo-ap-nd@ietf.org" , "Shwetha Bhandari (shwethab)" , "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>, "secdir@ietf.org" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLTZsby1hcC1u?= =?utf-8?Q?d-13:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHV1q8ObZjsSNLsNE+ME5HgTzGBvKgBtsSwgAASbYCAAsfmsA== Date: Fri, 31 Jan 2020 10:22:45 +0000 Deferred-Delivery: Fri, 31 Jan 2020 10:21:49 +0000 Message-ID: References: <158030752268.2728.2544838912831012540.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:44f3:1300:41e7:7725:e525:b2e8] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d6238c67-5754-4249-2e06-08d7a63784c6 x-ms-traffictypediagnostic: MN2PR11MB4125: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 029976C540 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(346002)(39860400002)(366004)(396003)(189003)(199004)(966005)(76116006)(71200400001)(316002)(7696005)(110136005)(54906003)(66946007)(81166006)(53546011)(6506007)(81156014)(2906002)(86362001)(5660300002)(8936002)(66556008)(9686003)(52536014)(450100002)(33656002)(4326008)(55016002)(224303003)(186003)(478600001)(66446008)(64756008)(66476007); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4125; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Q0z20dlmXNmead/TDuluzTWqyPbQQT6e6BTfEN3i2c2RU20pHIHM+Py9xiFQhAKEfFnEQRrthXSpLpWZmFsH8Ex+GhsGSB33e0H6SAqgInaM9fpcTclW15Ed6LiQBdd59mjBFxL445Iwy6iG8XKQEYJ6Gc5JGJkc+fvpJStg/Yx7lRlZQlPVi2byu09vljWAT48H+/Ac0FOOTvHrZKM9wIuoR8uiQdiI9p8li8o0OETfPbOMM4+aWcIjQalw2+jPqxvWZ6SbUJkqiNUtayToR//T/hUnXShLcNjaRzyiDUbdAxLjSZX8L66eFiTivuXiMBIdb4pbqO79ju0O3WbDF90iCXg58X60TjUCgSYHavzNT4EIg/pejex6djLzvQgndYgcPBrFHrg/mvYo8h0pb+KBxCkjEx/BHo7ey0N+Ma2WBxxCX4tYXYwhJ+hyNXpAzVa2hqqgXQ9TMxd4n+SmEyO9n0UsiGZfin3ZvmmUOkClg3tCVw4rMydDE22B1nLb9BQzFXWlloq4KJ5LFbLFPQ== x-ms-exchange-antispam-messagedata: yWUv+oL5waeWkcyJShH7AEGjAAPG6OPgmfD4LbreJeED/Hg/C27B+f/7qsOhMQbgiTrM9RrmK6f9eb/E702DFZ88OngU4uZYSWZp/uPzBB+0xE2fPD/Jz/Kk08YLK9l9FFQI4711K1uim5AHxL7pfTe0iamzGdx1F23hCnNhrtmG4MHVA9MYwkZ/5hzOZPn9FEnvGI/KerooYTEUOtAPCg== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d6238c67-5754-4249-2e06-08d7a63784c6 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2020 10:22:47.5907 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: c4KCdEgQHa0zgAnB8frtMTrovSa73fxFb6uRQaa6deZEq2gmAfnA0pTr0rVk6BDQPq0eszZkYZ6VjWnbHNMSCA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4125 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [secdir] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-6l?= =?utf-8?q?o-ap-nd-13=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 10:22:59 -0000 SGVsbG8gRXJpYzoNCg0KQWdhaW4gbWFueSB0aGFua3MgZm9yIHlvdXIgcmV2aWV3IDogKQ0KDQpJ IGp1c3QgcHVibGlzaGVkIDE0LCBhbmQgYWRkZWQgdGV4dCBvbiB0aGUgTm9uY2UgdG8gcmVtb3Zl IHRoZSBpbXBvc3NpYmxlIG11c3QuIFdlIHRhbGtlZCBiZXR3ZWVuIGF1dGhvcnMgYW5kIHRoZSBp bmRpY2F0aW9uIGlzIHNhbWUgYXMgUkZDIDM5NzEgdGhhdCB0aGlzIHNob3VsZCBiZSBhIHJhbmRv bS4NClRoZSBxdWFsaXR5IG9mIHRoZSByYW5kb20gaXMgbGlua2VkIHdpdGggdGhlIHNlY3VyaXR5 IGxldmVsIHRoYXQgY2FuIGJlIG9idGFpbmVkIGZyb20gaXQuIENvdXBsaW5nIHJhbmRvbXMgZnJv bSBib3RoIHBhcnRpZXMgbGFyZ2VseSBpbmNyZWFzZXMgdGhlIHByb3RlY3Rpb24sIGJ1dCBpbiBh biBJT1QgbmV0d29yayB0aGF0IHJlYm9vdHMsIHRoZXJlIGlzIHN0aWxsIGEgcmlzayBvZiBhIHJl cGxheS4NCkFsbCBpbiBhbGwgd2UgZ2l2ZSB0aGUgZ2VuZXJhbCBkaXJlY3Rpb24gb2YgdGhlIHJh bmRvbSwgYnV0IGFsbG93IGFuIGV2ZXIgaW5jcmVhc2luZyB2YWx1ZSBhcyB3ZWxsLCB3aGljaCBp cyBzaW1wbGVyIHRvIG9idGFpbiBmb3IgYSBub2RlIGFuZCB5aWVsZHMgdGhlIHNhbWUgTm9uY2Ug YmVuZWZpdHMuDQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJs ZSBhdDogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtNmxvLWFw LW5kLTE0DQoNClBsZWFzZSBsZXQgdXMga25vdyBpZiB0aGUgdGV4dCBub3cgY29uZm9ybXMgeW91 ciBleHBlY3RhdGlvbnM/DQoNCk1hbnkgdGhhbmtzIGFnYWluDQoNClBhc2NhbA0KDQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRXJpYyBWeW5ja2UgKGV2eW5ja2UpIDxl dnluY2tlQGNpc2NvLmNvbT4NCj4gU2VudDogbWVyY3JlZGkgMjkgamFudmllciAyMDIwIDE2OjQ3 DQo+IFRvOiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIDxwdGh1YmVydEBjaXNjby5jb20+OyBU aGUgSUVTRw0KPiA8aWVzZ0BpZXRmLm9yZz4NCj4gQ2M6IGRyYWZ0LWlldGYtNmxvLWFwLW5kQGll dGYub3JnOyBTaHdldGhhIEJoYW5kYXJpIChzaHdldGhhYikNCj4gPHNod2V0aGFiQGNpc2NvLmNv bT47IDZsby1jaGFpcnNAaWV0Zi5vcmc7IDZsb0BpZXRmLm9yZzsgc2VjZGlyQGlldGYub3JnDQo+ IFN1YmplY3Q6IFJlOiDDiXJpYyBWeW5ja2UncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtNmxvLWFw LW5kLTEzOiAod2l0aCBESVNDVVNTDQo+IGFuZCBDT01NRU5UKQ0KPiANCj4gUGFzY2FsDQo+IA0K PiBUaGFuayB5b3UgZm9yIHlvdXIgcHJvbXB0IHJlcGx5LiBJIHdpbGwgY2xlYXIgbXkgRElTQ1VT UyBpbiBhIG1vbWVudCBhcyB5b3UNCj4gd2lsbCBjaGFuZ2UgdGhlIHRleHQuDQo+IA0KPiBBZ3Jl ZWQgb24gYWxsIHRoZSBwb2ludHMgZXhjZXB0IGZvciB0aGUgJ25vbmNlJy4gSSBrbm93IHRoZSBj b25jZXB0IG9mIGNvdXJzZQ0KPiBidXQgdGhlIHNlbnRlbmNlICJ3YXMgbmV2ZXIgdXNlZCB3aXRo IHRoaXMgZGV2aWNlIiBpcyBzdGlsbCB0b28gc3Ryb25nIElNSE8uIFRvDQo+IGNvbXBseSwgaXQg d291bGQgcmVxdWlyZSB0byBrZWVwIHRoZSBoaXN0b3J5IGZvciBldmVyLi4uIEkgd291bGQgcHJl ZmVyIGEgbGVzcw0KPiBzdHJpbmdlbnQgd29yZGluZy4NCj4gDQo+IC3DqXJpYw0KPiANCj4g77u/ T24gMjkvMDEvMjAyMCwgMTY6MzgsICJQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIiA8cHRodWJl cnRAY2lzY28uY29tPg0KPiB3cm90ZToNCj4gDQo+ICAgICBIZWxsbyBFcmljIDogKQ0KPiANCj4g ICAgIE1hbnkgdGhhbmtzIGZvciB5b3VyIHJldmlldyEgSSBjYydlZCBTRUMtRElSIGJlY2F1c2Ug d2UgY291bGQgcmVhbGx5IHVzZQ0KPiB0aGVpciByZWNvbW1lbmRhdGlvbiB0byBzb2x2ZSBzb21l IG9mIHlvdXIgcXVlc3Rpb25zLCBtb3JlIGJlbG93Lg0KPiANCj4gICAgIFBsZWFzZSBzZWUgYmVs b3c6DQo+IA0KPiAgICAgPiA9PSBESVNDVVNTID09DQo+ICAgICA+DQo+ICAgICA+IC0tIFNlY3Rp b24gNC40IC0tDQo+ICAgICA+IFRoZSBsZW5ndGggb2YgdGhlIHJlc2VydmVkIGZpZWxkIGlzIG5v dCBzcGVjaWZpZWQuIE9yIGFtIEkgbWlzc2luZw0KPiBzb21ldGhpbmcNCj4gICAgID4gb2J2aW91 cyA/DQo+IA0KPiAgICAgSSBjb25jYXRlbmF0ZWQgdGhlIHJlc2VydmVkIGZpZWxkcyBpbiB0aGUg cGljdHVyZSBhbmQgZGVjbGFyZWQgaXQgYXMgNDAgYml0cy4NCj4gICAgIEFsc28gYWRkZWQgdGhl IG51bWJlciBvZiBiaXRzIGluIHRoZSByZXNlcnZlZCBmaWVsZHMgb2Ygb3RoZXIgc3RydWN0dXJl cy4NCj4gDQo+ICAgICA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gICAgID4gQ09NTUVOVDoNCj4gICAgID4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiAgICAgPg0KPiAgICAgPiA9PSBDT01NRU5UUyA9PQ0KPiAgICAgPg0K PiAgICAgPiAtLSBTZWN0aW9uIDQuMiAtLQ0KPiAgICAgPiBXaGlsZSBzdGF0dXMgaXMgc2V0IHRv IDAgd2hlbiBzZW5kaW5nIGEgTlMsIHdoYXQgaXMgdGhlIGV4cGVjdGVkIGJlaGF2aW9yDQo+IG9m IGENCj4gICAgID4gcmVjZWl2ZXIgPw0KPiANCj4gICAgIENoYW5nZWQgdG8NCj4gICAgICINCj4g ICAgIEluIE5TIG1lc3NhZ2VzIGl0IE1VU1QgYmUgc2V0IHRvIDAgYnkgdGhlIHNlbmRlciBhbmQg aWdub3JlZCBieSB0aGUNCj4gcmVjZWl2ZXIuDQo+ICAgICAiDQo+IA0KPiAgICAgPiAtLSBTZWN0 aW9uIDQuMyBhbmQgNC40IC0tDQo+ICAgICA+IFdoeSBpcyB0aGUgUGFkIExlbmd0aCBmaWVsZCBh IDgtYml0IGZpZWxkIHdoaWxlIHRoZSBhY3R1YWwgcGFkZGluZyB3aWxsDQo+IGFsd2F5cyBiZQ0K PiAgICAgPiBsZXNzIHRoYW4gOCBieXRlcy4gU3VnZ2VzdCB0byBtYWtlIGl0IGEgMyBvciA0IGJp dHMgZmllbGQgYW5kIGV4dGVuZCB0aGUNCj4gcmVzZXJ2ZWQNCj4gICAgID4gZmllbGQuDQo+IA0K PiAgICAgQWN0dWFsbHkgSSB0aG91Z2h0IHRoYXQgaWYgd2Ugd2FudCB0byBleHRlbmQgdGhlIG9w dGlvbiBpbiB0aGUgZnV0dXJlLCBpdCBpcw0KPiBiZXR0ZXIgdG8gaW5kaWNhdGUgdGhlIGxlbmd0 aCBvZiB0aGUgcHVibGljIGtleSBhcyBmb2xsb3dzOg0KPiANCj4gICAgICAgIHwgICAgIFR5cGUg ICAgICB8ICAgIExlbmd0aCAgICAgfCBSZXNlcnZlZHwgIFB1YmxpYyBLZXkgTGVuZ3RoICB8DQo+ IA0KPiAgICAgV2hlcmU6DQo+IA0KPiAgICAgUHVibGljIEtleSBMZW5ndGg6IDEzLWJpdCB1bnNp Z25lZCBpbnRlZ2VyLiBUaGUgbGVuZ3RoIG9mIHRoZSBQdWJsaWMgS2V5IGZpZWxkDQo+IGluIGJ5 dGVzLg0KPiAgICAgUHVibGljIEtleTogIEEgdmFyaWFibGUtbGVuZ3RoIGZpZWxkLCBzaXplIGlu ZGljYXRlZCBpbiB0aGUgUHVibGljIEtleSBMZW5ndGgNCj4gZmllbGQuDQo+ICAgICAgICAgICAg CSAgICAgSldLLUVuY29kZWQgUHVibGljIEtleSBbUkZDNzUxN10NCj4gICAgID5QYWRkaW5nOiAg QSB2YXJpYWJsZS1sZW5ndGggZmllbGQgY29tcGxldGluZyB0aGUgUHVibGljIEtleSBmaWVsZCB0 byBhbGlnbiB0bw0KPiB0aGUgbmV4dCA4LWJ5dGVzIGJvdW5kYXJ5Lg0KPiANCj4gDQo+ICAgICBX b3Jrcz8NCj4gDQo+IA0KPiANCj4gICAgID4NCj4gICAgID4gLS0gU2VjdGlvbiA2LjEgLS0NCj4g ICAgID4gQWJvdXQgIk5vbmNlIG9wdGlvbiBNVVNUIGNvbnRhaW4gYSByYW5kb20gTm9uY2UgdmFs dWUgdGhhdCB3YXMgbmV2ZXINCj4gdXNlZA0KPiAgICAgPiB3aXRoIHRoaXMgZGV2aWNlIiwgaG93 IGNhbiBpdCBiZSBkb25lPyBLZWVwaW5nIGEgbG9jYWwgaGlzdG9yeT8gR2l2aW5nDQo+IHNvbWUN Cj4gICAgID4gb3BlcmF0aW9uYWwgaGludHMgd291bGQgYmVlIHdlbGNvbWUuIEVzcGVjaWFsbHks IHdoZW4gdGhlcmUgYXJlIG11bHRpcGxlDQo+IDZMUiBpbg0KPiAgICAgPiB0aGUgTExOOiBob3cg Y2FuIHRoZXkgc3luY2hyb25pemUgdGhlIG5vbmNlPw0KPiANCj4gICAgIFRoZSBub25jZSBpcyB1 c2VkIG9uY2UsIHNvIHRoZXJlJ3Mgbm8gc3luY2hyb25pemF0aW9uLiBBIG5ldyBwYWlyIGlzIGZv cm1lZA0KPiBhbmQgZXhjaGFuZ2VkIGF0IGVhY2ggdmFsaWRhdGlvbi4NCj4gDQo+ICAgICBUaGUg bm9uY2UgZ2FtZSB1c2VkIGhlcmUgYXBwZWFyIHRvIGJlIGNvbW1vbiBwcmFjdGljZS4gWWVzLCB0 aGVyZSdzDQo+IHVzdWFsbHkgYSBuZWVkIG9mIGxvY2FsIGhpc3RvcnksIGFuZCB0aGUgZmFjdCB0 aGF0IHdlIGdldCBhIG5vbmNlIGZyb20gYm90aA0KPiBzaWRlLCBhcGFydCBmcm9tIGd1YXJhbnRl ZWluZyB0aGF0IHRoZSByZXN1bHQgaXMgZWZmZWN0aXZlbHkgdW5pcXVlIHRvIGJvdGgNCj4gcGFy dGllcywgYWxzbyBtYWtlcyB0aGUgY2hhbmNlcyBmb3IgaGlzdG9yeSB0byByZXBlYXQgdmVyeSBs b3cuDQo+IA0KPiAgICAgQ0MnaW5nIFNFQy1ESVI6IFBsZWFzZSBoZWxwOiBpZiB0aGVyZSBpcyBh IHJlZmVyZW5jZSBmb3IgdGhhdCBwcmFjdGljZSwgd2hhdCBpdA0KPiB0YWtlcyB0byBtYWludGFp biBhIG5vbmNlLCBhbmQgd2h5IHdlIGhhdmUgYSBub25jZSBmcm9tIGJvdGggc2lkZXM/IFRyeWlu Zw0KPiB0byByZWludmVudCB0aGF0IHRleHQgZG9lcyBub3QgbG9vayBsaWtlIGEgZ29vZCBpZGVh IGZvciB0aGlzIGRyYWZ0Lg0KPiANCj4gDQo+IA0KPiAgICAgPg0KPiAgICAgPiAtLSBSZWZlcmVu Y2VzIC0tDQo+ICAgICA+IElzIHRoZXJlIGEgcmVhc29uIHdoeSB0aGUgY3J5cHRvIGFsZ29yaXRo bXMgUkZDIDc3NDggYW5kIDgwMzIgYXJlIG5vdA0KPiAgICAgPiBub3JtYXRpdmU/DQo+IA0KPiAg ICAgSW50ZXJlc3RpbmdseSB0aGV5IGFyZSBpbmZvcm1hdGlvbmFsLiBTbyB0aGF0IHdvdWxkIGJl IGEgZG93bnJlZi4NCj4gDQo+ICAgICBDQydpbmcgU0VDLURJUjogUGxlYXNlIGhlbHA6IHNob3Vs ZCB3ZSBtYWtlIHRoZXNlIHJlZnMgbm9ybWF0aXZlPw0KPiANCj4gDQo+ICAgICA+DQo+ICAgICA+ ID09IE5JVFMgPT0NCj4gICAgID4NCj4gICAgID4gLS0gU2VjdGlvbiAyLjIgLS0NCj4gICAgID4g VG8gYmUgaG9uZXN0LCBJIGFtIG5vdCBhIGJpZyBmYW4gb2Ygc2ltcGx5IGFubm91bmNpbmcgY29u Y2VwdHMgYW5kDQo+IHJlZmVycmluZyB0bw0KPiAgICAgPiBtYW55IG90aGVyIFJGQ3MuIFN1Z2dl c3QgdG8gbWVudGlvbiB3aGljaCB0ZXJtcyBhbmQgY29uY2VwdHMgYXJlDQo+IGRlZmluZWQgaW4N Cj4gICAgID4gZWFjaCBkb2N1bWVudC4gRWxzZSwgdGhlIGN1cnJlbnQgc2VjdGlvbiAyLjIgbW9z dGx5IGZvcmNlcyB0aGUgcmVhZGVycyB0bw0KPiByZWFkDQo+ICAgICA+IGFsbCB0aGUgcmVmZXJl bmNlcy4NCj4gDQo+ICAgICBZZXMgYW5kIHRoZXkgYXJlIHJlYWxseSB0aGVyZSBhcyBhZGRpdGlv bmFsIHJlYWRpbmcsIG5vdCBub3JtYXRpdmUuDQo+ICAgICBJIGNoYW5nZWQgdGhlIHRleHQgdG8N Cj4gICAgICIgVGhlIHJlYWRlciBtYXkgZ2V0IGFkZGl0aW9uYWwgY29udGV4dCBmb3IgdGhpcyBz cGVjaWZpY2F0aW9uIGZyb20gdGhlDQo+IGZvbGxvd2luZyByZWZlcmVuY2VzIg0KPiAgICAgSSBh bHNvIG1vdmVkIGNsYXNzaWNhbCBORCBhbmQgU0VORCByZWZlcmVuY2VzIHRvIGluZm9ybWF0aW9u YWwgcmVmZXJlbmNlcy4NCj4gDQo+ICAgICBXb3Jrcz8NCj4gDQo+ICAgICA+IC0tIFNlY3Rpb24g NiAtLQ0KPiAgICAgPiBzL21heSB1c2UgYSBzYW1lIENyeXB0by1JRC9tYXkgdXNlIHRoZSBzYW1l IENyeXB0by1JRC8gPw0KPiANCj4gICAgIERvbmUNCj4gDQo+ICAgICBNYW55IHRoYW5rcyBhZ2Fp biBFcmljIQ0KPiANCj4gICAgIExldCdzIHNlZSB3aGF0IFNFQy1ESVIgdGhpbmtzDQo+IA0KPiAg ICAgQW5kIGEgdmVyeSBoYXBweSBuZXcgeWVhciAoaW4gRnJhbmNlIHdlIGhhdmUgdGlsbCBKYW4g MzFzdCB0byBzZW5kIHdpc2hlcw0KPiDwn5iJKQ0KPiANCj4gICAgIFBhc2NhbA0KPiANCj4gDQo+ IA0KPiANCg0K From nobody Fri Jan 31 11:14:06 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20162120BD4; Fri, 31 Jan 2020 11:13:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=NWkbP4+m; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=gna4JwPV Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uVlAs1nWRmv; Fri, 31 Jan 2020 11:13:55 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7703B1200F6; Fri, 31 Jan 2020 11:13:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9530; q=dns/txt; s=iport; t=1580498035; x=1581707635; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pg+igjlmU92yDNhHvdc2wwgBKJCZG9hTSKoChc/73Nk=; b=NWkbP4+mtkvPKNRFTQsOwZ/lAP4WGwGdaBJlZTZkIIRhillsBV/xMXGE t7USHEYMxJl6G0lqaRwXUxkJBE4w/VzVE4h/uVP1c2Y7bgklOfEPNGrdM POQGBE4N54brZmiQOM1MUxENYAo3TYA/NChZVaujxrUtNhGg3CA5zfAwO 0=; IronPort-PHdr: =?us-ascii?q?9a23=3AB5J8NRDt84nMaMcQOBaTUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs13kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuIeD7aSc5EexJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CDAAAcfDRe/4UNJK1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBEQEBAQEBAQEBAQEBgXuBVFAFbFggBAsqhBSDRgOKdII6JZg?= =?us-ascii?q?PglIDVAkBAQEMAQEjCgIBAYRAAheCGiQ4EwIDDQEBBAEBAQIBBQRthTcMhWY?= =?us-ascii?q?BAQEBAxIREQwBATcBCwQCAQYCEQQBAQECAiYCAgIwFQUDCAIEAQ0FIoMEAYJ?= =?us-ascii?q?KAy4BDpIukGYCgTmIYnWBMoJ/AQEFgTMCg1UYggwDBoEOKoUehT+BQxqBQT+?= =?us-ascii?q?BEScMFIJMPoJkAgIagUcXgnkygiyNYYI6O54ecAqCO5Y/G4JIiA2ESIcjhEW?= =?us-ascii?q?DSYsXmxgCBAIEBQIOAQEFgWkigVhwFWUBgkFQGA2OHQkaFYM7hRSFP3SBKYp?= =?us-ascii?q?fLYIUAQE?= X-IronPort-AV: E=Sophos;i="5.70,386,1574121600"; d="scan'208";a="419580033" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 31 Jan 2020 19:13:54 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 00VJDsBF021122 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 31 Jan 2020 19:13:54 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 31 Jan 2020 13:13:53 -0600 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 31 Jan 2020 13:13:53 -0600 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 31 Jan 2020 13:13:53 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eNpaybjzvKmRQFQs/VivsSbgtYbgwEeK9BmeuzpJ/DG4w0azF1g249XswaH6LaecRj3Ic8fByTkgJ4RtU81uv0ThyiL25f0uYME/DLx4D5K7dqiu56JGVSDv9T0ycHuCN9BsK/6TEUMCJp0S/H/XPTiV5YTJ8lD31y4jUbCU36eoUJnq63jZdEBhXZnnjbEZVqIadPU/Ldn6JGb/F3fpP5DQI8+CIKHexL+I5Mf6OsNr3XVvndaoWwS3DcfmDtZ53W/r6RR2Mip5k7G9NSDMoPrdryFSCGIT7DlguMhXQgxjFr0HpZf22uYQW8nrl0akp0BrVTDMqnR6NPH9xHPCXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pg+igjlmU92yDNhHvdc2wwgBKJCZG9hTSKoChc/73Nk=; b=TvVH7/fjSzEnzBDhl47prwRbzH+dDnDV1d2mYiAYEccLJiPUawWdoTeMgxOdQHpXsJlgEhSylK6lwICNoOrX8ZM0q6BUSDRcTBbPJtJ8ic+6t/J398VwoB0qXbHoXbPMxK+VjU3Ci3BBWlTtZTmi/A0llz1aGx9uKA05iPwToh8HIs1utvq/vcKKAo4QVGhGvo6xe59Y6nM9qmlztudRqxL3PrWa6Lu3mynt5IGTZqxLpuLj4SJZTHh5k1aam20FFm2DwClmZrmuwt6huBhCkZWmxVHhV1ssaeDXfNLVnEMj0IGEyDQvKgkvsEoRnVUPgcYHFKI5O/77IPGugFw/2Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pg+igjlmU92yDNhHvdc2wwgBKJCZG9hTSKoChc/73Nk=; b=gna4JwPVgDv9/oiiUzqLow+9GzqWyMCrtok3CIOjjVlvtIVcMCARywEQUOWlFa9qr3HxUlvZ0gFpb0XRx9Q0esFwi77119dXNc/Hg1uQM3Y2F9w/36udTBLLcqedZzJSnBdgc/GweyMF9Xkyqxgq671/7ORuDfauXwMzmYvPESk= Received: from DM5PR11MB1753.namprd11.prod.outlook.com (10.175.88.141) by DM5PR11MB2043.namprd11.prod.outlook.com (10.168.105.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.20; Fri, 31 Jan 2020 19:13:52 +0000 Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::bcaa:91e6:c27b:b8ff]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::bcaa:91e6:c27b:b8ff%11]) with mapi id 15.20.2665.027; Fri, 31 Jan 2020 19:13:52 +0000 From: "Eric Vyncke (evyncke)" To: "Pascal Thubert (pthubert)" , The IESG CC: "draft-ietf-6lo-ap-nd@ietf.org" , "Shwetha Bhandari (shwethab)" , "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>, "secdir@ietf.org" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLTZsby1hcC1u?= =?utf-8?Q?d-13:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHV1rol7hp9w1bEa06QELjbj0JyDqgB2d0AgAK5cICAAF7XAA== Date: Fri, 31 Jan 2020 19:13:51 +0000 Message-ID: <3CB5DBCB-8BC5-41BE-8850-64C2AC8FA2E5@cisco.com> References: <158030752268.2728.2544838912831012540.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:69ec:3c1b:61a1:52be] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1a810735-ab02-42fb-14ee-08d7a681b57f x-ms-traffictypediagnostic: DM5PR11MB2043: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 029976C540 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(39860400002)(136003)(346002)(396003)(199004)(189003)(33656002)(224303003)(71200400001)(478600001)(966005)(8936002)(81166006)(316002)(110136005)(54906003)(81156014)(91956017)(5660300002)(76116006)(66946007)(66476007)(66556008)(64756008)(66446008)(86362001)(2906002)(36756003)(4326008)(450100002)(2616005)(186003)(6512007)(6486002)(53546011)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB2043; H:DM5PR11MB1753.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: UnZEoNuiqQemD3y1EFKq/imaUK3HjDEs/21YjuxqyT2I15sFatwzglw1n8nk9eejlyZVjvMe9JxP23C9cJARGsYFfdUHLacPVxACo9nGeY3JxpHnkBzuY8GQxazegWntWXstvBbFgLEvY0TPXbPsgnerSJxanwqQ7zW3EXGrRM1NMM/oTFa6I5Qi9bMXLVoExaSu92+kFqAaoqtNUKqXynURy/ovmR2EFilmZY8CowSpfUmmrmvk01NPfvODWkoDQlt1Aaagy+lnyXOrDdS8QMcP56i1APlq/OTfiVsmHs5dKujqq210xPrcDDSfpkrfkUuSlnMfxAS1E2Ns575ZF6MtXVk8JFYUU6A+7pIgB7jLtpE0RVeupTBUREiug3itI+27l7njibK0gZcMI9r/yffmBIEAzaRqdbFbsjyASW5A/ALZvuLSZdel7V42KVcsQT4kJH8wIhDq/J3bwaT7RyFvoTchDVjYxTPz0VRWhRdHdetsRPBDSd8cKpNHMNbB+Zf/6LKprBYJZpRBNjEK0g== x-ms-exchange-antispam-messagedata: oR3zJeYvvXdPX2K6ybjhlItYejluIh3Z2+FMQKagPm4IjLx/nET/bTg2HuX4t3mrBF+1cpIsBvorm/Efr1av4qSY9TKm7BJhXSNAz2GCfmJS9f58+KpuVfVVOOGMv8jJi8vBkFEl3JMYl+JKi9Ae/vze7XP22Bnb1y0qL6q0C+ZaOmSd6AO7AX86EqfvdvS5YY5TheWbrDAFacgUDPVTCA== Content-Type: text/plain; charset="utf-8" Content-ID: <0DC5C864E965B04E97BAD62864726B73@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 1a810735-ab02-42fb-14ee-08d7a681b57f X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2020 19:13:51.7783 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: R8NnrH9hOzwNUHmJ1A8Z69nCWs3aiq576PUKQR55wvQW6zzDF8VqeEZuNl0cEIoBRiNYt2Cibxn1FgScEfgEnw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB2043 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: Re: [secdir] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-6l?= =?utf-8?q?o-ap-nd-13=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 19:14:01 -0000 VGhhbmsgeW91IHZlcnkgbXVjaCBQYXNjYWwgYW5kIHRoZSBvdGhlciBhdXRob3JzLg0KDQpBcyBz b29uIGFzIEkgYW0gYmFjay1vbmxpbmUsIEkgYW0gY2xlYXJpbmcgbXkgRElTQ1VTUy4NCg0KLcOp cmljDQoNCu+7v09uIDMxLzAxLzIwMjAsIDExOjIyLCAiUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0 KSIgPHB0aHViZXJ0QGNpc2NvLmNvbT4gd3JvdGU6DQoNCiAgICBIZWxsbyBFcmljOg0KICAgIA0K ICAgIEFnYWluIG1hbnkgdGhhbmtzIGZvciB5b3VyIHJldmlldyA6ICkNCiAgICANCiAgICBJIGp1 c3QgcHVibGlzaGVkIDE0LCBhbmQgYWRkZWQgdGV4dCBvbiB0aGUgTm9uY2UgdG8gcmVtb3ZlIHRo ZSBpbXBvc3NpYmxlIG11c3QuIFdlIHRhbGtlZCBiZXR3ZWVuIGF1dGhvcnMgYW5kIHRoZSBpbmRp Y2F0aW9uIGlzIHNhbWUgYXMgUkZDIDM5NzEgdGhhdCB0aGlzIHNob3VsZCBiZSBhIHJhbmRvbS4N CiAgICBUaGUgcXVhbGl0eSBvZiB0aGUgcmFuZG9tIGlzIGxpbmtlZCB3aXRoIHRoZSBzZWN1cml0 eSBsZXZlbCB0aGF0IGNhbiBiZSBvYnRhaW5lZCBmcm9tIGl0LiBDb3VwbGluZyByYW5kb21zIGZy b20gYm90aCBwYXJ0aWVzIGxhcmdlbHkgaW5jcmVhc2VzIHRoZSBwcm90ZWN0aW9uLCBidXQgaW4g YW4gSU9UIG5ldHdvcmsgdGhhdCByZWJvb3RzLCB0aGVyZSBpcyBzdGlsbCBhIHJpc2sgb2YgYSBy ZXBsYXkuDQogICAgQWxsIGluIGFsbCB3ZSBnaXZlIHRoZSBnZW5lcmFsIGRpcmVjdGlvbiBvZiB0 aGUgcmFuZG9tLCBidXQgYWxsb3cgYW4gZXZlciBpbmNyZWFzaW5nIHZhbHVlIGFzIHdlbGwsIHdo aWNoIGlzIHNpbXBsZXIgdG8gb2J0YWluIGZvciBhIG5vZGUgYW5kIHlpZWxkcyB0aGUgc2FtZSBO b25jZSBiZW5lZml0cy4NCiAgICANCiAgICBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lv biBpcyBhdmFpbGFibGUgYXQ6IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1pZXRmLTZsby1hcC1uZC0xNA0KICAgIA0KICAgIFBsZWFzZSBsZXQgdXMga25vdyBpZiB0aGUg dGV4dCBub3cgY29uZm9ybXMgeW91ciBleHBlY3RhdGlvbnM/DQogICAgDQogICAgTWFueSB0aGFu a3MgYWdhaW4NCiAgICANCiAgICBQYXNjYWwNCiAgICANCiAgICANCiAgICA+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQogICAgPiBGcm9tOiBFcmljIFZ5bmNrZSAoZXZ5bmNrZSkgPGV2eW5j a2VAY2lzY28uY29tPg0KICAgID4gU2VudDogbWVyY3JlZGkgMjkgamFudmllciAyMDIwIDE2OjQ3 DQogICAgPiBUbzogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSA8cHRodWJlcnRAY2lzY28uY29t PjsgVGhlIElFU0cNCiAgICA+IDxpZXNnQGlldGYub3JnPg0KICAgID4gQ2M6IGRyYWZ0LWlldGYt NmxvLWFwLW5kQGlldGYub3JnOyBTaHdldGhhIEJoYW5kYXJpIChzaHdldGhhYikNCiAgICA+IDxz aHdldGhhYkBjaXNjby5jb20+OyA2bG8tY2hhaXJzQGlldGYub3JnOyA2bG9AaWV0Zi5vcmc7IHNl Y2RpckBpZXRmLm9yZw0KICAgID4gU3ViamVjdDogUmU6IMOJcmljIFZ5bmNrZSdzIERpc2N1c3Mg b24gZHJhZnQtaWV0Zi02bG8tYXAtbmQtMTM6ICh3aXRoIERJU0NVU1MNCiAgICA+IGFuZCBDT01N RU5UKQ0KICAgID4gDQogICAgPiBQYXNjYWwNCiAgICA+IA0KICAgID4gVGhhbmsgeW91IGZvciB5 b3VyIHByb21wdCByZXBseS4gSSB3aWxsIGNsZWFyIG15IERJU0NVU1MgaW4gYSBtb21lbnQgYXMg eW91DQogICAgPiB3aWxsIGNoYW5nZSB0aGUgdGV4dC4NCiAgICA+IA0KICAgID4gQWdyZWVkIG9u IGFsbCB0aGUgcG9pbnRzIGV4Y2VwdCBmb3IgdGhlICdub25jZScuIEkga25vdyB0aGUgY29uY2Vw dCBvZiBjb3Vyc2UNCiAgICA+IGJ1dCB0aGUgc2VudGVuY2UgIndhcyBuZXZlciB1c2VkIHdpdGgg dGhpcyBkZXZpY2UiIGlzIHN0aWxsIHRvbyBzdHJvbmcgSU1ITy4gVG8NCiAgICA+IGNvbXBseSwg aXQgd291bGQgcmVxdWlyZSB0byBrZWVwIHRoZSBoaXN0b3J5IGZvciBldmVyLi4uIEkgd291bGQg cHJlZmVyIGEgbGVzcw0KICAgID4gc3RyaW5nZW50IHdvcmRpbmcuDQogICAgPiANCiAgICA+IC3D qXJpYw0KICAgID4gDQogICAgPiBPbiAyOS8wMS8yMDIwLCAxNjozOCwgIlBhc2NhbCBUaHViZXJ0 IChwdGh1YmVydCkiIDxwdGh1YmVydEBjaXNjby5jb20+DQogICAgPiB3cm90ZToNCiAgICA+IA0K ICAgID4gICAgIEhlbGxvIEVyaWMgOiApDQogICAgPiANCiAgICA+ICAgICBNYW55IHRoYW5rcyBm b3IgeW91ciByZXZpZXchIEkgY2MnZWQgU0VDLURJUiBiZWNhdXNlIHdlIGNvdWxkIHJlYWxseSB1 c2UNCiAgICA+IHRoZWlyIHJlY29tbWVuZGF0aW9uIHRvIHNvbHZlIHNvbWUgb2YgeW91ciBxdWVz dGlvbnMsIG1vcmUgYmVsb3cuDQogICAgPiANCiAgICA+ICAgICBQbGVhc2Ugc2VlIGJlbG93Og0K ICAgID4gDQogICAgPiAgICAgPiA9PSBESVNDVVNTID09DQogICAgPiAgICAgPg0KICAgID4gICAg ID4gLS0gU2VjdGlvbiA0LjQgLS0NCiAgICA+ICAgICA+IFRoZSBsZW5ndGggb2YgdGhlIHJlc2Vy dmVkIGZpZWxkIGlzIG5vdCBzcGVjaWZpZWQuIE9yIGFtIEkgbWlzc2luZw0KICAgID4gc29tZXRo aW5nDQogICAgPiAgICAgPiBvYnZpb3VzID8NCiAgICA+IA0KICAgID4gICAgIEkgY29uY2F0ZW5h dGVkIHRoZSByZXNlcnZlZCBmaWVsZHMgaW4gdGhlIHBpY3R1cmUgYW5kIGRlY2xhcmVkIGl0IGFz IDQwIGJpdHMuDQogICAgPiAgICAgQWxzbyBhZGRlZCB0aGUgbnVtYmVyIG9mIGJpdHMgaW4gdGhl IHJlc2VydmVkIGZpZWxkcyBvZiBvdGhlciBzdHJ1Y3R1cmVzLg0KICAgID4gDQogICAgPiAgICAg PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQogICAgPiAgICAgPiBDT01NRU5UOg0KICAgID4gICAgID4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KICAgID4gICAgID4NCiAgICA+ICAgICA+ID09IENPTU1FTlRTID09DQogICAgPiAg ICAgPg0KICAgID4gICAgID4gLS0gU2VjdGlvbiA0LjIgLS0NCiAgICA+ICAgICA+IFdoaWxlIHN0 YXR1cyBpcyBzZXQgdG8gMCB3aGVuIHNlbmRpbmcgYSBOUywgd2hhdCBpcyB0aGUgZXhwZWN0ZWQg YmVoYXZpb3INCiAgICA+IG9mIGENCiAgICA+ICAgICA+IHJlY2VpdmVyID8NCiAgICA+IA0KICAg ID4gICAgIENoYW5nZWQgdG8NCiAgICA+ICAgICAiDQogICAgPiAgICAgSW4gTlMgbWVzc2FnZXMg aXQgTVVTVCBiZSBzZXQgdG8gMCBieSB0aGUgc2VuZGVyIGFuZCBpZ25vcmVkIGJ5IHRoZQ0KICAg ID4gcmVjZWl2ZXIuDQogICAgPiAgICAgIg0KICAgID4gDQogICAgPiAgICAgPiAtLSBTZWN0aW9u IDQuMyBhbmQgNC40IC0tDQogICAgPiAgICAgPiBXaHkgaXMgdGhlIFBhZCBMZW5ndGggZmllbGQg YSA4LWJpdCBmaWVsZCB3aGlsZSB0aGUgYWN0dWFsIHBhZGRpbmcgd2lsbA0KICAgID4gYWx3YXlz IGJlDQogICAgPiAgICAgPiBsZXNzIHRoYW4gOCBieXRlcy4gU3VnZ2VzdCB0byBtYWtlIGl0IGEg MyBvciA0IGJpdHMgZmllbGQgYW5kIGV4dGVuZCB0aGUNCiAgICA+IHJlc2VydmVkDQogICAgPiAg ICAgPiBmaWVsZC4NCiAgICA+IA0KICAgID4gICAgIEFjdHVhbGx5IEkgdGhvdWdodCB0aGF0IGlm IHdlIHdhbnQgdG8gZXh0ZW5kIHRoZSBvcHRpb24gaW4gdGhlIGZ1dHVyZSwgaXQgaXMNCiAgICA+ IGJldHRlciB0byBpbmRpY2F0ZSB0aGUgbGVuZ3RoIG9mIHRoZSBwdWJsaWMga2V5IGFzIGZvbGxv d3M6DQogICAgPiANCiAgICA+ICAgICAgICB8ICAgICBUeXBlICAgICAgfCAgICBMZW5ndGggICAg IHwgUmVzZXJ2ZWR8ICBQdWJsaWMgS2V5IExlbmd0aCAgfA0KICAgID4gDQogICAgPiAgICAgV2hl cmU6DQogICAgPiANCiAgICA+ICAgICBQdWJsaWMgS2V5IExlbmd0aDogMTMtYml0IHVuc2lnbmVk IGludGVnZXIuIFRoZSBsZW5ndGggb2YgdGhlIFB1YmxpYyBLZXkgZmllbGQNCiAgICA+IGluIGJ5 dGVzLg0KICAgID4gICAgIFB1YmxpYyBLZXk6ICBBIHZhcmlhYmxlLWxlbmd0aCBmaWVsZCwgc2l6 ZSBpbmRpY2F0ZWQgaW4gdGhlIFB1YmxpYyBLZXkgTGVuZ3RoDQogICAgPiBmaWVsZC4NCiAgICA+ ICAgICAgICAgICAgCSAgICAgSldLLUVuY29kZWQgUHVibGljIEtleSBbUkZDNzUxN10NCiAgICA+ ICAgICA+UGFkZGluZzogIEEgdmFyaWFibGUtbGVuZ3RoIGZpZWxkIGNvbXBsZXRpbmcgdGhlIFB1 YmxpYyBLZXkgZmllbGQgdG8gYWxpZ24gdG8NCiAgICA+IHRoZSBuZXh0IDgtYnl0ZXMgYm91bmRh cnkuDQogICAgPiANCiAgICA+IA0KICAgID4gICAgIFdvcmtzPw0KICAgID4gDQogICAgPiANCiAg ICA+IA0KICAgID4gICAgID4NCiAgICA+ICAgICA+IC0tIFNlY3Rpb24gNi4xIC0tDQogICAgPiAg ICAgPiBBYm91dCAiTm9uY2Ugb3B0aW9uIE1VU1QgY29udGFpbiBhIHJhbmRvbSBOb25jZSB2YWx1 ZSB0aGF0IHdhcyBuZXZlcg0KICAgID4gdXNlZA0KICAgID4gICAgID4gd2l0aCB0aGlzIGRldmlj ZSIsIGhvdyBjYW4gaXQgYmUgZG9uZT8gS2VlcGluZyBhIGxvY2FsIGhpc3Rvcnk/IEdpdmluZw0K ICAgID4gc29tZQ0KICAgID4gICAgID4gb3BlcmF0aW9uYWwgaGludHMgd291bGQgYmVlIHdlbGNv bWUuIEVzcGVjaWFsbHksIHdoZW4gdGhlcmUgYXJlIG11bHRpcGxlDQogICAgPiA2TFIgaW4NCiAg ICA+ICAgICA+IHRoZSBMTE46IGhvdyBjYW4gdGhleSBzeW5jaHJvbml6ZSB0aGUgbm9uY2U/DQog ICAgPiANCiAgICA+ICAgICBUaGUgbm9uY2UgaXMgdXNlZCBvbmNlLCBzbyB0aGVyZSdzIG5vIHN5 bmNocm9uaXphdGlvbi4gQSBuZXcgcGFpciBpcyBmb3JtZWQNCiAgICA+IGFuZCBleGNoYW5nZWQg YXQgZWFjaCB2YWxpZGF0aW9uLg0KICAgID4gDQogICAgPiAgICAgVGhlIG5vbmNlIGdhbWUgdXNl ZCBoZXJlIGFwcGVhciB0byBiZSBjb21tb24gcHJhY3RpY2UuIFllcywgdGhlcmUncw0KICAgID4g dXN1YWxseSBhIG5lZWQgb2YgbG9jYWwgaGlzdG9yeSwgYW5kIHRoZSBmYWN0IHRoYXQgd2UgZ2V0 IGEgbm9uY2UgZnJvbSBib3RoDQogICAgPiBzaWRlLCBhcGFydCBmcm9tIGd1YXJhbnRlZWluZyB0 aGF0IHRoZSByZXN1bHQgaXMgZWZmZWN0aXZlbHkgdW5pcXVlIHRvIGJvdGgNCiAgICA+IHBhcnRp ZXMsIGFsc28gbWFrZXMgdGhlIGNoYW5jZXMgZm9yIGhpc3RvcnkgdG8gcmVwZWF0IHZlcnkgbG93 Lg0KICAgID4gDQogICAgPiAgICAgQ0MnaW5nIFNFQy1ESVI6IFBsZWFzZSBoZWxwOiBpZiB0aGVy ZSBpcyBhIHJlZmVyZW5jZSBmb3IgdGhhdCBwcmFjdGljZSwgd2hhdCBpdA0KICAgID4gdGFrZXMg dG8gbWFpbnRhaW4gYSBub25jZSwgYW5kIHdoeSB3ZSBoYXZlIGEgbm9uY2UgZnJvbSBib3RoIHNp ZGVzPyBUcnlpbmcNCiAgICA+IHRvIHJlaW52ZW50IHRoYXQgdGV4dCBkb2VzIG5vdCBsb29rIGxp a2UgYSBnb29kIGlkZWEgZm9yIHRoaXMgZHJhZnQuDQogICAgPiANCiAgICA+IA0KICAgID4gDQog ICAgPiAgICAgPg0KICAgID4gICAgID4gLS0gUmVmZXJlbmNlcyAtLQ0KICAgID4gICAgID4gSXMg dGhlcmUgYSByZWFzb24gd2h5IHRoZSBjcnlwdG8gYWxnb3JpdGhtcyBSRkMgNzc0OCBhbmQgODAz MiBhcmUgbm90DQogICAgPiAgICAgPiBub3JtYXRpdmU/DQogICAgPiANCiAgICA+ICAgICBJbnRl cmVzdGluZ2x5IHRoZXkgYXJlIGluZm9ybWF0aW9uYWwuIFNvIHRoYXQgd291bGQgYmUgYSBkb3du cmVmLg0KICAgID4gDQogICAgPiAgICAgQ0MnaW5nIFNFQy1ESVI6IFBsZWFzZSBoZWxwOiBzaG91 bGQgd2UgbWFrZSB0aGVzZSByZWZzIG5vcm1hdGl2ZT8NCiAgICA+IA0KICAgID4gDQogICAgPiAg ICAgPg0KICAgID4gICAgID4gPT0gTklUUyA9PQ0KICAgID4gICAgID4NCiAgICA+ICAgICA+IC0t IFNlY3Rpb24gMi4yIC0tDQogICAgPiAgICAgPiBUbyBiZSBob25lc3QsIEkgYW0gbm90IGEgYmln IGZhbiBvZiBzaW1wbHkgYW5ub3VuY2luZyBjb25jZXB0cyBhbmQNCiAgICA+IHJlZmVycmluZyB0 bw0KICAgID4gICAgID4gbWFueSBvdGhlciBSRkNzLiBTdWdnZXN0IHRvIG1lbnRpb24gd2hpY2gg dGVybXMgYW5kIGNvbmNlcHRzIGFyZQ0KICAgID4gZGVmaW5lZCBpbg0KICAgID4gICAgID4gZWFj aCBkb2N1bWVudC4gRWxzZSwgdGhlIGN1cnJlbnQgc2VjdGlvbiAyLjIgbW9zdGx5IGZvcmNlcyB0 aGUgcmVhZGVycyB0bw0KICAgID4gcmVhZA0KICAgID4gICAgID4gYWxsIHRoZSByZWZlcmVuY2Vz Lg0KICAgID4gDQogICAgPiAgICAgWWVzIGFuZCB0aGV5IGFyZSByZWFsbHkgdGhlcmUgYXMgYWRk aXRpb25hbCByZWFkaW5nLCBub3Qgbm9ybWF0aXZlLg0KICAgID4gICAgIEkgY2hhbmdlZCB0aGUg dGV4dCB0bw0KICAgID4gICAgICIgVGhlIHJlYWRlciBtYXkgZ2V0IGFkZGl0aW9uYWwgY29udGV4 dCBmb3IgdGhpcyBzcGVjaWZpY2F0aW9uIGZyb20gdGhlDQogICAgPiBmb2xsb3dpbmcgcmVmZXJl bmNlcyINCiAgICA+ICAgICBJIGFsc28gbW92ZWQgY2xhc3NpY2FsIE5EIGFuZCBTRU5EIHJlZmVy ZW5jZXMgdG8gaW5mb3JtYXRpb25hbCByZWZlcmVuY2VzLg0KICAgID4gDQogICAgPiAgICAgV29y a3M/DQogICAgPiANCiAgICA+ICAgICA+IC0tIFNlY3Rpb24gNiAtLQ0KICAgID4gICAgID4gcy9t YXkgdXNlIGEgc2FtZSBDcnlwdG8tSUQvbWF5IHVzZSB0aGUgc2FtZSBDcnlwdG8tSUQvID8NCiAg ICA+IA0KICAgID4gICAgIERvbmUNCiAgICA+IA0KICAgID4gICAgIE1hbnkgdGhhbmtzIGFnYWlu IEVyaWMhDQogICAgPiANCiAgICA+ICAgICBMZXQncyBzZWUgd2hhdCBTRUMtRElSIHRoaW5rcw0K ICAgID4gDQogICAgPiAgICAgQW5kIGEgdmVyeSBoYXBweSBuZXcgeWVhciAoaW4gRnJhbmNlIHdl IGhhdmUgdGlsbCBKYW4gMzFzdCB0byBzZW5kIHdpc2hlcw0KICAgID4g8J+YiSkNCiAgICA+IA0K ICAgID4gICAgIFBhc2NhbA0KICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4gDQogICAgDQog ICAgDQoNCg==