From nobody Thu Apr 1 08:16:59 2021 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39BE83A179C; Thu, 1 Apr 2021 08:16:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: opsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: opsec@ietf.org Message-ID: <161729021819.12435.16878383097735524331@ietfa.amsl.com> Date: Thu, 01 Apr 2021 08:16:58 -0700 Archived-At: Subject: [OPSEC] I-D Action: draft-ietf-opsec-v6-25.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2021 15:16:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure WG of the IETF. Title : Operational Security Considerations for IPv6 Networks Authors : Eric Vyncke Kiran Kumar Merike Kaeo Enno Rey Filename : draft-ietf-opsec-v6-25.txt Pages : 57 Date : 2021-04-01 Abstract: Knowledge and experience on how to operate IPv4 networks securely is available: whether it is the Internet or an enterprise internal network. However, IPv6 presents some new security challenges. RFC 4942 describes the security issues in the protocol, but network managers also need a more practical, operations-minded document to enumerate advantages and/or disadvantages of certain choices. This document analyzes the operational security issues associated with several types of network and proposes technical and procedural mitigation techniques. This document is only applicable to managed networks, such as enterprise networks. The recommendations in this document are not applicable to residential user cases, even in cases where a Service Provider may be managing the home gateway. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-opsec-v6-25 https://datatracker.ietf.org/doc/html/draft-ietf-opsec-v6-25 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-v6-25 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 1 08:55:03 2021 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E943A199F; Thu, 1 Apr 2021 08:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.918 X-Spam-Level: X-Spam-Status: No, score=-11.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=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=YRGNEMxD; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=LJI3iBHk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owp90IC8OTM0; Thu, 1 Apr 2021 08:54:52 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03FC13A1999; Thu, 1 Apr 2021 08:54:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4446; q=dns/txt; s=iport; t=1617292492; x=1618502092; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FlkuuY5MdKkfzn5Bpxa9uhcSSrfVK9YP8NwHMFCFSMI=; b=YRGNEMxDo+3JsfSL6pqCKFGVKXnRRTiZAiJfVsa9D7P22mYNG/ATjJAS jLvCA1ur7iRRm72Gfol2MsnRuqM8fkCCiUGhDgEjDDLu3YHB/chjoXhkX Kl/ylVimqhtyhCuItl1hhzAaPMjTJi8siaf6f87/lleMOjMLsSRtzUMA8 w=; X-IPAS-Result: =?us-ascii?q?A0BbAwBP62VgmJpdJa1aHgEBCxIMQIMjUX5aNjEChECDS?= =?us-ascii?q?AOFOYhOA4orjwuBQoERA1QLAQEBDQEBKAoCBAEBhFACF4FkAiU4EwIDAQEBA?= =?us-ascii?q?wIDAQEBAQEFAQEBAgEGBBQBAQEBAQEBAYY2DYZEAQEBAQMjEQwBATcBCwQCA?= =?us-ascii?q?QgRAwECAwImAgICHxEUAQgIAgQBDQWCcQGCVQMvAQ6fbQKKH3eBMoMEAQEGh?= =?us-ascii?q?RQNC4ITCYEPKoJ2gnESPkiGSyYcgUlCgRInHIJZPoIeNwsCgSkBEgGDNzWCK?= =?us-ascii?q?4FPN4EoBFIjXRkIOQoEAgEXBgsZBQELkGKDWYt0mW5bCoMJiE+BEI1dBIUxA?= =?us-ascii?q?x+DS4E+iTmWJ5UQi2WDFo83IIRIAgICAgQFAg4BAQaBayFrcHAVZQGCPglHF?= =?us-ascii?q?wINjh8Zg1eFFIVFcwILKwIGAQkBAQMJfI1MAQE?= IronPort-PHdr: A9a23:i2wGQRXG46twOVqGXkAiAQ5hhIHV8K0OAWYlgqEPgq9Scqml45XpN VDe4vMollLSQIHH8JpsgOvNuKemUmsFst6Ns3EHJZpLURJNycAbhBcpD8PND0rnZOXrYCo3E IUnNhdl8ni3PFITFJP4YFvf8Xaz9jUVXB74MFk9KuH8AIWHicOx2qi78IHSZAMdgj27bPtyI Ry6oB+XuNMRhN5pK706zV3CpX4bE9k= IronPort-HdrOrdr: A9a23:NUADrqiJSsv3cekCmZQn8hjjIXBQX8tx3DAbvn1ZSRFFG/Gwv/ uF2NwGyB75jysQUnk8mdaGfJKNW2/Y6IQd2+gsFJ+Ydk3DtHGzJI9vqbHjzTrpBjHk+odmu5 tIW5NVTOf9BV0St6nHySGzGdo43Z2j+Kenme/Rwx5WPH5XQotLhj0JbTqzOEtwWQVAGN4YOf Onl4p6jhCnfmkaadn+I3EDUfTKqdGjruOZXTctARk75A6SyQ6y4LnhHBSCmjsYWTVDwbAtmF K10DDRzKOlrv2911vgx3behq4m2efJ5/liIIi3isYTIijxkQrAXuRccpCLoTxdmpDV1H8Ei9 /Jyi1QWvhby3SURW2tpAuo5g+I6kdT11bH6Xu1xUTuutb4QjVSMbsCuat8fgHC40Qt+PFQuZ g7pV6xjJZcARPekCmV3bGhPHsG+jvW0BgfuNUegHBFXYwVZKU5l/1jwGpuDJwCECjmgbpXdt VGMcDG6P5aNXOcYnzJ11MfuOCEY3UpEh+KBnUFo8yeugIm5UxR8k1w/r16ol4wsLYGD7VU7e XNNapl0JtUSNUNUK57DOAdBeOqF23kW3v3QSevCGWiMJtCF2PGqpbx7rlwzvqtYoY0wJw7n4 mEeE9EtFQ1Z1nlBaS1rdl22yGIZF/4cSXmy8lY6ZQ8kKb7XqDXPSqKT01rtMe8vfMFAIn+V+ yoMJxbR9/vRFGeXrph7knbYd1/OHMeWMoatpIQQFSVuP/GLYXsq6jVa/DWKL3xESs1W2/2D3 cZNQKDfflo3wSOYDvVkRLRU3TidgjU5pRrCpXX+OAV1cwMO+R3w1AooGX8wvvOBSxJs6Qwck c7CqjgiLmHqW6/+nuN621oPxFaH1tE+bmIaQIQmSY6d2fPNZoTsdSWfm5fmFGdIAVkcs/QGA lD41Jt+ay2KJSUzTs4C82uN3+bi3d7ngPNc74s3om4oev1cJIxCZgrHIZrEx/QKhBzkQF27H tYZBQcXU/ZHDP2gaCjhJgZbduvLeVUsUOOG4p5uHjfvUKTqYUTXXMdRSepStPSqx0pXSBoil p49LI/jLKMlS20E3Y2hP01PTR3GTmqKYMDKD7ARY1P3pj3ZQl7TA6x9E2noiB2XlCvymI/qS jKKzaOdfTCH1xH00oooprCwRdTbWWSf0V5d3Zgl5ZyfF625kpb4Kusere51XeXZx8kxOwQWQ u1Pwc6E0dJ28290gKTlXK5MUgegr8qPuDbEd0YAu7u83uwNYyFkrwHFfdI/JBjcMvjqPMPTP j3QX7mEBrlEe8znwSaqnE5URME20UMgLfm3gbo43O/22N6Cf3OIE5+T7VeON2E6XP4Lsz4n6 lRnJYwveGqNH/2ZcPDwabLbyRbIhe7mx/6c8g47ZRVt7k1rr19At3SVibJzmhO2FE7IN3vnE 0TBKR977apAP4iQ+UCPyZY9EEujtKBMQ8itRH3GPY3eRU1lGDAVun5q4bguP4qGAmMtQHwMV 6Q/2lU+OrERTKK0fofB7grKWpbZUAg4B1Zja2/XpyVDB/ve/BI/VK8PHP4arNbRaSfEbgbrx px4biz7qWqXju93BqVsSpwI6pI/WriXNi7BxiUH/VUt9O9IlaBj8KRkYeOpSayTSH+bUsWhY dILxNNKstCjyQvl40x3Gy5TLftrkcsjltZ5nVmmzfWq/+byXaeGVsDNwvTxohSV31UNHODiM ze6+iW1Hjn+lF+qNL+PVYVessLAsQaS4j8MjxnJscRtqO55qZHuFU2XD4+S2onzC3n1+xo3b 2lyOzfVu3rB3DvI08A81d+d/hJtz1ur3pBfci45Y+8ZQtSFvdgOYpL2rxr X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,296,1610409600"; d="scan'208";a="669599162" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Apr 2021 15:54:50 +0000 Received: from mail.cisco.com (xbe-aln-001.cisco.com [173.36.7.16]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 131FsoiS014598 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Thu, 1 Apr 2021 15:54:50 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xbe-aln-001.cisco.com (173.36.7.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Thu, 1 Apr 2021 10:54:50 -0500 Received: from xfe-rcd-003.cisco.com (173.37.227.251) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 1 Apr 2021 11:54:41 -0400 Received: from NAM04-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Thu, 1 Apr 2021 10:54:41 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=StlLZrabauBawttOSY///HXeG1dD1HzzYxym7myfdAgEx+ByRutdyiafu6Z2nIQrFkTZW4IxEguMgmDL5wBhRlEloPzfDTAYsdYvZ8ZOwsvebv7eNLg04s6uAUFOyzS3Timc+zzN712+hCpKMVdoGPwpDM8kjnXORbzKCNS5YRMmUcYt9nKnr0PVCDMSgnczEXhiIa2NTG6j+TH5mXmiAdANMBAH/esELvnhg344x2mntsOEatK162hJyCr1M13F4IaDalBqwWU68tadHXJgRYQKZ960/OR1d/tM/+vVMm1rjyNR0lLOA18K8PJKY9UYl13FRhODtU6BI+I2E76rGA== 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=FlkuuY5MdKkfzn5Bpxa9uhcSSrfVK9YP8NwHMFCFSMI=; b=OwLEP0g3C3qTFVU0eVPZcXYEymG5vv5vYVblIw3JwDR1SHT+Qzg8R3T5QSIR4VsDGU1YfTTJDcpRyjmjsYrlpmpXCKlRqFoVCfdA1YPvTLQVZ8f51ZkegaXXrirZbzhgksujXhfpCw+w6LN1ISX5Xy3sGkRZscqE0/akKhEDAHrrcXl8/ALvsZeqM4xIc6axnLnZjUBd0vhn9h3Qs8J7A5IlbgDlSw+RqVDFaVPcJekwZjrqjqmpc4AFjY9cVgSKqc1GHY6kSFHGzeohFeDkxOz29rDNVkDabGlF/x6fbKUL8aalh9jbaESvqHK5XDQ7uAPYkU0L1H9mfnzjOi3KfA== 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=FlkuuY5MdKkfzn5Bpxa9uhcSSrfVK9YP8NwHMFCFSMI=; b=LJI3iBHk2V6K8J2sDl7m3g5BBT9/UqBJVqpLtsc+Noo7CVR2WtxngS63NiFwm1kCmrg6PLKWqSoGs8dXAw1P1vZcLb3siRwxxTLTBoxKB+LI273p+HkTM+3sqbeTOZ4DKjrzUHvBrjjokZvrgcXIE6XkbQSl34FkmIcabRJ3tic= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB4773.namprd11.prod.outlook.com (2603:10b6:510:33::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.27; Thu, 1 Apr 2021 15:54:40 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::dcdf:3910:b85d:6eba]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::dcdf:3910:b85d:6eba%7]) with mapi id 15.20.3999.028; Thu, 1 Apr 2021 15:54:40 +0000 From: "Eric Vyncke (evyncke)" To: "Acee Lindem (acee)" , "rtg-dir@ietf.org" CC: "draft-ietf-opsec-v6.all@ietf.org" , "last-call@ietf.org" , "opsec@ietf.org" Thread-Topic: Rtgdir last call review of draft-ietf-opsec-v6-24 Thread-Index: AQHXH++AzC/ke47HVkGH7xWxQ+OC0KqgAEyA Date: Thu, 1 Apr 2021 15:54:40 +0000 Message-ID: References: <161650914469.13419.16565124530354757829@ietfa.amsl.com> In-Reply-To: <161650914469.13419.16565124530354757829@ietfa.amsl.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.47.21031401 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:2449:d67a:d536:56f7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1a19ca78-63b7-463b-efba-08d8f52675b5 x-ms-traffictypediagnostic: PH0PR11MB4773: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: k7lR/48eUYBQymUsNTx8IZ7w64CZdYaFs8I1ENYbVcFPgqp1UT5A0B1gIx2h6TACceEDvi+KZOx8DLf1tV8P4lAuXavXPVLG4XDNHJZjN5wn+QlvYqRtIBlYiomMmusCZkn1WVDeyMyBwc2j2Oa8I0YNG5rB4MvMR5X3nMv2Chf+0H9WPYnjvGwO4iWAPGlvTGwOLzX1u2VPg68Te8DRBP6Z3fuNV/s/P1795D1YLVrPzLxHtLbJDPJlrnWN/g6jnAXJp/I49vIVkNi+liWTISw4Qcs8qpp6symOCiOjDb0ZnnvAylSK9S2ehWVrMIGmr708kbo/ckl2PKuQSZ6zhR5g+2g6uGTy/+JPbmiNjanum9OTQZKqgS5W3qNOhBX/uZF6n67hfrB6tAkNoytHq7i3TS6qh91VRR0vUskpQVXOtiy33NO0OzWu0J0iSdU5K957b8BMzFu//ul8svmhQIevBMVx4N7QX9YOJHe6x6960/T4wLLZL82g78FAB9qm9MZmO4lGdA/wS719+QIqR8z4u2NGXVnLGuert1zd35KimQjQMGIZmHMR0yi4LIb4TF8vQdC7pS30jlm840yPka7qmxY1sLqi0FIorvKl6NYPba+TPh0vb6xUDf6/wCLD1YLrVaRSYRCzOaAo59c4Y2SeoFpy0OJ00MoamGSmrWNZ9JCbn5d+ZEQqWGdEgIT/LWkFfVjOgXbTj6XKtK/24evOsCIhqBMpnlRZ+1x0jA3UejkkSrgTqQRertZV0l6VFosPvErSP55ar9hP/RXcww== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(366004)(396003)(39860400002)(376002)(136003)(2616005)(66446008)(66946007)(76116006)(91956017)(8676002)(66476007)(64756008)(66556008)(83380400001)(54906003)(110136005)(478600001)(86362001)(8936002)(316002)(6512007)(186003)(2906002)(53546011)(966005)(5660300002)(450100002)(38100700001)(6506007)(33656002)(4326008)(36756003)(6486002)(71200400001)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?eDE5VXZSWGpQeE0rTUhoekJNRWRkdnRZdWhVYmowMkFURU9OTmNxeUJYNXM1?= =?utf-8?B?QUk4Z3dXU1VrT3h1OEp6NWVFeUxLQkFPbFJNZWgxNHRZYXNsYUhWNDZzUUlw?= =?utf-8?B?WU1jNHFaT0lLTzNuOU9kYXk5RzgzQ0U5TXpNUVhaVVM3UkR0NWNveHAwTGgw?= =?utf-8?B?a2tqc3JCRERGa3Y4UFIwNWVMM09zVkFFQXc1WUllNU9HaXBSUWREMk56OW1T?= =?utf-8?B?dTVKUi96TW92MXU3YUlsc3ltcGtJS2lYYytRRVV0blNZYXZzWFIwVUdUVXdk?= =?utf-8?B?WGhibnBHOWUvc256cDZiZm4zVzN4aUxMbDlPWm9CTkk1d0M0ZXAyNEp0MkFQ?= =?utf-8?B?bXo2SGM2eGhGUktTZEVrTWhYMzFLMXVqMGtta3c3bW1velVrUmpPUlZOSHlF?= =?utf-8?B?eTlTaDgwSTVBYjZsYVBDQUVNUlI5M0x5aDB5ZzA1YXIxNm12Mm40ekM5dW84?= =?utf-8?B?VFhlZGRvZ25aRWV0cE5XcmYya2k2Y0YxS0JQVFhvN1JYbTRiVTlLQk1IWlNo?= =?utf-8?B?cHZrRzZ5dEF6eXBPOFFMNDJmTlZ1aFZva3FJRVRXS0tnK2VGWnpicFVobmUz?= =?utf-8?B?WE92U0RWUHBhb1NQaXlWbHhBV2ZFeTJuUFBZR3N0ZDA4SWZuaW5uV3B1SVFi?= =?utf-8?B?WXpibDgxZGk2V3lkVGo3dU5MTEwyaC9jZlBPV2lDRXJ3d0ZSU2tRRmVvci9m?= =?utf-8?B?b3dOS3FFRWxaYXI1YXlTdFArWlQxcFkwQ3lTYzZ6SWtpY2hJN243YlVoeE80?= =?utf-8?B?aC9ybStzTTlkQ0owQW1zMGZjOHlldnZneGV2LzNwM3lHTzJDS2FDRGsxZURI?= =?utf-8?B?UmQxbS9MTS90d3o1MFNwWW5vd1l6T3hYNGJSZzYzMGhpY1VYRTNFTHd4SDRX?= =?utf-8?B?UzdTK0Q2V3ovWjdvNVljaUthUDdGMDFROXdSTC9PUlg3R3JIRjhVZjd2M0lj?= =?utf-8?B?UkZqVFpVVHpyMENKcDlkTFpoTDluQStmdW9iMVZTZi9kTUloKzJlUkNNQVY1?= =?utf-8?B?ajRnbDQ1WGgrT2UyNzBQVTM0Zy80TU4zSTl0SEY2M1EvTWhydjR3TENBNTE3?= =?utf-8?B?WHViRmNUU1NKWktmNTAyWHkwVTVISTNkakFteUszT2dIOGM3UHNSbDBaUm5S?= =?utf-8?B?L2RlZUpLdmFWTmtPRThQV3ozaSthKzhaMHR1bFhHZk1YOUM4NmU3aTZLaW0x?= =?utf-8?B?MzlRZU14TlZta2FWbi93YnBHWEoxOVh0ZlcxOUhlbnJlRjhHU2dJYjhFSDZt?= =?utf-8?B?Yk8vaTV3RFB1MlI5bmdSR054dWZjL0FHaTB2N1p3QTQxQkowS0M4Ky9pNzQr?= =?utf-8?B?MUFKUU1LN1lYQUZNMHkzeFlIQzdUaFowd3RKWFpBQldlOVF4NTd1eDVsVnVT?= =?utf-8?B?UlFlZ0JKZDdhdnJaSGJGcVJIU1A4MXFiV09WK0hqSlhUbXlxWnFLb2hhdytL?= =?utf-8?B?ME1QZGQxOFR3VkdOTWVFRm12VmJIbFNic3U2K0prT0Vrb2c4ZkQ5VkpBVUJC?= =?utf-8?B?QkV1M1BxNWo2OFNvNGxwY1A1QW9DdDUrTm5vZXJaWmk2RUVQNjhMa3FDYkU5?= =?utf-8?B?dER3NmlBMi9CNStjMWdjRVJEdWVSeEJuVDcvdlRqV0tjU2ZteFNmTGlETGZi?= =?utf-8?B?Q2NieVdnWERla3Q5NVVZNm1yL2JMYVZVL1Y2dkV1bEVTSlVnNzFIQlRaRTY0?= =?utf-8?B?MkZQcEc0YklDRkk0Uk5XZ2dHdlpsZ2xGYXFsc3JDa25jWU9BY0FDVjcvWnNq?= =?utf-8?B?MnFjY2RBWXQwcVZBS0xtYjBhREtyREVPcnBzWi82cG1SZ0ZJNEMwZ0RTVFFi?= =?utf-8?B?TEtUUU5vb0Y1ZjFsMkFlVWFPL1ZXak5kN0Zxd1d0SXdlTFBHMXlXcDJJQ0Qw?= =?utf-8?Q?2ZAdaNjZWk/Y2?= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1a19ca78-63b7-463b-efba-08d8f52675b5 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2021 15:54:40.3712 (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: sZ+Amvz8vCdZ+aa+aGwhuqPTX5sD4gvEbGVqk9WdrCyNujQcrM39Wo8KSN86PZHEojmg8u9SJqx7k+PFwDTglw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4773 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xbe-aln-001.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [OPSEC] Rtgdir last call review of draft-ietf-opsec-v6-24 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2021 15:54:57 -0000 QWNlZSwNCg0KQmlnIHRoYW5rIHlvdSBvbiB5b3VyIG5pdHMgcmV2aWV3ISBBcyBhIG5vbi1Fbmds aXNoIHNwZWFrZXIsIEkgYWx3YXlzIHdlbGNvbWUgKGFuZCBsZWFybiBmcm9tKSBzdWNoIGEgZGV0 YWlsZWQgcmV2aWV3LiBUaGUganVzdCBwb3N0ZWQgLTI1IGhhcyBhbGwgdGhlIG5pdHMgZml4ZWQg KHBlciB5b3VyIG90aGVyIGVtYWlsKSBhbmQgd2UgdG9vayBhY3Rpb24gb24geW91ciB0d28gc3Vn Z2VzdGlvbnMgYmVsb3cuDQoNCkJUVywgd2UgYWRkZWQgYSByZWZlcmVuY2UgdG8gUkZDIDgxNzcg aW4gc2VjdGlvbiAyLjUuMyAnc2VjdXJpbmcgcm91dGluZyB1cGRhdGVzIiBhcyBpdCBzZWVtcyBt b3JlIHN1aXRhYmxlLg0KDQpSZWdhcmRzDQoNCi3DqXJpYw0KDQpQUzogaGFwcHkgdG8gaGF2ZSBh IEFwcmlsIDFzdCBJLUQsIHdoaWNoIGlzIE5PVCBhIGpva2UgOy0pDQoNCg0KDQrvu78tLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQWNlZSBMaW5kZW0gdmlhIERhdGF0cmFja2VyIDxu b3JlcGx5QGlldGYub3JnPg0KUmVwbHktVG86ICJBY2VlIExpbmRlbSAoYWNlZSkiIDxhY2VlQGNp c2NvLmNvbT4NCkRhdGU6IFR1ZXNkYXksIDIzIE1hcmNoIDIwMjEgYXQgMTU6MTkNClRvOiAicnRn LWRpckBpZXRmLm9yZyIgPHJ0Zy1kaXJAaWV0Zi5vcmc+DQpDYzogImRyYWZ0LWlldGYtb3BzZWMt djYuYWxsQGlldGYub3JnIiA8ZHJhZnQtaWV0Zi1vcHNlYy12Ni5hbGxAaWV0Zi5vcmc+LCAibGFz dC1jYWxsQGlldGYub3JnIiA8bGFzdC1jYWxsQGlldGYub3JnPiwgIm9wc2VjQGlldGYub3JnIiA8 b3BzZWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSdGdkaXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFm dC1pZXRmLW9wc2VjLXY2LTI0DQpSZXNlbnQtRnJvbTogPGFsaWFzLWJvdW5jZXNAaWV0Zi5vcmc+ DQpSZXNlbnQtVG86IEVyaWMgVnluY2tlIDxldnluY2tlQGNpc2NvLmNvbT4sIEtpcmFuIEt1bWFy IENoaXR0aW1hbmVuaSA8a2suY2hpdHRpbWFuZW5pQGdtYWlsLmNvbT4sIE1lcmlrZSBLYWVvIDxt ZXJpa2VAZG91Ymxlc2hvdHNlY3VyaXR5LmNvbT4sIDxlcmV5QGVybncuZGU+LCA8ZnVycnkxM0Bn bWFpbC5jb20+LCBSb24gQm9uaWNhIDxyYm9uaWNhQGp1bmlwZXIubmV0PiwgPHdhcnJlbkBrdW1h cmkubmV0PiwgPHJ3aWx0b25AY2lzY28uY29tPiwgR3lhbiBNaXNocmEgPGhheWFidXNhZ3NtQGdt YWlsLmNvbT4sIDxoYXlhYnVzYWdzbUBnbWFpbC5jb20+DQpSZXNlbnQtRGF0ZTogVHVlc2RheSwg MjMgTWFyY2ggMjAyMSBhdCAxNToxOQ0KDQogICAgUmV2aWV3ZXI6IEFjZWUgTGluZGVtDQogICAg UmV2aWV3IHJlc3VsdDogSGFzIE5pdHMNCg0KICAgIEhlbGxvLA0KDQogICAgSSBoYXZlIGJlZW4g c2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXMgZHJh ZnQuDQogICAgVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8gcmV2aWV3IGFsbCByb3V0 aW5nIG9yIHJvdXRpbmctcmVsYXRlZA0KICAgIGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJ RVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZA0KICAgIHNvbWV0aW1lcyBvbiBzcGVj aWFsIHJlcXVlc3QuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZQ0KICAg IGFzc2lzdGFuY2UgdG8gdGhlIFJvdXRpbmcgQURzLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91 dCB0aGUgUm91dGluZw0KICAgIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlICANCg0KICAgICAgaHR0 cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0Rpcg0KDQogICAg QWx0aG91Z2ggdGhlc2UgY29tbWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUg Um91dGluZyBBRHMsDQogICAgaXQgd291bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lk ZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlcg0KICAgIElFVEYgRWFybHkgUmV2aWV3L0xhc3Qg Q2FsbCAgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0bw0KICAgIHJlc29s dmUgdGhlbSB0aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhlIGRyYWZ0Lg0KDQog ICAgRG9jdW1lbnQ6IGRyYWZ0LWlldGYtb3BzZWMtdjYtMjQudHh0DQogICAgUmV2aWV3ZXI6IEFj ZWUgTGluZGVtDQogICAgUmV2aWV3IERhdGU6IDAzLzIzLzIwMjENCiAgICBJRVRGIExDIEVuZCBE YXRlOiBTb29uDQogICAgSW50ZW5kZWQgU3RhdHVzOiAgSW5mb3JtYXRpb25hbA0KDQogICAgU3Vt bWFyeTogVGhlIGRvY3VtZW50IGNvbnRhaW5zIGEgbG90IG9mIHVzZWZ1bCByZWNvbW1lbmRhdGlv bnMgYW5kDQogICAgICAgICAgICAgcmVmZXJlbmNlcyBmb3IgT3BlcmF0aW9uYWwgU2VjdXJpdHkg aW4gSVB2NiBuZXR3b3Jrcy4gU2luY2UNCiAgICAgICAgICAgICB0aGUgZG9jdW1lbnQgaGFzICJJ bmZvcm1hdGlvbmFsIiBzdGF0dXMsIG5vbmUgb2YgdGhlIHRleHQgaXMNCiAgICAgICAgICAgICBu b3JtYXRpdmUuDQoNCiAgICAgICAgICAgICBUaGUgZG9jdW1lbnQgaXMgYmFzaWNhbGx5IHJlYWR5 IGZvciBwdWJsaWNhdGlvbi4gSSBoYXZlIHNvbWUNCiAgICAgICAgICAgICBuaXRzIGF0dGFjaGVk IGFuZCBhIGhhdmUgY291cGxlIHN1Z2dlc3RlZCByZWZlcmVuY2VzIGZvcg0KICAgICAgICAgICAg IElQdjYgY29udHJvbCBwbGFuZSBzZWN1cml0eS4NCg0KICAgIE1ham9yIElzc3VlczogTm9uZQ0K DQogICAgTWlub3IgSXNzdWVzOg0KDQogICAgICAgIDEuIFNlY3Rpb24gMi40IC0gUmVjb21tZW5k IGltcGxlbWVudGF0aW9uIG9mIGtleS1jaGFpbnMgYW5kIGdyYWNlZnVsDQogICAgICAgICAgIGtl eSByb2xsb3ZlciBhcyBkb2N1bWVudGVkIGluIHNlY3Rpb24gMi4yIG9mIFJGQyA4MTc3LiBUaGlz IHdpbGwNCiAgICAgICAgICAgYXZvaWQgdGhlIGRpc3J1cHRpb25zIGR1cmluZyBrZXkgcm9sbG92 ZXIuDQoNCiAgICAgICAgMi4gU2VjdGlvbiAyLjQgLSBSZWNvbW1lbmQgaW1wbGVtZW50YXRpb24g b2YgU1BGIHJhdGUtbGltaXRpbmcgYXMNCiAgICAgICAgICAgZG9jdW1lbnRlZCBpbiBSRkMgODU0 MS4gVGhpcyBpcyBpbiB0aGUgY29udGV4dCBvZiBPU1BGdjMgcHJvdG9jb2wNCiAgICAgICAgICAg c3BlY2lmaWMgbWVjaGFuaXNtcyBhbmQgdGhlIHJlY29tbWVuZGVkIHJhdGUtbGltaXRpbmcuDQoN CiAgICBOaXRzOiBXaWxsIHNlbmQgZGlmZnMgaW4gc2VwYXJhdGUgbWVzc2FnZS4NCg0KDQoNCg0K From nobody Thu Apr 1 11:30:36 2021 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C9D3A1E4C; Thu, 1 Apr 2021 11:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.618 X-Spam-Level: X-Spam-Status: No, score=-9.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=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=BnX5JPyL; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=O2qx6kZw Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iW7GxdeggLgc; Thu, 1 Apr 2021 11:30:26 -0700 (PDT) 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 9409F3A1E3E; Thu, 1 Apr 2021 11:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5564; q=dns/txt; s=iport; t=1617301810; x=1618511410; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ke0W6q8Md3cqyzqgYRsILpgSD/2Txcj3rSam6Bc56XU=; b=BnX5JPyLsexcLAYuR0v+dok4AwSRct6K3w4/fhvmHhaf7NrKrAm5VyDC szx3I/5BGWDWnZwMTW669YmA6tQShRtEMs9pdOGkIw6+fMm0230/Fm2vx tTej33F8PeYG3hoefGARiJp1mT/JdTplWayOMlbZM8lWL1tJZDjCxDxc8 I=; IronPort-PHdr: =?us-ascii?q?A9a23=3AkjeEfh12omCvBAfKsmDPW1BlVkAck7zpIg4Y7?= =?us-ascii?q?IYmgLtSc6Oluo7vJ1Hb+e4FpFTIRo7crflDjrmev6PhXDkG5pCM+DAHfYdXX?= =?us-ascii?q?hAIwcMRg0Q7AcGDBEG6SZyibyEzEMlYElMw+Xa9PBteGd31YBvZpXjhpTIXE?= =?us-ascii?q?w/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxnec4M?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3Awnydh63dshbleBWoZItf+AqjBaN2eYIsi2?= =?us-ascii?q?QD101hICF9Wvez0+izgfUW0gL1gj4NWHcm3euNIrWEXGm0z/9IyKErF/OHUB?= =?us-ascii?q?P9sGWlaLtj44zr3iH6F0TFmNJ1/ZxLN5JzANiYNzdHpO7x6gWgDpIEyN6I7K?= =?us-ascii?q?iniY7lvghQZCtBApsQiDtRIACdD0FwWU1nKPMCZdqhz+BAoCetfmlSS8y9CG?= =?us-ascii?q?UMUeSrnay0qLvNZxkaCxk7rDSUhTSz57LgVzSe1BESUzRAqI1SslTtuQr/+6?= =?us-ascii?q?mlrrWH2gbRvlWjrqh+tfnA7p94BMKKgtUIMTmEsGaVTaloRrHqhkFPnMiB81?= =?us-ascii?q?Av+eO8xisIH8M20H/Je3HwnB2F4Xid7B8Ly1vPjWCVmmHip8uRfkN5N+NkiZ?= =?us-ascii?q?hCehXUr2oM1esMqp5j5G6Su5pJAR6opk2UjLKkO2AI5yiJiEEvnuIJg3tUXZ?= =?us-ascii?q?F2Us4tkaUk4EhXHJ0cdRiKjrwPLeh0AMnQoNZQfF+KBkqpxlVH/d22Unw/Wi?= =?us-ascii?q?qBW0gJ0/blqgR+oXYR9Tp9+OUv2lM7sL4tQZhN4OrJdo5ykqtVc8MQZaVhQM?= =?us-ascii?q?8cXMqeEAX2MFfxGVPXBW6iOLAMOnrLpZKyyq4y/vuWdJsBy4Z3sIjdUWlfqX?= =?us-ascii?q?U5dyvVeImz9awO1iqIbHS2XDzrxM0bzYN+oKfASL3iNjDGb1wyjc26obE6Dt?= =?us-ascii?q?fAU/i+fLJaasWTalfGKMJs5UnTSpNSIX4RXIk+odAgQW+DpcrNN8nkrerefP?= =?us-ascii?q?HPJKf8EDotV2/la0FzBQTbFYFl1ASGS3X4iB/eVzfGYUrk5699F6Dc4qwSxe?= =?us-ascii?q?E2R9VxmzlQrW78ytCAKDVEvKBzVlB5OqnbnqSyonTz+W7J6m5uKwdMF0o92s?= =?us-ascii?q?S6b1p64Ssxd2/ke7cKvNuSPUpI2mGcGxN5R8TKVAhFp1p2/qqzJ4eKxT8rDs?= =?us-ascii?q?+mNm7ytQpUmFu6C7Mn3oGT78bsfZ01Srw8XrZqKAnNHxtp3RpxpHxbcw8CTE?= =?us-ascii?q?/HHjbogaGo5aZkXt33Rp1ZukOGMMRUoXXQuQGgvskpXGIcRCPre9WQmxwSSz?= =?us-ascii?q?1dgUBR/6cTjKGboyumLXIyjY0DQQBxQVXSJIgDLQyeIK1Ih7jgeWhLPBa3rA?= =?us-ascii?q?3fryt2R03H2AE5gHf7ISidZPfRa2Atykxw4+LN61N7dmKUYkRqTGt12LcNSV?= =?us-ascii?q?juizJUzfKBYLa13i+3bFYPq9ttbg3tUH81Ph5kwcyx2VquvAu6UV8ixpkoI4?= =?us-ascii?q?XmfeseWrnOx3KgL5CJn6kaH/lSuI1oLszqr/Vja5PsRyaINj/iT+sm1wuJz0?= =?us-ascii?q?xVSxVcuT0ql+jl1wbi63X91HkjAeDKKFAjXL0DJcqAhlKUCMqgwdF8jdgvu/?= =?us-ascii?q?G3PXi0YtmaybvPZzorEGKfnUemC+Upo4tTp6Q8qf96GITaSyLB0DVC0A8lJM?= =?us-ascii?q?n50EMYT6IT2sGMBqZ/O8gTcTle5FwniZCGK1YqqBX/BqsmZk425kWrd++h8v?= =?us-ascii?q?7Ns/4iE0eBrAz/NR2W9DBc5e7MW2+G2aQBA6w9LGxKYCEHmTpf1fLHc5eVBB?= =?us-ascii?q?ShdulF8lb/KHO7fbNHQKWOGLkbrH9Bkpu1tv7SczC91BHbvDN9LK4L7n2uRt?= =?us-ascii?q?mqBhmQXeFP6N63ND238+KXyd/2iC2yTzS1a04V39IYMUMRa9lOkTkkgsk81D?= =?us-ascii?q?OoRqn+v0IilB9f7Fhc5ynQ85nj5H2eG0dMdRDdiNFRWzJYN3CTl8TL8eSCzh?= =?us-ascii?q?3GkXN48IiGEF0VZ81EHtgbU5P+IChvI9UBpbLAxdtavg1TJBM1S3MmgD/z3+?= =?us-ascii?q?l6za601fXbVerlE2rpMzs6iEh4L58xmDcqp2FGe9W/6pz4Yhx/LJ98P8cC?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvCQAaEGZg/5FdJa1aHQEBAQEJARI?= =?us-ascii?q?BBQUBQIFQgVNRB3daNjECCIQ4g0gDhTmIUQOKK48LgUKBEQNUCwEBAQ0BASg?= =?us-ascii?q?KAgQBAYRQAheBZAIlOBMCAwEBDAEBBQEBAQIBBgRxhWENhkQBAQEBAyMRDAE?= =?us-ascii?q?BNwELBAIBCBEDAQIDAiYCAgIfERQBCAgCBAENBYJxAYJVAy8BDqBBAoofd4E?= =?us-ascii?q?ygwQBAQaFHA0LghMJgQ8qgnaCcRI+SIZLJhyCC4ESJxyCWT6CHjcLAoEpARI?= =?us-ascii?q?BIYMWNYIrgU83gSgEUiNdGQgsDQoEAgEXBgsZBQELD5BTg1mLdJluWwqDCYh?= =?us-ascii?q?PgRCNXQSFMQMfg0uBPok5lieVEIElikCDFo83IIRIAgQCBAUCDgEBBoFrI2l?= =?us-ascii?q?wcBVlAYI+CUcXAg2OH4NwhRSFRXMCCysCBgEJAQEDCXyMPQExXQEB?= X-IronPort-AV: E=Sophos;i="5.81,296,1610409600"; d="scan'208";a="855461401" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Apr 2021 18:30:08 +0000 Received: from mail.cisco.com (xbe-aln-003.cisco.com [173.36.7.18]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 131IU6BT021011 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Thu, 1 Apr 2021 18:30:09 GMT Received: from xfe-aln-005.cisco.com (173.37.135.125) by xbe-aln-003.cisco.com (173.36.7.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Thu, 1 Apr 2021 13:30:06 -0500 Received: from xfe-aln-001.cisco.com (173.37.135.121) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Thu, 1 Apr 2021 13:30:06 -0500 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-001.cisco.com (173.37.135.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Thu, 1 Apr 2021 13:30:06 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=f0VJ1ZTFRWMSzq6B6bw+ThFpPPnn8WWh+EhkcVxRePxtgJ/5ekJmkjmpmBSa35jm1ZAqOd856vUiYqw1AWlCADkfa7bYkNyPmz+r2s0unkDYv+6xmBCbxzMCxobtD68Juehf2ob6YG9kSdMd7C7rGuBO83chOexXotROQlxDhDr6b1QRwZPRb1NDGUfmXKXVLL9hE4pHvtqZU97bcF9lEINeePzGJC+KorLiyMxLjUXyAMmcWxZEn0gJBHfm/eysacUjLMo6CTKNrIDPs0J6p2Im9Rtmxk3gTwuFmXigIZwhs2lTzECiBkJixTxt+6pfBCGdaahP/rOzo5zv17Umvg== 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=ke0W6q8Md3cqyzqgYRsILpgSD/2Txcj3rSam6Bc56XU=; b=BWRgD94lEy059lMzPi15CUMy7ZfgtJoDI6wm18ERkQlt+VKwgtgFT7pLkIV6wwVHn4dqGHJJFvfotSSm2prJpMt0K1Y64j7JM+22oS9pLBaQ3t9VrZrdeJVjgEK18wdlKIBXhnf3IgQPlKeTdct0MwGUuExd5G/Dy9PuGnUWg0B/NTW9lwCixBCTLGUNaNqdp/PglMb4232Wok76ZLHt81goIbcbzzddhTktLMZ/j+SLwM5KGR5v4NqGEu+Y3QpSBuFiH7kZG55vtM9Mekr/MiSp+eJyUqJSeE6rsGCOilDXnWceG6B1i47MvDvyN3CRR9UTkFR70lh8Q9FsV1S2pA== 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=ke0W6q8Md3cqyzqgYRsILpgSD/2Txcj3rSam6Bc56XU=; b=O2qx6kZw27G+FUyvASCqZl3psmFgjbb/G9kSSANGxRgKo3hkVsbLYzptk4if4fTOvRfo7Dtl75TwY173TKEvMkDN0E/NA5B0igfCAE7pUffzL7NV0olTmCvV2ugfPNbmvnDLj3PmV8O4isaPZCHr+iPoJOdaYbkYNknGrAcF/SM= Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by SJ0PR11MB5086.namprd11.prod.outlook.com (2603:10b6:a03:2d1::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.25; Thu, 1 Apr 2021 18:30:05 +0000 Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::f82f:ff98:d282:d5e5]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::f82f:ff98:d282:d5e5%5]) with mapi id 15.20.3977.033; Thu, 1 Apr 2021 18:30:04 +0000 From: "Acee Lindem (acee)" To: "Eric Vyncke (evyncke)" , "rtg-dir@ietf.org" CC: "draft-ietf-opsec-v6.all@ietf.org" , "last-call@ietf.org" , "opsec@ietf.org" Thread-Topic: Rtgdir last call review of draft-ietf-opsec-v6-24 Thread-Index: AQHXJw9TAbVoG9icqUO344jB7wloRaqfuN6A Date: Thu, 1 Apr 2021 18:30:04 +0000 Message-ID: References: <161650914469.13419.16565124530354757829@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.47.21031401 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [136.56.133.70] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: df2e359d-1dfb-4959-cfe6-08d8f53c2b81 x-ms-traffictypediagnostic: SJ0PR11MB5086: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ab6izJVIwauHqWavsmnFQSThkc/22z7NaxcHZlHI74outEVwdrMMJKrHO0h3hvLKJoqEiwIDCufx7j2HSAHUvQRlMyP/C7V9t+OFbaHjZQFKdoIp6OdqIhlJVFjXSEj2iKO37/tVt62fuCkkngYD5Q7f9n9ayG76HdtQqyKLZWjUNtQBJLG7raknFeSKQyP5yAcmtzel5Zn7GtYfEZqqYKOK8Ao2cRBCQkGgw0KjSezhcFkPeGFiMH2GgmOYoJqOt1CAR6gGmKoitqQYRONO3Va0goadnGJJPZfU8I2n4WSSrhqNrhyJY0GtBwjLflsgRZluCGCPeuwweYk9wQOL0RPCcGnItf+oJuhe9l5KA2dzqCgshtPWEzIIvVjzDeKkT0YLbItRujnmicQYaikNtXWVp10LFOxS0nfrIHFI/4wAltWBMDA7aAqLwyN+2NUB5yOmUU7CVWT9rvbT7y23GImqBHAZPy9KizMpUuZ0kzaxzR4kO2Cj2dd/nT+0EJn1XrO750i0BAV3yWcIAgcqPp16hrXjKYjMZ0j/7lRDlmhpcQPqwdc9wNtm/smymNxZ1xqCLEJJ7Uk1M7ovi910XdvJK3SnzmvSb6lM1PlLkiGVqONXiAG8SVdKs0wb0twyrNr5yTPwBrSeoAPqOAelGjAIqjcVYCiXjQYLv2cdNYLnEkvnznFUICRd6cXQTmByf6+QvD/xktFe0bkNEv4XVXiyb+k2DK99N8nvDPHy/HfgpaODj9G8z5YTs003WI9QbtmTDVvs5zTW/H3O9NynhQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(346002)(376002)(366004)(136003)(39860400002)(2906002)(966005)(66946007)(76116006)(66556008)(64756008)(5660300002)(4326008)(2616005)(450100002)(66446008)(83380400001)(6512007)(66476007)(38100700001)(6486002)(186003)(33656002)(86362001)(8676002)(54906003)(316002)(110136005)(71200400001)(6506007)(53546011)(26005)(66574015)(36756003)(478600001)(8936002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?UmM1b2JlL1luNWNmNXFqZ0tUWHRLOHcxUVpwbUdnTXdLNmpWMnZQUHNsNWhV?= =?utf-8?B?THBGMHZnaDl6RVk0d1R2TEJ3L1laVU90cWc2NWR5V2dxbVUzOVpkUnJXRzRh?= =?utf-8?B?VTlmMzkveTlOeGxRcEtTLzBEQWwzUU91VTNXa0lCd3hManMzWTRTSjRIQ3hF?= =?utf-8?B?QmU4RXdBTFRKaG9DVEtBVzA4N2dDOWQwR09WSS9ocnZjd0xrL0FHbjhvbTZ1?= =?utf-8?B?Y3pIRWhkZWh6RW1nNHRGUVViaXVSN0pLZmpIZE82U3huVEsyMDU0T1UvMEhN?= =?utf-8?B?VXQvRWg4SUt3ZFBDczRCQnZCR0piT0p5UkoraEFVMWUxK3prbVZ6R1pLZFRu?= =?utf-8?B?OW9sSUtsU0RQRkNSV00yNXlVY0RIcVM3eDdZN2ZmWkkxNzB2TU43ZFZ0VTVK?= =?utf-8?B?akxJTmFGeFRsZFRqQkhnZmM3bGJQUkZ2R0ZoQ29lOU0vWDMrZ2M2T3BzWDZu?= =?utf-8?B?YTVkZU9uUHVFd3JSV3JsOE9wMEZHckpVWUlMVXg2V2gyaEkzUjd2VXBSby9l?= =?utf-8?B?S2VtQXRmbTFmSHdlMng5UmVwaWpac21XR0hNZU1zcHBtb0l0Y09aNk5udWZl?= =?utf-8?B?cWtkMG00OWFRaUF4cmRWL1ZGWnp4a2swNUQ1YlNuRE50ZTUwd25NZWVSV0c5?= =?utf-8?B?SnlKVmZ6aE1SeGRySERoQ254RHA1K1lMcU9EamplOUhQOEduL2t5UHRyUGNx?= =?utf-8?B?MTZkK2taeU1iaUM0ZW9HY3F5MUFEbHZGODdjRzJteHlhSzd0UmRTWVFUZm9x?= =?utf-8?B?T1lTRUZoSVg5bmRITTRjQXRjVjRjOXhLWnNPUWdic3l4T041TXYrUGFFV01s?= =?utf-8?B?UHRqK3hqVmp0YmVOaCtWRVBqazhBdGFZeEd6TWl2Sk8yV0FMZ1Q0N3JhWFo0?= =?utf-8?B?Sit3UzQ4clBhM0QwZUZ1WXIyVUlLMW9ILzJDM3g0d1YreGF2cGQvUGRYZ0dr?= =?utf-8?B?SkgzcWRIbVdkcDhEZG0zYy9FSHR6VTBFaUo1RDdTemwxS1BQL1N2S05iNUJl?= =?utf-8?B?ZkJRRGtBd3lHSjU1ZjVCc25MOTZwZHNEZ2xMUS9GWVRpRS9CSTRNS3Ezc3hL?= =?utf-8?B?SG84bEgxRWlIRjRJYVdGZnFHY3dPeHVmSkh5QzFVeHdyZUpDaDVEWGhDM2dh?= =?utf-8?B?YXZtUnJueW5CMCs3ZUxyOGdoSHdCYkxqNmZCN0NGOTRlbFgxUXVXTDB0MWVy?= =?utf-8?B?MFRva21DREhHLzNvNW4rMVBIUkVWL0RwZ0RqcE92TzNXWEVJNlRKYUZpdG9B?= =?utf-8?B?MW1GSUNLbjZZdFVCc3J2RGVhR25UQSsvTnMyamtHakEvOEpHYkxqQUlsMGtY?= =?utf-8?B?dk82YWJJR1RsTVBlaThEV25PSzR3bmpHamtrMTNvMnVXSjZHakg3VWJzbG91?= =?utf-8?B?VUlUOGw5T3NQR0ZnZVpCcEdZQkpkMWxnVmdZMlVDc3JFSUtUTjNWT1VTaGZx?= =?utf-8?B?UXQwaVV3aS9HcWhQYThBZlVjSlFvN3YyVzlYTUFoWjhhbWtTTWUvMTRUdWp5?= =?utf-8?B?bFFMeW9zb28rdCtKTE95SmpTQmgzb0F4WGJzcXU1WlMwRlpLbFZyZ2M0Q2tY?= =?utf-8?B?NXZOaWVzZkNHSDBnUTZsQU1xOUZhZGJwWW16NDMvellsZVRlNFpycGVuT3A2?= =?utf-8?B?bnZaalo5eitwQ2VTMkNCNkxoRUtDekpyV2lYYk9HcXVtNGd5UFFzSURvejdG?= =?utf-8?B?bGdCWC93OCtROFZwZ0pieEZrQ09WemtkZG5IRHBPNFgyeWJyNHFQV09PNXRy?= =?utf-8?B?OHVBbTNZNFp5cEUxbVVtc3dVdjh3Z1ZOUW5wZWk5Q1ZyVTVWU1VRcUdoUzNu?= =?utf-8?B?NkFlbXNKRzUwdFZUZmNwZz09?= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2887.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: df2e359d-1dfb-4959-cfe6-08d8f53c2b81 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2021 18:30:04.8606 (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: ymmU0lV3i+hJnyU7fLT++jtNDZAttzRbqrDKrLHSeKfmnk7tLcvPDnMpwswHGl3h X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB5086 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.18, xbe-aln-003.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [OPSEC] Rtgdir last call review of draft-ietf-opsec-v6-24 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2021 18:30:31 -0000 SGkgRXJpYywgDQoNClRoYW5rcyBtdWNoIGZvciBpbmNvcnBvcmF0aW5nIG15IGNvbW1lbnRzLiAg DQoNCu+7v09uIDQvMS8yMSwgMTE6NTQgQU0sICJFcmljIFZ5bmNrZSAoZXZ5bmNrZSkiIDxldnlu Y2tlQGNpc2NvLmNvbT4gd3JvdGU6DQoNCiAgICBBY2VlLA0KDQogICAgQmlnIHRoYW5rIHlvdSBv biB5b3VyIG5pdHMgcmV2aWV3ISBBcyBhIG5vbi1FbmdsaXNoIHNwZWFrZXIsIEkgYWx3YXlzIHdl bGNvbWUgKGFuZCBsZWFybiBmcm9tKSBzdWNoIGEgZGV0YWlsZWQgcmV2aWV3LiBUaGUganVzdCBw b3N0ZWQgLTI1IGhhcyBhbGwgdGhlIG5pdHMgZml4ZWQgKHBlciB5b3VyIG90aGVyIGVtYWlsKSBh bmQgd2UgdG9vayBhY3Rpb24gb24geW91ciB0d28gc3VnZ2VzdGlvbnMgYmVsb3cuDQoNCiAgICBC VFcsIHdlIGFkZGVkIGEgcmVmZXJlbmNlIHRvIFJGQyA4MTc3IGluIHNlY3Rpb24gMi41LjMgJ3Nl Y3VyaW5nIHJvdXRpbmcgdXBkYXRlcyIgYXMgaXQgc2VlbXMgbW9yZSBzdWl0YWJsZS4NCg0KSXQg YXBwbGllcyB0aGVyZS4gSG93ZXZlciwgSSB3YXMgdGhpbmtpbmcgb2YgaXQgaW4gdGhlIGNvbnRl eHQgb2YgdGhpcyBzdGF0ZW1lbnQgaW4gMi40LiANCg0KICAgICAgICJUaGUgY29udHJvbCBwbGFu ZSBwcm9jZXNzb3IgaXMgdGhlbiB1bmFibGUgdG8gcHJvY2VzcyB2YWxpZCBjb250cm9sIHBhY2tl dHMgYW5kDQogICAgICAgICB0aGUgcm91dGVyIGNhbiBsb3NlIE9TUEYgb3IgQkdQIGFkamFjZW5j aWVzIHdoaWNoIGNhbiBjYXVzZSBhIHNldmVyZQ0KICAgICAgICBuZXR3b3JrIGRpc3J1cHRpb24u Ig0KDQpJZiBvbmUgc3VwcG9ydHMgYSB0aGUga2V5LWNoYWluIG1lY2hhbmlzbXMgZm9yIHJvbGxv dmVyIGluIHRoZWlyIE9TUEYgYW5kIEJHUCBpbXBsZW1lbnRhdGlvbnMsIHRoZXJlIHdpbGwgYmUg bm8gZGlzcnVwdGlvbi4gQW55d2F5LCBpdCB3YXMgb25seSBhIHN1Z2dlc3Rpb24uIA0KDQpUaGFu a3MsDQpBY2VlDQoNCiAgICBSZWdhcmRzDQoNCiAgICAtw6lyaWMNCg0KICAgIFBTOiBoYXBweSB0 byBoYXZlIGEgQXByaWwgMXN0IEktRCwgd2hpY2ggaXMgTk9UIGEgam9rZSA7LSkNCg0KDQoNCiAg ICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgIEZyb206IEFjZWUgTGluZGVtIHZpYSBE YXRhdHJhY2tlciA8bm9yZXBseUBpZXRmLm9yZz4NCiAgICBSZXBseS1UbzogIkFjZWUgTGluZGVt IChhY2VlKSIgPGFjZWVAY2lzY28uY29tPg0KICAgIERhdGU6IFR1ZXNkYXksIDIzIE1hcmNoIDIw MjEgYXQgMTU6MTkNCiAgICBUbzogInJ0Zy1kaXJAaWV0Zi5vcmciIDxydGctZGlyQGlldGYub3Jn Pg0KICAgIENjOiAiZHJhZnQtaWV0Zi1vcHNlYy12Ni5hbGxAaWV0Zi5vcmciIDxkcmFmdC1pZXRm LW9wc2VjLXY2LmFsbEBpZXRmLm9yZz4sICJsYXN0LWNhbGxAaWV0Zi5vcmciIDxsYXN0LWNhbGxA aWV0Zi5vcmc+LCAib3BzZWNAaWV0Zi5vcmciIDxvcHNlY0BpZXRmLm9yZz4NCiAgICBTdWJqZWN0 OiBSdGdkaXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLW9wc2VjLXY2LTI0DQogICAg UmVzZW50LUZyb206IDxhbGlhcy1ib3VuY2VzQGlldGYub3JnPg0KICAgIFJlc2VudC1UbzogRXJp YyBWeW5ja2UgPGV2eW5ja2VAY2lzY28uY29tPiwgS2lyYW4gS3VtYXIgQ2hpdHRpbWFuZW5pIDxr ay5jaGl0dGltYW5lbmlAZ21haWwuY29tPiwgTWVyaWtlIEthZW8gPG1lcmlrZUBkb3VibGVzaG90 c2VjdXJpdHkuY29tPiwgPGVyZXlAZXJudy5kZT4sIDxmdXJyeTEzQGdtYWlsLmNvbT4sIFJvbiBC b25pY2EgPHJib25pY2FAanVuaXBlci5uZXQ+LCA8d2FycmVuQGt1bWFyaS5uZXQ+LCA8cndpbHRv bkBjaXNjby5jb20+LCBHeWFuIE1pc2hyYSA8aGF5YWJ1c2Fnc21AZ21haWwuY29tPiwgPGhheWFi dXNhZ3NtQGdtYWlsLmNvbT4NCiAgICBSZXNlbnQtRGF0ZTogVHVlc2RheSwgMjMgTWFyY2ggMjAy MSBhdCAxNToxOQ0KDQogICAgICAgIFJldmlld2VyOiBBY2VlIExpbmRlbQ0KICAgICAgICBSZXZp ZXcgcmVzdWx0OiBIYXMgTml0cw0KDQogICAgICAgIEhlbGxvLA0KDQogICAgICAgIEkgaGF2ZSBi ZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHJldmlld2VyIGZvciB0aGlz IGRyYWZ0Lg0KICAgICAgICBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byByZXZpZXcg YWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkDQogICAgICAgIGRyYWZ0cyBhcyB0aGV5IHBh c3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZA0KICAgICAgICBz b21ldGltZXMgb24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlz IHRvIHByb3ZpZGUNCiAgICAgICAgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBt b3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nDQogICAgICAgIERpcmVjdG9yYXRlLCBw bGVhc2Ugc2VlICANCg0KICAgICAgICAgIGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEv cnRnL3RyYWMvd2lraS9SdGdEaXINCg0KICAgICAgICBBbHRob3VnaCB0aGVzZSBjb21tZW50cyBh cmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywNCiAgICAgICAgaXQg d291bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFu eSBvdGhlcg0KICAgICAgICBJRVRGIEVhcmx5IFJldmlldy9MYXN0IENhbGwgIGNvbW1lbnRzIHRo YXQgeW91IHJlY2VpdmUsIGFuZCBzdHJpdmUgdG8NCiAgICAgICAgcmVzb2x2ZSB0aGVtIHRocm91 Z2ggZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZyB0aGUgZHJhZnQuDQoNCiAgICAgICAgRG9jdW1l bnQ6IGRyYWZ0LWlldGYtb3BzZWMtdjYtMjQudHh0DQogICAgICAgIFJldmlld2VyOiBBY2VlIExp bmRlbQ0KICAgICAgICBSZXZpZXcgRGF0ZTogMDMvMjMvMjAyMQ0KICAgICAgICBJRVRGIExDIEVu ZCBEYXRlOiBTb29uDQogICAgICAgIEludGVuZGVkIFN0YXR1czogIEluZm9ybWF0aW9uYWwNCg0K ICAgICAgICBTdW1tYXJ5OiBUaGUgZG9jdW1lbnQgY29udGFpbnMgYSBsb3Qgb2YgdXNlZnVsIHJl Y29tbWVuZGF0aW9ucyBhbmQNCiAgICAgICAgICAgICAgICAgcmVmZXJlbmNlcyBmb3IgT3BlcmF0 aW9uYWwgU2VjdXJpdHkgaW4gSVB2NiBuZXR3b3Jrcy4gU2luY2UNCiAgICAgICAgICAgICAgICAg dGhlIGRvY3VtZW50IGhhcyAiSW5mb3JtYXRpb25hbCIgc3RhdHVzLCBub25lIG9mIHRoZSB0ZXh0 IGlzDQogICAgICAgICAgICAgICAgIG5vcm1hdGl2ZS4NCg0KICAgICAgICAgICAgICAgICBUaGUg ZG9jdW1lbnQgaXMgYmFzaWNhbGx5IHJlYWR5IGZvciBwdWJsaWNhdGlvbi4gSSBoYXZlIHNvbWUN CiAgICAgICAgICAgICAgICAgbml0cyBhdHRhY2hlZCBhbmQgYSBoYXZlIGNvdXBsZSBzdWdnZXN0 ZWQgcmVmZXJlbmNlcyBmb3INCiAgICAgICAgICAgICAgICAgSVB2NiBjb250cm9sIHBsYW5lIHNl Y3VyaXR5Lg0KDQogICAgICAgIE1ham9yIElzc3VlczogTm9uZQ0KDQogICAgICAgIE1pbm9yIElz c3VlczoNCg0KICAgICAgICAgICAgMS4gU2VjdGlvbiAyLjQgLSBSZWNvbW1lbmQgaW1wbGVtZW50 YXRpb24gb2Yga2V5LWNoYWlucyBhbmQgZ3JhY2VmdWwNCiAgICAgICAgICAgICAgIGtleSByb2xs b3ZlciBhcyBkb2N1bWVudGVkIGluIHNlY3Rpb24gMi4yIG9mIFJGQyA4MTc3LiBUaGlzIHdpbGwN CiAgICAgICAgICAgICAgIGF2b2lkIHRoZSBkaXNydXB0aW9ucyBkdXJpbmcga2V5IHJvbGxvdmVy Lg0KDQogICAgICAgICAgICAyLiBTZWN0aW9uIDIuNCAtIFJlY29tbWVuZCBpbXBsZW1lbnRhdGlv biBvZiBTUEYgcmF0ZS1saW1pdGluZyBhcw0KICAgICAgICAgICAgICAgZG9jdW1lbnRlZCBpbiBS RkMgODU0MS4gVGhpcyBpcyBpbiB0aGUgY29udGV4dCBvZiBPU1BGdjMgcHJvdG9jb2wNCiAgICAg ICAgICAgICAgIHNwZWNpZmljIG1lY2hhbmlzbXMgYW5kIHRoZSByZWNvbW1lbmRlZCByYXRlLWxp bWl0aW5nLg0KDQogICAgICAgIE5pdHM6IFdpbGwgc2VuZCBkaWZmcyBpbiBzZXBhcmF0ZSBtZXNz YWdlLg0KDQoNCg0KDQoNCg== From nobody Mon Apr 5 11:13:18 2021 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E68EE3A2223; Mon, 5 Apr 2021 11:13:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Duke via Datatracker To: "The IESG" Cc: draft-ietf-opsec-v6@ietf.org, opsec-chairs@ietf.org, opsec@ietf.org, Gyan Mishra , hayabusagsm@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Martin Duke Message-ID: <161764639244.16129.8383571157085804937@ietfa.amsl.com> Date: Mon, 05 Apr 2021 11:13:12 -0700 Archived-At: Subject: [OPSEC] Martin Duke's No Objection on draft-ietf-opsec-v6-25: (with COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2021 18:13:13 -0000 Martin Duke has entered the following ballot position for draft-ietf-opsec-v6-25: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I haven't gone through the dozens of references to verify the claims about them, so I'm trusting the WG and ADs here... In Sec 2.3.2.4, RA-Guard and SAVI are recommended, but then in the same paragraph it says that "only trivial cases" should enable it by default. I can't reconcile these two statements. From nobody Mon Apr 5 14:07:59 2021 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5E73A2813; Mon, 5 Apr 2021 14:07:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Alvaro Retana via Datatracker To: "The IESG" Cc: draft-ietf-opsec-v6@ietf.org, opsec-chairs@ietf.org, opsec@ietf.org, Gyan Mishra X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alvaro Retana Message-ID: <161765687327.663.16409961435864058863@ietfa.amsl.com> Date: Mon, 05 Apr 2021 14:07:53 -0700 Archived-At: Subject: [OPSEC] Alvaro Retana's No Objection on draft-ietf-opsec-v6-25: (with COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2021 21:07:53 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-opsec-v6-25: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) The applicability statement in §1.1 is confusing to me. a. The Abstract says that "this document are not applicable to residential user cases", but that seems not to be true because this section says that the contents do apply to "some knowledgeable-home-user-managed residential network[s]", and §5 is specific to residential users. b. "This applicability statement especially applies to Section 2.3 and Section 2.5.4." Those two sections represent a small part of the document; what about the rest? It makes sense to me for the applicability statement to cover most of the document. c. "For example, an exception to the generic recommendations of this document is when a residential or enterprise network is multi-homed." I'm not sure if this sentence is an example of the previous one (above) or if "for example" is out of place. (2) §5 mentions "early 2020" -- I assume that the statement is still true now. (3) It caught my attention that there's only one Normative Reference (besides rfc8200, of course). Why? What is special about the IPFIX registry? It seems that an argument could be made to the fact that to secure OSPFv3, for example, an understanding of the protocol is necessary. This argument could be extended to other protocols or mechanisms, including IPv6-specific technology: ND, the addressing architecture, etc. Consider the classification of the references in light of [1]. [1] https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ From nobody Tue Apr 6 08:00:14 2021 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4CBF3A2498; Tue, 6 Apr 2021 08:00:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Lars Eggert via Datatracker To: "The IESG" Cc: draft-ietf-opsec-v6@ietf.org, opsec-chairs@ietf.org, opsec@ietf.org, Gyan Mishra , hayabusagsm@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Lars Eggert Message-ID: <161772120964.13732.17403156280296269605@ietfa.amsl.com> Date: Tue, 06 Apr 2021 08:00:09 -0700 Archived-At: Subject: [OPSEC] Lars Eggert's No Objection on draft-ietf-opsec-v6-25: (with COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2021 15:00:10 -0000 Lars Eggert has entered the following ballot position for draft-ietf-opsec-v6-25: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 2.3.1, paragraph 6, comment: > o Tuning of NDP process (where supported). Tuning in which way? Section 2.7.2, paragraph 2, comment: > There are many tunnels used for specific use cases. Except when > protected by IPsec [RFC4301], all those tunnels have a couple of > security issues as described in RFC 6169 [RFC6169]; IPsec is not the only security mechanism that will protect tunnels, most tunnel encryption mechanisms would. ------------------------------------------------------------------------------- All comments below are very minor change suggestions that you may choose to incorporate in some way (or ignore), as you see fit. There is no need to let me know what you did with these suggestions. Section 2.5.3, paragraph 4, nit: > Many routing protocols support the use of cryptography to protect the > routing updates, the use of this protection is recommended; [RFC8177] > is a YANG data model key chains including the renewal. > I can't parse the part after the semicolon. Section 2.6.2.2, paragraph 9, nit: Might also want to mention http://www.entropy-ip.com/ and similar tools. Section 2.2.3, paragraph 3, nit: - not contain the entire ipv6 header chain (including the transport- - ^^ + not contain the entire IPv6 header chain (including the transport- + ^^ Section 2.2.3, paragraph 4, nit: - contain the entire ipv6 header chain (including the transport- - ^^ + contain the entire IPv6 header chain (including the transport- + ^^ Section 2.2.4, paragraph 2, nit: - the updated IPv6 Nodes Requirement standard [RFC8504] IPsec is a + the updated IPv6 Nodes Requirement standard [RFC8504], IPsec is a + + Section 2.3, paragraph 2, nit: - operations such as discovering other nodes on the link, resolving + operations, such as discovering other nodes on the link, resolving + + Section 2.3, paragraph 2, nit: - secured, NDP is vulnerable to various attacks such as router/neighbor + secured, NDP is vulnerable to various attacks, such as router/neighbor + + Section 2.3, paragraph 2, nit: - documented in IPv6 ND Trust Models and Threats [RFC3756] and in Section 2.3.1, paragraph 2, nit: - Neighbor Discovery Protocol (NDP) can be vulnerable to remote denial + The Neighbor Discovery Protocol (NDP) can be vulnerable to remote denial + ++++ Section 2.3.1, paragraph 6, nit: - o Using /127 on point-to-point link per [RFC6164]. + o Using a /127 on a point-to-point link, per [RFC6164]. + ++ ++ + Section 2.3.2.3, paragraph 2, nit: - on-link prefix; 3GPP Section 2.3.4 uses a similar mechanism. + on-link prefix; 3GPP (see Section 2.3.4) uses a similar mechanism. + +++++ + Section 2.3.3, paragraph 2, nit: - Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as described - in [RFC8415], enables DHCP servers to pass configuration parameters - such as IPv6 network addresses and other configuration information to - IPv6 nodes such as a hostile recursive DNS server. DHCP plays an + The Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as described + ++++ + in [RFC8415], enables DHCP servers to pass configuration parameters, + + + such as IPv6 network addresses and other configuration information, to + + + IPv6 nodes, such as a hostile recursive DNS server. DHCP plays an + + Section 2.3.3, paragraph 3, nit: - of-service attack or to mount on path attack. While unintentional, a - ^ + of-service attack or to mount an on-path attack. While unintentional, a + +++ ^ Section 2.3.4, paragraph 2, nit: - address. This implies there can only be an end host (the mobile - ^ + address. This implies there can only be one end host (the mobile + ^ + Section 2.3.4, paragraph 2, nit: - address built by the mobile host. The GGSN/PGW always provides an - ^^^^ + address generated by the mobile host. The GGSN/PGW always provides an + ^^^^^^ ++ Section 2.3.4, paragraph 4, nit: - link model, NDP on it and the address configuration details. In some - ------ + link model, NDP and the address configuration details. In some Section 2.5, paragraph 8, nit: - interface where it is required. + interfaces where it is required. + + Section 2.5.4, paragraph 2, nit: - pertain to edge route filtering vs internal route filtering. At a + pertain to edge route filtering vs. internal route filtering. At a + + Section 2.6.1.5, paragraph 2, nit: - clients. It is indeed quite similar to DHCP for IPv4 so it can be + clients. It is indeed quite similar to DHCP for IPv4, so it can be + + Section 2.6.1.5, paragraph 3, nit: - It is not so easy in the IPv6 networks because not all nodes will use - ---- + It is not so easy in IPv6 networks, because not all nodes will use + + Section 2.7.3.1, paragraph 2, nit: - Carrier-Grade NAT (CGN), also called NAT444 CGN or Large Scale NAT - ^^^ + Carrier-Grade NAT (CGN), also called NAT444 CGN, Large Scale NAT + ^ Section 4.3, paragraph 3, nit: - (e.g., his/her PPP session, physical line, or CPE MAC address). With - ^^^^ + (e.g., his/her PPP session, physical line, or CPE MAC address). In + ^^ From nobody Tue Apr 6 21:18:29 2021 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 722653A3E18; Tue, 6 Apr 2021 21:18:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Erik Kline via Datatracker To: "The IESG" Cc: draft-ietf-opsec-v6@ietf.org, opsec-chairs@ietf.org, opsec@ietf.org, Gyan Mishra , hayabusagsm@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Erik Kline Message-ID: <161776910743.14253.17550631411662929687@ietfa.amsl.com> Date: Tue, 06 Apr 2021 21:18:27 -0700 Archived-At: Subject: [OPSEC] Erik Kline's Discuss on draft-ietf-opsec-v6-25: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2021 04:18:28 -0000 Erik Kline has entered the following ballot position for draft-ietf-opsec-v6-25: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- [ section 2.1 ] * "may also force the use of NPTv6" seems like it draws some conclusions. Perhaps something like: "may also increase the perceived need for the use of NPTv6"? [ section 2.2 ] * "It must also be noted that there is no indication in the IPv6 packet as to whether the Next Protocol field points to an extension header or to a transport header." What is this trying to say? Is this about what 8200 calls the "Next Header" field? If so, the Next Header field indicates...the next header, and whether that's a transport header or not depends on its value. I guess I read this text as implying that the 8200 standard is somehow ambiguous about what NH means, but it's really not. It's just that NH does not always indicate a transport. [ section 2.3.2.4 ] * "Only trivial cases [...] should have RA-guard..." Only? This doesn't strike me as being obviously the best recommendation. Definitely in trivial cases it should be enabled, but surely it should also be enabled even in more complex cases, albeit ones where knowledgeable administrators can configure things appropriately (vis. the applicability statement in section 1.1)...maybe? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [ general ] * There are many uses of ellipses ("...") that probably could be tightened up (usually just removed might work). [ section 2.1.1 ] * I think it never hurts to repeat the message that ULA /48s from the fd00::/8 space (L=1) MUST be generated with a pseudo-random algorithm, per RFC 4193 sections 3.2, 3.2.1, &c. [ section 2.1.4 ] * I think the opening sentence might clarify that it's talking about stable address assignment for nodes. On a one-pass reading, section 2.1.3 immediately preceding this is discussing router loopback addressing, so I found I had routers on the brain when I started 2.1.4. [ section 2.1.5 ] * Up to you, but 4941 has been superseded by 8981. [ section 2.1.6 ] * "(see Section 2.6.1.5)" -> I think the trailing ")" probably wants to be at the end of that sentence; if not, it does not quite make grammatical sense (to me). [ section 2.2.3 ] * s/ipv6/IPv6/g [ section 2.3.5 ] * As an addendum to the final paragraph, it might be noted that such filtering can inhibit mDNS (whether or not that's a desirable outcome). [ section 2.4 ] * "non-legit": perhaps a bit too casual? [ section 2.6.1.7 ] * "as currently collected as in" -> "as currently collected in", I suspect [ section 2.6.2.1 ] * There are other motivations for doing forensic analysis that simply investigating "malicious activity" (even if this is the most common motivation). As a concrete proposal, perhaps: "At the end of the process, the interface of the host originating, or the subscriber identity associated with, the activity in question has been determined." ...or something [ section 2.7.2 ] * "legit": perhaps a bit too casual? "legitimate"? Or perhaps just s/legit and//. [ section 2.7.2.8 ] * s/IPV4/IPv4/ * Consider port 123 NTP in your allowlist. :-) * "hardly never" -> "hardly ever" [ section 2.7.3.1 ] * Does this section belong in this document? It's all about IPv4, and not even particular to IPv4 in the presence of IPv6 -- just IPv4 in general. [ section 2.7.3.2 ] * "DNSSEC has an impact on DNS64" It might also be said that "DNS64 has an impact on DNSSEC", so perhaps "DNSSEC and DNS64 negatively interact"? [ section 4.3 ] * "and what the respective log retention" -> "and the respective log retention", I think From nobody Wed Apr 7 02:12:47 2021 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 572E13A1310; Wed, 7 Apr 2021 02:12:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tim Chown via Datatracker To: Cc: draft-ietf-opsec-v6.all@ietf.org, last-call@ietf.org, opsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161778675730.8077.2835666586607648895@ietfa.amsl.com> Reply-To: Tim Chown Date: Wed, 07 Apr 2021 02:12:37 -0700 Archived-At: Subject: [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-25 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2021 09:12:38 -0000 Reviewer: Tim Chown Review result: Has Issues Hi, I have reviewed this document (draft-ietf-opsec-v6-25) as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments. This draft analyses operational security issues related to the deployment of IPv6, and describes appropriate mechanisms and practices to mitigate potential threats. I had previously reviewed the draft as an OPS-DIR Early Review in July 2018, and again since then, so am familiar with the document and its history. General comments: The document has evolved over time with many topics added, and has an inevitable “Frankenstein” feel to it. The document would be much better for a rewrite, but that would be significant work, and would delay publication further. The material in the document is good, and the advice is valuable, so the focus should be on publishing it sooner rather than later, and thus the issues with structure are probably best overlooked. An example of the historical evolution of the document are the instances where the same topic os covered multiple times. This would ideally be avoided. The section most in need of attention is 2.1, where many aspects of addressing are weaved together: allocations, assignments, assignment to hosts, ULAs, stable and temporary addresses, etc. This might be better presented as a section listing addressing related security issues, such as privacy for users, first hop security, network manageability, implications of multi-addressed hosts, address accountability (which isn’t mentioned here?), avoiding renumbering (if that is security?), etc. There are also some sections which summarise recommendations, or reinforce them, and others that do not. For a document of over 50 pages, which is quite a long read, it would be desirable to have a summary of the key recommendations, either at the end of each 2nd level topic, or as a standalone section at the end of the document where the key points of each 2nd level topic are summarised. Is it worth citing examples of security toolkits readers can explore, like the THC kit, SI6 Networks, etc, maybe Scapy? Specific comments: p.3 I don’t understand why NPTv6 is mentioned here, this early. Just say that some security issues have IPv4 equivalents, like ND attacks and ARP attacks, and some do not, like IPv6 EHs or hop by hop DoS. The NAT discussion should be in a standalone section, and be neutral there. p.4 Why mention the specific example of multi-homed networks? What do you mean by the exception? Is it that multi-homing is out of scope, and so are unmanaged networks? p.4 Again, NPTv6 is mentioned. This section is titled “addressing architecture” but this bit of text is about reasons for going PA, PI, or becoming an LIR, which is not architecture. p.4 In the 7934 para, RFC8981 should be mentioned as it’s a significant reason of devices having more addresses. p.5 ULAs are also useful where the prefix changes, for stable internal addressing as the global prefix changes? Typically in residential networks. p.5 Section 2.1.4 is really about choices in address assignment within a network. p.6 Some of these paras should be in a section about IPv6 network reconnaissance, how to best mitigate against scanning, and how to inventory your own network elements. p.6 All mentions of 4941 should be replaced with 8981. p.7 Can use 7721 and 8981 together. p.7 Why are DHCP and DNS limped together? The DNS is only about DNSSEC, so call it that? p.7 “Even if the use of DHCP” - this reads badly. Rather 8504 talks about this in 6.5, where RFC7844 is mentioned for example. This should be in a user privacy section (if this document had one). Section 8.4 is also useful advice. p.8 The first para is very muddled. p.8 In 2.1.7 this can also be useful for ACL controls, if one admin / control system sits in a prefix of its own. p.10 This is really about handling of fragmented packets (the topic) not the fragment header itself Also this is covered in 2.3.2.1 as well. p.10 In 2.2, the intro can say these issues have parallels in IPv4. p.11 First line, say the attack can typically happen from a large address scan if permitted into the network? p.11 Bullet 1 - that contradicts the comments on predictable addressing. Bullet 2 - how? Some clues here would be useful. p.12 “Current” - really? All current implementations? Delete “current” or replace with “naive” maybe. p.12 “Communicate directly” - at L2? If so, why? p.12 An example of a recommendations section here, where other sections with advice are not titled as such. See the General comment on this. p.13 “Trivial” cases - aren’t these common ones, like edge switches in an enterprise? p.13 Why “hostile”? Delete? p.14 In 2.3.5 last para, what about mDNS, Bonjour? Though the DNS SD work is now on unicast discovery. p.21 Maybe add here 802.1x as an example of the value of RADIUS logs, and add in here as bullets info harvested from switches and (say) router NDP syslog (though that’s I suppose the 4th bullet). These are mentioned in 2.6.1.7 but should be split out at the same level as the other topics here. p.28 The text is 2.6.2.2 repeats earlier text. Similarly text in 2.6.2.3 is repeated form before. p.29 In 2.6.2.4 presumably also a rapid growth in ND cache size is an indicator. p.29 In 2.7 point to RFC 4942 p.30 Should RFC 6092 be mentioned here? And that the best defence against IPv6 attacks n “IPv4 only” networks is to deploy and manage IPv6? p.31 First bullet on this page - but isn’t this the same as if the traffic is not tunnelled? Why does tunnelling add the requirement? The same applies on the first para on p.32 p.31 Maybe say here the mitigations can also break tunnel brokers (might be desired, but users will notice…)…. Maybe tunnels to specific brokers can be allowed. p.32 ISATAP, in 2021? Same with 6rd. General advice should be deploy native, avoid tunnels. p.33 Same for 6to4. p.34 Teredo though, is that still included in Windows and XBoX, as a MS thing? p.36 Maybe cite Geoff Huston’s blog on this - it’s very good. Maybe there’s a more recent update though - https://blog.apnic.net/2016/06/09/lets-talk-ipv6-dns64-dnssec/. Host CLAT is applicable here? (Hence a site should support the 64PREF RA option? RFC8781 p.38 In 2.8, to be fair IPv4 is also hardened a lot of late due to the prevalence of use of devices in WiFi hotspots etc. p.37 Also RFC6092 on section 3.1? p.38 “Where RFC1918 address are often used” - add “often”, the text implies all enterprises use v4 NAT. p.41 Only 2 normative references? Nits: p.1 “The Internet” - you probably mean “an ISP network” “Describes the security” - delete “the” p.4 “Which are the switch” delete “which are” p.8 Varying -> various p.10 ipv6 -> IPv6 p.18 Router processor - add r to “route” — Tim From nobody Wed Apr 7 03:33:47 2021 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF643A1669; Wed, 7 Apr 2021 03:33:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Zaheduzzaman Sarker via Datatracker To: "The IESG" Cc: draft-ietf-opsec-v6@ietf.org, opsec-chairs@ietf.org, opsec@ietf.org, Gyan Mishra , hayabusagsm@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Zaheduzzaman Sarker Message-ID: <161779162147.18816.9995103488367885739@ietfa.amsl.com> Date: Wed, 07 Apr 2021 03:33:41 -0700 Archived-At: Subject: [OPSEC] Zaheduzzaman Sarker's No Objection on draft-ietf-opsec-v6-25: (with COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2021 10:33:42 -0000 Zaheduzzaman Sarker has entered the following ballot position for draft-ietf-opsec-v6-25: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I found this document very informative and I learned quite a lot by reading this document (I must confess I haven't read the long list of referenced documents :-)). I think the collected recommendations in one place will be very helpful. Some comments - * The abstract says - "The recommendations in this document are not applicable to residential user cases". However, later on in section 1.1 it says - "This covers Service Provider (SP), enterprise networks and some knowledgeable-home-user-managed residential network." Furthermore in section 5, it recommends configurations for residential users. May be I am not getting the distinction among residential user cases, managed residential network and residential users correct but I think further clarification is needed on what is written in thee abstract and what is in the rest of the document. * I noted that section 2.3.4 refers to 3GPP 4G terminologies while describing the case. If this section is not supposed to restricted to certain generations of 3GPP technologies then I would recommend to update the section with 5G terminologies as well. * In section 2.6 there is an ask for the network operators to log "of all applications using the network (including user space and kernel space) when available (for example web servers)". How realistic is this? I hardly see the web servers sharing logging files with network operators ( I would be happy to be corrected here ). I am also missing the discussion on -- if not available how much this affects the forensic research in the event of security incident and abnormal behavior. From nobody Thu Apr 8 15:50:09 2021 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFA23A2017; Thu, 8 Apr 2021 15:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNkJE10zJ-N3; Thu, 8 Apr 2021 15:50:01 -0700 (PDT) Received: from mx1.ernw.net (mx1.ernw.net [62.159.96.78]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC0F53A2015; Thu, 8 Apr 2021 15:50:00 -0700 (PDT) Received: from mail1.ernw.net (unknown [172.31.1.30]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id F371527309; Fri, 9 Apr 2021 00:49:54 +0200 (CEST) Received: from ws26.ernw.net (ws26.ernw.net [172.31.1.70]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ws26.ernw.net", Issuer "ernw ca1" (verified OK)) by mail1.ernw.net (Postfix) with ESMTPS id DDC5D40AF10; Fri, 9 Apr 2021 00:49:54 +0200 (CEST) Received: by ws26.ernw.net (Postfix, from userid 1002) id 03503E2BA; Fri, 9 Apr 2021 00:49:54 +0200 (CEST) Date: Fri, 9 Apr 2021 00:49:54 +0200 From: Enno Rey To: Erik Kline Cc: The IESG , draft-ietf-opsec-v6@ietf.org, opsec-chairs@ietf.org, opsec@ietf.org Message-ID: <20210408224954.GA85489@ernw.de> References: <161776910743.14253.17550631411662929687@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <161776910743.14253.17550631411662929687@ietfa.amsl.com> User-Agent: Mutt/1.11.3 (2019-02-01) Archived-At: Subject: Re: [OPSEC] Erik Kline's Discuss on draft-ietf-opsec-v6-25: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2021 22:50:04 -0000 Hi Erik, thank you very much for the detailed feedback. Based on that, and on some other reviewers' comments, we plan to do some edits, more specifically: On Tue, Apr 06, 2021 at 09:18:27PM -0700, Erik Kline via Datatracker wrote: > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > [ section 2.1 ] > > * "may also force the use of NPTv6" seems like it draws some conclusions. > > Perhaps something like: > > "may also increase the perceived need for the use of NPTv6"? That's a good point & proposed change; we'll incorporate that. > > [ section 2.2 ] > > * "It must also be noted that there is no indication in the IPv6 packet > as to whether the Next Protocol field points to an extension header > or to a transport header." > > What is this trying to say? Is this about what 8200 calls the "Next > Header" field? If so, the Next Header field indicates...the next > header, and whether that's a transport header or not depends on its > value. > > I guess I read this text as implying that the 8200 standard is somehow > ambiguous about what NH means, but it's really not. It's just that > NH does not always indicate a transport. I have in mind to replace the above sentence by the following: "Vendors of filtering solutions and operations personnel [responsible for implementing packet filtering rules] should be aware that the 'Next Header' field in an IPv6 header can both point to an IPv6 extension header or to an upper layer protocol header. This has to be kept in mind [or: considered] when designing the UX of filtering solutions or during the creation of [filtering] rule sets." >From ypur perspective, would this provide sufficient clarification with regard to the potential problem space? This was about misconceptions among security operators, not about RFC 8200 ambiguities. I hope my suggested sentence makes this clear. > > [ section 2.3.2.4 ] > > * "Only trivial cases [...] should have RA-guard..." > > Only? This doesn't strike me as being obviously the best recommendation. > Definitely in trivial cases it should be enabled, but surely it should > also be enabled even in more complex cases, albeit ones where > knowledgeable administrators can configure things appropriately > (vis. the applicability statement in section 1.1)...maybe? I agree with what you're writing. Point is that other reviewers pointed out that they see cases where RA-Guard would be counterproductve. I hence suggest to replace the phrase ("Only trivial cases") by the following: "Enabling RA-Guard by default in Wi-Fi networks or enterprise campus networks should be [strongly] considered unless specific circumstances [or: use cases] such as the presence of Homenet devices emitting router advertisements preclude this." Would that make sense, from your point of view? We will also address the majority of your COMMENTs in the next revision. Thank you again for providing those, and the above (very valid) points. Enno > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > [ general ] > > * There are many uses of ellipses ("...") that probably could be > tightened up (usually just removed might work). > > [ section 2.1.1 ] > > * I think it never hurts to repeat the message that ULA /48s from the > fd00::/8 space (L=1) MUST be generated with a pseudo-random algorithm, > per RFC 4193 sections 3.2, 3.2.1, &c. > > [ section 2.1.4 ] > > * I think the opening sentence might clarify that it's talking about > stable address assignment for nodes. On a one-pass reading, > section 2.1.3 immediately preceding this is discussing router loopback > addressing, so I found I had routers on the brain when I started 2.1.4. > > [ section 2.1.5 ] > > * Up to you, but 4941 has been superseded by 8981. > > [ section 2.1.6 ] > > * "(see Section 2.6.1.5)" -> I think the trailing ")" probably wants to be > at the end of that sentence; if not, it does not quite make grammatical > sense (to me). > > [ section 2.2.3 ] > > * s/ipv6/IPv6/g > > [ section 2.3.5 ] > > * As an addendum to the final paragraph, it might be noted that such > filtering can inhibit mDNS (whether or not that's a desirable outcome). > > [ section 2.4 ] > > * "non-legit": perhaps a bit too casual? > > [ section 2.6.1.7 ] > > * "as currently collected as in" -> "as currently collected in", I suspect > > [ section 2.6.2.1 ] > > * There are other motivations for doing forensic analysis that simply > investigating "malicious activity" (even if this is the most common > motivation). > > As a concrete proposal, perhaps: > > "At the end of the process, the interface of the host originating, > or the subscriber identity associated with, the activity in question > has been determined." > > ...or something > > [ section 2.7.2 ] > > * "legit": perhaps a bit too casual? "legitimate"? Or perhaps just > s/legit and//. > > [ section 2.7.2.8 ] > > * s/IPV4/IPv4/ > > * Consider port 123 NTP in your allowlist. :-) > > * "hardly never" -> "hardly ever" > > [ section 2.7.3.1 ] > > * Does this section belong in this document? It's all about IPv4, and > not even particular to IPv4 in the presence of IPv6 -- just IPv4 in > general. > > [ section 2.7.3.2 ] > > * "DNSSEC has an impact on DNS64" > > It might also be said that "DNS64 has an impact on DNSSEC", so perhaps > "DNSSEC and DNS64 negatively interact"? > > [ section 4.3 ] > > * "and what the respective log retention" -> > "and the respective log retention", I think > > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec -- Enno Rey Cell: +49 173 6745902 Twitter: @Enno_Insinuator From nobody Thu Apr 8 18:26:36 2021 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC6E3A2549; Thu, 8 Apr 2021 18:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 5OtttTmrunot; Thu, 8 Apr 2021 18:26:27 -0700 (PDT) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 937743A2547; Thu, 8 Apr 2021 18:26:26 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id c24-20020a9d6c980000b02902662e210895so4205226otr.9; Thu, 08 Apr 2021 18:26:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=4wks5ayQwHH2GMK+fkkB6EfZLNwoqg5IgQCQLibCS+o=; b=UQ6t8n2rB0mIqFk/02eil9m4paNTftzquzB3wrys9QgMxRFbB/P4MbVJz4oFJK58/h qtctyMP54lNe3LXyInLkT55zaGGvv64u030Xd3ciO7YsIULvSTI8Q+9bm9ii6VWAjF1w +ot9/cK24gVFhWO9E9EarBOMgQ6IBYjHXZlgRQYqPejITWQCZZ8QoJROOIN5V36WhZj7 oGj3zov+oXATRpk3IA6XpR3JXs1exPx/ZrhadGhdafd42p7t7XUUevF4P1uLau8DBgm6 fOgYe4OShdyPTYKbCr258oZcbNXGcofqF84BHMFwQ3HtGvrCJkoZYOZrY5jIuVwnx0vO SK4g== 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=4wks5ayQwHH2GMK+fkkB6EfZLNwoqg5IgQCQLibCS+o=; b=VC+L+aZ+UjYsrm9WvwKf59VyNbGWLP/C0UuH0vajRfAtMjXOcBd8PPy3wEX52WLTAE /rsiE9eWl9KHLY2hUzR3Isr5s3DIT5kxJhMPLB1ZMbwOl9gaxcUvlJ0NAzhY+TXtr4aS FYo9S2oOsQrh0jccOZHtIg1Je6fBwufVdq7N2s8UaQpvhDVWrJEPiKRtFNOTirCqV4RY V0MUk9DUicKlWL2OSIGovIZ9RbF1oPu9Yg9iNJwWBVh4H7xa3vG+VXIA3COnVg9o6c9W HnSHiCo5/gAYOhHuXmsaWlqCU3pVa3gCr+Hj/w4KYfdj1LSV2wHDPTqeEQSMDU3mWulc GmQA== X-Gm-Message-State: AOAM5312/pKv/tJOwHHcEI4mm3/dLnbB2gmtW6lfvjZqLrUiCbV4dJFd 9UTcAnF9PUdGG22VV/62BGh+WzunHq4OCcYDBh+ieW9p X-Google-Smtp-Source: ABdhPJzxKs4vdZQn7DuTlLNyY9MQ0ykKOVP8AgJx4uo8FhyX7S9pufYct0uIhbddZTxMiBs06o7ILq/IRRiDNN5q2RU= X-Received: by 2002:a05:6830:140e:: with SMTP id v14mr10319338otp.155.1617931585377; Thu, 08 Apr 2021 18:26:25 -0700 (PDT) MIME-Version: 1.0 References: <161776910743.14253.17550631411662929687@ietfa.amsl.com> <20210408224954.GA85489@ernw.de> In-Reply-To: <20210408224954.GA85489@ernw.de> From: Erik Kline Date: Thu, 8 Apr 2021 18:26:14 -0700 Message-ID: To: Enno Rey Cc: The IESG , draft-ietf-opsec-v6@ietf.org, opsec-chairs@ietf.org, opsec@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OPSEC] Erik Kline's Discuss on draft-ietf-opsec-v6-25: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2021 01:26:32 -0000 Enno, Broadly these proposed changes seem good to me. I look forward to reading the next version. Thanks! On Thu, Apr 8, 2021 at 3:49 PM Enno Rey wrote: > > Hi Erik, > > thank you very much for the detailed feedback. > Based on that, and on some other reviewers' comments, we plan to do some = edits, more specifically: > > > > On Tue, Apr 06, 2021 at 09:18:27PM -0700, Erik Kline via Datatracker wrot= e: > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > [ section 2.1 ] > > > > * "may also force the use of NPTv6" seems like it draws some conclusion= s. > > > > Perhaps something like: > > > > "may also increase the perceived need for the use of NPTv6"? > > That's a good point & proposed change; we'll incorporate that. > > > > > > [ section 2.2 ] > > > > * "It must also be noted that there is no indication in the IPv6 packet > > as to whether the Next Protocol field points to an extension header > > or to a transport header." > > > > What is this trying to say? Is this about what 8200 calls the "Next > > Header" field? If so, the Next Header field indicates...the next > > header, and whether that's a transport header or not depends on its > > value. > > > > I guess I read this text as implying that the 8200 standard is someho= w > > ambiguous about what NH means, but it's really not. It's just that > > NH does not always indicate a transport. > > I have in mind to replace the above sentence by the following: > "Vendors of filtering solutions and operations personnel [responsible for= implementing packet filtering rules] should be aware that the 'Next Header= ' field in an IPv6 header can both point to an IPv6 extension header or to = an upper layer protocol header. This has to be kept in mind [or: considered= ] when designing the UX of filtering solutions or during the creation of [f= iltering] rule sets." > > From ypur perspective, would this provide sufficient clarification with r= egard to the potential problem space? This was about misconceptions among s= ecurity operators, not about RFC 8200 ambiguities. I hope my suggested sent= ence makes this clear. > > > > > > [ section 2.3.2.4 ] > > > > * "Only trivial cases [...] should have RA-guard..." > > > > Only? This doesn't strike me as being obviously the best recommendat= ion. > > Definitely in trivial cases it should be enabled, but surely it shoul= d > > also be enabled even in more complex cases, albeit ones where > > knowledgeable administrators can configure things appropriately > > (vis. the applicability statement in section 1.1)...maybe? > > I agree with what you're writing. Point is that other reviewers pointed o= ut that they see cases where RA-Guard would be counterproductve. I hence su= ggest to replace the phrase ("Only trivial cases") by the following: > > "Enabling RA-Guard by default in Wi-Fi networks or enterprise campus netw= orks should be [strongly] considered unless specific circumstances [or: use= cases] such as the presence of Homenet devices emitting router advertiseme= nts preclude this." > > Would that make sense, from your point of view? > > We will also address the majority of your COMMENTs in the next revision. = Thank you again for providing those, and the above (very valid) points. > > Enno > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > [ general ] > > > > * There are many uses of ellipses ("...") that probably could be > > tightened up (usually just removed might work). > > > > [ section 2.1.1 ] > > > > * I think it never hurts to repeat the message that ULA /48s from the > > fd00::/8 space (L=3D1) MUST be generated with a pseudo-random algorit= hm, > > per RFC 4193 sections 3.2, 3.2.1, &c. > > > > [ section 2.1.4 ] > > > > * I think the opening sentence might clarify that it's talking about > > stable address assignment for nodes. On a one-pass reading, > > section 2.1.3 immediately preceding this is discussing router loopbac= k > > addressing, so I found I had routers on the brain when I started 2.1.= 4. > > > > [ section 2.1.5 ] > > > > * Up to you, but 4941 has been superseded by 8981. > > > > [ section 2.1.6 ] > > > > * "(see Section 2.6.1.5)" -> I think the trailing ")" probably wants to= be > > at the end of that sentence; if not, it does not quite make grammatic= al > > sense (to me). > > > > [ section 2.2.3 ] > > > > * s/ipv6/IPv6/g > > > > [ section 2.3.5 ] > > > > * As an addendum to the final paragraph, it might be noted that such > > filtering can inhibit mDNS (whether or not that's a desirable outcome= ). > > > > [ section 2.4 ] > > > > * "non-legit": perhaps a bit too casual? > > > > [ section 2.6.1.7 ] > > > > * "as currently collected as in" -> "as currently collected in", I susp= ect > > > > [ section 2.6.2.1 ] > > > > * There are other motivations for doing forensic analysis that simply > > investigating "malicious activity" (even if this is the most common > > motivation). > > > > As a concrete proposal, perhaps: > > > > "At the end of the process, the interface of the host originating, > > or the subscriber identity associated with, the activity in question > > has been determined." > > > > ...or something > > > > [ section 2.7.2 ] > > > > * "legit": perhaps a bit too casual? "legitimate"? Or perhaps just > > s/legit and//. > > > > [ section 2.7.2.8 ] > > > > * s/IPV4/IPv4/ > > > > * Consider port 123 NTP in your allowlist. :-) > > > > * "hardly never" -> "hardly ever" > > > > [ section 2.7.3.1 ] > > > > * Does this section belong in this document? It's all about IPv4, and > > not even particular to IPv4 in the presence of IPv6 -- just IPv4 in > > general. > > > > [ section 2.7.3.2 ] > > > > * "DNSSEC has an impact on DNS64" > > > > It might also be said that "DNS64 has an impact on DNSSEC", so perhap= s > > "DNSSEC and DNS64 negatively interact"? > > > > [ section 4.3 ] > > > > * "and what the respective log retention" -> > > "and the respective log retention", I think > > > > > > > > _______________________________________________ > > OPSEC mailing list > > OPSEC@ietf.org > > https://www.ietf.org/mailman/listinfo/opsec > > -- > Enno Rey > > Cell: +49 173 6745902 > Twitter: @Enno_Insinuator From nobody Fri Apr 9 08:31:06 2021 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A86B3A24F0; Fri, 9 Apr 2021 08:31:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: opsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: opsec@ietf.org Message-ID: <161798226004.20384.18073846203833109876@ietfa.amsl.com> Date: Fri, 09 Apr 2021 08:31:00 -0700 Archived-At: Subject: [OPSEC] I-D Action: draft-ietf-opsec-v6-26.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2021 15:31:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure WG of the IETF. Title : Operational Security Considerations for IPv6 Networks Authors : Eric Vyncke Kiran Kumar Merike Kaeo Enno Rey Filename : draft-ietf-opsec-v6-26.txt Pages : 57 Date : 2021-04-09 Abstract: Knowledge and experience on how to operate IPv4 networks securely is available: whether it is an Internet Service Provider or an enterprise internal network. However, IPv6 presents some new security challenges. RFC 4942 describes security issues in the protocol, but network managers also need a more practical, operations-minded document to enumerate advantages and/or disadvantages of certain choices. This document analyzes the operational security issues associated with several types of network and proposes technical and procedural mitigation techniques. This document is only applicable to managed networks, such as enterprise networks. The recommendations in this document are not applicable to residential user cases, even in cases where a Service Provider may be managing the home gateway. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-opsec-v6-26 https://datatracker.ietf.org/doc/html/draft-ietf-opsec-v6-26 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-v6-26 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Apr 10 11:31:53 2021 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3073A0DD5; Sat, 10 Apr 2021 11:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkkjtySmy5Nv; Sat, 10 Apr 2021 11:31:39 -0700 (PDT) Received: from mx1.ernw.net (mx1.ernw.net [62.159.96.78]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE4CD3A0DF8; Sat, 10 Apr 2021 11:31:37 -0700 (PDT) Received: from mail1.ernw.net (unknown [IPv6:fd00:2001:0:d001::30]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id 9B1B127326; Sat, 10 Apr 2021 20:31:33 +0200 (CEST) Received: from ws26.ernw.net (ws26.ernw.net [172.31.1.70]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ws26.ernw.net", Issuer "ernw ca1" (verified OK)) by mail1.ernw.net (Postfix) with ESMTPS id 8B01B452D59; Sat, 10 Apr 2021 20:31:33 +0200 (CEST) Received: by ws26.ernw.net (Postfix, from userid 1002) id 787EFE5AB; Sat, 10 Apr 2021 20:31:33 +0200 (CEST) Date: Sat, 10 Apr 2021 20:31:33 +0200 From: Enno Rey To: Martin Duke Cc: The IESG , draft-ietf-opsec-v6@ietf.org, opsec-chairs@ietf.org, opsec@ietf.org Message-ID: <20210410183133.GB91991@ernw.de> References: <161764639244.16129.8383571157085804937@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <161764639244.16129.8383571157085804937@ietfa.amsl.com> User-Agent: Mutt/1.11.3 (2019-02-01) Archived-At: Subject: Re: [OPSEC] Martin Duke's No Objection on draft-ietf-opsec-v6-25: (with COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2021 18:31:47 -0000 Hi Martin, thank you for the evaluation. Regarding your COMMENT: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I haven't gone through the dozens of references to verify the claims about > them, so I'm trusting the WG and ADs here... > > In Sec 2.3.2.4, RA-Guard and SAVI are recommended, but then in the same > paragraph it says that "only trivial cases" should enable it by default. I > can't reconcile these two statements. In fact your sentiment identifies a proper point. I've modified the respective section, and a new version has been uploaded. Thanks again & have a good weekend Enno > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec -- Enno Rey Cell: +49 173 6745902 Twitter: @Enno_Insinuator From nobody Sat Apr 10 11:36:39 2021 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8C63A0DF6; Sat, 10 Apr 2021 11:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8vJfC-xjGya; Sat, 10 Apr 2021 11:36:28 -0700 (PDT) Received: from mx1.ernw.net (mx1.ernw.net [62.159.96.78]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A2AE3A0DF3; Sat, 10 Apr 2021 11:36:28 -0700 (PDT) Received: from mail1.ernw.net (unknown [172.31.1.30]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (2048 bits) client-signature RSA-PSS (2048 bits)) (Client CN "mail1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id 4123B27309; Sat, 10 Apr 2021 20:36:26 +0200 (CEST) Received: from ws26.ernw.net (ws26.ernw.net [172.31.1.70]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ws26.ernw.net", Issuer "ernw ca1" (verified OK)) by mail1.ernw.net (Postfix) with ESMTPS id 2E204452D68; Sat, 10 Apr 2021 20:36:26 +0200 (CEST) Received: by ws26.ernw.net (Postfix, from userid 1002) id 27894E5B4; Sat, 10 Apr 2021 20:36:26 +0200 (CEST) Date: Sat, 10 Apr 2021 20:36:26 +0200 From: Enno Rey To: Alvaro Retana Cc: The IESG , draft-ietf-opsec-v6@ietf.org, opsec-chairs@ietf.org, opsec@ietf.org, Gyan Mishra Message-ID: <20210410183626.GC91991@ernw.de> References: <161765687327.663.16409961435864058863@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <161765687327.663.16409961435864058863@ietfa.amsl.com> User-Agent: Mutt/1.11.3 (2019-02-01) Archived-At: Subject: Re: [OPSEC] Alvaro Retana's No Objection on draft-ietf-opsec-v6-25: (with COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2021 18:36:33 -0000 Hi Alvaro, thanks for the detailed evaluation and for the valuable feedback. I went thru your COMMENTS and performed some related adaptions of the draft. A new version has been uploaded. thank you again & have a great weekend Enno On Mon, Apr 05, 2021 at 02:07:53PM -0700, Alvaro Retana via Datatracker wrote: > Alvaro Retana has entered the following ballot position for > draft-ietf-opsec-v6-25: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > (1) The applicability statement in ??1.1 is confusing to me. > > a. The Abstract says that "this document are not applicable to residential > user cases", but that seems not to be true because this section says that the > contents do apply to "some knowledgeable-home-user-managed residential > network[s]", and ??5 is specific to residential users. > > b. "This applicability statement especially applies to Section 2.3 and Section > 2.5.4." Those two sections represent a small part of the document; what about > the rest? It makes sense to me for the applicability statement to cover most > of the document. > > c. "For example, an exception to the generic recommendations of this document > is when a residential or enterprise network is multi-homed." I'm not sure if > this sentence is an example of the previous one (above) or if "for example" is > out of place. > > (2) ??5 mentions "early 2020" -- I assume that the statement is still true now. > > (3) It caught my attention that there's only one Normative Reference (besides > rfc8200, of course). Why? What is special about the IPFIX registry? > > It seems that an argument could be made to the fact that to secure OSPFv3, for > example, an understanding of the protocol is necessary. This argument could be > extended to other protocols or mechanisms, including IPv6-specific technology: > ND, the addressing architecture, etc. Consider the classification of the > references in light of [1]. > > [1] > https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ > > > -- Enno Rey Cell: +49 173 6745902 Twitter: @Enno_Insinuator From nobody Sat Apr 10 11:39:41 2021 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96AB03A0E14; Sat, 10 Apr 2021 11:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WksG6JBReXaO; Sat, 10 Apr 2021 11:39:30 -0700 (PDT) Received: from mx1.ernw.net (mx1.ernw.net [IPv6:2003:60:4010:10a0::11]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 542E43A0E11; Sat, 10 Apr 2021 11:39:29 -0700 (PDT) Received: from mail1.ernw.net (unknown [172.31.1.30]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (2048 bits) client-signature RSA-PSS (2048 bits)) (Client CN "mail1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id DD6B327309; Sat, 10 Apr 2021 20:39:26 +0200 (CEST) Received: from ws26.ernw.net (ws26.ernw.net [172.31.1.70]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ws26.ernw.net", Issuer "ernw ca1" (verified OK)) by mail1.ernw.net (Postfix) with ESMTPS id C88E8452D6D; Sat, 10 Apr 2021 20:39:26 +0200 (CEST) Received: by ws26.ernw.net (Postfix, from userid 1002) id AB0FCE5BA; Sat, 10 Apr 2021 20:39:26 +0200 (CEST) Date: Sat, 10 Apr 2021 20:39:26 +0200 From: Enno Rey To: Lars Eggert Cc: The IESG , draft-ietf-opsec-v6@ietf.org, opsec-chairs@ietf.org, opsec@ietf.org, Gyan Mishra Message-ID: <20210410183926.GD91991@ernw.de> References: <161772120964.13732.17403156280296269605@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <161772120964.13732.17403156280296269605@ietfa.amsl.com> User-Agent: Mutt/1.11.3 (2019-02-01) Archived-At: Subject: Re: [OPSEC] Lars Eggert's No Objection on draft-ietf-opsec-v6-25: (with COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2021 18:39:35 -0000 Hi Lars, thank you for the extensive evaluation/feedback. I went through all your COMMENTs and I've performed a number of adaptions/corrections. We subsequently uploaded a new version of the draft. Thanks again for pointing out those items, cheers Enno On Tue, Apr 06, 2021 at 08:00:09AM -0700, Lars Eggert via Datatracker wrote: > Lars Eggert has entered the following ballot position for > draft-ietf-opsec-v6-25: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 2.3.1, paragraph 6, comment: > > o Tuning of NDP process (where supported). > > Tuning in which way? > > Section 2.7.2, paragraph 2, comment: > > There are many tunnels used for specific use cases. Except when > > protected by IPsec [RFC4301], all those tunnels have a couple of > > security issues as described in RFC 6169 [RFC6169]; > > IPsec is not the only security mechanism that will protect tunnels, most > tunnel encryption mechanisms would. > > ------------------------------------------------------------------------------- > All comments below are very minor change suggestions that you may choose to > incorporate in some way (or ignore), as you see fit. There is no need to let me > know what you did with these suggestions. > > Section 2.5.3, paragraph 4, nit: > > Many routing protocols support the use of cryptography to protect the > > routing updates, the use of this protection is recommended; [RFC8177] > > is a YANG data model key chains including the renewal. > > > > I can't parse the part after the semicolon. > > Section 2.6.2.2, paragraph 9, nit: > Might also want to mention http://www.entropy-ip.com/ and similar tools. > > Section 2.2.3, paragraph 3, nit: > - not contain the entire ipv6 header chain (including the transport- > - ^^ > + not contain the entire IPv6 header chain (including the transport- > + ^^ > > Section 2.2.3, paragraph 4, nit: > - contain the entire ipv6 header chain (including the transport- > - ^^ > + contain the entire IPv6 header chain (including the transport- > + ^^ > > Section 2.2.4, paragraph 2, nit: > - the updated IPv6 Nodes Requirement standard [RFC8504] IPsec is a > + the updated IPv6 Nodes Requirement standard [RFC8504], IPsec is a > + + > > Section 2.3, paragraph 2, nit: > - operations such as discovering other nodes on the link, resolving > + operations, such as discovering other nodes on the link, resolving > + + > > Section 2.3, paragraph 2, nit: > - secured, NDP is vulnerable to various attacks such as router/neighbor > + secured, NDP is vulnerable to various attacks, such as router/neighbor > + + > > Section 2.3, paragraph 2, nit: > - documented in IPv6 ND Trust Models and Threats [RFC3756] and in > > Section 2.3.1, paragraph 2, nit: > - Neighbor Discovery Protocol (NDP) can be vulnerable to remote denial > + The Neighbor Discovery Protocol (NDP) can be vulnerable to remote denial > + ++++ > > Section 2.3.1, paragraph 6, nit: > - o Using /127 on point-to-point link per [RFC6164]. > + o Using a /127 on a point-to-point link, per [RFC6164]. > + ++ ++ + > > Section 2.3.2.3, paragraph 2, nit: > - on-link prefix; 3GPP Section 2.3.4 uses a similar mechanism. > + on-link prefix; 3GPP (see Section 2.3.4) uses a similar mechanism. > + +++++ + > > Section 2.3.3, paragraph 2, nit: > - Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as described > - in [RFC8415], enables DHCP servers to pass configuration parameters > - such as IPv6 network addresses and other configuration information to > - IPv6 nodes such as a hostile recursive DNS server. DHCP plays an > + The Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as described > + ++++ > + in [RFC8415], enables DHCP servers to pass configuration parameters, > + + > + such as IPv6 network addresses and other configuration information, to > + + > + IPv6 nodes, such as a hostile recursive DNS server. DHCP plays an > + + > > Section 2.3.3, paragraph 3, nit: > - of-service attack or to mount on path attack. While unintentional, a > - ^ > + of-service attack or to mount an on-path attack. While unintentional, a > + +++ ^ > > Section 2.3.4, paragraph 2, nit: > - address. This implies there can only be an end host (the mobile > - ^ > + address. This implies there can only be one end host (the mobile > + ^ + > > Section 2.3.4, paragraph 2, nit: > - address built by the mobile host. The GGSN/PGW always provides an > - ^^^^ > + address generated by the mobile host. The GGSN/PGW always provides an > + ^^^^^^ ++ > > Section 2.3.4, paragraph 4, nit: > - link model, NDP on it and the address configuration details. In some > - ------ > + link model, NDP and the address configuration details. In some > > Section 2.5, paragraph 8, nit: > - interface where it is required. > + interfaces where it is required. > + + > > Section 2.5.4, paragraph 2, nit: > - pertain to edge route filtering vs internal route filtering. At a > + pertain to edge route filtering vs. internal route filtering. At a > + + > > Section 2.6.1.5, paragraph 2, nit: > - clients. It is indeed quite similar to DHCP for IPv4 so it can be > + clients. It is indeed quite similar to DHCP for IPv4, so it can be > + + > > Section 2.6.1.5, paragraph 3, nit: > - It is not so easy in the IPv6 networks because not all nodes will use > - ---- > + It is not so easy in IPv6 networks, because not all nodes will use > + + > > Section 2.7.3.1, paragraph 2, nit: > - Carrier-Grade NAT (CGN), also called NAT444 CGN or Large Scale NAT > - ^^^ > + Carrier-Grade NAT (CGN), also called NAT444 CGN, Large Scale NAT > + ^ > > Section 4.3, paragraph 3, nit: > - (e.g., his/her PPP session, physical line, or CPE MAC address). With > - ^^^^ > + (e.g., his/her PPP session, physical line, or CPE MAC address). In > + ^^ > > > -- Enno Rey Cell: +49 173 6745902 Twitter: @Enno_Insinuator From nobody Sat Apr 10 11:46:15 2021 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBB23A0E62; Sat, 10 Apr 2021 11:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgkeCGAwZanm; Sat, 10 Apr 2021 11:46:01 -0700 (PDT) Received: from mx1.ernw.net (mx1.ernw.net [62.159.96.78]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B95E3A0E60; Sat, 10 Apr 2021 11:45:57 -0700 (PDT) Received: from mail1.ernw.net (unknown [IPv6:fd00:2001:0:d001::30]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (2048 bits) client-signature RSA-PSS (2048 bits)) (Client CN "mail1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id 9DE1227309; Sat, 10 Apr 2021 20:45:55 +0200 (CEST) Received: from ws26.ernw.net (ws26.ernw.net [172.31.1.70]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ws26.ernw.net", Issuer "ernw ca1" (verified OK)) by mail1.ernw.net (Postfix) with ESMTPS id 8566D452D7C; Sat, 10 Apr 2021 20:45:55 +0200 (CEST) Received: by ws26.ernw.net (Postfix, from userid 1002) id 7B3FDE5C1; Sat, 10 Apr 2021 20:45:55 +0200 (CEST) Date: Sat, 10 Apr 2021 20:45:55 +0200 From: Enno Rey To: Tim Chown Cc: ops-dir@ietf.org, last-call@ietf.org, opsec@ietf.org, draft-ietf-opsec-v6.all@ietf.org Message-ID: <20210410184555.GE91991@ernw.de> References: <161778675730.8077.2835666586607648895@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <161778675730.8077.2835666586607648895@ietfa.amsl.com> User-Agent: Mutt/1.11.3 (2019-02-01) Archived-At: Subject: Re: [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-25 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2021 18:46:06 -0000 Hi Tim, thanks so much for another detailed look at the draft. Your feeling that it has been in the making for a while is correct (tell me about it ;-), still we think that the operational security guidance for IPv6 hasn't change much over time, and it might even be more needed than ever (given current momentum of IPv6 uptake). I went through your below points, and for many of them I've performed according clarifications/enhancements of the draft. A new version has then been uploaded. Wish you a great weekend Enno On Wed, Apr 07, 2021 at 02:12:37AM -0700, Tim Chown via Datatracker wrote: > Reviewer: Tim Chown > Review result: Has Issues > > Hi, > > I have reviewed this document (draft-ietf-opsec-v6-25) as part of the > Operational directorate's ongoing effort to review all IETF documents being > processed by the IESG.?? These comments were written with the intent of > improving the operational aspects of the IETF drafts. Comments that are not > addressed in last call may be included in AD reviews during the IESG review.?? > Document editors and WG chairs should treat these comments just like any other > last call comments. > > This draft analyses operational security issues related to the deployment of > IPv6, and describes appropriate mechanisms and practices to mitigate potential > threats. > > I had previously reviewed the draft as an OPS-DIR Early Review in July 2018, > and again since then, so am familiar with the document and its history. > > General comments: > > The document has evolved over time with many topics added, and has an > inevitable ???Frankenstein??? feel to it. The document would be much better for a > rewrite, but that would be significant work, and would delay publication > further. The material in the document is good, and the advice is valuable, so > the focus should be on publishing it sooner rather than later, and thus the > issues with structure are probably best overlooked. > > An example of the historical evolution of the document are the instances where > the same topic os covered multiple times. This would ideally be avoided. > > The section most in need of attention is 2.1, where many aspects of addressing > are weaved together: allocations, assignments, assignment to hosts, ULAs, > stable and temporary addresses, etc. This might be better presented as a > section listing addressing related security issues, such as privacy for users, > first hop security, network manageability, implications of multi-addressed > hosts, address accountability (which isn???t mentioned here?), avoiding > renumbering (if that is security?), etc. > > There are also some sections which summarise recommendations, or reinforce > them, and others that do not. For a document of over 50 pages, which is quite > a long read, it would be desirable to have a summary of the key > recommendations, either at the end of each 2nd level topic, or as a standalone > section at the end of the document where the key points of each 2nd level topic > are summarised. > > Is it worth citing examples of security toolkits readers can explore, like the > THC kit, SI6 Networks, etc, maybe Scapy? > > Specific comments: > > p.3 > I don???t understand why NPTv6 is mentioned here, this early. Just say that some > security issues have IPv4 equivalents, like ND attacks and ARP attacks, and > some do not, like IPv6 EHs or hop by hop DoS. The NAT discussion should be in > a standalone section, and be neutral there. > > p.4 > Why mention the specific example of multi-homed networks? What do you mean by > the exception? Is it that multi-homing is out of scope, and so are unmanaged > networks? > > p.4 > Again, NPTv6 is mentioned. This section is titled ???addressing architecture??? > but this bit of text is about reasons for going PA, PI, or becoming an LIR, > which is not architecture. > > p.4 > In the 7934 para, RFC8981 should be mentioned as it???s a significant reason of > devices having more addresses. > > p.5 > ULAs are also useful where the prefix changes, for stable internal addressing > as the global prefix changes? Typically in residential networks. > > p.5 > Section 2.1.4 is really about choices in address assignment within a network. > > p.6 > Some of these paras should be in a section about IPv6 network reconnaissance, > how to best mitigate against scanning, and how to inventory your own network > elements. > > p.6 > All mentions of 4941 should be replaced with 8981. > > p.7 > Can use 7721 and 8981 together. > > p.7 > Why are DHCP and DNS limped together? The DNS is only about DNSSEC, so call it > that? > > p.7 > ???Even if the use of DHCP??? - this reads badly. Rather 8504 talks about this in > 6.5, where RFC7844 is mentioned for example. This should be in a user privacy > section (if this document had one). Section 8.4 is also useful advice. > > p.8 > The first para is very muddled. > > p.8 > In 2.1.7 this can also be useful for ACL controls, if one admin / control > system sits in a prefix of its own. > > p.10 > This is really about handling of fragmented packets (the topic) not the > fragment header itself Also this is covered in 2.3.2.1 as well. > > p.10 > In 2.2, the intro can say these issues have parallels in IPv4. > > p.11 > First line, say the attack can typically happen from a large address scan if > permitted into the network? > > p.11 > Bullet 1 - that contradicts the comments on predictable addressing. > Bullet 2 - how? Some clues here would be useful. > > p.12 > ???Current??? - really? All current implementations? Delete ???current??? or replace > with ???naive??? maybe. > > p.12 > ???Communicate directly??? - at L2? If so, why? > > p.12 > An example of a recommendations section here, where other sections with advice > are not titled as such. See the General comment on this. > > p.13 > ???Trivial??? cases - aren???t these common ones, like edge switches in an enterprise? > > p.13 > Why ???hostile???? Delete? > > p.14 > In 2.3.5 last para, what about mDNS, Bonjour? Though the DNS SD work is now > on unicast discovery. > > p.21 > Maybe add here 802.1x as an example of the value of RADIUS logs, and add in > here as bullets info harvested from switches and (say) router NDP syslog > (though that???s I suppose the 4th bullet). These are mentioned in 2.6.1.7 but > should be split out at the same level as the other topics here. > > p.28 > The text is 2.6.2.2 repeats earlier text. > Similarly text in 2.6.2.3 is repeated form before. > > p.29 > In 2.6.2.4 presumably also a rapid growth in ND cache size is an indicator. > > p.29 > In 2.7 point to RFC 4942 > > p.30 > Should RFC 6092 be mentioned here? > And that the best defence against IPv6 attacks n ???IPv4 only??? networks is to > deploy and manage IPv6? > > p.31 > First bullet on this page - but isn???t this the same as if the traffic is not > tunnelled? Why does tunnelling add the requirement? The same applies on the > first para on p.32 > > p.31 > Maybe say here the mitigations can also break tunnel brokers (might be desired, > but users will notice???)???. Maybe tunnels to specific brokers can be allowed. > > p.32 > ISATAP, in 2021? Same with 6rd. General advice should be deploy native, avoid > tunnels. > > p.33 > Same for 6to4. > > p.34 > Teredo though, is that still included in Windows and XBoX, as a MS thing? > > p.36 > Maybe cite Geoff Huston???s blog on this - it???s very good. Maybe there???s a more > recent update though - > https://blog.apnic.net/2016/06/09/lets-talk-ipv6-dns64-dnssec/. Host CLAT is > applicable here? (Hence a site should support the 64PREF RA option? RFC8781 > > p.38 > In 2.8, to be fair IPv4 is also hardened a lot of late due to the prevalence of > use of devices in WiFi hotspots etc. > > p.37 > Also RFC6092 on section 3.1? > > p.38 > ???Where RFC1918 address are often used??? - add ???often???, the text implies all > enterprises use v4 NAT. > > p.41 > Only 2 normative references? > > Nits: > > p.1 > ???The Internet??? - you probably mean ???an ISP network??? > ???Describes the security??? - delete ???the??? > > p.4 > ???Which are the switch??? delete ???which are??? > > p.8 > Varying -> various > > p.10 > ipv6 -> IPv6 > > p.18 > Router processor - add r to ???route??? > > ??? > Tim > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec -- Enno Rey Cell: +49 173 6745902 Twitter: @Enno_Insinuator From nobody Sat Apr 10 11:53:55 2021 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F189B3A0EF0; Sat, 10 Apr 2021 11:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCfBdXhrd063; Sat, 10 Apr 2021 11:53:44 -0700 (PDT) Received: from mx1.ernw.net (mx1.ernw.net [62.159.96.78]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CF6C3A0EEE; Sat, 10 Apr 2021 11:53:43 -0700 (PDT) Received: from mail1.ernw.net (unknown [IPv6:fd00:2001:0:d001::30]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (2048 bits) client-signature RSA-PSS (2048 bits)) (Client CN "mail1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id 91E4927309; Sat, 10 Apr 2021 20:53:42 +0200 (CEST) Received: from ws26.ernw.net (ws26.ernw.net [172.31.1.70]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ws26.ernw.net", Issuer "ernw ca1" (verified OK)) by mail1.ernw.net (Postfix) with ESMTPS id 74BAE452D87; Sat, 10 Apr 2021 20:53:42 +0200 (CEST) Received: by ws26.ernw.net (Postfix, from userid 1002) id 6F1A4E5C8; Sat, 10 Apr 2021 20:53:42 +0200 (CEST) Date: Sat, 10 Apr 2021 20:53:42 +0200 From: Enno Rey To: Erik Kline Cc: The IESG , draft-ietf-opsec-v6@ietf.org, opsec-chairs@ietf.org, opsec@ietf.org Message-ID: <20210410185342.GA92112@ernw.de> References: <161776910743.14253.17550631411662929687@ietfa.amsl.com> <20210408224954.GA85489@ernw.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) Archived-At: Subject: Re: [OPSEC] Erik Kline's Discuss on draft-ietf-opsec-v6-25: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2021 18:53:49 -0000 Erik, On Thu, Apr 08, 2021 at 06:26:14PM -0700, Erik Kline wrote: > Enno, > > Broadly these proposed changes seem good to me. I look forward to > reading the next version. It has been uploaded in the interim. I incorporated those proposed changes, and I also performed a number of additional changes which should address your COMMENTs (plus those of other reviewers). May I kindly ask you to clear your DISCUSS once you had the time to look at the revised version (and, evidently, you consider the changes sufficiently clarifying)? Thanks again very much for the extensive review. Wish you a great weekend, Enno > > Thanks! > > On Thu, Apr 8, 2021 at 3:49 PM Enno Rey wrote: > > > > Hi Erik, > > > > thank you very much for the detailed feedback. > > Based on that, and on some other reviewers' comments, we plan to do some edits, more specifically: > > > > > > > > On Tue, Apr 06, 2021 at 09:18:27PM -0700, Erik Kline via Datatracker wrote: > > > > > > ---------------------------------------------------------------------- > > > DISCUSS: > > > ---------------------------------------------------------------------- > > > > > > [ section 2.1 ] > > > > > > * "may also force the use of NPTv6" seems like it draws some conclusions. > > > > > > Perhaps something like: > > > > > > "may also increase the perceived need for the use of NPTv6"? > > > > That's a good point & proposed change; we'll incorporate that. > > > > > > > > > > [ section 2.2 ] > > > > > > * "It must also be noted that there is no indication in the IPv6 packet > > > as to whether the Next Protocol field points to an extension header > > > or to a transport header." > > > > > > What is this trying to say? Is this about what 8200 calls the "Next > > > Header" field? If so, the Next Header field indicates...the next > > > header, and whether that's a transport header or not depends on its > > > value. > > > > > > I guess I read this text as implying that the 8200 standard is somehow > > > ambiguous about what NH means, but it's really not. It's just that > > > NH does not always indicate a transport. > > > > I have in mind to replace the above sentence by the following: > > "Vendors of filtering solutions and operations personnel [responsible for implementing packet filtering rules] should be aware that the 'Next Header' field in an IPv6 header can both point to an IPv6 extension header or to an upper layer protocol header. This has to be kept in mind [or: considered] when designing the UX of filtering solutions or during the creation of [filtering] rule sets." > > > > From ypur perspective, would this provide sufficient clarification with regard to the potential problem space? This was about misconceptions among security operators, not about RFC 8200 ambiguities. I hope my suggested sentence makes this clear. > > > > > > > > > > [ section 2.3.2.4 ] > > > > > > * "Only trivial cases [...] should have RA-guard..." > > > > > > Only? This doesn't strike me as being obviously the best recommendation. > > > Definitely in trivial cases it should be enabled, but surely it should > > > also be enabled even in more complex cases, albeit ones where > > > knowledgeable administrators can configure things appropriately > > > (vis. the applicability statement in section 1.1)...maybe? > > > > I agree with what you're writing. Point is that other reviewers pointed out that they see cases where RA-Guard would be counterproductve. I hence suggest to replace the phrase ("Only trivial cases") by the following: > > > > "Enabling RA-Guard by default in Wi-Fi networks or enterprise campus networks should be [strongly] considered unless specific circumstances [or: use cases] such as the presence of Homenet devices emitting router advertisements preclude this." > > > > Would that make sense, from your point of view? > > > > We will also address the majority of your COMMENTs in the next revision. Thank you again for providing those, and the above (very valid) points. > > > > Enno > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > > [ general ] > > > > > > * There are many uses of ellipses ("...") that probably could be > > > tightened up (usually just removed might work). > > > > > > [ section 2.1.1 ] > > > > > > * I think it never hurts to repeat the message that ULA /48s from the > > > fd00::/8 space (L=1) MUST be generated with a pseudo-random algorithm, > > > per RFC 4193 sections 3.2, 3.2.1, &c. > > > > > > [ section 2.1.4 ] > > > > > > * I think the opening sentence might clarify that it's talking about > > > stable address assignment for nodes. On a one-pass reading, > > > section 2.1.3 immediately preceding this is discussing router loopback > > > addressing, so I found I had routers on the brain when I started 2.1.4. > > > > > > [ section 2.1.5 ] > > > > > > * Up to you, but 4941 has been superseded by 8981. > > > > > > [ section 2.1.6 ] > > > > > > * "(see Section 2.6.1.5)" -> I think the trailing ")" probably wants to be > > > at the end of that sentence; if not, it does not quite make grammatical > > > sense (to me). > > > > > > [ section 2.2.3 ] > > > > > > * s/ipv6/IPv6/g > > > > > > [ section 2.3.5 ] > > > > > > * As an addendum to the final paragraph, it might be noted that such > > > filtering can inhibit mDNS (whether or not that's a desirable outcome). > > > > > > [ section 2.4 ] > > > > > > * "non-legit": perhaps a bit too casual? > > > > > > [ section 2.6.1.7 ] > > > > > > * "as currently collected as in" -> "as currently collected in", I suspect > > > > > > [ section 2.6.2.1 ] > > > > > > * There are other motivations for doing forensic analysis that simply > > > investigating "malicious activity" (even if this is the most common > > > motivation). > > > > > > As a concrete proposal, perhaps: > > > > > > "At the end of the process, the interface of the host originating, > > > or the subscriber identity associated with, the activity in question > > > has been determined." > > > > > > ...or something > > > > > > [ section 2.7.2 ] > > > > > > * "legit": perhaps a bit too casual? "legitimate"? Or perhaps just > > > s/legit and//. > > > > > > [ section 2.7.2.8 ] > > > > > > * s/IPV4/IPv4/ > > > > > > * Consider port 123 NTP in your allowlist. :-) > > > > > > * "hardly never" -> "hardly ever" > > > > > > [ section 2.7.3.1 ] > > > > > > * Does this section belong in this document? It's all about IPv4, and > > > not even particular to IPv4 in the presence of IPv6 -- just IPv4 in > > > general. > > > > > > [ section 2.7.3.2 ] > > > > > > * "DNSSEC has an impact on DNS64" > > > > > > It might also be said that "DNS64 has an impact on DNSSEC", so perhaps > > > "DNSSEC and DNS64 negatively interact"? > > > > > > [ section 4.3 ] > > > > > > * "and what the respective log retention" -> > > > "and the respective log retention", I think > > > > > > > > > > > > _______________________________________________ > > > OPSEC mailing list > > > OPSEC@ietf.org > > > https://www.ietf.org/mailman/listinfo/opsec > > > > -- > > Enno Rey > > > > Cell: +49 173 6745902 > > Twitter: @Enno_Insinuator -- Enno Rey Cell: +49 173 6745902 Twitter: @Enno_Insinuator From nobody Tue Apr 13 14:00:16 2021 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECBEE3A0D05 for ; Tue, 13 Apr 2021 14:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 HSP1IsYhuxfN for ; Tue, 13 Apr 2021 14:00:10 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43E713A0CFF for ; Tue, 13 Apr 2021 14:00:10 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id l22so13580690ljc.9 for ; Tue, 13 Apr 2021 14:00:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EIGjCx4M7eDTw/OiVEu5NklDZL+uLDm9ZpHZd4KuS+g=; b=tb8MC8W8aBVU/n6SZPPutKn6VZIVSPNmhvjbGTO19lA8eo6KkAZXQfkPXChnUKoalB xCYAoFV3K3PGQmWKKYaTX6zn02frfwVgFXVF2XosuiE9jG0cIwJiEPAWuolKvSKY4z2m W3vSrJ88f+T+OChYKQrGnFRxVdBtTzYBhLDExyiP7CWh67fOOwq9W+zmfPouP1BCJMHv xwCvZsR0ztox6aZWyOxHKDSEyIVD7VHYjqEaU4yi3rV0nfZSDQmYzZUeibfF9L90cs0A mPqTS41wB8ScIRocRrjIXzkd9VDHwu4hNWhozyLm5CCqveosNY5Ruu5YLuzrny07Nsjp 2/gw== 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=EIGjCx4M7eDTw/OiVEu5NklDZL+uLDm9ZpHZd4KuS+g=; b=qBvDkozmxSdMjih2lp1k9S80PRTSRDvezimxVMxeblSX2lKbIOpWCcb2LXoqPRrE04 S5Xv34IcEmTYMJHda9jyO3zWFIIFDMkLG48qKZWvCzjknz8XNkrnMfSvjcbY9ME9kqK8 QEjeaGN+MsI9wmKvPXXuw5vWs6732V1JRdFL4Y/dkNU5C66HZnZyhz3S3JCgb4OLVxKm bhhWL7UvVTXanhe2k1jBT6h68KLdiOz57+ITL3avT77IgumXdOYF1j0KIVQFJneyQwFQ cOBunkWpi0B7Ks5qvFm/O8i4Hvb6n3rFcz3gfVPwX5fezC4676rIIxlwKBNxalgzkPT4 vklg== X-Gm-Message-State: AOAM533EgmvHL8X2wHIXgStX0vn2W96In6VTJazxXJ6ysmxOrytE1RNX 9ZGuxN2XMLwDUNbBtldtCLdNXL54qSF/T8MvHnYQgA== X-Google-Smtp-Source: ABdhPJwn4h+MIHf9Qv97s8zKZOe5KW/GxPBxapKVrc/klozA8ZCb/vdzGmxJr+m+I/VDpE1ktMTzo0HWVzJs+N8N17A= X-Received: by 2002:a2e:b80d:: with SMTP id u13mr7927979ljo.316.1618347607245; Tue, 13 Apr 2021 14:00:07 -0700 (PDT) MIME-Version: 1.0 References: <161778675730.8077.2835666586607648895@ietfa.amsl.com> <20210410184555.GE91991@ernw.de> In-Reply-To: <20210410184555.GE91991@ernw.de> From: Warren Kumari Date: Tue, 13 Apr 2021 16:59:31 -0400 Message-ID: To: Enno Rey Cc: Tim Chown , ops-dir , last-call@ietf.org, opsec wg mailing list , draft-ietf-opsec-v6.all@ietf.org Content-Type: multipart/alternative; boundary="00000000000040dc1605bfe0ea65" Archived-At: Subject: Re: [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-25 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2021 21:00:16 -0000 --00000000000040dc1605bfe0ea65 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just a quick note to say thanks to Tim for the excellent and detailed review, and to the authors for addressing it... I took a quick skim through the diffs, and it was a little tricky for me to tel which all of the comments had been addressed -- authors, if you get a chance, could you reply noting which comments were folded into -26? W On Sat, Apr 10, 2021 at 2:46 PM Enno Rey wrote: > Hi Tim, > > thanks so much for another detailed look at the draft. > Your feeling that it has been in the making for a while is correct (tell > me about it ;-), still we think that the operational security guidance fo= r > IPv6 hasn't change much over time, and it might even be more needed than > ever (given current momentum of IPv6 uptake). > I went through your below points, and for many of them I've performed > according clarifications/enhancements of the draft. A new version has the= n > been uploaded. > > Wish you a great weekend > > Enno > > > > > On Wed, Apr 07, 2021 at 02:12:37AM -0700, Tim Chown via Datatracker wrote= : > > Reviewer: Tim Chown > > Review result: Has Issues > > > > Hi, > > > > I have reviewed this document (draft-ietf-opsec-v6-25) as part of the > > Operational directorate's ongoing effort to review all IETF documents > being > > processed by the IESG.?? These comments were written with the intent of > > improving the operational aspects of the IETF drafts. Comments that are > 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 an= y > other > > last call comments. > > > > This draft analyses operational security issues related to the > deployment of > > IPv6, and describes appropriate mechanisms and practices to mitigate > potential > > threats. > > > > I had previously reviewed the draft as an OPS-DIR Early Review in July > 2018, > > and again since then, so am familiar with the document and its history. > > > > General comments: > > > > The document has evolved over time with many topics added, and has an > > inevitable ???Frankenstein??? feel to it. The document would be much > better for a > > rewrite, but that would be significant work, and would delay publicatio= n > > further. The material in the document is good, and the advice is > valuable, so > > the focus should be on publishing it sooner rather than later, and thus > the > > issues with structure are probably best overlooked. > > > > An example of the historical evolution of the document are the instance= s > where > > the same topic os covered multiple times. This would ideally be avoide= d. > > > > The section most in need of attention is 2.1, where many aspects of > addressing > > are weaved together: allocations, assignments, assignment to hosts, ULA= s, > > stable and temporary addresses, etc. This might be better presented as= a > > section listing addressing related security issues, such as privacy for > users, > > first hop security, network manageability, implications of > multi-addressed > > hosts, address accountability (which isn???t mentioned here?), avoiding > > renumbering (if that is security?), etc. > > > > There are also some sections which summarise recommendations, or > reinforce > > them, and others that do not. For a document of over 50 pages, which i= s > quite > > a long read, it would be desirable to have a summary of the key > > recommendations, either at the end of each 2nd level topic, or as a > standalone > > section at the end of the document where the key points of each 2nd > level topic > > are summarised. > > > > Is it worth citing examples of security toolkits readers can explore, > like the > > THC kit, SI6 Networks, etc, maybe Scapy? > > > > Specific comments: > > > > p.3 > > I don???t understand why NPTv6 is mentioned here, this early. Just say > that some > > security issues have IPv4 equivalents, like ND attacks and ARP attacks, > and > > some do not, like IPv6 EHs or hop by hop DoS. The NAT discussion > should be in > > a standalone section, and be neutral there. > > > > p.4 > > Why mention the specific example of multi-homed networks? What do you > mean by > > the exception? Is it that multi-homing is out of scope, and so are > unmanaged > > networks? > > > > p.4 > > Again, NPTv6 is mentioned. This section is titled ???addressing > architecture??? > > but this bit of text is about reasons for going PA, PI, or becoming an > LIR, > > which is not architecture. > > > > p.4 > > In the 7934 para, RFC8981 should be mentioned as it???s a significant > reason of > > devices having more addresses. > > > > p.5 > > ULAs are also useful where the prefix changes, for stable internal > addressing > > as the global prefix changes? Typically in residential networks. > > > > p.5 > > Section 2.1.4 is really about choices in address assignment within a > network. > > > > p.6 > > Some of these paras should be in a section about IPv6 network > reconnaissance, > > how to best mitigate against scanning, and how to inventory your own > network > > elements. > > > > p.6 > > All mentions of 4941 should be replaced with 8981. > > > > p.7 > > Can use 7721 and 8981 together. > > > > p.7 > > Why are DHCP and DNS limped together? The DNS is only about DNSSEC, so > call it > > that? > > > > p.7 > > ???Even if the use of DHCP??? - this reads badly. Rather 8504 talks > about this in > > 6.5, where RFC7844 is mentioned for example. This should be in a user > privacy > > section (if this document had one). Section 8.4 is also useful advice. > > > > p.8 > > The first para is very muddled. > > > > p.8 > > In 2.1.7 this can also be useful for ACL controls, if one admin / contr= ol > > system sits in a prefix of its own. > > > > p.10 > > This is really about handling of fragmented packets (the topic) not the > > fragment header itself Also this is covered in 2.3.2.1 as well. > > > > p.10 > > In 2.2, the intro can say these issues have parallels in IPv4. > > > > p.11 > > First line, say the attack can typically happen from a large address > scan if > > permitted into the network? > > > > p.11 > > Bullet 1 - that contradicts the comments on predictable addressing. > > Bullet 2 - how? Some clues here would be useful. > > > > p.12 > > ???Current??? - really? All current implementations? Delete > ???current??? or replace > > with ???naive??? maybe. > > > > p.12 > > ???Communicate directly??? - at L2? If so, why? > > > > p.12 > > An example of a recommendations section here, where other sections with > advice > > are not titled as such. See the General comment on this. > > > > p.13 > > ???Trivial??? cases - aren???t these common ones, like edge switches in > an enterprise? > > > > p.13 > > Why ???hostile???? Delete? > > > > p.14 > > In 2.3.5 last para, what about mDNS, Bonjour? Though the DNS SD work > is now > > on unicast discovery. > > > > p.21 > > Maybe add here 802.1x as an example of the value of RADIUS logs, and ad= d > in > > here as bullets info harvested from switches and (say) router NDP syslo= g > > (though that???s I suppose the 4th bullet). These are mentioned in > 2.6.1.7 but > > should be split out at the same level as the other topics here. > > > > p.28 > > The text is 2.6.2.2 repeats earlier text. > > Similarly text in 2.6.2.3 is repeated form before. > > > > p.29 > > In 2.6.2.4 presumably also a rapid growth in ND cache size is an > indicator. > > > > p.29 > > In 2.7 point to RFC 4942 > > > > p.30 > > Should RFC 6092 be mentioned here? > > And that the best defence against IPv6 attacks n ???IPv4 only??? > networks is to > > deploy and manage IPv6? > > > > p.31 > > First bullet on this page - but isn???t this the same as if the traffic > is not > > tunnelled? Why does tunnelling add the requirement? The same applies > on the > > first para on p.32 > > > > p.31 > > Maybe say here the mitigations can also break tunnel brokers (might be > desired, > > but users will notice???)???. Maybe tunnels to specific brokers can be > allowed. > > > > p.32 > > ISATAP, in 2021? Same with 6rd. General advice should be deploy > native, avoid > > tunnels. > > > > p.33 > > Same for 6to4. > > > > p.34 > > Teredo though, is that still included in Windows and XBoX, as a MS thin= g? > > > > p.36 > > Maybe cite Geoff Huston???s blog on this - it???s very good. Maybe > there???s a more > > recent update though - > > https://blog.apnic.net/2016/06/09/lets-talk-ipv6-dns64-dnssec/. Host > CLAT is > > applicable here? (Hence a site should support the 64PREF RA option? > RFC8781 > > > > p.38 > > In 2.8, to be fair IPv4 is also hardened a lot of late due to the > prevalence of > > use of devices in WiFi hotspots etc. > > > > p.37 > > Also RFC6092 on section 3.1? > > > > p.38 > > ???Where RFC1918 address are often used??? - add ???often???, the text > implies all > > enterprises use v4 NAT. > > > > p.41 > > Only 2 normative references? > > > > Nits: > > > > p.1 > > ???The Internet??? - you probably mean ???an ISP network??? > > ???Describes the security??? - delete ???the??? > > > > p.4 > > ???Which are the switch??? delete ???which are??? > > > > p.8 > > Varying -> various > > > > p.10 > > ipv6 -> IPv6 > > > > p.18 > > Router processor - add r to ???route??? > > > > ??? > > Tim > > > > > > _______________________________________________ > > OPSEC mailing list > > OPSEC@ietf.org > > https://www.ietf.org/mailman/listinfo/opsec > > -- > Enno Rey > > Cell: +49 173 6745902 > Twitter: @Enno_Insinuator > --=20 The computing scientist=E2=80=99s main challenge is not to get confused by = the complexities of his own making. -- E. W. Dijkstra --00000000000040dc1605bfe0ea65 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just a quick note to say thanks=C2=A0to Tim for the excellent a= nd detailed review, and to the authors=C2=A0for addressing it...

=
I too= k a quick skim through the diffs, and it was a little tricky for me to tel = which all of the comments had been addressed -- authors, if you get a chanc= e, could you reply noting which comments were folded into -26?
W

On Sa= t, Apr 10, 2021 at 2:46 PM Enno Rey <ere= y@ernw.de> wrote:
Hi Tim,

thanks so much for another detailed look at the draft.
Your feeling that it has been in the making for a while is correct (tell me= about it ;-), still we think that the operational security guidance for IP= v6 hasn't change much over time, and it might even be more needed than = ever (given current momentum of IPv6 uptake).
I went through your below points, and for many of them I've performed a= ccording clarifications/enhancements of the draft. A new version has then b= een uploaded.

Wish you a great weekend

Enno




On Wed, Apr 07, 2021 at 02:12:37AM -0700, Tim Chown via Datatracker wrote:<= br> > Reviewer: Tim Chown
> Review result: Has Issues
>
> Hi,
>
> I have reviewed this document (draft-ietf-opsec-v6-25) as part of the<= br> > Operational directorate's ongoing effort to review all IETF docume= nts being
> processed by the IESG.?? These comments were written with the intent o= f
> improving the operational aspects of the IETF drafts. Comments that ar= e not
> addressed in last call may be included in AD reviews during the IESG r= eview.??
> Document editors and WG chairs should treat these comments just like a= ny other
> last call comments.
>
> This draft analyses operational security issues related to the deploym= ent of
> IPv6, and describes appropriate mechanisms and practices to mitigate p= otential
> threats.
>
> I had previously reviewed the draft as an OPS-DIR Early Review in July= 2018,
> and again since then, so am familiar with the document and its history= .
>
> General comments:
>
> The document has evolved over time with many topics added, and has an<= br> > inevitable ???Frankenstein??? feel to it.=C2=A0 The document would be = much better for a
> rewrite, but that would be significant work, and would delay publicati= on
> further.=C2=A0 The material in the document is good, and the advice is= valuable, so
> the focus should be on publishing it sooner rather than later, and thu= s the
> issues with structure are probably best overlooked.
>
> An example of the historical evolution of the document are the instanc= es where
> the same topic os covered multiple times.=C2=A0 This would ideally be = avoided.
>
> The section most in need of attention is 2.1, where many aspects of ad= dressing
> are weaved together: allocations, assignments, assignment to hosts, UL= As,
> stable and temporary addresses, etc.=C2=A0 This might be better presen= ted as a
> section listing addressing related security issues, such as privacy fo= r users,
> first hop security, network manageability, implications of multi-addre= ssed
> hosts, address accountability (which isn???t mentioned here?), avoidin= g
> renumbering (if that is security?), etc.
>
> There are also some sections which summarise recommendations, or reinf= orce
> them, and others that do not.=C2=A0 For a document of over 50 pages, w= hich is quite
> a long read, it would be desirable to have a summary of the key
> recommendations, either at the end of each 2nd level topic, or as a st= andalone
> section at the end of the document where the key points of each 2nd le= vel topic
> are summarised.
>
> Is it worth citing examples of security toolkits readers can explore, = like the
> THC kit, SI6 Networks, etc, maybe Scapy?
>
> Specific comments:
>
> p.3
> I don???t understand why NPTv6 is mentioned here, this early.=C2=A0 Ju= st say that some
> security issues have IPv4 equivalents, like ND attacks and ARP attacks= , and
> some do not, like IPv6 EHs or hop by hop DoS.=C2=A0 =C2=A0The NAT disc= ussion should be in
> a standalone section, and be neutral there.
>
> p.4
> Why mention the specific example of multi-homed networks?=C2=A0 =C2=A0= What do you mean by
> the exception?=C2=A0 Is it that multi-homing is out of scope, and so a= re unmanaged
> networks?
>
> p.4
> Again, NPTv6 is mentioned.=C2=A0 This section is titled ???addressing = architecture???
> but this bit of text is about reasons for going PA, PI, or becoming an= LIR,
> which is not architecture.
>
> p.4
> In the 7934 para, RFC8981 should be mentioned as it???s a significant = reason of
> devices having more addresses.
>
> p.5
> ULAs are also useful where the prefix changes, for stable internal add= ressing
> as the global prefix changes?=C2=A0 Typically in residential networks.=
>
> p.5
> Section 2.1.4 is really about choices in address assignment within a n= etwork.
>
> p.6
> Some of these paras should be in a section about IPv6 network reconnai= ssance,
> how to best mitigate against scanning, and how to inventory your own n= etwork
> elements.
>
> p.6
> All mentions of 4941 should be replaced with 8981.
>
> p.7
> Can use 7721 and 8981 together.
>
> p.7
> Why are DHCP and DNS limped together?=C2=A0 The DNS is only about DNSS= EC, so call it
> that?
>
> p.7
> ???Even if the use of DHCP??? - this reads badly.=C2=A0 Rather 8504 ta= lks about this in
> 6.5, where RFC7844 is mentioned for example.=C2=A0 This should be in a= user privacy
> section (if this document had one).=C2=A0 Section 8.4 is also useful a= dvice.
>
> p.8
> The first para is very muddled.
>
> p.8
> In 2.1.7 this can also be useful for ACL controls, if one admin / cont= rol
> system sits in a prefix of its own.
>
> p.10
> This is really about handling of fragmented packets (the topic) not th= e
> fragment header itself Also this is covered in 2.3.2.1 as well.
>
> p.10
> In 2.2, the intro can say these issues have parallels in IPv4.
>
> p.11
> First line, say the attack can typically happen from a large address s= can if
> permitted into the network?
>
> p.11
> Bullet 1 - that contradicts the comments on predictable addressing. > Bullet 2 - how?=C2=A0 Some clues here would be useful.
>
> p.12
> ???Current??? - really? All current implementations?=C2=A0 Delete ???c= urrent??? or replace
> with ???naive??? maybe.
>
> p.12
> ???Communicate directly??? - at L2?=C2=A0 If so, why?
>
> p.12
> An example of a recommendations section here, where other sections wit= h advice
> are not titled as such. See the General comment on this.
>
> p.13
> ???Trivial??? cases - aren???t these common ones, like edge switches i= n an enterprise?
>
> p.13
> Why ???hostile????=C2=A0 Delete?
>
> p.14
> In 2.3.5 last para, what about mDNS, Bonjour?=C2=A0 =C2=A0Though the D= NS SD work is now
> on unicast discovery.
>
> p.21
> Maybe add here 802.1x as an example of the value of RADIUS logs, and a= dd in
> here as bullets info harvested from switches and (say) router NDP sysl= og
> (though that???s I suppose the 4th bullet).=C2=A0 These are mentioned = in 2.6.1.7 but
> should be split out at the same level as the other topics here.
>
> p.28
> The text is 2.6.2.2 repeats earlier text.
> Similarly text in 2.6.2.3 is repeated form before.
>
> p.29
> In 2.6.2.4 presumably also a rapid growth in ND cache size is an indic= ator.
>
> p.29
> In 2.7 point to RFC 4942
>
> p.30
> Should RFC 6092 be mentioned here?
> And that the best defence against IPv6 attacks n ???IPv4 only??? netwo= rks is to
> deploy and manage IPv6?
>
> p.31
> First bullet on this page - but isn???t this the same as if the traffi= c is not
> tunnelled?=C2=A0 Why does tunnelling add the requirement?=C2=A0 The sa= me applies on the
> first para on p.32
>
> p.31
> Maybe say here the mitigations can also break tunnel brokers (might be= desired,
> but users will notice???)???. Maybe tunnels to specific brokers can be= allowed.
>
> p.32
> ISATAP, in 2021?=C2=A0 Same with 6rd.=C2=A0 General advice should be d= eploy native, avoid
> tunnels.
>
> p.33
> Same for 6to4.
>
> p.34
> Teredo though, is that still included in Windows and XBoX, as a MS thi= ng?
>
> p.36
> Maybe cite Geoff Huston???s blog on this - it???s very good.=C2=A0 May= be there???s a more
> recent update though -
> https://blog.apnic.net/2016/06/09= /lets-talk-ipv6-dns64-dnssec/. Host CLAT is
> applicable here?=C2=A0 (Hence a site should support the 64PREF RA opti= on?=C2=A0 RFC8781
>
> p.38
> In 2.8, to be fair IPv4 is also hardened a lot of late due to the prev= alence of
> use of devices in WiFi hotspots etc.
>
> p.37
> Also RFC6092 on section 3.1?
>
> p.38
> ???Where RFC1918 address are often used??? - add ???often???, the text= implies all
> enterprises use v4 NAT.
>
> p.41
> Only 2 normative references?
>
> Nits:
>
> p.1
> ???The Internet??? - you probably mean ???an ISP network???
> ???Describes the security??? - delete ???the???
>
> p.4
> ???Which are the switch??? delete ???which are???
>
> p.8
> Varying -> various
>
> p.10
> ipv6 -> IPv6
>
> p.18
> Router processor - add r to ???route???
>
> ???
> Tim
>
>
> _______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org=
> https://www.ietf.org/mailman/listinfo/opsec

--
Enno Rey

Cell: +49 173 6745902
Twitter: @Enno_Insinuator


--
The computing scientist=E2=80= =99s main challenge is not to get confused by the
complexities of his ow= n making.
=C2=A0 -- E. W. Dijkstra
--00000000000040dc1605bfe0ea65-- From nobody Wed Apr 14 21:20:12 2021 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC9443A0C87; Wed, 14 Apr 2021 21:20:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Erik Kline via Datatracker To: "The IESG" Cc: draft-ietf-opsec-v6@ietf.org, opsec-chairs@ietf.org, opsec@ietf.org, Gyan Mishra , hayabusagsm@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Erik Kline Message-ID: <161846040774.16412.16638219042072866947@ietfa.amsl.com> Date: Wed, 14 Apr 2021 21:20:07 -0700 Archived-At: Subject: [OPSEC] Erik Kline's No Objection on draft-ietf-opsec-v6-26: (with COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2021 04:20:08 -0000 Erik Kline has entered the following ballot position for draft-ietf-opsec-v6-26: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think there are still a few nits here and there ("non-legit"?), but I know they'll get cleaned up. Thanks! From nobody Mon Apr 19 08:27:48 2021 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B389E3A35C3; Mon, 19 Apr 2021 08:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 xuMISLpyFwzl; Mon, 19 Apr 2021 08:27:37 -0700 (PDT) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BA5E3A35A5; Mon, 19 Apr 2021 08:27:36 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id g17so40530512edm.6; Mon, 19 Apr 2021 08:27:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=4gT2mcbluOjPZLZCGim3pz5yX+6WaQ1PfGI0rITXHEE=; b=J1uDibrG5vIz9bYXgn2hdAMTIC+w4sr3lTcMBzlx7BRZhwsSlKmx4XjzVdDA0c42ve jmG8v2iXos4foMC2bJIlVtFmXCnYfYnFk0E2m06jCpZD5f9ztHAfCiXAERSShz3nUtXF OER9YzboURVv5S4oRur/fhbYVXhQV2wqHJjJrhgRzmulIf8/TJZ2zN4GHeAXYrVagIzZ 1QMNBj0iIXslJ7Bw/igTegYyTiSJYjnn82hAXXN18k1gOii9nmHx1tInpFAHygoEu8qE t/VVHVVQUxO/ZfgOEsMyX1luoKsSBHTssNBez/1WHB+tLilMHbQ93w2TBH/L8NwG2Rjb 5EPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=4gT2mcbluOjPZLZCGim3pz5yX+6WaQ1PfGI0rITXHEE=; b=A15cSmDdmmY2hDMmUX1Aj+yWPGyWjD9oApvsO+Ad6pIaDI8L8ab56vZxOikYzrV3QV z18jEa+Iigf+8jsL/tkXDgAAEoVI8LguRaxfzcimN3UD6uVuFmpwUYY/pdkcgHPJ+6mo VDsUmAE6LYaCo5+yrwSQFaA/PuACLcDesPHRGiWPmCfMuPx9sq2tnKnmuxXavtJN8NTM sloHVREeXzsA2KMyaatdfNT5aawTHWbF5AXTdF8QMWF2W1rIPw6Vmxz9w4FhOD7mB8SV CbreowsCPgCFavcq4BTG+GjXBEu9OnYnOjxWy294nr20u6iEYa262m2K3W6rnnR1y2hn gQsg== X-Gm-Message-State: AOAM531zE1Rymby9bH06rGW87Ktp8Mv8x7EXrLf4K/5rYLyXw/8DEzt2 UuDah3sXKG36WN7YP6JwAaAEG/nMkLCKarR82WI= X-Google-Smtp-Source: ABdhPJzXmte7tmiFf+OFfOt4Z1q0ozUXMGTxP15+bGPNjV/EfRZHWia2wiqbrF0hBIe/CTlx0+P5RWaoo2Bd2ia2SvI= X-Received: by 2002:a05:6402:274d:: with SMTP id z13mr26786778edd.344.1618846053393; Mon, 19 Apr 2021 08:27:33 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 19 Apr 2021 08:27:32 -0700 From: Alvaro Retana In-Reply-To: <20210410183626.GC91991@ernw.de> References: <161765687327.663.16409961435864058863@ietfa.amsl.com> <20210410183626.GC91991@ernw.de> MIME-Version: 1.0 Date: Mon, 19 Apr 2021 08:27:32 -0700 Message-ID: To: Enno Rey Cc: opsec@ietf.org, Gyan Mishra , draft-ietf-opsec-v6@ietf.org, The IESG , opsec-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000f569e305c054f714" Archived-At: Subject: Re: [OPSEC] Alvaro Retana's No Objection on draft-ietf-opsec-v6-25: (with COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2021 15:27:46 -0000 --000000000000f569e305c054f714 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Enno: Hi! I looked at -26. I still find the applicability statement confusing, the the reasons I described in 1.a/1.b (below). There is a contradiction about whether the document applies to residential users (as mentioned in =C2=A71.1 and =C2=A7= 5) or not (as mentioned in the Abstract). Also, why does the "applicability statement especially applies to Section 2.3 and Section 2.5.4=E2=80=9D *onl= y*? This is obviously a non-blocking comment, but I believe it is important since the applicability statement may influence who reads and follows the recommendations. Thanks! Alvaro. On April 10, 2021 at 2:36:26 PM, Enno Rey (erey@ernw.de) wrote: Hi Alvaro, thanks for the detailed evaluation and for the valuable feedback. I went thru your COMMENTS and performed some related adaptions of the draft. A new version has been uploaded. thank you again & have a great weekend Enno On Mon, Apr 05, 2021 at 02:07:53PM -0700, Alvaro Retana via Datatracker wrote: > Alvaro Retana has entered the following ballot position for > draft-ietf-opsec-v6-25: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > (1) The applicability statement in ??1.1 is confusing to me. > > a. The Abstract says that "this document are not applicable to residential > user cases", but that seems not to be true because this section says that the > contents do apply to "some knowledgeable-home-user-managed residential > network[s]", and ??5 is specific to residential users. > > b. "This applicability statement especially applies to Section 2.3 and Section > 2.5.4." Those two sections represent a small part of the document; what about > the rest? It makes sense to me for the applicability statement to cover most > of the document. > > c. "For example, an exception to the generic recommendations of this document > is when a residential or enterprise network is multi-homed." I'm not sure if > this sentence is an example of the previous one (above) or if "for example" is > out of place. > > (2) ??5 mentions "early 2020" -- I assume that the statement is still true now. > > (3) It caught my attention that there's only one Normative Reference (besides > rfc8200, of course). Why? What is special about the IPFIX registry? > > It seems that an argument could be made to the fact that to secure OSPFv3, for > example, an understanding of the protocol is necessary. This argument could be > extended to other protocols or mechanisms, including IPv6-specific technology: > ND, the addressing architecture, etc. Consider the classification of the > references in light of [1]. > > [1] > https://www.ietf.org/about/groups/iesg/statements/normative-informative-ref= erences/ > > > --=20 Enno Rey Cell: +49 173 6745902 Twitter: @Enno_Insinuator --000000000000f569e305c054f714 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Enno= :

=
Hi!

I looked at -26. =C2=A0

= I still find the applicability statement confusing, the the reasons I descr= ibed in 1.a/1.b (below).=C2=A0 There is a contradiction about whether the d= ocument applies to residential users (as mentioned in =C2=A71.1 and =C2=A75= ) or not (as mentioned in the Abstract).=C2=A0 Also, why does the "applicability statement especially applies to Section 2.3 and Section 2= .5.4=E2=80=9D *only*?

This is obviously a non-blocking comment, but I believe it = is important since the applicability statement may influence who reads and = follows the recommendations.

Thanks!

Alvaro.

On April 10,= 2021 at 2:36:26 PM, Enno Rey (erey@ernw.de= ) wrote:

Hi Alvaro,

thanks for the detailed evaluation and for the valuable feedback.

I went thru your COMMENTS and performed some related adaptions of the d= raft. A new version has been uploaded.

thank you again & have a great weekend

Enno




On Mon, Apr 05, 2021 at 02:07:53PM -0700, Alvaro Retana via Datatracker= wrote:
> Alvaro Retana has entered the following ballot position for
> draft-ietf-opsec-v6-25: No Objection
> =20
> When responding, please keep the subject line intact and reply to = all
> email addresses included in the To and CC lines. (Feel free to cut= this
> introductory paragraph, however.)
> =20
> =20
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml
> for more information about IESG DISCUSS and COMMENT positions.
> =20
> =20
> The document, along with other ballot positions, can be found here= :
> = https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/
> =20
> =20
> =20
> ------------------------------------------------------------------= ----
> COMMENT:
> ------------------------------------------------------------------= ----
> =20
> =20
> (1) The applicability statement in ??1.1 is confusing to me.
> =20
> a. The Abstract says that "this document are not applicable = to residential
> user cases", but that seems not to be true because this secti= on says that the
> contents do apply to "some knowledgeable-home-user-managed re= sidential
> network[s]", and ??5 is specific to residential users.
> =20
> b. "This applicability statement especially applies to Sectio= n 2.3 and Section
> 2.5.4." Those two sections represent a small part of the doc= ument; what about
> the rest? It makes sense to me for the applicability statement t= o cover most
> of the document.
> =20
> c. "For example, an exception to the generic recommendations = of this document
> is when a residential or enterprise network is multi-homed." = I'm not sure if
> this sentence is an example of the previous one (above) or if &quo= t;for example" is
> out of place.
> =20
> (2) ??5 mentions "early 2020" -- I assume that the state= ment is still true now.
> =20
> (3) It caught my attention that there's only one Normative Ref= erence (besides
> rfc8200, of course). Why? What is special about the IPFIX regist= ry?
> =20
> It seems that an argument could be made to the fact that to secure= OSPFv3, for
> example, an understanding of the protocol is necessary. This argu= ment could be
> extended to other protocols or mechanisms, including IPv6-specific= technology:
> ND, the addressing architecture, etc. Consider the classification= of the
> references in light of [1].
> =20
> [1]
> https://www.ietf.org/about/groups/iesg/statem= ents/normative-informative-references/
> =20
> =20
> =20

-- =20
Enno Rey

Cell: +49 173 6745902
Twitter: @Enno_Insinuator
<= /body> --000000000000f569e305c054f714-- From nobody Mon Apr 19 16:40:48 2021 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E790C3A4978; Mon, 19 Apr 2021 16:40:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-opsec-v6@ietf.org, opsec-chairs@ietf.org, opsec@ietf.org, Gyan Mishra , hayabusagsm@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <161887564392.1499.4789299861346688678@ietfa.amsl.com> Date: Mon, 19 Apr 2021 16:40:43 -0700 Archived-At: Subject: [OPSEC] Benjamin Kaduk's No Objection on draft-ietf-opsec-v6-26: (with COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2021 23:40:44 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-opsec-v6-26: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- While the guidance of the need to be prepared to postprocess logs to normalize the string representation of IPv6 addresses (if necessary) is good, I am not sure that the specific perl code provided in Section 2.6.1.1 is useful to include. In addition to my specific comments in the section-by-section comments, it is in a sense a very blunt instrument that assumes whitespace-separated records and blindly tries to treat every word as an IPv6 address with no regard for the message/record format. This can easily induce collateral damage, and it seems that in most cases it will be possible to use a much more targeted normalization procedure that takes into account knowledge of the message structure. So my recommendation would be to just remove the specific example perl script. Section 2.1.1 Unique Local Addresses (ULAs) [RFC4193] are intended for scenarios where interfaces are not globally reachable, despite being routed within a domain. They formally have global scope, but [RFC4193] specifies that they must be filtered at domain boundaries. [...] I'm not seeing something quite so strong in RFC 4193. It has a note that "[i]f BGP is being used at the site border with an ISP, the default BDP configuration must filter out [...]", but that is only a default, and the guidance about non-BGP mechanisms is not even this strong. Section 2.1.2 Is there a reference for "the ping-pong attack" (where the use of the definite article implies there is a specific well-known attack)? Section 2.1.4 Stable addresses also allow easy enforcement of a security policy at the perimeter based on IPv6 addresses. [RFC8520] is a mechanism where the perimeter defense can retrieve security policy template based on the type of internal device. IIUC when using MUD there is a need to have a mapping from IP address to type of device (or MUD file), which doesn't seem to be mentioned by the text here. Section 2.1.7 Please call out the privacy considerations (already discussed in RFC 8273) of using a /64 per host. Section 2.2.3 If those requirements are not met, stateless filtering could be bypassed by a hostile party. [RFC6980] applies a stricter rule to Neighbor Discovery Protocol (NDP) by enforcing the drop of fragmented NDP packets. [...] As is clarified later in Section 2.3.2.1, fragmented Certification Path Advertisement messages are not required to be dropped. In my opinion we should provide a consistent treatment of the topic across all locations we mention it. Section 2.2.4 The IPsec [RFC4301] [RFC4301] extension headers (AH [RFC4302] and ESP [RFC4303]) are required if IPsec is to be utilized for network level security. But IPsec is no longer required for normal IPv6 nodes: in I think at this point AH is in practice deprecated, because ESP with NULL cipher can perform the same role. Also, is there any further commentary about IPsec in general that is appropriate for this document? Section 2.3.2.3 Isolating hosts for the NDP traffic can be done by using a /64 per host, refer to Section 2.1.7, as NDP is only relevant within a /64 on-link prefix; 3GPP Section 2.3.4 uses a similar mechanism. I recall some previous discussion about whether the prefix/IID boundary must fall at exactly 64 bits, but I trust the authors to have a better handle on this topic than I do. Section 2.6 Please note that there are privacy issues or regulations related to how these logs are collected, stored, and safely discarded. Also to how they are *used*, e.g., the "correlation" behavior listed below. Section 2.6.1.1 my (@words, $word, $binary_address) ; @words is unused. $binary_address = inet_pton AF_INET6, $word ; if ($binary_address) { print inet_ntop AF_INET6, $binary_address ; I'd strongly recommend using parentheses for at least the function calls inet_pton and inet_ntop. I also get warnings trying to run this code: Subroutine main::pack_sockaddr_in6 redefined at /usr/share/perl/5.26/Exporter.pm line 66. at ... line 5. Subroutine main::unpack_sockaddr_in6 redefined at /usr/share/perl/5.26/Exporter.pm line 66. at ... line 5. Subroutine main::sockaddr_in6 redefined at /usr/share/perl/5.26/Exporter.pm line 66. Section 2.6.1.4 This is an important source of information because it is trivial (on a switch not using the SAVI [RFC7039] algorithm) to defeat the mapping between data-link layer address and IPv6 address. Let us rephrase the previous statement: having access to the current and past content of the neighbor cache has a paramount value for the forensic and audit trail. And if it's interesting to the operator it's interesting to other parties as well; in certain threat models this information could itself be a target. Section 2.7.2 o reflection attack: another specific use case of tunnel injection where the attacker injects packets with an IPv4 destination address not matching the IPv6 address causing the first tunnel endpoint to re-encapsulate the packet to the destination... Hence, the final IPv4 destination will not see the original IPv4 address but only the IPv4 address of the relay router. Is it possible at least sometimes to configure the tunnel endpoints to drop traffic rather than "hairpin" it back out? To mitigate the bypassing of security policies, it is recommended to block all default configuration tunnels by denying IPv4 packets matching: [...] This is not something I'd expect in a general-purpose recommendation, so I wonder if a reminder (and backreference) of the Applicability Statement in Section 1.1 would help. o UDP protocol 3544: this will block the default encapsulation of Teredo (Section 2.7.2.8) tunnels. (really a nit, but up here since it's important) s/protocol/port/. Section 2.7.2.2 Special care must be taken to avoid a looping attack by implementing the measures of [RFC6324] and [RFC6964]. I see a section 3.6 in RFC 6964 entitled "Loop Avoidance"; are we intending to refer to just that guidance or the entire document? (I could easily imagine that there are other parts of the document that have relevance for this topic, but did not read closely enough to attempt to make my own determination of that.) Section 2.7.2.3 While 6rd tunnels share the same encapsulation as 6to4 tunnels (Section 2.7.2.7), they are designed to be used within a single SP domain, in other words, they are deployed in a more constrained environment than 6to4 tunnels and have few security issues other than lack of confidentiality. [...] My current guess is that the "more constrained environment" is intended to refer to a restricted or restricted-access environment that is assumed to not have any potential for (e.g.) traffic injection. But if lack of confidentiality remains an issue, it seems that the risk of an attacker or compromised device on the path is considered in scope, so I'm not sure how injection and the other attacks would be impossible in that case. I think we need some more clarity on what this sentence is intended to say. Section 2.7.2.4 Organizations using MPLS in their core can also use 6PE [RFC4798] and 6VPE [RFC4659] to enable IPv6 access over MPLS. As 6PE and 6VPE are really similar to BGP/MPLS IP VPNs described in [RFC4364], the security properties of these networks are also similar to those described in [RFC4381]. They rely on: (RFC 4381 is, of course, an ISE doc, so we are in some sense endorsing its content by referencing it in this way.) LDPv6 itself does not induce new risks, see also [RFC7552]. Should we say which security considerations continue to apply (i.e., the LDPv4 ones)? Section 2.7.2.8 Internet. While host policies can be deployed to block Teredo in an IPv4-only network in order to avoid this firewall bypass, it would be enough to block all UDP outbound traffic at the IPv4 firewall if deemed possible (of course, at least port 53 should be left open for DNS traffic, port 123 for NTP, port 443 for QUIC, port 500 for IKE, port 3478 for STUN, i.e., filter judiciously). I find it hard to accept as useful a recommendation to "block all UDP outbound traffic if deemeed possible" followed by a necessarily incomplete list of exceptions. Perhaps it is enough to note that when outbound UDP is blocked, outbound Teredo is likewise blocked, and keep the list of common UDP services. Section 2.7.3.2 The Security Consideration sections of [RFC6146] and [RFC6147] list the comprehensive issues. A specific issue with the use of NAT64 is that it will interfere with most IPsec deployments unless UDP encapsulation is used. DNSSEC and DNS64 negatively interact, see section 3.1 of [RFC7050]. My reading of Section 3.1 of RFC 7050 is more about using DNSSEC to secure the discovery of Pref64::/n than about the negative interactions between DNSSEC and DNS64. The latter seems to be covered in the (already referenced) security considerations section of RFC 6147, though. I might say something stronger than just "negatively interact", too. Section 2.8 o Use cryptographically protected protocols for device management if possible (SCP, SNMPv3, SSH, TLS, etc.) Since these are already only guidelines, I would strike "if possible". Section 3.1 In light of RFC 2804, I wonder whether more of a disclaimer is appropriate when referencing RFC 3924 and otherwise discussing lawful intercept. o Filter specific extension headers by accepting only the required ones (permit list approach) such as ESP, AH (not forgetting the required transport layers: ICMP, TCP, UDP, ...), where possible at the edge and possibly inside the perimeter; see also [I-D.ietf-opsec-ipv6-eh-filtering] [This seems to be another place where general-purpose and managed-network-specific advice diverge, and reiteration of the applicability statement might be in order.] o Implement appropriate rate-limiters and control-plane policers Is there a reference to give guidance on what is "appropriate"? NITS Section 1 This document complements [RFC4942] by listing all security issues I'm always a little wary of "all" or "comprehensive" when covering security issues; it's hard to be sure that we really have captured everything. Section 2.1 A common question is whether companies should use Provider Independent (PI) vs. Provider Allocated (PA) space [RFC7381], but The terminology used in 7381 seems to be about requesting address space from a LIR/RIR/NIR vs using "Provider-Aggregated" address space, so just searching for the terms listed here doesn't find much useful discussion. Perhaps linking to specifically Section 2.6 thereof would help. Section 2.1.4 While in some environments obfuscating addresses could be considered an added benefit, it does not preclude enforcement of perimeter rules and that stable addresses follow some logical allocation scheme for ease of operation (as simplicity always helps security). This sentence might be a bit long for a paragraph. I'd suggest breaking after "enforcement of perimeter rules" and continuing with "It also does not preclude stable addresses from following [...]" (assuming I'm even parsing the current version correctly). Section 2.1.5 Historically, stateless address autoconfiguration (SLAAC) makes up the globally unique IPv6 address based on an automatically generated Is "makes up" accurate for something that was only historically the recommended practice but no longer is? Disabling SLAAC and privacy extension addresses can be done for most operating systems by sending RA messages with a hint to get addresses via DHCPv6 by setting the M-bit but also disabling SLAAC by resetting all A-bits in all prefix information options. [...] I think s/but/and/? However, in scenarios where anonymity is a strong desire (protecting user privacy is more important than user attribution), privacy extension addresses should be used. When [RFC8064] is available, the RFC 8064 is a "recommendation" (and seems to defer to RFC 7217 for the actual computation), so maybe we are concerned about the "mechanisms recommended by RFC 8064" being available? Section 2.2.1 A firewall or edge device should be used to enforce the recommended order and the maximum occurrences of extension headers. If it's only a recommended order, why do we want to strictly enforce it? ;) Section 2.3.1 o Using a /127 on point-to-point link per [RFC6164]. either "a point-to-point link" or "links" o Using link-local addresses only on links where there are only routers, see [RFC7404] Is the first "only" correct? Section 2.3.2.3 A more drastic technique to prevent all NDP attacks is based on isolation of all hosts with specific configurations. Hosts (i.e., all nodes that are not routers) are unable to send data-link layer I suggest starting the second sentence with something like "When this technique is used" or "In such a scenario", since (AFAICT) the statement is not true in the general case. Section 2.3.2.4 hosts. This recommendation also applies when DHCPv6 is used as RA messages are used to discover the default router(s) and for on-link comma after "is used". in Section 2.2.3. The generated log should also be analyzed to identify and act on violations. Network operators should be aware What generated log? This document does not have a prior mention of logging. Enabling RA-Guard by default in Wi-Fi networks or enterprise campus networks should be strongly considered unless specific use cases such as the presence of devices Homenet devices emitting router advertisements preclude this. spurious (first?) "devices". Section 2.3.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as described in [RFC8415], enables DHCP servers to pass configuration parameters such as IPv6 network addresses and other configuration information to IPv6 nodes such as a recursive DNS server. DHCP plays an important "such as a recursive DNS server" should come before "to IPv6 nodes". The two most common threats to DHCP clients come from malicious (a.k.a., rogue) or unintentionally misconfigured DHCP servers. A malicious DHCP server is established with the intent of providing I'd suggest a transition phrase, such as "in these scenarios", as the current phrasing could be misread as an authoritative statement of the only reason why one might maliciously set up a DHCP server. incorrect configuration information to the clients to cause a denial- of-service attack or to mount on path attack. While unintentional, a "an on-path attack". Section 2.3.5 [RFC7772], [RFC6775] (for specific wireless networks) discuss methods to rate-limit RAs and other ND messages on wireless networks in order to address this issue. s/,/and/? Section 2.4 [RFC6192] defines the router control plane and provides detailed guidance to secure it for IPv4 and IPv6 networks. This definition is repeated here for the reader's convenience. Please note that the There is some churn in the diff, added commas and a few removed words. If possible, it might be worth using some formatting to indicate that only the one paragraph is quoted. its input queue with more packets than it can process. The control plane processor is then unable to process valid control packets and the router can lose OSPF or BGP adjacencies which can cause a severe network disruption. Why do we privilege OSPF as the only IGP mentioned? (Also later on.) Section 2.4.2 o Drop packets destined to the routers except those belonging to protocols which are used (for example, permit TCP 22 and drop all others when only SSH is used); (Isn't NETCONF on port 22 as well, given its use of ssh as substrate?) Section 2.4.3 o processing of the hop-by-hop options header, new implementations follow section 4.3 of [RFC8200] where this processing is optional; comma splice. On some routers, not everything can be done by the specialized data plane hardware which requires some packets to be 'punted' to the It's nice that we pseudo-define "punted" but we've used the term earlier already. packet exceptions. The only protection for the RP is to rate-limit those packet exceptions that are forwarded to the RP, this means that some data plane packets will be dropped without an ICMP message sent to the source which may delay Path MTU discovery and cause drops. comma splice Section 2.5.2 [RFC7166] changes OSPFv3 reliance on IPsec by appending an authentication trailer to the end of the OSPFv3 packets; it does not I suggest "adds an authentication mechanism for OSPFv3 other than IPsec"; the phrasing about "reliance" is a bit surprising since (I assume) many sites run without any cryptographic protection at all. specifically authenticate the specific originator of an OSPFv3 Maybe the specifically/specific are redundant and one could be dropped? With all authentication mechanisms, operators should confirm that implementations can support re-keying mechanisms that do not cause outages. There have been instances where any re-keying causes BCP 107 might be a good reference here for re-keying concepts. outages and therefore, the tradeoff between utilizing this functionality needs to be weighed against the protection it provides. This phrasing seems to imply that even now there is a tradeoff to weigh between using cryptographic protection and risk of outage. I'd suggest rewording to use the past tense and qualify that it is only the scenarios where re-keying requires outage that has such a pronounced tradeoff. (To be clear, there is still a tradeoff for using any cryptographic protection, but that is more along the lines of "fail-safe vs fail-open".) Section 2.5.3 Many routing protocols support the use of cryptography to protect the routing updates, the use of this protection is recommended; [RFC8177] is a YANG data model key chains including the renewal. "YANG data model for key chains that includes re-keying functionality". Section 2.5.4 o Configure ingress route filters that validate route origin, prefix ownership, etc. through the use of various routing databases, e.g., [RADB]. There is additional work being done in this area to formally validate the origin ASs of BGP announcements in [RFC8210]. To what extent is this still "work being done" vs a realized result, protocol-wise? Section 2.6.1.3 o interfaces-state/interface/statistics from ietf- interfaces@2018-02-20.yang [RFC8343] which contains counters for interface . I can't tell if this sentence ended prematurely or not. Section 2.6.1.4 The neighbor cache of routers contains all mappings between IPv6 addresses and data-link layer addresses. There are multiple ways to I think we've also used the terms "physical layer", "link-layer address", and "MAC address" already as well. o using streaming telemetry or NETCONF [RFC6241] and [RFC8040] to collect the operational state of the neighbor cache; Since RFC 8040 is RESTCONF this line doesn't scan very well. Section 2.6.1.5 address, some being data-link layer address prepended with time information, or even an opaque number which is useless for operational security. Moreover, when the DUID is based on the data- I suggest "that requires correlation with another data source to be usable for operational security". Section 2.6.1.6 used by the user. This technique can be used notably for Wi-Fi networks with Wi-Fi Protected Address (WPA) or any other IEEE 802.1X [IEEE-802.1X] wired interface on an Ethernet switch. Wi-Fi networks are not 802.1X wired interfaces (last I checked), so s/other//. Section 2.6.2.1 a subscriber via the RADIUS log. Alternatively, the Forwarding Information Base of the CMTS or BNG indicates the CPE of the Please expand CMTS and BNG. Section 2.6.2.3 In order to do correlation in IPv6-related logs, it is advised to have all logs in a format with only canonical IPv6 addresses [RFC5952]. Then, the neighbor cache current (or historical) data set (We made this recommendation already earlier.) Section 2.7.2 There are many tunnels used for specific use cases. Except when protected by IPsec [RFC4301], all those tunnels have a couple of security issues as described in RFC 6169 [RFC6169]; s/couple/number/ o bypassing security policy: if a firewall or an IPS is on the path Expand IPS. Section 2.7.2.1 tunnel injection are still possible. Therefore, the use of IPsec [RFC4301] in transport mode and protecting the encapsulated IPv4 packets is recommended for those tunnels. Alternatively, IPsec in s/and protecting/to protect/ Section 2.7.2.4 o Hiding the IPv4 core, hence removing all attacks against P-routers; This is the only place we use the term "P-router", so we might just expand out the definition to avoid the jargon. Section 2.7.2.6 As MAP has a predictable IPv4 address and port mapping, the audit logs are easier to manage. Easier to manage than what? Section 2.7.2.8 Teredo is now hardly never used and no longer enabled by default in s/hardly never/hardly ever/ most environments, so, it is less of a threat, however, special consideration must be taken in case of devices with older or non- s/case of/cases when/ Section 3.1 o Filter internal-use IPv6 addresses at the perimeter this will also mitigate the vulnerabilities listed in [RFC7359] Some kind of punctuation (sentence break; semicolon) after "perimeter". o Implement ingress and egress anti-spoofing in the forwarding and control planes, see [RFC2827] and [RFC3704] Using a BCP 84 reference would also pick up the updates in RFC 8704. It is recommended to filter at Internet connection(s) packets having a source or destination address belonging to the site internal prefix(es); this should be done for ingress and egress traffic. Do we want to say "respectively" here? (Filtering any traffic with source or destination belonging to internal prefixes would seem to result in the site being an island, disconnected from the internet...) Section 5 Some residential users have less experience and knowledge about security or networking. [...] Less than who/what? From nobody Tue Apr 20 01:10:46 2021 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 103313A16D1; Tue, 20 Apr 2021 01:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.918 X-Spam-Level: X-Spam-Status: No, score=-11.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=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=GA+o7pRX; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=0h518i/l Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQcrf5eAfvva; Tue, 20 Apr 2021 01:10:36 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8CD13A16CD; Tue, 20 Apr 2021 01:10:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36518; q=dns/txt; s=iport; t=1618906235; x=1620115835; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yUzNQZC8f3WjdFBy99yacChGdQXGt8uXOqTF4X5SB4U=; b=GA+o7pRXUOPtTtlfAey/jr8HgxBJK4SyLscFBLmrRe/O3pyGEZNrDmNm DWN2Uy18Yj+zA1khF/4YOdOutKnADyjLfDPT4BBjuBwD7qG4DWhj3Y0qd PuNvIL50Ds5Ip+GUePfxm/sCT78ScCyLantZ/KEQ2hyecysWRm7iTx+Ag M=; X-IPAS-Result: =?us-ascii?q?A0DvAQBei35gmIMNJK1QCg4OAQEBAQEBBwEBEgEBBAQBA?= =?us-ascii?q?UCBUoFTIy5+WhIkMYRDg0gDhTmIcAOBCYkmhHmKFYFCgREDVAsBAQENAQEoC?= =?us-ascii?q?gIEAQGEUAIXgV4CJTgTAgMBAQEDAgMBAQEBAQUBAQECAQYEFAEBAQEBAQEBa?= =?us-ascii?q?IUjByYNhkQBAQEEGgkRDAEBNwELBAIBCBEDAQIDAhEVAgICHxEUAQgIAgQBD?= =?us-ascii?q?QWCcQGCVQMvAQ6dLwKKH3mBMoEBggQBAQaBR0GDKw0LghMJgRAqgniEC4JdC?= =?us-ascii?q?IFDezV6JxyBSUKBEyccgik2PoIeQgIBAoEWEgEHBQYBBwIYP4JYNoIrgVgBB?= =?us-ascii?q?QQxBBQZNBAgBgQYCgUICQMICAYCFAwCDSEGChsEBgwHAgUBIggCBwEBAQMED?= =?us-ascii?q?AEBAQwEAQQCAQgCBAMJCAUGAQQPAgQpkDYBGgcEB4JrQ5RvkE45WwqDDIloh?= =?us-ascii?q?k1VhkcEhTgEH4NPgT6JQYYWkB6UKXWBKIpIgxmPIQIEJgMBGoRHAgICAgQFA?= =?us-ascii?q?g4BAQaBayFrWBEHcBU7KgGCPglHFwIOiA6GEQwNCYNOhRQ0hFBFcwI2AgYBC?= =?us-ascii?q?QEBAwl8iU0BAQUhB4E6XQEB?= IronPort-PHdr: A9a23:LqcCNh3d2Qj4IKsssmDPR1BlVkAck7zpIg4Y7IYmgLtSc6Oluo7vJ 1Hb+e4FpFrIQcPW5+8Xw+bVsqW1X2sG7N7BtX0Za5VDWlcDjtlehA0vBsOJSCiZZP7nZiA3B oJOAVli+XzoNElJXsvyeg6arni79zVHHBL5OEJ8Lfj0HYiHicOx2qiy9pTfbh8OiiC6ZOZ5L Q69qkPascxF6bY= IronPort-HdrOrdr: A9a23:kefliK3Ug29mPMdoBz9jhgqjBaN2eYIsi2QD101hICF9Wvez0+ izgfUW0gL1gj4NWHcm3euNIrWEXGm0z/9IyKErF/OHUBP9sGWlaLtj44zr3iH6F0TFmNJ1/Z xLN5JzANiYNzdHpO7x6gWgDpIEyN6I7KiniY7lvghQZCtBApsQiDtRIACdD0FwWU1nKPMCZd qhz+BAoCetfmlSS8y9CGUMUeSrnay0qLvNZxkaCxk7rDSUhTSz57LgVzSe1BESUzRAqI1Ssl TtuQr/+6mlrrWH2gbRvlWjrqh+tfnA7p94BMKKgtUIMTmEsGaVTaloRrHqhkFPnMiB81Av+e O8xisIH8M20H/Je3HwnB2F4Xid7B8Ly1vPjWCVmmHip8uRfkN5N+NkiZhCehXUr2oM1esMqp 5j5G6Su5pJAR6opk2UjLKkO2AI5yiJiEEvnuIJg3tUXZF2Us4tkaUk4EhXHJ0cdRiKjrwPLe h0AMnQoNZQfF+KBkqpxlVH/d22Unw/WiqBW0gJ0/blqgR+oXYR9Tp9+OUv2lM7sL4tQZhN4O rJdo5ykqtVc8MQZaVhQM8cXMqeEAX2MFfxGVPXBW6iOLAMOnrLpZKyyq4y/vuWdJsBy4Z3sI jdUWlfqXU5dyvVeImz9awO1iqIbHS2XDzrxM0bzYN+oKfASL3iNjDGb1wyjc26obE6DtfAU/ i+fLJaasWTalfGKMJs5UnTSpNSIX4RXIk+odAgQW+DpcrNN8nkrerefPHPJKf8EDotV2/la0 FzBQTbFYFl1ASGS3X4iB/eVzfGYUrk5699F6Dc4qwSxeE2R9VxmzlQrW78ytCAKDVEvKBzVl B5OqnbnqSyonTz+W7J6m5uKwdMF0o92sS6b1p64Ssxd2/ke7cKvNuSPUpI2mGcGxN5R8TKVA hFp1p2/qqzJ4eKxT8rDs+mNm7ytQpUmFu6C7Mn3oGT78bsfZ01Srw8XrZqKAnNHxtp3RpxpH xbcw8CTE/HHjbogaGo5aZkXt33Rp1ZukOGMMRUoXXQuQGgvskpXGIcRCPre9WQmxwSSz1dgU BR/6cTjKGboyumLXIyjY0DQQBxQVXSJIgDLQyeIK1Ih7jgeWhLPBa3rA3fryt2R03H2AE5gH f7ISidZPfRa2Atykxw4+LN61N7dmKUYkRqTGt12LcNSVjuizJUzfKBYLa13i+3bFYPq9ttbg 3tUH81Ph5kwcyx2VquvAu6UV8ixpkoI4XmfeseWrnOx3KgL5CJn6kaH/lSuI1oLszqr/Vja5 PsRyaINj/iT+sm1wuJz0xVSxVcuT0ql+jl1wbi63X91HkjAeDKKFAjXL0DJcqAhlKUC8qgwd F8jdgvu/G3PXi0YtmaybvPZzorEGKYnUemC+Upo4tTp6Q8qf96GITaSyLB0DVC0A8lJMn50E MYT6IT2sGNBqZ/O8gTcTle5FwniZCGK1YqqBX/BqsmZk425kWrdu+h8v7Ns/4iE0eBrAz/NR 2W9DBc5e7MW2+G2aQBA6w9LGxKYCEHmTtf1fLHc5eVBBShdulF8lb/KHO7fbNHQKWOGLkbrH 9Bkpq1tv7SczC91BHbvDN9LK4L7n2uRtmqBhmQXeFP6N63ND238+WXyd/2iC2yTzS1a04V39 IYMUMRa9lOkTkkgsk81DOoRqn+v0IilB9f7Fhc5ynQ85nj5H2eG0dMdRDdiNFRWzJYN3CTl8 TL8eSCzh3GkXB48IiGEF0VZ81EHtgbU5P+IChvI9UBpbLAxdtavg1TJBM1S3MmgD/z3+l6za 601fXbVerlE2rpMzs6iEh4L58xmDcqp2FGe9W/6pz4Yhx/LJ98P8cC X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,236,1613433600"; d="scan'208";a="700827993" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Apr 2021 08:10:34 +0000 Received: from mail.cisco.com (xbe-aln-003.cisco.com [173.36.7.18]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 13K8AYL4002143 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 20 Apr 2021 08:10:34 GMT Received: from xfe-rcd-004.cisco.com (173.37.227.252) by xbe-aln-003.cisco.com (173.36.7.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Tue, 20 Apr 2021 03:10:33 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xfe-rcd-004.cisco.com (173.37.227.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Tue, 20 Apr 2021 03:10:33 -0500 Received: from NAM11-BN8-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.1497.2 via Frontend Transport; Tue, 20 Apr 2021 04:10:33 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bstNYY9x82W7QZh41z2Z+XFraukBhqlyrvdQTp/m3ePwcaCsN/XjjwcCwMVHQLlp5yC4h8NKqC/VYlcRmhJ32xy7tvEUWZukRDa41ytB9BY37+nUEke+h9iqDWV5/AerLgu1qXBnZ1x75ssl5s14M7Zh4rsxIITaFZPw0RQ8m2Tma9fxrauPLjbI4dakMFefcGlxqELp1NQkGXSeTILAnUFN3WUDPhhiAaDFzX/i6CDxeF+2lqaFh+7th8Vd3EICeaZMnfbe7tMSBDi5nRhCeGhzqXXr2uHUME6HLNBy2qMuFrM+ahiVtcZsXvAvvbCPdqhmVHV9Uj6FRkhWo7ICvA== 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=yUzNQZC8f3WjdFBy99yacChGdQXGt8uXOqTF4X5SB4U=; b=VTjE481kJ5XCJEhmcUlMLgeCDFE5QKm20BdcVFqxTXNbCAK6XtJfA4OCD73dYddL0+GHsFvF6IugPkM0SLjr6ioDq+lEX+6+Bzys/3MSKbXgKf3xLLmurLb3CyHkshA+s2m9nDDjm/WcBZ+iDbBocupHrtaQwofjLa/fcvCYC5Itn4KI/noUw3zSDNjc4smCt36iVijQUj/hgkzz9I+hRq1Q0nFMM9rC8i0JCoHKzwhg0CU4fRtkPMNghzFp/meIm77GiL7JruTXbbKiVWh6LuKQjFzymGBfTLI1UyY5TLKzzR1PPjWP/7JIMRagRh7yuUbkhr8zK30eTv/PlSxmkg== 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=yUzNQZC8f3WjdFBy99yacChGdQXGt8uXOqTF4X5SB4U=; b=0h518i/lwVpDrzDv+d7ko2xc5LDjLaENoQ47BcLjcUdU3On1TzZ58NpFl0hVy3mz3J1SyHCaNdwZOTldxAf8v5zEm2rIg6DA+6SWVWoDLNVG8ibOo98G99KkVw4CF6/yVKyy7bSkJAIQD1mQ0BB45EZsxGCB6Zk+5pDNIbcb+E8= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB5029.namprd11.prod.outlook.com (2603:10b6:510:30::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.20; Tue, 20 Apr 2021 08:10:32 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::dcdf:3910:b85d:6eba]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::dcdf:3910:b85d:6eba%7]) with mapi id 15.20.4042.018; Tue, 20 Apr 2021 08:10:32 +0000 From: "Eric Vyncke (evyncke)" To: Benjamin Kaduk , The IESG CC: "draft-ietf-opsec-v6@ietf.org" , "opsec-chairs@ietf.org" , "opsec@ietf.org" , "hayabusagsm@gmail.com" Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-opsec-v6-26: (with COMMENT) Thread-Index: AQHXNXVw9+Z+Kopoz0Gxz3Ej7vZkbqq9L9+A Date: Tue, 20 Apr 2021 08:10:31 +0000 Message-ID: <8203FF71-0A53-449B-84A4-6470952F0BF2@cisco.com> References: <161887564392.1499.4789299861346688678@ietfa.amsl.com> In-Reply-To: <161887564392.1499.4789299861346688678@ietfa.amsl.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.48.21041102 authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:8cab:714d:f3ee:42e0] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b839ee3e-fdea-4e07-e023-08d903d3c48f x-ms-traffictypediagnostic: PH0PR11MB5029: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: TLmOq+Uc3qQ7rZmS8j3qhwuFweq/EYR+6uKTAVhnHBbLeI0JmzB6URP48ABVc50oa3si+UaYR0fFWa+BL0VBOx41nzhPAIevxB1dzjfqqHOpk0qQ7WF9uf9ENFM9wngAVnPsEcvf5FQBjSUL04cc663TbRYqb97H8vUCvQaY4Gxm8Qfu2gI3Ln7y35MsiQgcQJsIUU7TSmjgCyq7hAlO1oCVbE8Vm4jap9LnlMIevFkpPNdXtBpBJr8InC+SCZ1V/p3oLAirb0r0yIfU7t2k2aN6UUvroWFbmLPodOpzcnu+peHlAWgxU9fz/a8gjdQ6swNcSwD9a/0vlhDE226cJAKq8drLx10wS+H0hhJr8FZZBjWoLKzCEuCUU1CEm4VduSuSBQ+nEpiQ2LV+LuIiyQxDX//mXuIGAjtqoT22L4TEHJEVHsDfUsBsWA2SNMw9pbQV9Us2NOFRwjI9MmN2Zogw9o3i2tu3EhnJovxHaKeAK6fgcOm810Qnya4V10YmeqyiS0jZnR4X2O19yulTgngbxv541fDCNHSwq8UhpMwY7qUvHW4JQ+wDXJpoCymWfRAec/tiFb8xXUkzGzoNsvyIl4fsz5Xm9P1AAjCcwxZuWE0rJ4ozqFO06p+fA1qLn/ImuvcpmbJJy23DopDiUNKRuwjfTQL9k0SegkziATQOKInUImIR0hA/yyxfZhdL8iCETJkopvYk11RIDp5+C/L5ryu/r8G7Uj03LSIgemk= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(376002)(366004)(346002)(39860400002)(396003)(2616005)(76116006)(91956017)(66476007)(8676002)(54906003)(66446008)(36756003)(64756008)(2906002)(83380400001)(6486002)(66946007)(66556008)(5660300002)(66574015)(110136005)(30864003)(86362001)(4326008)(186003)(316002)(478600001)(71200400001)(966005)(38100700002)(6506007)(6512007)(122000001)(53546011)(8936002)(33656002)(45980500001)(559001)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?Y1BBcUN3ditnVXcxOUkwTkgvOUpzVEJJUGZTcWtkK01TSVBpUUpnNDJzWkE5?= =?utf-8?B?dFQ5K1U1NC9hR3ZLU3RlNUlzQjFDdnVHWFBzTGFleEhha1Y0SVBJZjBOMHJq?= =?utf-8?B?LzdLRW9ZaDhRazBtcm9xY2hzTWtDSmZZZ1hVZlVaMytGaTdhK0dYSHNvSk52?= =?utf-8?B?TnVNM0FybU54NW9SYk9wbnNqd3R3ZWVYZ2xhSjJzOEFxazdTK3NBNUZaR2RK?= =?utf-8?B?QWRzUFhLT1AyZkJLWDdCWlp5MjNtRE82T3Y3QkxNRjdkRFZKVTdVdWRob3Zj?= =?utf-8?B?VFZBeGVVOHBsOVI4QktMZDdkdno2NVVmNEVQTHBTaXR2Y2E0TWVwcEJkc011?= =?utf-8?B?VlJORS8vbkR5VmxkeHEvTlVTNWpzVlRrR2Q2NGVZWFVWUE5LaWx6VFpaakRo?= =?utf-8?B?UFU1TWhLMlRaUUY5eFhQQ0JzVzAvRTJkdUUxalVnVnZnYUZ4ekowTTJOcDFq?= =?utf-8?B?bHRJWU04MExJQm1MZjlZWnFOYVFXVjYwdVcxNVpPUWJ2TXpsUjBHL3hFM0lT?= =?utf-8?B?SC9jeGI3RG5OczgvTzZ6bUUvNXFWY1A0Wm0ramFaNmhRZkgwM0Ryc2N3ei9W?= =?utf-8?B?bVFrdFVnaUFIbm91WmlkaDFJYkpCVWoyd3F5NWNTSGJtRk40NHB6c01XVTY0?= =?utf-8?B?cVB3RE53VGxjMHNuT2dkUW9LR2FTK3I2SDdyeUdlSjNkQzhIQlRUbWJXaExS?= =?utf-8?B?NWR5QytoazNLZ2ZIZlhzd1lFQWpKODZoRURGRzYrOG90ektZOG5PTVlDcnJz?= =?utf-8?B?SjhmT3ZQbHlKSURRWkRWR1ZlSVRXTkc0TGNrRkJnams2V3ZnSEtybUs0WmFC?= =?utf-8?B?N2V2VlpQQktsd0FUMEY2NkpzTFBaSGZtY3BINmtCYjZMT0wyd1ZOcWFOSi9k?= =?utf-8?B?NTI0OWRlYXpVZUo4dm15dTJ0cjRESnBZMDNOVlFpMzZUViszMENwb1dwMTU4?= =?utf-8?B?dWY1UmhEZkdNNE9YVS96eldRbUczMEMzZlA5ZnoxVHVpZWxzREdsQTZ6QjVo?= =?utf-8?B?cVI0R3RoU3ZjTzNad2p2RklPTGVyZjh6b1Y0NzU3V3ZlR05jTjFkcERQNUhU?= =?utf-8?B?MTNlTUVmdmdwdFdHVWg3ajhlOUg1dmZselRPTURPQUtSa1d1OU1OQ3dIbmlM?= =?utf-8?B?aFhTT2Mzcm9pZzBRTy9zRE5OV2h6aUZKME5HUlBzYThvWndESFhZVDlHQi9h?= =?utf-8?B?QXdRcUNsSzdPOWJZSmVtVDc1cVcwK2pFc0J4VlNJR0xjUGpEQ05xdHA1Snh4?= =?utf-8?B?YXFHSDNNdVQ5cmoycXZIUmVwYUs5MVpJUVhoQmZxQkFMSlhzcUI1VjVIbkk1?= =?utf-8?B?d0FlR0E3aytUSHBEckJGSTBZbVQ0MmZrakhHdTYwMjdGOGxteDh5TlMzQTZi?= =?utf-8?B?NHIweGVpck5sNzZhN2VLTnJER3dnS3Y3blhOVkFGbnk1d0tpejBhdFB2djBo?= =?utf-8?B?ZkR1dDBqYkZrNzlhbk5SOEJuSGt2aFVxRDZjN21GQ2N3ZkdnZ3ozZ29HM3BS?= =?utf-8?B?bW10YmFyY3JyckJEMURBb0graUk5bWd4WTAxUktCMmtQT2tsOXAzYTJRTFVH?= =?utf-8?B?cVdoYUZGYWxRZXRJV2NWM3lHZjRteHZ4YmlFbHFqQml0ZWxLdHE3S2xFL3hq?= =?utf-8?B?aWpHVUZPM2c2UUUwNDFUMnVYVTNTekltajBjYkRmbHlkWVZiU3U3V2t4MDJK?= =?utf-8?B?U2xyc0NieE05RG8xQklaU2dzanRaS2srOUZneHRBd1IzM1gwWGkzSDlpYUVv?= =?utf-8?B?UEl2L1dsS1ZUblQzOVNOR0NtT05VbXpvSnZNQjJlRExkMng2MGtibVJlT1ht?= =?utf-8?B?aXV2a2txZGhuWEFscHQ1Nk5LU1NSd1lqNUptRnhtbk56UXRUWk83aTVUMzJR?= =?utf-8?Q?NzKPqJ6sntT4F?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b839ee3e-fdea-4e07-e023-08d903d3c48f X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2021 08:10:31.9008 (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: HSu5iis/zcFSEOfB4mHa3f9iVBjcjjDYmkUpr8eJNdNVbr5Ctad4l6eT+mNsI/hmktMTjo9I81L5vY/z8JEoYw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5029 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.18, xbe-aln-003.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [OPSEC] Benjamin Kaduk's No Objection on draft-ietf-opsec-v6-26: (with COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2021 08:10:41 -0000 PHdlYXJpbmcganVzdCB0aGUgYXV0aG9yIGhhdD4NCg0KVGhhbmsgeW91IEJlbiBmb3IgdGhpcyBl eHRlbmRlZCByZXZpZXcuDQoNClRoZSBhdXRob3JzIHdpbGwgb2J2aW91c2x5IHJlcGx5IHRvIGFs bCB5b3VyIGNvbW1lbnQgYW5kIHVwbG9hZCBhIHJldmlzZWQgSS1EIHdpdGggc29tZSBtb2RpZmlj YXRpb25zLiBJbmRlZWQsIHNvbWUgY29tbWVudHMgb2YgeW91cnMgaGF2ZSBiZWVuIHVuZGVyIGhl YXZ5IGRpc2N1c3Npb25zIGF0IHRoZSBPUFNFQyBXRyBhbmQgdGhlIHRleHQgaXMgdGhlIFdHIHJv dWdoIGNvbnNlbnN1cyAod2Ugd2lsbCBpbmRpY2F0ZSB0aGlzIGNhc2UgaW4gb3VyIHJlcGx5KS4N Cg0KQWJvdXQgdGhlIHBlcmwgc2NyaXB0LCB3ZSB3aWxsIHNpbXBseSByZW1vdmUgaXQuIFdobyBk b2VzIHVzZSBwZXJsIG5vd2FkYXlzIGFueXdheSA/IDstKQ0KDQpSZWdhcmRzDQoNCi3DqXJpYw0K DQrvu78tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaWVzZyA8aWVzZy1ib3VuY2Vz QGlldGYub3JnPiBvbiBiZWhhbGYgb2YgQmVuamFtaW4gS2FkdWsgdmlhIERhdGF0cmFja2VyIDxu b3JlcGx5QGlldGYub3JnPg0KUmVwbHktVG86IEJlbmphbWluIEthZHVrIDxrYWR1a0BtaXQuZWR1 Pg0KRGF0ZTogVHVlc2RheSwgMjAgQXByaWwgMjAyMSBhdCAwMTo0MA0KVG86IFRoZSBJRVNHIDxp ZXNnQGlldGYub3JnPg0KQ2M6ICJkcmFmdC1pZXRmLW9wc2VjLXY2QGlldGYub3JnIiA8ZHJhZnQt aWV0Zi1vcHNlYy12NkBpZXRmLm9yZz4sICJvcHNlYy1jaGFpcnNAaWV0Zi5vcmciIDxvcHNlYy1j aGFpcnNAaWV0Zi5vcmc+LCAib3BzZWNAaWV0Zi5vcmciIDxvcHNlY0BpZXRmLm9yZz4sICJoYXlh YnVzYWdzbUBnbWFpbC5jb20iIDxoYXlhYnVzYWdzbUBnbWFpbC5jb20+DQpTdWJqZWN0OiBCZW5q YW1pbiBLYWR1aydzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLW9wc2VjLXY2LTI2OiAod2l0 aCBDT01NRU5UKQ0KDQogICAgQmVuamFtaW4gS2FkdWsgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2lu ZyBiYWxsb3QgcG9zaXRpb24gZm9yDQogICAgZHJhZnQtaWV0Zi1vcHNlYy12Ni0yNjogTm8gT2Jq ZWN0aW9uDQoNCiAgICBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxp bmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCiAgICBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQg aW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcw0KICAgIGludHJv ZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNCiAgICBQbGVhc2UgcmVmZXIgdG8gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQog ICAgZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlv bnMuDQoNCg0KICAgIFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRp b25zLCBjYW4gYmUgZm91bmQgaGVyZToNCiAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLW9wc2VjLXY2Lw0KDQoNCg0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICBD T01NRU5UOg0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICAgIFdoaWxlIHRoZSBndWlkYW5jZSBvZiB0 aGUgbmVlZCB0byBiZSBwcmVwYXJlZCB0byBwb3N0cHJvY2VzcyBsb2dzIHRvIG5vcm1hbGl6ZSB0 aGUNCiAgICBzdHJpbmcgcmVwcmVzZW50YXRpb24gb2YgSVB2NiBhZGRyZXNzZXMgKGlmIG5lY2Vz c2FyeSkgaXMgZ29vZCwgSSBhbSBub3QNCiAgICBzdXJlIHRoYXQgdGhlIHNwZWNpZmljIHBlcmwg Y29kZSBwcm92aWRlZCBpbiBTZWN0aW9uIDIuNi4xLjEgaXMgdXNlZnVsDQogICAgdG8gaW5jbHVk ZS4gIEluIGFkZGl0aW9uIHRvIG15IHNwZWNpZmljIGNvbW1lbnRzIGluIHRoZQ0KICAgIHNlY3Rp b24tYnktc2VjdGlvbiBjb21tZW50cywgaXQgaXMgaW4gYSBzZW5zZSBhIHZlcnkgYmx1bnQgaW5z dHJ1bWVudA0KICAgIHRoYXQgYXNzdW1lcyB3aGl0ZXNwYWNlLXNlcGFyYXRlZCByZWNvcmRzIGFu ZCBibGluZGx5IHRyaWVzIHRvIHRyZWF0DQogICAgZXZlcnkgd29yZCBhcyBhbiBJUHY2IGFkZHJl c3Mgd2l0aCBubyByZWdhcmQgZm9yIHRoZSBtZXNzYWdlL3JlY29yZA0KICAgIGZvcm1hdC4gIFRo aXMgY2FuIGVhc2lseSBpbmR1Y2UgY29sbGF0ZXJhbCBkYW1hZ2UsIGFuZCBpdCBzZWVtcyB0aGF0 IGluDQogICAgbW9zdCBjYXNlcyBpdCB3aWxsIGJlIHBvc3NpYmxlIHRvIHVzZSBhIG11Y2ggbW9y ZSB0YXJnZXRlZA0KICAgIG5vcm1hbGl6YXRpb24gcHJvY2VkdXJlIHRoYXQgdGFrZXMgaW50byBh Y2NvdW50IGtub3dsZWRnZSBvZiB0aGUgbWVzc2FnZQ0KICAgIHN0cnVjdHVyZS4gIFNvIG15IHJl Y29tbWVuZGF0aW9uIHdvdWxkIGJlIHRvIGp1c3QgcmVtb3ZlIHRoZSBzcGVjaWZpYw0KICAgIGV4 YW1wbGUgcGVybCBzY3JpcHQuDQoNCiAgICBTZWN0aW9uIDIuMS4xDQoNCiAgICAgICBVbmlxdWUg TG9jYWwgQWRkcmVzc2VzIChVTEFzKSBbUkZDNDE5M10gYXJlIGludGVuZGVkIGZvciBzY2VuYXJp b3MNCiAgICAgICB3aGVyZSBpbnRlcmZhY2VzIGFyZSBub3QgZ2xvYmFsbHkgcmVhY2hhYmxlLCBk ZXNwaXRlIGJlaW5nIHJvdXRlZA0KICAgICAgIHdpdGhpbiBhIGRvbWFpbi4gIFRoZXkgZm9ybWFs bHkgaGF2ZSBnbG9iYWwgc2NvcGUsIGJ1dCBbUkZDNDE5M10NCiAgICAgICBzcGVjaWZpZXMgdGhh dCB0aGV5IG11c3QgYmUgZmlsdGVyZWQgYXQgZG9tYWluIGJvdW5kYXJpZXMuICBbLi4uXQ0KDQog ICAgSSdtIG5vdCBzZWVpbmcgc29tZXRoaW5nIHF1aXRlIHNvIHN0cm9uZyBpbiBSRkMgNDE5My4g IEl0IGhhcyBhIG5vdGUNCiAgICB0aGF0ICJbaV1mIEJHUCBpcyBiZWluZyB1c2VkIGF0IHRoZSBz aXRlIGJvcmRlciB3aXRoIGFuIElTUCwgdGhlIGRlZmF1bHQNCiAgICBCRFAgY29uZmlndXJhdGlv biBtdXN0IGZpbHRlciBvdXQgWy4uLl0iLCBidXQgdGhhdCBpcyBvbmx5IGEgZGVmYXVsdCwNCiAg ICBhbmQgdGhlIGd1aWRhbmNlIGFib3V0IG5vbi1CR1AgbWVjaGFuaXNtcyBpcyBub3QgZXZlbiB0 aGlzIHN0cm9uZy4NCg0KICAgIFNlY3Rpb24gMi4xLjINCg0KICAgIElzIHRoZXJlIGEgcmVmZXJl bmNlIGZvciAidGhlIHBpbmctcG9uZyBhdHRhY2siICh3aGVyZSB0aGUgdXNlIG9mIHRoZQ0KICAg IGRlZmluaXRlIGFydGljbGUgaW1wbGllcyB0aGVyZSBpcyBhIHNwZWNpZmljIHdlbGwta25vd24g YXR0YWNrKT8NCg0KICAgIFNlY3Rpb24gMi4xLjQNCg0KICAgICAgIFN0YWJsZSBhZGRyZXNzZXMg YWxzbyBhbGxvdyBlYXN5IGVuZm9yY2VtZW50IG9mIGEgc2VjdXJpdHkgcG9saWN5IGF0DQogICAg ICAgdGhlIHBlcmltZXRlciBiYXNlZCBvbiBJUHY2IGFkZHJlc3Nlcy4gIFtSRkM4NTIwXSBpcyBh IG1lY2hhbmlzbQ0KICAgICAgIHdoZXJlIHRoZSBwZXJpbWV0ZXIgZGVmZW5zZSBjYW4gcmV0cmll dmUgc2VjdXJpdHkgcG9saWN5IHRlbXBsYXRlDQogICAgICAgYmFzZWQgb24gdGhlIHR5cGUgb2Yg aW50ZXJuYWwgZGV2aWNlLg0KDQogICAgSUlVQyB3aGVuIHVzaW5nIE1VRCB0aGVyZSBpcyBhIG5l ZWQgdG8gaGF2ZSBhIG1hcHBpbmcgZnJvbSBJUCBhZGRyZXNzIHRvDQogICAgdHlwZSBvZiBkZXZp Y2UgKG9yIE1VRCBmaWxlKSwgd2hpY2ggZG9lc24ndCBzZWVtIHRvIGJlIG1lbnRpb25lZCBieSB0 aGUNCiAgICB0ZXh0IGhlcmUuDQoNCiAgICBTZWN0aW9uIDIuMS43DQoNCiAgICBQbGVhc2UgY2Fs bCBvdXQgdGhlIHByaXZhY3kgY29uc2lkZXJhdGlvbnMgKGFscmVhZHkgZGlzY3Vzc2VkIGluIFJG Qw0KICAgIDgyNzMpIG9mIHVzaW5nIGEgLzY0IHBlciBob3N0Lg0KDQogICAgU2VjdGlvbiAyLjIu Mw0KDQogICAgICAgSWYgdGhvc2UgcmVxdWlyZW1lbnRzIGFyZSBub3QgbWV0LCBzdGF0ZWxlc3Mg ZmlsdGVyaW5nIGNvdWxkIGJlDQogICAgICAgYnlwYXNzZWQgYnkgYSBob3N0aWxlIHBhcnR5LiAg W1JGQzY5ODBdIGFwcGxpZXMgYSBzdHJpY3RlciBydWxlIHRvDQogICAgICAgTmVpZ2hib3IgRGlz Y292ZXJ5IFByb3RvY29sIChORFApIGJ5IGVuZm9yY2luZyB0aGUgZHJvcCBvZiBmcmFnbWVudGVk DQogICAgICAgTkRQIHBhY2tldHMuICBbLi4uXQ0KDQogICAgQXMgaXMgY2xhcmlmaWVkIGxhdGVy IGluIFNlY3Rpb24gMi4zLjIuMSwgZnJhZ21lbnRlZCBDZXJ0aWZpY2F0aW9uIFBhdGgNCiAgICBB ZHZlcnRpc2VtZW50IG1lc3NhZ2VzIGFyZSBub3QgcmVxdWlyZWQgdG8gYmUgZHJvcHBlZC4gIElu IG15IG9waW5pb24gd2UNCiAgICBzaG91bGQgcHJvdmlkZSBhIGNvbnNpc3RlbnQgdHJlYXRtZW50 IG9mIHRoZSB0b3BpYyBhY3Jvc3MgYWxsIGxvY2F0aW9ucw0KICAgIHdlIG1lbnRpb24gaXQuDQoN CiAgICBTZWN0aW9uIDIuMi40DQoNCiAgICAgICBUaGUgSVBzZWMgW1JGQzQzMDFdIFtSRkM0MzAx XSBleHRlbnNpb24gaGVhZGVycyAoQUggW1JGQzQzMDJdIGFuZCBFU1ANCiAgICAgICBbUkZDNDMw M10pIGFyZSByZXF1aXJlZCBpZiBJUHNlYyBpcyB0byBiZSB1dGlsaXplZCBmb3IgbmV0d29yayBs ZXZlbA0KICAgICAgIHNlY3VyaXR5LiAgQnV0IElQc2VjIGlzIG5vIGxvbmdlciByZXF1aXJlZCBm b3Igbm9ybWFsIElQdjYgbm9kZXM6IGluDQoNCiAgICBJIHRoaW5rIGF0IHRoaXMgcG9pbnQgQUgg aXMgaW4gcHJhY3RpY2UgZGVwcmVjYXRlZCwgYmVjYXVzZSBFU1Agd2l0aA0KICAgIE5VTEwgY2lw aGVyIGNhbiBwZXJmb3JtIHRoZSBzYW1lIHJvbGUuDQoNCiAgICBBbHNvLCBpcyB0aGVyZSBhbnkg ZnVydGhlciBjb21tZW50YXJ5IGFib3V0IElQc2VjIGluIGdlbmVyYWwgdGhhdCBpcw0KICAgIGFw cHJvcHJpYXRlIGZvciB0aGlzIGRvY3VtZW50Pw0KDQogICAgU2VjdGlvbiAyLjMuMi4zDQoNCiAg ICAgICBJc29sYXRpbmcgaG9zdHMgZm9yIHRoZSBORFAgdHJhZmZpYyBjYW4gYmUgZG9uZSBieSB1 c2luZyBhIC82NCBwZXINCiAgICAgICBob3N0LCByZWZlciB0byBTZWN0aW9uIDIuMS43LCBhcyBO RFAgaXMgb25seSByZWxldmFudCB3aXRoaW4gYSAvNjQNCiAgICAgICBvbi1saW5rIHByZWZpeDsg M0dQUCBTZWN0aW9uIDIuMy40IHVzZXMgYSBzaW1pbGFyIG1lY2hhbmlzbS4NCg0KICAgIEkgcmVj YWxsIHNvbWUgcHJldmlvdXMgZGlzY3Vzc2lvbiBhYm91dCB3aGV0aGVyIHRoZSBwcmVmaXgvSUlE IGJvdW5kYXJ5DQogICAgbXVzdCBmYWxsIGF0IGV4YWN0bHkgNjQgYml0cywgYnV0IEkgdHJ1c3Qg dGhlIGF1dGhvcnMgdG8gaGF2ZSBhIGJldHRlcg0KICAgIGhhbmRsZSBvbiB0aGlzIHRvcGljIHRo YW4gSSBkby4NCg0KICAgIFNlY3Rpb24gMi42DQoNCiAgICAgICBQbGVhc2Ugbm90ZSB0aGF0IHRo ZXJlIGFyZSBwcml2YWN5IGlzc3VlcyBvciByZWd1bGF0aW9ucyByZWxhdGVkIHRvDQogICAgICAg aG93IHRoZXNlIGxvZ3MgYXJlIGNvbGxlY3RlZCwgc3RvcmVkLCBhbmQgc2FmZWx5IGRpc2NhcmRl ZC4NCg0KICAgIEFsc28gdG8gaG93IHRoZXkgYXJlICp1c2VkKiwgZS5nLiwgdGhlICJjb3JyZWxh dGlvbiIgYmVoYXZpb3IgbGlzdGVkDQogICAgYmVsb3cuDQoNCiAgICBTZWN0aW9uIDIuNi4xLjEN Cg0KICAgICAgIG15IChAd29yZHMsICR3b3JkLCAkYmluYXJ5X2FkZHJlc3MpIDsNCg0KICAgIEB3 b3JkcyBpcyB1bnVzZWQuDQoNCiAgICAgICAgICAgJGJpbmFyeV9hZGRyZXNzID0gaW5ldF9wdG9u IEFGX0lORVQ2LCAkd29yZCA7DQogICAgICAgICAgIGlmICgkYmluYXJ5X2FkZHJlc3MpIHsNCiAg ICAgICAgICAgICBwcmludCBpbmV0X250b3AgQUZfSU5FVDYsICRiaW5hcnlfYWRkcmVzcyA7DQoN CiAgICBJJ2Qgc3Ryb25nbHkgcmVjb21tZW5kIHVzaW5nIHBhcmVudGhlc2VzIGZvciBhdCBsZWFz dCB0aGUgZnVuY3Rpb24gY2FsbHMNCiAgICBpbmV0X3B0b24gYW5kIGluZXRfbnRvcC4NCg0KICAg IEkgYWxzbyBnZXQgd2FybmluZ3MgdHJ5aW5nIHRvIHJ1biB0aGlzIGNvZGU6DQoNCiAgICBTdWJy b3V0aW5lIG1haW46OnBhY2tfc29ja2FkZHJfaW42IHJlZGVmaW5lZCBhdCAvdXNyL3NoYXJlL3Bl cmwvNS4yNi9FeHBvcnRlci5wbSBsaW5lIDY2Lg0KICAgICBhdCAuLi4gbGluZSA1Lg0KICAgIFN1 YnJvdXRpbmUgbWFpbjo6dW5wYWNrX3NvY2thZGRyX2luNiByZWRlZmluZWQgYXQgL3Vzci9zaGFy ZS9wZXJsLzUuMjYvRXhwb3J0ZXIucG0gbGluZSA2Ni4NCiAgICAgYXQgLi4uIGxpbmUgNS4NCiAg ICBTdWJyb3V0aW5lIG1haW46OnNvY2thZGRyX2luNiByZWRlZmluZWQgYXQgL3Vzci9zaGFyZS9w ZXJsLzUuMjYvRXhwb3J0ZXIucG0gbGluZSA2Ni4NCg0KICAgIFNlY3Rpb24gMi42LjEuNA0KDQog ICAgICAgVGhpcyBpcyBhbiBpbXBvcnRhbnQgc291cmNlIG9mIGluZm9ybWF0aW9uIGJlY2F1c2Ug aXQgaXMgdHJpdmlhbCAob24NCiAgICAgICBhIHN3aXRjaCBub3QgdXNpbmcgdGhlIFNBVkkgW1JG QzcwMzldIGFsZ29yaXRobSkgdG8gZGVmZWF0IHRoZQ0KICAgICAgIG1hcHBpbmcgYmV0d2VlbiBk YXRhLWxpbmsgbGF5ZXIgYWRkcmVzcyBhbmQgSVB2NiBhZGRyZXNzLiAgTGV0IHVzDQogICAgICAg cmVwaHJhc2UgdGhlIHByZXZpb3VzIHN0YXRlbWVudDogaGF2aW5nIGFjY2VzcyB0byB0aGUgY3Vy cmVudCBhbmQNCiAgICAgICBwYXN0IGNvbnRlbnQgb2YgdGhlIG5laWdoYm9yIGNhY2hlIGhhcyBh IHBhcmFtb3VudCB2YWx1ZSBmb3IgdGhlDQogICAgICAgZm9yZW5zaWMgYW5kIGF1ZGl0IHRyYWls Lg0KDQogICAgQW5kIGlmIGl0J3MgaW50ZXJlc3RpbmcgdG8gdGhlIG9wZXJhdG9yIGl0J3MgaW50 ZXJlc3RpbmcgdG8gb3RoZXINCiAgICBwYXJ0aWVzIGFzIHdlbGw7IGluIGNlcnRhaW4gdGhyZWF0 IG1vZGVscyB0aGlzIGluZm9ybWF0aW9uIGNvdWxkIGl0c2VsZg0KICAgIGJlIGEgdGFyZ2V0Lg0K DQogICAgU2VjdGlvbiAyLjcuMg0KDQogICAgICAgbyAgcmVmbGVjdGlvbiBhdHRhY2s6IGFub3Ro ZXIgc3BlY2lmaWMgdXNlIGNhc2Ugb2YgdHVubmVsIGluamVjdGlvbg0KICAgICAgICAgIHdoZXJl IHRoZSBhdHRhY2tlciBpbmplY3RzIHBhY2tldHMgd2l0aCBhbiBJUHY0IGRlc3RpbmF0aW9uDQog ICAgICAgICAgYWRkcmVzcyBub3QgbWF0Y2hpbmcgdGhlIElQdjYgYWRkcmVzcyBjYXVzaW5nIHRo ZSBmaXJzdCB0dW5uZWwNCiAgICAgICAgICBlbmRwb2ludCB0byByZS1lbmNhcHN1bGF0ZSB0aGUg cGFja2V0IHRvIHRoZSBkZXN0aW5hdGlvbi4uLiBIZW5jZSwNCiAgICAgICAgICB0aGUgZmluYWwg SVB2NCBkZXN0aW5hdGlvbiB3aWxsIG5vdCBzZWUgdGhlIG9yaWdpbmFsIElQdjQgYWRkcmVzcw0K ICAgICAgICAgIGJ1dCBvbmx5IHRoZSBJUHY0IGFkZHJlc3Mgb2YgdGhlIHJlbGF5IHJvdXRlci4N Cg0KICAgIElzIGl0IHBvc3NpYmxlIGF0IGxlYXN0IHNvbWV0aW1lcyB0byBjb25maWd1cmUgdGhl IHR1bm5lbCBlbmRwb2ludHMgdG8NCiAgICBkcm9wIHRyYWZmaWMgcmF0aGVyIHRoYW4gImhhaXJw aW4iIGl0IGJhY2sgb3V0Pw0KDQogICAgICAgVG8gbWl0aWdhdGUgdGhlIGJ5cGFzc2luZyBvZiBz ZWN1cml0eSBwb2xpY2llcywgaXQgaXMgcmVjb21tZW5kZWQgdG8NCiAgICAgICBibG9jayBhbGwg ZGVmYXVsdCBjb25maWd1cmF0aW9uIHR1bm5lbHMgYnkgZGVueWluZyBJUHY0IHBhY2tldHMNCiAg ICAgICBtYXRjaGluZzoNCiAgICAgICBbLi4uXQ0KDQogICAgVGhpcyBpcyBub3Qgc29tZXRoaW5n IEknZCBleHBlY3QgaW4gYSBnZW5lcmFsLXB1cnBvc2UgcmVjb21tZW5kYXRpb24sIHNvDQogICAg SSB3b25kZXIgaWYgYSByZW1pbmRlciAoYW5kIGJhY2tyZWZlcmVuY2UpIG9mIHRoZSBBcHBsaWNh YmlsaXR5DQogICAgU3RhdGVtZW50IGluIFNlY3Rpb24gMS4xIHdvdWxkIGhlbHAuDQoNCiAgICAg ICBvICBVRFAgcHJvdG9jb2wgMzU0NDogdGhpcyB3aWxsIGJsb2NrIHRoZSBkZWZhdWx0IGVuY2Fw c3VsYXRpb24gb2YNCiAgICAgICAgICBUZXJlZG8gKFNlY3Rpb24gMi43LjIuOCkgdHVubmVscy4N Cg0KICAgIChyZWFsbHkgYSBuaXQsIGJ1dCB1cCBoZXJlIHNpbmNlIGl0J3MgaW1wb3J0YW50KSBz L3Byb3RvY29sL3BvcnQvLg0KDQogICAgU2VjdGlvbiAyLjcuMi4yDQoNCiAgICAgICBTcGVjaWFs IGNhcmUgbXVzdCBiZSB0YWtlbiB0byBhdm9pZCBhIGxvb3BpbmcgYXR0YWNrIGJ5IGltcGxlbWVu dGluZw0KICAgICAgIHRoZSBtZWFzdXJlcyBvZiBbUkZDNjMyNF0gYW5kIFtSRkM2OTY0XS4NCg0K ICAgIEkgc2VlIGEgc2VjdGlvbiAzLjYgaW4gUkZDIDY5NjQgZW50aXRsZWQgIkxvb3AgQXZvaWRh bmNlIjsgYXJlIHdlDQogICAgaW50ZW5kaW5nIHRvIHJlZmVyIHRvIGp1c3QgdGhhdCBndWlkYW5j ZSBvciB0aGUgZW50aXJlIGRvY3VtZW50PyAgKEkNCiAgICBjb3VsZCBlYXNpbHkgaW1hZ2luZSB0 aGF0IHRoZXJlIGFyZSBvdGhlciBwYXJ0cyBvZiB0aGUgZG9jdW1lbnQgdGhhdA0KICAgIGhhdmUg cmVsZXZhbmNlIGZvciB0aGlzIHRvcGljLCBidXQgZGlkIG5vdCByZWFkIGNsb3NlbHkgZW5vdWdo IHRvDQogICAgYXR0ZW1wdCB0byBtYWtlIG15IG93biBkZXRlcm1pbmF0aW9uIG9mIHRoYXQuKQ0K DQogICAgU2VjdGlvbiAyLjcuMi4zDQoNCiAgICAgICBXaGlsZSA2cmQgdHVubmVscyBzaGFyZSB0 aGUgc2FtZSBlbmNhcHN1bGF0aW9uIGFzIDZ0bzQgdHVubmVscw0KICAgICAgIChTZWN0aW9uIDIu Ny4yLjcpLCB0aGV5IGFyZSBkZXNpZ25lZCB0byBiZSB1c2VkIHdpdGhpbiBhIHNpbmdsZSBTUA0K ICAgICAgIGRvbWFpbiwgaW4gb3RoZXIgd29yZHMsIHRoZXkgYXJlIGRlcGxveWVkIGluIGEgbW9y ZSBjb25zdHJhaW5lZA0KICAgICAgIGVudmlyb25tZW50IHRoYW4gNnRvNCB0dW5uZWxzIGFuZCBo YXZlIGZldyBzZWN1cml0eSBpc3N1ZXMgb3RoZXIgdGhhbg0KICAgICAgIGxhY2sgb2YgY29uZmlk ZW50aWFsaXR5LiAgWy4uLl0NCg0KICAgIE15IGN1cnJlbnQgZ3Vlc3MgaXMgdGhhdCB0aGUgIm1v cmUgY29uc3RyYWluZWQgZW52aXJvbm1lbnQiIGlzIGludGVuZGVkDQogICAgdG8gcmVmZXIgdG8g YSByZXN0cmljdGVkIG9yIHJlc3RyaWN0ZWQtYWNjZXNzIGVudmlyb25tZW50IHRoYXQgaXMNCiAg ICBhc3N1bWVkIHRvIG5vdCBoYXZlIGFueSBwb3RlbnRpYWwgZm9yIChlLmcuKSB0cmFmZmljIGlu amVjdGlvbi4gIEJ1dCBpZg0KICAgIGxhY2sgb2YgY29uZmlkZW50aWFsaXR5IHJlbWFpbnMgYW4g aXNzdWUsIGl0IHNlZW1zIHRoYXQgdGhlIHJpc2sgb2YgYW4NCiAgICBhdHRhY2tlciBvciBjb21w cm9taXNlZCBkZXZpY2Ugb24gdGhlIHBhdGggaXMgY29uc2lkZXJlZCBpbiBzY29wZSwgc28NCiAg ICBJJ20gbm90IHN1cmUgaG93IGluamVjdGlvbiBhbmQgdGhlIG90aGVyIGF0dGFja3Mgd291bGQg YmUgaW1wb3NzaWJsZSBpbg0KICAgIHRoYXQgY2FzZS4gIEkgdGhpbmsgd2UgbmVlZCBzb21lIG1v cmUgY2xhcml0eSBvbiB3aGF0IHRoaXMgc2VudGVuY2UgaXMNCiAgICBpbnRlbmRlZCB0byBzYXku DQoNCiAgICBTZWN0aW9uIDIuNy4yLjQNCg0KICAgICAgIE9yZ2FuaXphdGlvbnMgdXNpbmcgTVBM UyBpbiB0aGVpciBjb3JlIGNhbiBhbHNvIHVzZSA2UEUgW1JGQzQ3OThdIGFuZA0KICAgICAgIDZW UEUgW1JGQzQ2NTldIHRvIGVuYWJsZSBJUHY2IGFjY2VzcyBvdmVyIE1QTFMuICBBcyA2UEUgYW5k IDZWUEUgYXJlDQogICAgICAgcmVhbGx5IHNpbWlsYXIgdG8gQkdQL01QTFMgSVAgVlBOcyBkZXNj cmliZWQgaW4gW1JGQzQzNjRdLCB0aGUNCiAgICAgICBzZWN1cml0eSBwcm9wZXJ0aWVzIG9mIHRo ZXNlIG5ldHdvcmtzIGFyZSBhbHNvIHNpbWlsYXIgdG8gdGhvc2UNCiAgICAgICBkZXNjcmliZWQg aW4gW1JGQzQzODFdLiAgVGhleSByZWx5IG9uOg0KDQogICAgKFJGQyA0MzgxIGlzLCBvZiBjb3Vy c2UsIGFuIElTRSBkb2MsIHNvIHdlIGFyZSBpbiBzb21lIHNlbnNlIGVuZG9yc2luZw0KICAgIGl0 cyBjb250ZW50IGJ5IHJlZmVyZW5jaW5nIGl0IGluIHRoaXMgd2F5LikNCg0KICAgICAgIExEUHY2 IGl0c2VsZiBkb2VzIG5vdCBpbmR1Y2UgbmV3IHJpc2tzLCBzZWUgYWxzbyBbUkZDNzU1Ml0uDQoN CiAgICBTaG91bGQgd2Ugc2F5IHdoaWNoIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGNvbnRpbnVl IHRvIGFwcGx5IChpLmUuLCB0aGUNCiAgICBMRFB2NCBvbmVzKT8NCg0KICAgIFNlY3Rpb24gMi43 LjIuOA0KDQogICAgICAgSW50ZXJuZXQuICBXaGlsZSBob3N0IHBvbGljaWVzIGNhbiBiZSBkZXBs b3llZCB0byBibG9jayBUZXJlZG8gaW4gYW4NCiAgICAgICBJUHY0LW9ubHkgbmV0d29yayBpbiBv cmRlciB0byBhdm9pZCB0aGlzIGZpcmV3YWxsIGJ5cGFzcywgaXQgd291bGQgYmUNCiAgICAgICBl bm91Z2ggdG8gYmxvY2sgYWxsIFVEUCBvdXRib3VuZCB0cmFmZmljIGF0IHRoZSBJUHY0IGZpcmV3 YWxsIGlmDQogICAgICAgZGVlbWVkIHBvc3NpYmxlIChvZiBjb3Vyc2UsIGF0IGxlYXN0IHBvcnQg NTMgc2hvdWxkIGJlIGxlZnQgb3BlbiBmb3INCiAgICAgICBETlMgdHJhZmZpYywgcG9ydCAxMjMg Zm9yIE5UUCwgcG9ydCA0NDMgZm9yIFFVSUMsIHBvcnQgNTAwIGZvciBJS0UsDQogICAgICAgcG9y dCAzNDc4IGZvciBTVFVOLCBpLmUuLCBmaWx0ZXIganVkaWNpb3VzbHkpLg0KDQogICAgSSBmaW5k IGl0IGhhcmQgdG8gYWNjZXB0IGFzIHVzZWZ1bCBhIHJlY29tbWVuZGF0aW9uIHRvICJibG9jayBh bGwgVURQDQogICAgb3V0Ym91bmQgdHJhZmZpYyBpZiBkZWVtZWVkIHBvc3NpYmxlIiBmb2xsb3dl ZCBieSBhIG5lY2Vzc2FyaWx5DQogICAgaW5jb21wbGV0ZSBsaXN0IG9mIGV4Y2VwdGlvbnMuICBQ ZXJoYXBzIGl0IGlzIGVub3VnaCB0byBub3RlIHRoYXQgd2hlbg0KICAgIG91dGJvdW5kIFVEUCBp cyBibG9ja2VkLCBvdXRib3VuZCBUZXJlZG8gaXMgbGlrZXdpc2UgYmxvY2tlZCwgYW5kIGtlZXAN CiAgICB0aGUgbGlzdCBvZiBjb21tb24gVURQIHNlcnZpY2VzLg0KDQogICAgU2VjdGlvbiAyLjcu My4yDQoNCiAgICAgICBUaGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbiBzZWN0aW9ucyBvZiBbUkZD NjE0Nl0gYW5kIFtSRkM2MTQ3XSBsaXN0DQogICAgICAgdGhlIGNvbXByZWhlbnNpdmUgaXNzdWVz LiAgQSBzcGVjaWZpYyBpc3N1ZSB3aXRoIHRoZSB1c2Ugb2YgTkFUNjQgaXMNCiAgICAgICB0aGF0 IGl0IHdpbGwgaW50ZXJmZXJlIHdpdGggbW9zdCBJUHNlYyBkZXBsb3ltZW50cyB1bmxlc3MgVURQ DQogICAgICAgZW5jYXBzdWxhdGlvbiBpcyB1c2VkLiAgRE5TU0VDIGFuZCBETlM2NCBuZWdhdGl2 ZWx5IGludGVyYWN0LCBzZWUNCiAgICAgICBzZWN0aW9uIDMuMSBvZiBbUkZDNzA1MF0uDQoNCiAg ICBNeSByZWFkaW5nIG9mIFNlY3Rpb24gMy4xIG9mIFJGQyA3MDUwIGlzIG1vcmUgYWJvdXQgdXNp bmcgRE5TU0VDIHRvDQogICAgc2VjdXJlIHRoZSBkaXNjb3Zlcnkgb2YgUHJlZjY0OjovbiB0aGFu IGFib3V0IHRoZSBuZWdhdGl2ZSBpbnRlcmFjdGlvbnMNCiAgICBiZXR3ZWVuIEROU1NFQyBhbmQg RE5TNjQuICBUaGUgbGF0dGVyIHNlZW1zIHRvIGJlIGNvdmVyZWQgaW4gdGhlDQogICAgKGFscmVh ZHkgcmVmZXJlbmNlZCkgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBvZiBSRkMgNjE0 NywNCiAgICB0aG91Z2guDQoNCiAgICBJIG1pZ2h0IHNheSBzb21ldGhpbmcgc3Ryb25nZXIgdGhh biBqdXN0ICJuZWdhdGl2ZWx5IGludGVyYWN0IiwgdG9vLg0KDQogICAgU2VjdGlvbiAyLjgNCg0K ICAgICAgIG8gIFVzZSBjcnlwdG9ncmFwaGljYWxseSBwcm90ZWN0ZWQgcHJvdG9jb2xzIGZvciBk ZXZpY2UgbWFuYWdlbWVudCBpZg0KICAgICAgICAgIHBvc3NpYmxlIChTQ1AsIFNOTVB2MywgU1NI LCBUTFMsIGV0Yy4pDQoNCiAgICBTaW5jZSB0aGVzZSBhcmUgYWxyZWFkeSBvbmx5IGd1aWRlbGlu ZXMsIEkgd291bGQgc3RyaWtlICJpZiBwb3NzaWJsZSIuDQoNCiAgICBTZWN0aW9uIDMuMQ0KDQog ICAgSW4gbGlnaHQgb2YgUkZDIDI4MDQsIEkgd29uZGVyIHdoZXRoZXIgbW9yZSBvZiBhIGRpc2Ns YWltZXIgaXMNCiAgICBhcHByb3ByaWF0ZSB3aGVuIHJlZmVyZW5jaW5nIFJGQyAzOTI0IGFuZCBv dGhlcndpc2UgZGlzY3Vzc2luZyBsYXdmdWwNCiAgICBpbnRlcmNlcHQuDQoNCiAgICAgICBvICBG aWx0ZXIgc3BlY2lmaWMgZXh0ZW5zaW9uIGhlYWRlcnMgYnkgYWNjZXB0aW5nIG9ubHkgdGhlIHJl cXVpcmVkDQogICAgICAgICAgb25lcyAocGVybWl0IGxpc3QgYXBwcm9hY2gpIHN1Y2ggYXMgRVNQ LCBBSCAobm90IGZvcmdldHRpbmcgdGhlDQogICAgICAgICAgcmVxdWlyZWQgdHJhbnNwb3J0IGxh eWVyczogSUNNUCwgVENQLCBVRFAsIC4uLiksIHdoZXJlIHBvc3NpYmxlIGF0DQogICAgICAgICAg dGhlIGVkZ2UgYW5kIHBvc3NpYmx5IGluc2lkZSB0aGUgcGVyaW1ldGVyOyBzZWUgYWxzbw0KICAg ICAgICAgIFtJLUQuaWV0Zi1vcHNlYy1pcHY2LWVoLWZpbHRlcmluZ10NCg0KICAgIFtUaGlzIHNl ZW1zIHRvIGJlIGFub3RoZXIgcGxhY2Ugd2hlcmUgZ2VuZXJhbC1wdXJwb3NlIGFuZA0KICAgIG1h bmFnZWQtbmV0d29yay1zcGVjaWZpYyBhZHZpY2UgZGl2ZXJnZSwgYW5kIHJlaXRlcmF0aW9uIG9m IHRoZQ0KICAgIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IG1pZ2h0IGJlIGluIG9yZGVyLl0NCg0K ICAgICAgIG8gIEltcGxlbWVudCBhcHByb3ByaWF0ZSByYXRlLWxpbWl0ZXJzIGFuZCBjb250cm9s LXBsYW5lIHBvbGljZXJzDQoNCiAgICBJcyB0aGVyZSBhIHJlZmVyZW5jZSB0byBnaXZlIGd1aWRh bmNlIG9uIHdoYXQgaXMgImFwcHJvcHJpYXRlIj8NCg0KDQogICAgTklUUw0KDQogICAgU2VjdGlv biAxDQoNCiAgICAgICBUaGlzIGRvY3VtZW50IGNvbXBsZW1lbnRzIFtSRkM0OTQyXSBieSBsaXN0 aW5nIGFsbCBzZWN1cml0eSBpc3N1ZXMNCg0KICAgIEknbSBhbHdheXMgYSBsaXR0bGUgd2FyeSBv ZiAiYWxsIiBvciAiY29tcHJlaGVuc2l2ZSIgd2hlbiBjb3ZlcmluZw0KICAgIHNlY3VyaXR5IGlz c3VlczsgaXQncyBoYXJkIHRvIGJlIHN1cmUgdGhhdCB3ZSByZWFsbHkgaGF2ZSBjYXB0dXJlZA0K ICAgIGV2ZXJ5dGhpbmcuDQoNCiAgICBTZWN0aW9uIDIuMQ0KDQogICAgICAgQSBjb21tb24gcXVl c3Rpb24gaXMgd2hldGhlciBjb21wYW5pZXMgc2hvdWxkIHVzZSBQcm92aWRlcg0KICAgICAgIElu ZGVwZW5kZW50IChQSSkgdnMuIFByb3ZpZGVyIEFsbG9jYXRlZCAoUEEpIHNwYWNlIFtSRkM3Mzgx XSwgYnV0DQoNCiAgICBUaGUgdGVybWlub2xvZ3kgdXNlZCBpbiA3MzgxIHNlZW1zIHRvIGJlIGFi b3V0IHJlcXVlc3RpbmcgYWRkcmVzcyBzcGFjZQ0KICAgIGZyb20gYSBMSVIvUklSL05JUiB2cyB1 c2luZyAiUHJvdmlkZXItQWdncmVnYXRlZCIgYWRkcmVzcyBzcGFjZSwgc28ganVzdA0KICAgIHNl YXJjaGluZyBmb3IgdGhlIHRlcm1zIGxpc3RlZCBoZXJlIGRvZXNuJ3QgZmluZCBtdWNoIHVzZWZ1 bCBkaXNjdXNzaW9uLg0KICAgIFBlcmhhcHMgbGlua2luZyB0byBzcGVjaWZpY2FsbHkgU2VjdGlv biAyLjYgdGhlcmVvZiB3b3VsZCBoZWxwLg0KDQogICAgU2VjdGlvbiAyLjEuNA0KDQogICAgICAg V2hpbGUgaW4gc29tZSBlbnZpcm9ubWVudHMgb2JmdXNjYXRpbmcgYWRkcmVzc2VzIGNvdWxkIGJl IGNvbnNpZGVyZWQNCiAgICAgICBhbiBhZGRlZCBiZW5lZml0LCBpdCBkb2VzIG5vdCBwcmVjbHVk ZSBlbmZvcmNlbWVudCBvZiBwZXJpbWV0ZXIgcnVsZXMNCiAgICAgICBhbmQgdGhhdCBzdGFibGUg YWRkcmVzc2VzIGZvbGxvdyBzb21lIGxvZ2ljYWwgYWxsb2NhdGlvbiBzY2hlbWUgZm9yDQogICAg ICAgZWFzZSBvZiBvcGVyYXRpb24gKGFzIHNpbXBsaWNpdHkgYWx3YXlzIGhlbHBzIHNlY3VyaXR5 KS4NCg0KICAgIFRoaXMgc2VudGVuY2UgbWlnaHQgYmUgYSBiaXQgbG9uZyBmb3IgYSBwYXJhZ3Jh cGguICBJJ2Qgc3VnZ2VzdCBicmVha2luZw0KICAgIGFmdGVyICJlbmZvcmNlbWVudCBvZiBwZXJp bWV0ZXIgcnVsZXMiIGFuZCBjb250aW51aW5nIHdpdGggIkl0IGFsc28gZG9lcw0KICAgIG5vdCBw cmVjbHVkZSBzdGFibGUgYWRkcmVzc2VzIGZyb20gZm9sbG93aW5nIFsuLi5dIiAoYXNzdW1pbmcg SSdtIGV2ZW4NCiAgICBwYXJzaW5nIHRoZSBjdXJyZW50IHZlcnNpb24gY29ycmVjdGx5KS4NCg0K ICAgIFNlY3Rpb24gMi4xLjUNCg0KICAgICAgIEhpc3RvcmljYWxseSwgc3RhdGVsZXNzIGFkZHJl c3MgYXV0b2NvbmZpZ3VyYXRpb24gKFNMQUFDKSBtYWtlcyB1cA0KICAgICAgIHRoZSBnbG9iYWxs eSB1bmlxdWUgSVB2NiBhZGRyZXNzIGJhc2VkIG9uIGFuIGF1dG9tYXRpY2FsbHkgZ2VuZXJhdGVk DQoNCiAgICBJcyAibWFrZXMgdXAiIGFjY3VyYXRlIGZvciBzb21ldGhpbmcgdGhhdCB3YXMgb25s eSBoaXN0b3JpY2FsbHkgdGhlDQogICAgcmVjb21tZW5kZWQgcHJhY3RpY2UgYnV0IG5vIGxvbmdl ciBpcz8NCg0KICAgICAgIERpc2FibGluZyBTTEFBQyBhbmQgcHJpdmFjeSBleHRlbnNpb24gYWRk cmVzc2VzIGNhbiBiZSBkb25lIGZvciBtb3N0DQogICAgICAgb3BlcmF0aW5nIHN5c3RlbXMgYnkg c2VuZGluZyBSQSBtZXNzYWdlcyB3aXRoIGEgaGludCB0byBnZXQgYWRkcmVzc2VzDQogICAgICAg dmlhIERIQ1B2NiBieSBzZXR0aW5nIHRoZSBNLWJpdCBidXQgYWxzbyBkaXNhYmxpbmcgU0xBQUMg YnkgcmVzZXR0aW5nDQogICAgICAgYWxsIEEtYml0cyBpbiBhbGwgcHJlZml4IGluZm9ybWF0aW9u IG9wdGlvbnMuICBbLi4uXQ0KDQogICAgSSB0aGluayBzL2J1dC9hbmQvPw0KDQogICAgICAgSG93 ZXZlciwgaW4gc2NlbmFyaW9zIHdoZXJlIGFub255bWl0eSBpcyBhIHN0cm9uZyBkZXNpcmUgKHBy b3RlY3RpbmcNCiAgICAgICB1c2VyIHByaXZhY3kgaXMgbW9yZSBpbXBvcnRhbnQgdGhhbiB1c2Vy IGF0dHJpYnV0aW9uKSwgcHJpdmFjeQ0KICAgICAgIGV4dGVuc2lvbiBhZGRyZXNzZXMgc2hvdWxk IGJlIHVzZWQuICBXaGVuIFtSRkM4MDY0XSBpcyBhdmFpbGFibGUsIHRoZQ0KDQogICAgUkZDIDgw NjQgaXMgYSAicmVjb21tZW5kYXRpb24iIChhbmQgc2VlbXMgdG8gZGVmZXIgdG8gUkZDIDcyMTcg Zm9yIHRoZQ0KICAgIGFjdHVhbCBjb21wdXRhdGlvbiksIHNvIG1heWJlIHdlIGFyZSBjb25jZXJu ZWQgYWJvdXQgdGhlICJtZWNoYW5pc21zDQogICAgcmVjb21tZW5kZWQgYnkgUkZDIDgwNjQiIGJl aW5nIGF2YWlsYWJsZT8NCg0KICAgIFNlY3Rpb24gMi4yLjENCg0KICAgICAgIEEgZmlyZXdhbGwg b3IgZWRnZSBkZXZpY2Ugc2hvdWxkIGJlIHVzZWQgdG8gZW5mb3JjZSB0aGUgcmVjb21tZW5kZWQN CiAgICAgICBvcmRlciBhbmQgdGhlIG1heGltdW0gb2NjdXJyZW5jZXMgb2YgZXh0ZW5zaW9uIGhl YWRlcnMuDQoNCiAgICBJZiBpdCdzIG9ubHkgYSByZWNvbW1lbmRlZCBvcmRlciwgd2h5IGRvIHdl IHdhbnQgdG8gc3RyaWN0bHkgZW5mb3JjZSBpdD8NCiAgICA7KQ0KDQogICAgU2VjdGlvbiAyLjMu MQ0KDQogICAgICAgbyAgVXNpbmcgYSAvMTI3IG9uIHBvaW50LXRvLXBvaW50IGxpbmsgcGVyIFtS RkM2MTY0XS4NCg0KICAgIGVpdGhlciAiYSBwb2ludC10by1wb2ludCBsaW5rIiBvciAibGlua3Mi DQoNCiAgICAgICBvICBVc2luZyBsaW5rLWxvY2FsIGFkZHJlc3NlcyBvbmx5IG9uIGxpbmtzIHdo ZXJlIHRoZXJlIGFyZSBvbmx5DQogICAgICAgICAgcm91dGVycywgc2VlIFtSRkM3NDA0XQ0KDQog ICAgSXMgdGhlIGZpcnN0ICJvbmx5IiBjb3JyZWN0Pw0KDQogICAgU2VjdGlvbiAyLjMuMi4zDQoN CiAgICAgICBBIG1vcmUgZHJhc3RpYyB0ZWNobmlxdWUgdG8gcHJldmVudCBhbGwgTkRQIGF0dGFj a3MgaXMgYmFzZWQgb24NCiAgICAgICBpc29sYXRpb24gb2YgYWxsIGhvc3RzIHdpdGggc3BlY2lm aWMgY29uZmlndXJhdGlvbnMuICBIb3N0cyAoaS5lLiwNCiAgICAgICBhbGwgbm9kZXMgdGhhdCBh cmUgbm90IHJvdXRlcnMpIGFyZSB1bmFibGUgdG8gc2VuZCBkYXRhLWxpbmsgbGF5ZXINCg0KICAg IEkgc3VnZ2VzdCBzdGFydGluZyB0aGUgc2Vjb25kIHNlbnRlbmNlIHdpdGggc29tZXRoaW5nIGxp a2UgIldoZW4gdGhpcw0KICAgIHRlY2huaXF1ZSBpcyB1c2VkIiBvciAiSW4gc3VjaCBhIHNjZW5h cmlvIiwgc2luY2UgKEFGQUlDVCkgdGhlIHN0YXRlbWVudA0KICAgIGlzIG5vdCB0cnVlIGluIHRo ZSBnZW5lcmFsIGNhc2UuDQoNCiAgICBTZWN0aW9uIDIuMy4yLjQNCg0KICAgICAgIGhvc3RzLiAg VGhpcyByZWNvbW1lbmRhdGlvbiBhbHNvIGFwcGxpZXMgd2hlbiBESENQdjYgaXMgdXNlZCBhcyBS QQ0KICAgICAgIG1lc3NhZ2VzIGFyZSB1c2VkIHRvIGRpc2NvdmVyIHRoZSBkZWZhdWx0IHJvdXRl cihzKSBhbmQgZm9yIG9uLWxpbmsNCg0KICAgIGNvbW1hIGFmdGVyICJpcyB1c2VkIi4NCg0KICAg ICAgIGluIFNlY3Rpb24gMi4yLjMuICBUaGUgZ2VuZXJhdGVkIGxvZyBzaG91bGQgYWxzbyBiZSBh bmFseXplZCB0bw0KICAgICAgIGlkZW50aWZ5IGFuZCBhY3Qgb24gdmlvbGF0aW9ucy4gIE5ldHdv cmsgb3BlcmF0b3JzIHNob3VsZCBiZSBhd2FyZQ0KDQogICAgV2hhdCBnZW5lcmF0ZWQgbG9nPyAg VGhpcyBkb2N1bWVudCBkb2VzIG5vdCBoYXZlIGEgcHJpb3IgbWVudGlvbiBvZg0KICAgIGxvZ2dp bmcuDQoNCiAgICAgICBFbmFibGluZyBSQS1HdWFyZCBieSBkZWZhdWx0IGluIFdpLUZpIG5ldHdv cmtzIG9yIGVudGVycHJpc2UgY2FtcHVzDQogICAgICAgbmV0d29ya3Mgc2hvdWxkIGJlIHN0cm9u Z2x5IGNvbnNpZGVyZWQgdW5sZXNzIHNwZWNpZmljIHVzZSBjYXNlcyBzdWNoDQogICAgICAgYXMg dGhlIHByZXNlbmNlIG9mIGRldmljZXMgSG9tZW5ldCBkZXZpY2VzIGVtaXR0aW5nIHJvdXRlcg0K ICAgICAgIGFkdmVydGlzZW1lbnRzIHByZWNsdWRlIHRoaXMuDQoNCiAgICBzcHVyaW91cyAoZmly c3Q/KSAiZGV2aWNlcyIuDQoNCiAgICBTZWN0aW9uIDIuMy4zDQoNCiAgICAgICBEeW5hbWljIEhv c3QgQ29uZmlndXJhdGlvbiBQcm90b2NvbCBmb3IgSVB2NiAoREhDUHY2KSwgYXMgZGVzY3JpYmVk DQogICAgICAgaW4gW1JGQzg0MTVdLCBlbmFibGVzIERIQ1Agc2VydmVycyB0byBwYXNzIGNvbmZp Z3VyYXRpb24gcGFyYW1ldGVycw0KICAgICAgIHN1Y2ggYXMgSVB2NiBuZXR3b3JrIGFkZHJlc3Nl cyBhbmQgb3RoZXIgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiB0bw0KICAgICAgIElQdjYgbm9k ZXMgc3VjaCBhcyBhIHJlY3Vyc2l2ZSBETlMgc2VydmVyLiAgREhDUCBwbGF5cyBhbiBpbXBvcnRh bnQNCg0KICAgICJzdWNoIGFzIGEgcmVjdXJzaXZlIEROUyBzZXJ2ZXIiIHNob3VsZCBjb21lIGJl Zm9yZSAidG8gSVB2NiBub2RlcyIuDQoNCiAgICAgICBUaGUgdHdvIG1vc3QgY29tbW9uIHRocmVh dHMgdG8gREhDUCBjbGllbnRzIGNvbWUgZnJvbSBtYWxpY2lvdXMNCiAgICAgICAoYS5rLmEuLCBy b2d1ZSkgb3IgdW5pbnRlbnRpb25hbGx5IG1pc2NvbmZpZ3VyZWQgREhDUCBzZXJ2ZXJzLiAgQQ0K ICAgICAgIG1hbGljaW91cyBESENQIHNlcnZlciBpcyBlc3RhYmxpc2hlZCB3aXRoIHRoZSBpbnRl bnQgb2YgcHJvdmlkaW5nDQoNCiAgICBJJ2Qgc3VnZ2VzdCBhIHRyYW5zaXRpb24gcGhyYXNlLCBz dWNoIGFzICJpbiB0aGVzZSBzY2VuYXJpb3MiLCBhcyB0aGUNCiAgICBjdXJyZW50IHBocmFzaW5n IGNvdWxkIGJlIG1pc3JlYWQgYXMgYW4gYXV0aG9yaXRhdGl2ZSBzdGF0ZW1lbnQgb2YgdGhlDQog ICAgb25seSByZWFzb24gd2h5IG9uZSBtaWdodCBtYWxpY2lvdXNseSBzZXQgdXAgYSBESENQIHNl cnZlci4NCg0KICAgICAgIGluY29ycmVjdCBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIHRvIHRo ZSBjbGllbnRzIHRvIGNhdXNlIGEgZGVuaWFsLQ0KICAgICAgIG9mLXNlcnZpY2UgYXR0YWNrIG9y IHRvIG1vdW50IG9uIHBhdGggYXR0YWNrLiAgV2hpbGUgdW5pbnRlbnRpb25hbCwgYQ0KDQogICAg ImFuIG9uLXBhdGggYXR0YWNrIi4NCg0KICAgIFNlY3Rpb24gMi4zLjUNCg0KICAgICAgIFtSRkM3 NzcyXSwgW1JGQzY3NzVdIChmb3Igc3BlY2lmaWMgd2lyZWxlc3MgbmV0d29ya3MpIGRpc2N1c3Mg bWV0aG9kcw0KICAgICAgIHRvIHJhdGUtbGltaXQgUkFzIGFuZCBvdGhlciBORCBtZXNzYWdlcyBv biB3aXJlbGVzcyBuZXR3b3JrcyBpbiBvcmRlcg0KICAgICAgIHRvIGFkZHJlc3MgdGhpcyBpc3N1 ZS4NCg0KICAgIHMvLC9hbmQvPw0KDQogICAgU2VjdGlvbiAyLjQNCg0KICAgICAgIFtSRkM2MTky XSBkZWZpbmVzIHRoZSByb3V0ZXIgY29udHJvbCBwbGFuZSBhbmQgcHJvdmlkZXMgZGV0YWlsZWQN CiAgICAgICBndWlkYW5jZSB0byBzZWN1cmUgaXQgZm9yIElQdjQgYW5kIElQdjYgbmV0d29ya3Mu ICBUaGlzIGRlZmluaXRpb24gaXMNCiAgICAgICByZXBlYXRlZCBoZXJlIGZvciB0aGUgcmVhZGVy J3MgY29udmVuaWVuY2UuICBQbGVhc2Ugbm90ZSB0aGF0IHRoZQ0KDQogICAgVGhlcmUgaXMgc29t ZSBjaHVybiBpbiB0aGUgZGlmZiwgYWRkZWQgY29tbWFzIGFuZCBhIGZldyByZW1vdmVkIHdvcmRz Lg0KICAgIElmIHBvc3NpYmxlLCBpdCBtaWdodCBiZSB3b3J0aCB1c2luZyBzb21lIGZvcm1hdHRp bmcgdG8gaW5kaWNhdGUgdGhhdA0KICAgIG9ubHkgdGhlIG9uZSBwYXJhZ3JhcGggaXMgcXVvdGVk Lg0KDQogICAgICAgaXRzIGlucHV0IHF1ZXVlIHdpdGggbW9yZSBwYWNrZXRzIHRoYW4gaXQgY2Fu IHByb2Nlc3MuICBUaGUgY29udHJvbA0KICAgICAgIHBsYW5lIHByb2Nlc3NvciBpcyB0aGVuIHVu YWJsZSB0byBwcm9jZXNzIHZhbGlkIGNvbnRyb2wgcGFja2V0cyBhbmQNCiAgICAgICB0aGUgcm91 dGVyIGNhbiBsb3NlIE9TUEYgb3IgQkdQIGFkamFjZW5jaWVzIHdoaWNoIGNhbiBjYXVzZSBhIHNl dmVyZQ0KICAgICAgIG5ldHdvcmsgZGlzcnVwdGlvbi4NCg0KICAgIFdoeSBkbyB3ZSBwcml2aWxl Z2UgT1NQRiBhcyB0aGUgb25seSBJR1AgbWVudGlvbmVkPyAgKEFsc28gbGF0ZXIgb24uKQ0KDQog ICAgU2VjdGlvbiAyLjQuMg0KDQogICAgICAgbyAgRHJvcCBwYWNrZXRzIGRlc3RpbmVkIHRvIHRo ZSByb3V0ZXJzIGV4Y2VwdCB0aG9zZSBiZWxvbmdpbmcgdG8NCiAgICAgICAgICBwcm90b2NvbHMg d2hpY2ggYXJlIHVzZWQgKGZvciBleGFtcGxlLCBwZXJtaXQgVENQIDIyIGFuZCBkcm9wIGFsbA0K ICAgICAgICAgIG90aGVycyB3aGVuIG9ubHkgU1NIIGlzIHVzZWQpOw0KDQogICAgKElzbid0IE5F VENPTkYgb24gcG9ydCAyMiBhcyB3ZWxsLCBnaXZlbiBpdHMgdXNlIG9mIHNzaCBhcyBzdWJzdHJh dGU/KQ0KDQogICAgU2VjdGlvbiAyLjQuMw0KDQogICAgICAgbyAgcHJvY2Vzc2luZyBvZiB0aGUg aG9wLWJ5LWhvcCBvcHRpb25zIGhlYWRlciwgbmV3IGltcGxlbWVudGF0aW9ucw0KICAgICAgICAg IGZvbGxvdyBzZWN0aW9uIDQuMyBvZiBbUkZDODIwMF0gd2hlcmUgdGhpcyBwcm9jZXNzaW5nIGlz IG9wdGlvbmFsOw0KDQogICAgY29tbWEgc3BsaWNlLg0KDQogICAgICAgT24gc29tZSByb3V0ZXJz LCBub3QgZXZlcnl0aGluZyBjYW4gYmUgZG9uZSBieSB0aGUgc3BlY2lhbGl6ZWQgZGF0YQ0KICAg ICAgIHBsYW5lIGhhcmR3YXJlIHdoaWNoIHJlcXVpcmVzIHNvbWUgcGFja2V0cyB0byBiZSAncHVu dGVkJyB0byB0aGUNCg0KICAgIEl0J3MgbmljZSB0aGF0IHdlIHBzZXVkby1kZWZpbmUgInB1bnRl ZCIgYnV0IHdlJ3ZlIHVzZWQgdGhlIHRlcm0gZWFybGllcg0KICAgIGFscmVhZHkuDQoNCiAgICAg ICBwYWNrZXQgZXhjZXB0aW9ucy4gIFRoZSBvbmx5IHByb3RlY3Rpb24gZm9yIHRoZSBSUCBpcyB0 byByYXRlLWxpbWl0DQogICAgICAgdGhvc2UgcGFja2V0IGV4Y2VwdGlvbnMgdGhhdCBhcmUgZm9y d2FyZGVkIHRvIHRoZSBSUCwgdGhpcyBtZWFucyB0aGF0DQogICAgICAgc29tZSBkYXRhIHBsYW5l IHBhY2tldHMgd2lsbCBiZSBkcm9wcGVkIHdpdGhvdXQgYW4gSUNNUCBtZXNzYWdlIHNlbnQNCiAg ICAgICB0byB0aGUgc291cmNlIHdoaWNoIG1heSBkZWxheSBQYXRoIE1UVSBkaXNjb3ZlcnkgYW5k IGNhdXNlIGRyb3BzLg0KDQogICAgY29tbWEgc3BsaWNlDQoNCiAgICBTZWN0aW9uIDIuNS4yDQoN CiAgICAgICBbUkZDNzE2Nl0gY2hhbmdlcyBPU1BGdjMgcmVsaWFuY2Ugb24gSVBzZWMgYnkgYXBw ZW5kaW5nIGFuDQogICAgICAgYXV0aGVudGljYXRpb24gdHJhaWxlciB0byB0aGUgZW5kIG9mIHRo ZSBPU1BGdjMgcGFja2V0czsgaXQgZG9lcyBub3QNCg0KICAgIEkgc3VnZ2VzdCAiYWRkcyBhbiBh dXRoZW50aWNhdGlvbiBtZWNoYW5pc20gZm9yIE9TUEZ2MyBvdGhlciB0aGFuDQogICAgSVBzZWMi OyB0aGUgcGhyYXNpbmcgYWJvdXQgInJlbGlhbmNlIiBpcyBhIGJpdCBzdXJwcmlzaW5nIHNpbmNl IChJDQogICAgYXNzdW1lKSBtYW55IHNpdGVzIHJ1biB3aXRob3V0IGFueSBjcnlwdG9ncmFwaGlj IHByb3RlY3Rpb24gYXQgYWxsLg0KDQogICAgICAgc3BlY2lmaWNhbGx5IGF1dGhlbnRpY2F0ZSB0 aGUgc3BlY2lmaWMgb3JpZ2luYXRvciBvZiBhbiBPU1BGdjMNCg0KICAgIE1heWJlIHRoZSBzcGVj aWZpY2FsbHkvc3BlY2lmaWMgYXJlIHJlZHVuZGFudCBhbmQgb25lIGNvdWxkIGJlIGRyb3BwZWQ/ DQoNCiAgICAgICBXaXRoIGFsbCBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc21zLCBvcGVyYXRvcnMg c2hvdWxkIGNvbmZpcm0gdGhhdA0KICAgICAgIGltcGxlbWVudGF0aW9ucyBjYW4gc3VwcG9ydCBy ZS1rZXlpbmcgbWVjaGFuaXNtcyB0aGF0IGRvIG5vdCBjYXVzZQ0KICAgICAgIG91dGFnZXMuICBU aGVyZSBoYXZlIGJlZW4gaW5zdGFuY2VzIHdoZXJlIGFueSByZS1rZXlpbmcgY2F1c2VzDQoNCiAg ICBCQ1AgMTA3IG1pZ2h0IGJlIGEgZ29vZCByZWZlcmVuY2UgaGVyZSBmb3IgcmUta2V5aW5nIGNv bmNlcHRzLg0KDQogICAgICAgb3V0YWdlcyBhbmQgdGhlcmVmb3JlLCB0aGUgdHJhZGVvZmYgYmV0 d2VlbiB1dGlsaXppbmcgdGhpcw0KICAgICAgIGZ1bmN0aW9uYWxpdHkgbmVlZHMgdG8gYmUgd2Vp Z2hlZCBhZ2FpbnN0IHRoZSBwcm90ZWN0aW9uIGl0IHByb3ZpZGVzLg0KDQogICAgVGhpcyBwaHJh c2luZyBzZWVtcyB0byBpbXBseSB0aGF0IGV2ZW4gbm93IHRoZXJlIGlzIGEgdHJhZGVvZmYgdG8g d2VpZ2gNCiAgICBiZXR3ZWVuIHVzaW5nIGNyeXB0b2dyYXBoaWMgcHJvdGVjdGlvbiBhbmQgcmlz ayBvZiBvdXRhZ2UuICBJJ2Qgc3VnZ2VzdA0KICAgIHJld29yZGluZyB0byB1c2UgdGhlIHBhc3Qg dGVuc2UgYW5kIHF1YWxpZnkgdGhhdCBpdCBpcyBvbmx5IHRoZQ0KICAgIHNjZW5hcmlvcyB3aGVy ZSByZS1rZXlpbmcgcmVxdWlyZXMgb3V0YWdlIHRoYXQgaGFzIHN1Y2ggYSBwcm9ub3VuY2VkDQog ICAgdHJhZGVvZmYuICAoVG8gYmUgY2xlYXIsIHRoZXJlIGlzIHN0aWxsIGEgdHJhZGVvZmYgZm9y IHVzaW5nIGFueQ0KICAgIGNyeXB0b2dyYXBoaWMgcHJvdGVjdGlvbiwgYnV0IHRoYXQgaXMgbW9y ZSBhbG9uZyB0aGUgbGluZXMgb2YgImZhaWwtc2FmZQ0KICAgIHZzIGZhaWwtb3BlbiIuKQ0KDQog ICAgU2VjdGlvbiAyLjUuMw0KDQogICAgICAgTWFueSByb3V0aW5nIHByb3RvY29scyBzdXBwb3J0 IHRoZSB1c2Ugb2YgY3J5cHRvZ3JhcGh5IHRvIHByb3RlY3QgdGhlDQogICAgICAgcm91dGluZyB1 cGRhdGVzLCB0aGUgdXNlIG9mIHRoaXMgcHJvdGVjdGlvbiBpcyByZWNvbW1lbmRlZDsgW1JGQzgx NzddDQogICAgICAgaXMgYSBZQU5HIGRhdGEgbW9kZWwga2V5IGNoYWlucyBpbmNsdWRpbmcgdGhl IHJlbmV3YWwuDQoNCiAgICAiWUFORyBkYXRhIG1vZGVsIGZvciBrZXkgY2hhaW5zIHRoYXQgaW5j bHVkZXMgcmUta2V5aW5nIGZ1bmN0aW9uYWxpdHkiLg0KDQogICAgU2VjdGlvbiAyLjUuNA0KDQog ICAgICAgbyAgQ29uZmlndXJlIGluZ3Jlc3Mgcm91dGUgZmlsdGVycyB0aGF0IHZhbGlkYXRlIHJv dXRlIG9yaWdpbiwgcHJlZml4DQogICAgICAgICAgb3duZXJzaGlwLCBldGMuIHRocm91Z2ggdGhl IHVzZSBvZiB2YXJpb3VzIHJvdXRpbmcgZGF0YWJhc2VzLA0KICAgICAgICAgIGUuZy4sIFtSQURC XS4gIFRoZXJlIGlzIGFkZGl0aW9uYWwgd29yayBiZWluZyBkb25lIGluIHRoaXMgYXJlYSB0bw0K ICAgICAgICAgIGZvcm1hbGx5IHZhbGlkYXRlIHRoZSBvcmlnaW4gQVNzIG9mIEJHUCBhbm5vdW5j ZW1lbnRzIGluDQogICAgICAgICAgW1JGQzgyMTBdLg0KDQogICAgVG8gd2hhdCBleHRlbnQgaXMg dGhpcyBzdGlsbCAid29yayBiZWluZyBkb25lIiB2cyBhIHJlYWxpemVkIHJlc3VsdCwNCiAgICBw cm90b2NvbC13aXNlPw0KDQogICAgU2VjdGlvbiAyLjYuMS4zDQoNCiAgICAgICBvICBpbnRlcmZh Y2VzLXN0YXRlL2ludGVyZmFjZS9zdGF0aXN0aWNzIGZyb20gaWV0Zi0NCiAgICAgICAgICBpbnRl cmZhY2VzQDIwMTgtMDItMjAueWFuZyBbUkZDODM0M10gd2hpY2ggY29udGFpbnMgY291bnRlcnMg Zm9yDQogICAgICAgICAgaW50ZXJmYWNlIC4NCg0KICAgIEkgY2FuJ3QgdGVsbCBpZiB0aGlzIHNl bnRlbmNlIGVuZGVkIHByZW1hdHVyZWx5IG9yIG5vdC4NCg0KICAgIFNlY3Rpb24gMi42LjEuNA0K DQogICAgICAgVGhlIG5laWdoYm9yIGNhY2hlIG9mIHJvdXRlcnMgY29udGFpbnMgYWxsIG1hcHBp bmdzIGJldHdlZW4gSVB2Ng0KICAgICAgIGFkZHJlc3NlcyBhbmQgZGF0YS1saW5rIGxheWVyIGFk ZHJlc3Nlcy4gIFRoZXJlIGFyZSBtdWx0aXBsZSB3YXlzIHRvDQoNCiAgICBJIHRoaW5rIHdlJ3Zl IGFsc28gdXNlZCB0aGUgdGVybXMgInBoeXNpY2FsIGxheWVyIiwgImxpbmstbGF5ZXIgYWRkcmVz cyIsDQogICAgYW5kICJNQUMgYWRkcmVzcyIgYWxyZWFkeSBhcyB3ZWxsLg0KDQogICAgICAgbyAg dXNpbmcgc3RyZWFtaW5nIHRlbGVtZXRyeSBvciBORVRDT05GIFtSRkM2MjQxXSBhbmQgW1JGQzgw NDBdIHRvDQogICAgICAgICAgY29sbGVjdCB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgb2YgdGhlIG5l aWdoYm9yIGNhY2hlOw0KDQogICAgU2luY2UgUkZDIDgwNDAgaXMgUkVTVENPTkYgdGhpcyBsaW5l IGRvZXNuJ3Qgc2NhbiB2ZXJ5IHdlbGwuDQoNCiAgICBTZWN0aW9uIDIuNi4xLjUNCg0KICAgICAg IGFkZHJlc3MsIHNvbWUgYmVpbmcgZGF0YS1saW5rIGxheWVyIGFkZHJlc3MgcHJlcGVuZGVkIHdp dGggdGltZQ0KICAgICAgIGluZm9ybWF0aW9uLCBvciBldmVuIGFuIG9wYXF1ZSBudW1iZXIgd2hp Y2ggaXMgdXNlbGVzcyBmb3INCiAgICAgICBvcGVyYXRpb25hbCBzZWN1cml0eS4gIE1vcmVvdmVy LCB3aGVuIHRoZSBEVUlEIGlzIGJhc2VkIG9uIHRoZSBkYXRhLQ0KDQogICAgSSBzdWdnZXN0ICJ0 aGF0IHJlcXVpcmVzIGNvcnJlbGF0aW9uIHdpdGggYW5vdGhlciBkYXRhIHNvdXJjZSB0byBiZQ0K ICAgIHVzYWJsZSBmb3Igb3BlcmF0aW9uYWwgc2VjdXJpdHkiLg0KDQogICAgU2VjdGlvbiAyLjYu MS42DQoNCiAgICAgICB1c2VkIGJ5IHRoZSB1c2VyLiAgVGhpcyB0ZWNobmlxdWUgY2FuIGJlIHVz ZWQgbm90YWJseSBmb3IgV2ktRmkNCiAgICAgICBuZXR3b3JrcyB3aXRoIFdpLUZpIFByb3RlY3Rl ZCBBZGRyZXNzIChXUEEpIG9yIGFueSBvdGhlciBJRUVFIDgwMi4xWA0KICAgICAgIFtJRUVFLTgw Mi4xWF0gd2lyZWQgaW50ZXJmYWNlIG9uIGFuIEV0aGVybmV0IHN3aXRjaC4NCg0KICAgIFdpLUZp IG5ldHdvcmtzIGFyZSBub3QgODAyLjFYIHdpcmVkIGludGVyZmFjZXMgKGxhc3QgSSBjaGVja2Vk KSwgc28NCiAgICBzL290aGVyLy8uDQoNCiAgICBTZWN0aW9uIDIuNi4yLjENCg0KICAgICAgIGEg c3Vic2NyaWJlciB2aWEgdGhlIFJBRElVUyBsb2cuICBBbHRlcm5hdGl2ZWx5LCB0aGUgRm9yd2Fy ZGluZw0KICAgICAgIEluZm9ybWF0aW9uIEJhc2Ugb2YgdGhlIENNVFMgb3IgQk5HIGluZGljYXRl cyB0aGUgQ1BFIG9mIHRoZQ0KDQogICAgUGxlYXNlIGV4cGFuZCBDTVRTIGFuZCBCTkcuDQoNCiAg ICBTZWN0aW9uIDIuNi4yLjMNCg0KICAgICAgIEluIG9yZGVyIHRvIGRvIGNvcnJlbGF0aW9uIGlu IElQdjYtcmVsYXRlZCBsb2dzLCBpdCBpcyBhZHZpc2VkIHRvDQogICAgICAgaGF2ZSBhbGwgbG9n cyBpbiBhIGZvcm1hdCB3aXRoIG9ubHkgY2Fub25pY2FsIElQdjYgYWRkcmVzc2VzDQogICAgICAg W1JGQzU5NTJdLiAgVGhlbiwgdGhlIG5laWdoYm9yIGNhY2hlIGN1cnJlbnQgKG9yIGhpc3Rvcmlj YWwpIGRhdGEgc2V0DQoNCiAgICAoV2UgbWFkZSB0aGlzIHJlY29tbWVuZGF0aW9uIGFscmVhZHkg ZWFybGllci4pDQoNCiAgICBTZWN0aW9uIDIuNy4yDQoNCiAgICAgICBUaGVyZSBhcmUgbWFueSB0 dW5uZWxzIHVzZWQgZm9yIHNwZWNpZmljIHVzZSBjYXNlcy4gIEV4Y2VwdCB3aGVuDQogICAgICAg cHJvdGVjdGVkIGJ5IElQc2VjIFtSRkM0MzAxXSwgYWxsIHRob3NlIHR1bm5lbHMgaGF2ZSBhIGNv dXBsZSBvZg0KICAgICAgIHNlY3VyaXR5IGlzc3VlcyBhcyBkZXNjcmliZWQgaW4gUkZDIDYxNjkg W1JGQzYxNjldOw0KDQogICAgcy9jb3VwbGUvbnVtYmVyLw0KDQogICAgICAgbyAgYnlwYXNzaW5n IHNlY3VyaXR5IHBvbGljeTogaWYgYSBmaXJld2FsbCBvciBhbiBJUFMgaXMgb24gdGhlIHBhdGgN Cg0KICAgIEV4cGFuZCBJUFMuDQoNCiAgICBTZWN0aW9uIDIuNy4yLjENCg0KICAgICAgIHR1bm5l bCBpbmplY3Rpb24gYXJlIHN0aWxsIHBvc3NpYmxlLiAgVGhlcmVmb3JlLCB0aGUgdXNlIG9mIElQ c2VjDQogICAgICAgW1JGQzQzMDFdIGluIHRyYW5zcG9ydCBtb2RlIGFuZCBwcm90ZWN0aW5nIHRo ZSBlbmNhcHN1bGF0ZWQgSVB2NA0KICAgICAgIHBhY2tldHMgaXMgcmVjb21tZW5kZWQgZm9yIHRo b3NlIHR1bm5lbHMuICBBbHRlcm5hdGl2ZWx5LCBJUHNlYyBpbg0KDQogICAgcy9hbmQgcHJvdGVj dGluZy90byBwcm90ZWN0Lw0KDQogICAgU2VjdGlvbiAyLjcuMi40DQoNCiAgICAgICBvICBIaWRp bmcgdGhlIElQdjQgY29yZSwgaGVuY2UgcmVtb3ZpbmcgYWxsIGF0dGFja3MgYWdhaW5zdA0KICAg ICAgICAgIFAtcm91dGVyczsNCg0KICAgIFRoaXMgaXMgdGhlIG9ubHkgcGxhY2Ugd2UgdXNlIHRo ZSB0ZXJtICJQLXJvdXRlciIsIHNvIHdlIG1pZ2h0IGp1c3QNCiAgICBleHBhbmQgb3V0IHRoZSBk ZWZpbml0aW9uIHRvIGF2b2lkIHRoZSBqYXJnb24uDQoNCiAgICBTZWN0aW9uIDIuNy4yLjYNCg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBB cyBNQVAgaGFzIGENCiAgICAgICBwcmVkaWN0YWJsZSBJUHY0IGFkZHJlc3MgYW5kIHBvcnQgbWFw cGluZywgdGhlIGF1ZGl0IGxvZ3MgYXJlIGVhc2llcg0KICAgICAgIHRvIG1hbmFnZS4NCg0KICAg IEVhc2llciB0byBtYW5hZ2UgdGhhbiB3aGF0Pw0KDQogICAgU2VjdGlvbiAyLjcuMi44DQoNCiAg ICAgICBUZXJlZG8gaXMgbm93IGhhcmRseSBuZXZlciB1c2VkIGFuZCBubyBsb25nZXIgZW5hYmxl ZCBieSBkZWZhdWx0IGluDQoNCiAgICBzL2hhcmRseSBuZXZlci9oYXJkbHkgZXZlci8NCg0KICAg ICAgIG1vc3QgZW52aXJvbm1lbnRzLCBzbywgaXQgaXMgbGVzcyBvZiBhIHRocmVhdCwgaG93ZXZl ciwgc3BlY2lhbA0KICAgICAgIGNvbnNpZGVyYXRpb24gbXVzdCBiZSB0YWtlbiBpbiBjYXNlIG9m IGRldmljZXMgd2l0aCBvbGRlciBvciBub24tDQoNCiAgICBzL2Nhc2Ugb2YvY2FzZXMgd2hlbi8N Cg0KICAgIFNlY3Rpb24gMy4xDQoNCiAgICAgICBvICBGaWx0ZXIgaW50ZXJuYWwtdXNlIElQdjYg YWRkcmVzc2VzIGF0IHRoZSBwZXJpbWV0ZXIgdGhpcyB3aWxsIGFsc28NCiAgICAgICAgICBtaXRp Z2F0ZSB0aGUgdnVsbmVyYWJpbGl0aWVzIGxpc3RlZCBpbiBbUkZDNzM1OV0NCg0KICAgIFNvbWUg a2luZCBvZiBwdW5jdHVhdGlvbiAoc2VudGVuY2UgYnJlYWs7IHNlbWljb2xvbikgYWZ0ZXIgInBl cmltZXRlciIuDQoNCiAgICAgICBvICBJbXBsZW1lbnQgaW5ncmVzcyBhbmQgZWdyZXNzIGFudGkt c3Bvb2ZpbmcgaW4gdGhlIGZvcndhcmRpbmcgYW5kDQogICAgICAgICAgY29udHJvbCBwbGFuZXMs IHNlZSBbUkZDMjgyN10gYW5kIFtSRkMzNzA0XQ0KDQogICAgVXNpbmcgYSBCQ1AgODQgcmVmZXJl bmNlIHdvdWxkIGFsc28gcGljayB1cCB0aGUgdXBkYXRlcyBpbiBSRkMgODcwNC4NCg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEl0IGlzIHJlY29tbWVuZGVkIHRvIGZpbHRlciBhdCBJ bnRlcm5ldA0KICAgICAgIGNvbm5lY3Rpb24ocykgcGFja2V0cyBoYXZpbmcgYSBzb3VyY2Ugb3Ig ZGVzdGluYXRpb24gYWRkcmVzcw0KICAgICAgIGJlbG9uZ2luZyB0byB0aGUgc2l0ZSBpbnRlcm5h bCBwcmVmaXgoZXMpOyB0aGlzIHNob3VsZCBiZSBkb25lIGZvcg0KICAgICAgIGluZ3Jlc3MgYW5k IGVncmVzcyB0cmFmZmljLg0KDQogICAgRG8gd2Ugd2FudCB0byBzYXkgInJlc3BlY3RpdmVseSIg aGVyZT8gIChGaWx0ZXJpbmcgYW55IHRyYWZmaWMgd2l0aA0KICAgIHNvdXJjZSBvciBkZXN0aW5h dGlvbiBiZWxvbmdpbmcgdG8gaW50ZXJuYWwgcHJlZml4ZXMgd291bGQgc2VlbSB0bw0KICAgIHJl c3VsdCBpbiB0aGUgc2l0ZSBiZWluZyBhbiBpc2xhbmQsIGRpc2Nvbm5lY3RlZCBmcm9tIHRoZSBp bnRlcm5ldC4uLikNCg0KICAgIFNlY3Rpb24gNQ0KDQogICAgICAgU29tZSByZXNpZGVudGlhbCB1 c2VycyBoYXZlIGxlc3MgZXhwZXJpZW5jZSBhbmQga25vd2xlZGdlIGFib3V0DQogICAgICAgc2Vj dXJpdHkgb3IgbmV0d29ya2luZy4gIFsuLi5dDQoNCiAgICBMZXNzIHRoYW4gd2hvL3doYXQ/DQoN Cg0KDQoNCg== From nobody Tue Apr 20 19:11:18 2021 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 265593A0B12; Tue, 20 Apr 2021 19:11:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-opsec-v6@ietf.org, opsec-chairs@ietf.org, opsec@ietf.org, Gyan Mishra , hayabusagsm@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <161897107564.3338.17761721532629857647@ietfa.amsl.com> Date: Tue, 20 Apr 2021 19:11:16 -0700 Archived-At: Subject: [OPSEC] Roman Danyliw's No Objection on draft-ietf-opsec-v6-26: (with COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2021 02:11:16 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-opsec-v6-26: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ** Section 2.1.5. Per “However, in scenarios where anonymity is a strong desire (protecting user privacy is more important than user attribution), privacy extension addresses should be used.”, it might be worth acknowledging that even if these are managed network, the end user and the operators may be at odds on what privacy properties are important. ** Section 2.2.1. Per “A firewall or edge device should be used to enforce the recommended order and the maximum occurrences of extension headers”, does enforcement mean dropping the packets? ** Section 2.3.2. Per “Network operators should be aware that RA-Guard and SAVI do not work or could even be harmful in specific network configurations”, please provide a more details, ideally through citation. ** Section 2.3.2, “Enabling RA-Guard by default in … enterprise campus networks …”, what’s the key property of “enterprise campus network”. The introduction already roughly says this whole document applies to managed networks. ** Section 2.5.2. Reading this section, the specific recommended practices weren’t clear. ** Section 2.6. It wasn’t clear how comprehensive this list of logs was intended to be. A few additional thoughts include: -- DHCPv6 logs -- firewall ACL logs -- authentication server logs -- NEA-like policy enforcement at the time of connection -- vpn/remote access logs -- passive DNS from port 53 traffic -- full packet capture -- active network and service scanning/audit information ** Section 2.6.1.2. The recommended fields in this section are helpful, but only in the context of the rest of the five-tuple + timing + interface + vlan + select layer 4 information for each flow. These open IPFIX information elements aren't mentioned. ** Section 2.6.2.1. Per “The forensic use case is when the network operator must locate an IPv6 address that was present in the network at a certain time or is currently in the network”, isn’t this use case more precisely an attempt to link an IP address to (a) a specific port in the case of a wired network; (b) a access point (or base station, etc.) in the case of wireless; or (c) an external IP address in the case of a VPN connection? ** Section 2.6.2.1. Additional techniques/suggestions to consider: -- Using the IPAM system noted in Section 2.1 or any other inventory system to provide hints in the about where an IP address might belong in the topology. -- A reminder that mapping between and IP+port or MAC+IP might not have been the same one as during the time of the event of interest -- there is discussion about identifying subscribers for an ISP but not in normal enterprise network scenario through SSO logs (if port level security doesn’t exist) ** Section 2.6.2.2. Per “The first technique is to use the IPFIX information and extract the list of all IPv6 source addresses to find all of the IPv6 nodes that sent packets through the router”. This framing is mixing the technique with a particular logging format. I would recommend being clear that the technique is question is passive inspection of network talkers. There a several ways to get that: a properly configured IPFIX feed from a router, but also from any number of network analysis tools on a span port or a tap. ** Section 2.7.1. In addition to the two listed practices at the IPv4 edge, I would recommend adding the common practice of application specific flow inspection. ** Section 2.8. The intent of this section isn’t clear as all of the described practices are equally true of v4. A few missing hardening practices include: -- applying firmware, OS and application patches/upgrades to the devices in a timely manner. -- using multi-factor credentials to authenticate to devices ** Section 3. This section is titled “Enterprises Specific …”, how is an “enterprise” different than a “managed network” called out in the applicability statement? ** Section 3.1. This list is helpful. Is text here and Section 2.5.4 needed? For example, does one need to say both “discard _packets_ from bogons” (this section) and “discard _routes_ from bogons” (Section 2.5.4) From nobody Wed Apr 21 06:41:30 2021 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECE033A2849; Wed, 21 Apr 2021 06:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCgza27o3mGJ; Wed, 21 Apr 2021 06:41:15 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80050.outbound.protection.outlook.com [40.107.8.50]) (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 F05863A284B; Wed, 21 Apr 2021 06:41:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A9ALsB2wGOk8babkSmdEFSKiQAz/+wL6h0gUGmsGYzC1kYrSz8FojPldLk5fkqWqKq9YLRERgdhaDBHfmcewGYL4HasnJEwHRba9ufcfvHCvMrRaQTktf0ZD7jzFbAyQCE94ZU/S3tAFIUgC4duLzt7kXkNN9R+eQI7U0xNtau/msfa+4eNSFLa8X7OU3wRRsmusha1W0swGzls9yCI/F2yBoRrsdx5fMibf6TriwsBmeljnd9E22kGzYRQ+gfK569INdRCx6CP6uMfZgnYBbbKJX8Tms/miNBBG+sa4TwM+C3FycDSsT3h0kWvimNkMkcmR++2bW8cfOG+i3rNBqg== 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=hu9IgUuMlj+6tJYfwtOTnIQRzzBGsdrfTnIGvFUojfk=; b=nR7pJ3oqODUQyd/RBekGJOPF7W2BfQt3TZQo4s9UdDXJzk9l6PDQYan3Lyogwm/Zpu7hm7AUlRv41MCzBVYKBBwAeQeWAolK+ztsGhidRd1vEpT7b/ZglAB4pqQtUz5e0XP1P4Nf1ZH1ZyqZUTVfv3wF+jYmRL/Rll4MXo0r93DSRWeV/u2cnFQ9Ec6seVc8QG3g+h/VOHUtxQZOHOaonejNybOnDgNmwus4uhSjgAVy46X9lX4WuSnFHRz/anCSK+lz6WGLgVzblLz2J8krhpKz6Bg1HR2gXxXQNB1QmFaDFlCOVmrK3tEYnzuDdZxTeAtpDWZ9DVkGY+eRtMWUNw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jisc.ac.uk; dmarc=pass action=none header.from=jisc.ac.uk; dkim=pass header.d=jisc.ac.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hu9IgUuMlj+6tJYfwtOTnIQRzzBGsdrfTnIGvFUojfk=; b=H6HXNgx/X5bKydoBPVxpGaCQzXsXO7reCf6U2Z9hfxaaojQt8PpN98BGVAxSs/ity/Ou6NhgojlUxClos9lAk1b33KwjJqZEPMHZOIMCBuC4eGO9VRu2sfqGTobH7DOTO2BjvarHcQVkiDPITv97NRkNBIcKTNZdqOoHgyC9mb4= Received: from DB9PR07MB7771.eurprd07.prod.outlook.com (2603:10a6:10:2a6::15) by DB6PR07MB3413.eurprd07.prod.outlook.com (2603:10a6:6:17::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.6; Wed, 21 Apr 2021 13:41:11 +0000 Received: from DB9PR07MB7771.eurprd07.prod.outlook.com ([fe80::6011:1efb:4348:f34f]) by DB9PR07MB7771.eurprd07.prod.outlook.com ([fe80::6011:1efb:4348:f34f%5]) with mapi id 15.20.4065.020; Wed, 21 Apr 2021 13:41:11 +0000 From: Tim Chown To: Warren Kumari CC: Enno Rey , ops-dir , "last-call@ietf.org" , opsec wg mailing list , "draft-ietf-opsec-v6.all@ietf.org" Thread-Topic: [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-25 Thread-Index: AQHXLjnDyQdRJCPbVUCT8CaQwzD7p6qy81iAgAwYLgA= Date: Wed, 21 Apr 2021 13:41:11 +0000 Message-ID: References: <161778675730.8077.2835666586607648895@ietfa.amsl.com> <20210410184555.GE91991@ernw.de> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3654.60.0.2.21) authentication-results: kumari.net; dkim=none (message not signed) header.d=none;kumari.net; dmarc=none action=none header.from=jisc.ac.uk; x-originating-ip: [2001:a88:d510:1101:6da8:4c54:334d:109b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6fcc61a8-9e94-45c4-0dc7-08d904cb1fff x-ms-traffictypediagnostic: DB6PR07MB3413: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4303; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6hzwKMcF3qNlPvE7PfwX1ZceIAtF+l8L4blXATnz4/hfp/yvVRpgXoCLtT/vfmSKyJUPaIXMWbeP4y1rsbWSApJLTncv+FhWd9v/MjQRL2omeaEc5lWW6J6JOVVJgrPvS2LJR5CFidHW1h8CoQDzelChnMIbpsKiVI69gG+xaohszAVxIiS42M2EKQmiR9lUOrA5vL1bEL2kJDIIRtd0T7lLKVTZsuRBI20K7TzBwmFLcpKVe4HKdLpOW/RNpjTidtbYHe7zs8E5cS0X47Sa5Pdt5OhiSo9zJbgbO1zc+KoulEiSbMN12pYjcCcrsG6Ct7vy2qliVNXg4dglPAjhsiJHcB4q6Rc70HS+v6uK4vgm0+vgZjmgCJVFdVs/qiqdoL1Rglm21nP6oXQvOvu5iHV1dS3H6jm6xvnvzvGb7vU5l3YvVqfqoQGjWdCurgUUOFlvv6XgqTt6OFzZHl/H9c53yQi2ZXp9uT7rmTKCGNyoEmvurEt0PpmR8LerXfImIAAErMSfuZEGmD6GndFCqy75P1m6HQwYE1/lHTTlLTckTJ8GgPjLzmxbDzf8zOZblpLi7w9bl0ChlHPCgDK3rpA8wFjr8w966MZUpFsIFwx1lnpv4ecOvaKE+7Mr1SOwWmTwJszrXSamtONUDz7WU+/92b5b1D80s9cctUWwc6AzjHYNnrpinfNSx637TtHStQekJ25Iu/DOB2EGW/HIJEeYZgRZqdyFREC3JdguUWNaEj5UFcKaj2PqP0ximV13 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB9PR07MB7771.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39850400004)(396003)(136003)(346002)(366004)(376002)(66556008)(64756008)(66574015)(66446008)(66476007)(2906002)(76116006)(86362001)(66946007)(91956017)(4326008)(6916009)(6512007)(30864003)(54906003)(316002)(786003)(6486002)(5660300002)(53546011)(186003)(122000001)(38100700002)(71200400001)(36756003)(478600001)(6506007)(966005)(33656002)(8936002)(8676002)(2616005)(83380400001)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?K3lsVStPcnhwWkdnR1pTTzh1NVJqVldNWFMyR1dVcEJqeHRjdGtsTFQ5V3B5?= =?utf-8?B?RkJ6SkVlT3JVeGdOdUNRZFJrdzYvK1NNM3dvSkFZUXY3cHQ3VG1CRWx5Z3Fj?= =?utf-8?B?RzBONUpmUXJsZ25idkFyd2RJRDllOXZoREpZajBtV0RJbGdPcmYxazBoQ21I?= =?utf-8?B?aWwvaklxNHVyQ2dtc3AwbjlqUjNxY2xCRG5hMlBjaDJLdlZQeDdyait0anlW?= =?utf-8?B?QlhxZ0xlcGlOcmFXRlBXS2ZudDVkRnNtR1h2Uy9IS0sxWi9tL3g0aHN4citp?= =?utf-8?B?cjR2Wi9BN055SG1aYzR0TEZqaC9hMnE5S1E5UU9KQ0FEODVqRGh2Z2w5bkxN?= =?utf-8?B?bkRTK3Z1V2k1WDNjMDJaOTl3L0pURUphL0ZNa2IrVGdJcDVYeEVmSFNEaU1Z?= =?utf-8?B?dWRKbjFvWmIwbXNJazhySnVDWmhyTGFJSG1GM2I1UEU4TzBpZ1kwWnA0M2lK?= =?utf-8?B?eVFOMDlNeTM2WFlPbGpwN2tUZ1AybHdMSEw4VGM5NjYyVjRKYWtabmZtcUVk?= =?utf-8?B?WkVkMTQ4Sk1TdEEzNndPbldQY3BwWkFoM2RsWFp1MXdMR3ZmZkdBdGMwTWEr?= =?utf-8?B?SFdNV3JsWDJaUHQzZXU3MEU5TnZuOUNwNVk4VnVML2orSU1xb1RMM3ppRVRC?= =?utf-8?B?bWFUd29ZTUdidUVmZ3dSY3pJeXorUXpsdDhyWi9iYitvdTNiQk44TnZCa0Z1?= =?utf-8?B?RFV4eWZob2FXbzh3T2dKMGVqd2dJaTloNlZaZWpKUTZsS1hTY201TjhwbmZ5?= =?utf-8?B?RUwxeFFTOWxlb3dhV3lPajJVcG1mLzJNUklkWmUxNWduM2F2TXFVK2JmcmY1?= =?utf-8?B?Y2RpUU9rRzV2Q0ZGUktCdGd0bEtSR09FK0RTNkphMHoyN1cyNWhUVnNsV3FH?= =?utf-8?B?UkFGNTZyYzkyRkVCMG0xVmRhZndQbURZT2p2Q29JR0tjbmZYY3hQengrUFha?= =?utf-8?B?U3ZCZHY5U3ZNdzFoTXMxNm1nQmxHK29jSjBuNHRCMytSMXRWVnpvSEJaS1dF?= =?utf-8?B?TVlwQ25jNHpxcWNKMWdQV01JZFlyd1ViY24yZ0hmVmxzUEZXR0dlZ3RZNFJV?= =?utf-8?B?akpENzJzaUpna2ZrZWJGWGwyTVRTeDREbktjTGFSZ1J3N1pKeVZIRE5uTjRu?= =?utf-8?B?Ny80VU1Ta2NtZFc2ZFVYN1BQNGJoUEdyRUdZdWk0bDIxUWNXZnpPZm5aUy9n?= =?utf-8?B?cW1FU2MyMWNISUtOUW8zZFh6cGxJM3p6VElkcWh4Q25pdWtCNEFZMmEvTkJR?= =?utf-8?B?YytMaTdWc2sxYllvU1ZiMmxoZXE5Mlcvd1NlTjVuaFR1Z0pNRkN0bkNvbWFH?= =?utf-8?B?Y3RHS2R6SUNXZ3dieHF1cXpuQmZFNXpEcHlSVE5FcUZyK2RaREVkMzFRL3N6?= =?utf-8?B?bGtXVHJNaE1kaGM0c00wbllYWHlJRCtoUk9RTURRLy9NTVhkazlKZWwyL0lp?= =?utf-8?B?b0xFUEVPQzBaRHZ2VGpRS2ZCSHhGM25sclpubDZ4dHIrQ1VOcEVSWWtRRDBI?= =?utf-8?B?d1RwUkxqNVVMbkRYVXo4MXdmdFlSL05aNVQrdGZ5UVRZdVl1c1Roc3ROTkxa?= =?utf-8?B?dEVtQ2w1V2JDdDJlc1lDUmhPSmFCdHlhaU00WWVlc1RNNVNPRG5aZkQ0dVZR?= =?utf-8?B?dFJ5UGtvMElHL3R4bWlJR3FDWkVLTmp0ZmVpdE1IVGF0Z2lqUVRjOGhWekEw?= =?utf-8?B?NG1EVWFLZ3dzYXNBWTJySjBuR1ZuWTNTSk9MQU1HbWl5alZGaE85QUlFdGQ0?= =?utf-8?B?dEZlRm1nVEI0UzJUK2dVRVFPMWtpeFhUWVNFd2pUeE9OZUFVZjJ1YmIrQm5Y?= =?utf-8?B?QmRzVHZJc0hKN0RrOTZjbEc5aE1MTWg0ZFQ5VHhlckJXenQwVlJKbkYrVlhj?= =?utf-8?B?OHMwSDg1My9hNjliVDBURGY3eldiN2pzSGFnQmdUM1VpcUE9PQ==?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB9PR07MB7771.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6fcc61a8-9e94-45c4-0dc7-08d904cb1fff X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2021 13:41:11.0102 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 6PB87CQUvK8qumXn4K1Tc/cAYmq6/CQVMX7vaAsQBxhLDIpThxuCQAelKnPd1xL8jL0+N3koj/D+U51DPzcEmQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB3413 Archived-At: Subject: Re: [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-25 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2021 13:41:21 -0000 SGksDQoNCknigJl2ZSBub3QgeWV0IHNlZW4gYW55IGNvbW1lbnRzIGFzIHByb3Bvc2VkIGJ5IFdh cnJlbiwgYW5kIHRoZSByZXZpZXcgaXMgZHVlICh0aGUgZGVhZGxpbmUgd2FzIGEgc2hvcnRlciB0 aGFuIHVzdWFsIG9uZSkuICBJIGNhbiBnbyBhaGVhZCBhbmQgbG9vayB0byBkZXRlcm1pbmUgdGhl IGNoYW5nZXMgZnJvbSB0aGUgZGlmZiB2aWV3Lg0KDQpBIGZhaXJseSBtYWluIHBvaW50IHdhcyB3 aGV0aGVyIGFueSBzdW1tYXJ5IHJlY29tbWVuZGF0aW9ucyB3b3VsZCBiZSBhZGRlZCwgZ2l2ZW4g dGhlIGRvY3VtZW504oCZcyBsZW5ndGgsIGFuZCB0aGUgdmFyaWF0aW9uIGluIHN0eWxlIHRocm91 Z2ggdGhlIGRvY3VtZW50LCB3aXRoIHNvbWUgc2VjdGlvbnMgaGF2aW5nIHJlY29tbWVuZGF0aW9u cyBzdWJzZWN0aW9ucywgb3RoZXJzIG5vdC4gIFRoZXJlIGlzIGEgbG90IG9mIGdvb2QgYWR2aWNl IGluIHRoZSB0ZXh0LCBidXQgaXTigJlzIGEgbG9uZyByZWFkIGFzIGlzLCBhbmQgdGhlcmXigJlz IGxpa2VseSBhIGNvdXBsZSBvZiBwYWdlcyBvZiBrZXkgYnVsbGV0IHBvaW50cyB0aGF0IGNvdWxk IGJlIGFkZGVkLg0KDQpXaGVuIGlzIHRoZSBkcmFmdCBjb21pbmcgYmFjayB0byB0aGUgSUVTRz8N Cg0KVGltDQoNCj4gT24gMTMgQXByIDIwMjEsIGF0IDIxOjU5LCBXYXJyZW4gS3VtYXJpIDx3YXJy ZW5Aa3VtYXJpLm5ldD4gd3JvdGU6DQo+IA0KPiBKdXN0IGEgcXVpY2sgbm90ZSB0byBzYXkgdGhh bmtzIHRvIFRpbSBmb3IgdGhlIGV4Y2VsbGVudCBhbmQgZGV0YWlsZWQgcmV2aWV3LCBhbmQgdG8g dGhlIGF1dGhvcnMgZm9yIGFkZHJlc3NpbmcgaXQuLi4NCj4gDQo+IEkgdG9vayBhIHF1aWNrIHNr aW0gdGhyb3VnaCB0aGUgZGlmZnMsIGFuZCBpdCB3YXMgYSBsaXR0bGUgdHJpY2t5IGZvciBtZSB0 byB0ZWwgd2hpY2ggYWxsIG9mIHRoZSBjb21tZW50cyBoYWQgYmVlbiBhZGRyZXNzZWQgLS0gYXV0 aG9ycywgaWYgeW91IGdldCBhIGNoYW5jZSwgY291bGQgeW91IHJlcGx5IG5vdGluZyB3aGljaCBj b21tZW50cyB3ZXJlIGZvbGRlZCBpbnRvIC0yNj8NCj4gVw0KPiANCj4gT24gU2F0LCBBcHIgMTAs IDIwMjEgYXQgMjo0NiBQTSBFbm5vIFJleSA8ZXJleUBlcm53LmRlPiB3cm90ZToNCj4gSGkgVGlt LA0KPiANCj4gdGhhbmtzIHNvIG11Y2ggZm9yIGFub3RoZXIgZGV0YWlsZWQgbG9vayBhdCB0aGUg ZHJhZnQuDQo+IFlvdXIgZmVlbGluZyB0aGF0IGl0IGhhcyBiZWVuIGluIHRoZSBtYWtpbmcgZm9y IGEgd2hpbGUgaXMgY29ycmVjdCAodGVsbCBtZSBhYm91dCBpdCA7LSksIHN0aWxsIHdlIHRoaW5r IHRoYXQgdGhlIG9wZXJhdGlvbmFsIHNlY3VyaXR5IGd1aWRhbmNlIGZvciBJUHY2IGhhc24ndCBj aGFuZ2UgbXVjaCBvdmVyIHRpbWUsIGFuZCBpdCBtaWdodCBldmVuIGJlIG1vcmUgbmVlZGVkIHRo YW4gZXZlciAoZ2l2ZW4gY3VycmVudCBtb21lbnR1bSBvZiBJUHY2IHVwdGFrZSkuDQo+IEkgd2Vu dCB0aHJvdWdoIHlvdXIgYmVsb3cgcG9pbnRzLCBhbmQgZm9yIG1hbnkgb2YgdGhlbSBJJ3ZlIHBl cmZvcm1lZCBhY2NvcmRpbmcgY2xhcmlmaWNhdGlvbnMvZW5oYW5jZW1lbnRzIG9mIHRoZSBkcmFm dC4gQSBuZXcgdmVyc2lvbiBoYXMgdGhlbiBiZWVuIHVwbG9hZGVkLg0KPiANCj4gV2lzaCB5b3Ug YSBncmVhdCB3ZWVrZW5kDQo+IA0KPiBFbm5vDQo+IA0KPiANCj4gDQo+IA0KPiBPbiBXZWQsIEFw ciAwNywgMjAyMSBhdCAwMjoxMjozN0FNIC0wNzAwLCBUaW0gQ2hvd24gdmlhIERhdGF0cmFja2Vy IHdyb3RlOg0KPiA+IFJldmlld2VyOiBUaW0gQ2hvd24NCj4gPiBSZXZpZXcgcmVzdWx0OiBIYXMg SXNzdWVzDQo+ID4gDQo+ID4gSGksDQo+ID4gDQo+ID4gSSBoYXZlIHJldmlld2VkIHRoaXMgZG9j dW1lbnQgKGRyYWZ0LWlldGYtb3BzZWMtdjYtMjUpIGFzIHBhcnQgb2YgdGhlDQo+ID4gT3BlcmF0 aW9uYWwgZGlyZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9j dW1lbnRzIGJlaW5nDQo+ID4gcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLj8/IFRoZXNlIGNvbW1lbnRz IHdlcmUgd3JpdHRlbiB3aXRoIHRoZSBpbnRlbnQgb2YNCj4gPiBpbXByb3ZpbmcgdGhlIG9wZXJh dGlvbmFsIGFzcGVjdHMgb2YgdGhlIElFVEYgZHJhZnRzLiBDb21tZW50cyB0aGF0IGFyZSBub3QN Cj4gPiBhZGRyZXNzZWQgaW4gbGFzdCBjYWxsIG1heSBiZSBpbmNsdWRlZCBpbiBBRCByZXZpZXdz IGR1cmluZyB0aGUgSUVTRyByZXZpZXcuPz8NCj4gPiBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBj aGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXINCj4g PiBsYXN0IGNhbGwgY29tbWVudHMuDQo+ID4gDQo+ID4gVGhpcyBkcmFmdCBhbmFseXNlcyBvcGVy YXRpb25hbCBzZWN1cml0eSBpc3N1ZXMgcmVsYXRlZCB0byB0aGUgZGVwbG95bWVudCBvZg0KPiA+ IElQdjYsIGFuZCBkZXNjcmliZXMgYXBwcm9wcmlhdGUgbWVjaGFuaXNtcyBhbmQgcHJhY3RpY2Vz IHRvIG1pdGlnYXRlIHBvdGVudGlhbA0KPiA+IHRocmVhdHMuDQo+ID4gDQo+ID4gSSBoYWQgcHJl dmlvdXNseSByZXZpZXdlZCB0aGUgZHJhZnQgYXMgYW4gT1BTLURJUiBFYXJseSBSZXZpZXcgaW4g SnVseSAyMDE4LA0KPiA+IGFuZCBhZ2FpbiBzaW5jZSB0aGVuLCBzbyBhbSBmYW1pbGlhciB3aXRo IHRoZSBkb2N1bWVudCBhbmQgaXRzIGhpc3RvcnkuDQo+ID4gDQo+ID4gR2VuZXJhbCBjb21tZW50 czoNCj4gPiANCj4gPiBUaGUgZG9jdW1lbnQgaGFzIGV2b2x2ZWQgb3ZlciB0aW1lIHdpdGggbWFu eSB0b3BpY3MgYWRkZWQsIGFuZCBoYXMgYW4NCj4gPiBpbmV2aXRhYmxlID8/P0ZyYW5rZW5zdGVp bj8/PyBmZWVsIHRvIGl0LiAgVGhlIGRvY3VtZW50IHdvdWxkIGJlIG11Y2ggYmV0dGVyIGZvciBh DQo+ID4gcmV3cml0ZSwgYnV0IHRoYXQgd291bGQgYmUgc2lnbmlmaWNhbnQgd29yaywgYW5kIHdv dWxkIGRlbGF5IHB1YmxpY2F0aW9uDQo+ID4gZnVydGhlci4gIFRoZSBtYXRlcmlhbCBpbiB0aGUg ZG9jdW1lbnQgaXMgZ29vZCwgYW5kIHRoZSBhZHZpY2UgaXMgdmFsdWFibGUsIHNvDQo+ID4gdGhl IGZvY3VzIHNob3VsZCBiZSBvbiBwdWJsaXNoaW5nIGl0IHNvb25lciByYXRoZXIgdGhhbiBsYXRl ciwgYW5kIHRodXMgdGhlDQo+ID4gaXNzdWVzIHdpdGggc3RydWN0dXJlIGFyZSBwcm9iYWJseSBi ZXN0IG92ZXJsb29rZWQuDQo+ID4gDQo+ID4gQW4gZXhhbXBsZSBvZiB0aGUgaGlzdG9yaWNhbCBl dm9sdXRpb24gb2YgdGhlIGRvY3VtZW50IGFyZSB0aGUgaW5zdGFuY2VzIHdoZXJlDQo+ID4gdGhl IHNhbWUgdG9waWMgb3MgY292ZXJlZCBtdWx0aXBsZSB0aW1lcy4gIFRoaXMgd291bGQgaWRlYWxs eSBiZSBhdm9pZGVkLg0KPiA+IA0KPiA+IFRoZSBzZWN0aW9uIG1vc3QgaW4gbmVlZCBvZiBhdHRl bnRpb24gaXMgMi4xLCB3aGVyZSBtYW55IGFzcGVjdHMgb2YgYWRkcmVzc2luZw0KPiA+IGFyZSB3 ZWF2ZWQgdG9nZXRoZXI6IGFsbG9jYXRpb25zLCBhc3NpZ25tZW50cywgYXNzaWdubWVudCB0byBo b3N0cywgVUxBcywNCj4gPiBzdGFibGUgYW5kIHRlbXBvcmFyeSBhZGRyZXNzZXMsIGV0Yy4gIFRo aXMgbWlnaHQgYmUgYmV0dGVyIHByZXNlbnRlZCBhcyBhDQo+ID4gc2VjdGlvbiBsaXN0aW5nIGFk ZHJlc3NpbmcgcmVsYXRlZCBzZWN1cml0eSBpc3N1ZXMsIHN1Y2ggYXMgcHJpdmFjeSBmb3IgdXNl cnMsDQo+ID4gZmlyc3QgaG9wIHNlY3VyaXR5LCBuZXR3b3JrIG1hbmFnZWFiaWxpdHksIGltcGxp Y2F0aW9ucyBvZiBtdWx0aS1hZGRyZXNzZWQNCj4gPiBob3N0cywgYWRkcmVzcyBhY2NvdW50YWJp bGl0eSAod2hpY2ggaXNuPz8/dCBtZW50aW9uZWQgaGVyZT8pLCBhdm9pZGluZw0KPiA+IHJlbnVt YmVyaW5nIChpZiB0aGF0IGlzIHNlY3VyaXR5PyksIGV0Yy4NCj4gPiANCj4gPiBUaGVyZSBhcmUg YWxzbyBzb21lIHNlY3Rpb25zIHdoaWNoIHN1bW1hcmlzZSByZWNvbW1lbmRhdGlvbnMsIG9yIHJl aW5mb3JjZQ0KPiA+IHRoZW0sIGFuZCBvdGhlcnMgdGhhdCBkbyBub3QuICBGb3IgYSBkb2N1bWVu dCBvZiBvdmVyIDUwIHBhZ2VzLCB3aGljaCBpcyBxdWl0ZQ0KPiA+IGEgbG9uZyByZWFkLCBpdCB3 b3VsZCBiZSBkZXNpcmFibGUgdG8gaGF2ZSBhIHN1bW1hcnkgb2YgdGhlIGtleQ0KPiA+IHJlY29t bWVuZGF0aW9ucywgZWl0aGVyIGF0IHRoZSBlbmQgb2YgZWFjaCAybmQgbGV2ZWwgdG9waWMsIG9y IGFzIGEgc3RhbmRhbG9uZQ0KPiA+IHNlY3Rpb24gYXQgdGhlIGVuZCBvZiB0aGUgZG9jdW1lbnQg d2hlcmUgdGhlIGtleSBwb2ludHMgb2YgZWFjaCAybmQgbGV2ZWwgdG9waWMNCj4gPiBhcmUgc3Vt bWFyaXNlZC4NCj4gPiANCj4gPiBJcyBpdCB3b3J0aCBjaXRpbmcgZXhhbXBsZXMgb2Ygc2VjdXJp dHkgdG9vbGtpdHMgcmVhZGVycyBjYW4gZXhwbG9yZSwgbGlrZSB0aGUNCj4gPiBUSEMga2l0LCBT STYgTmV0d29ya3MsIGV0YywgbWF5YmUgU2NhcHk/DQo+ID4gDQo+ID4gU3BlY2lmaWMgY29tbWVu dHM6DQo+ID4gDQo+ID4gcC4zDQo+ID4gSSBkb24/Pz90IHVuZGVyc3RhbmQgd2h5IE5QVHY2IGlz IG1lbnRpb25lZCBoZXJlLCB0aGlzIGVhcmx5LiAgSnVzdCBzYXkgdGhhdCBzb21lDQo+ID4gc2Vj dXJpdHkgaXNzdWVzIGhhdmUgSVB2NCBlcXVpdmFsZW50cywgbGlrZSBORCBhdHRhY2tzIGFuZCBB UlAgYXR0YWNrcywgYW5kDQo+ID4gc29tZSBkbyBub3QsIGxpa2UgSVB2NiBFSHMgb3IgaG9wIGJ5 IGhvcCBEb1MuICAgVGhlIE5BVCBkaXNjdXNzaW9uIHNob3VsZCBiZSBpbg0KPiA+IGEgc3RhbmRh bG9uZSBzZWN0aW9uLCBhbmQgYmUgbmV1dHJhbCB0aGVyZS4NCj4gPiANCj4gPiBwLjQNCj4gPiBX aHkgbWVudGlvbiB0aGUgc3BlY2lmaWMgZXhhbXBsZSBvZiBtdWx0aS1ob21lZCBuZXR3b3Jrcz8g ICBXaGF0IGRvIHlvdSBtZWFuIGJ5DQo+ID4gdGhlIGV4Y2VwdGlvbj8gIElzIGl0IHRoYXQgbXVs dGktaG9taW5nIGlzIG91dCBvZiBzY29wZSwgYW5kIHNvIGFyZSB1bm1hbmFnZWQNCj4gPiBuZXR3 b3Jrcz8NCj4gPiANCj4gPiBwLjQNCj4gPiBBZ2FpbiwgTlBUdjYgaXMgbWVudGlvbmVkLiAgVGhp cyBzZWN0aW9uIGlzIHRpdGxlZCA/Pz9hZGRyZXNzaW5nIGFyY2hpdGVjdHVyZT8/Pw0KPiA+IGJ1 dCB0aGlzIGJpdCBvZiB0ZXh0IGlzIGFib3V0IHJlYXNvbnMgZm9yIGdvaW5nIFBBLCBQSSwgb3Ig YmVjb21pbmcgYW4gTElSLA0KPiA+IHdoaWNoIGlzIG5vdCBhcmNoaXRlY3R1cmUuDQo+ID4gDQo+ ID4gcC40DQo+ID4gSW4gdGhlIDc5MzQgcGFyYSwgUkZDODk4MSBzaG91bGQgYmUgbWVudGlvbmVk IGFzIGl0Pz8/cyBhIHNpZ25pZmljYW50IHJlYXNvbiBvZg0KPiA+IGRldmljZXMgaGF2aW5nIG1v cmUgYWRkcmVzc2VzLg0KPiA+IA0KPiA+IHAuNQ0KPiA+IFVMQXMgYXJlIGFsc28gdXNlZnVsIHdo ZXJlIHRoZSBwcmVmaXggY2hhbmdlcywgZm9yIHN0YWJsZSBpbnRlcm5hbCBhZGRyZXNzaW5nDQo+ ID4gYXMgdGhlIGdsb2JhbCBwcmVmaXggY2hhbmdlcz8gIFR5cGljYWxseSBpbiByZXNpZGVudGlh bCBuZXR3b3Jrcy4NCj4gPiANCj4gPiBwLjUNCj4gPiBTZWN0aW9uIDIuMS40IGlzIHJlYWxseSBh Ym91dCBjaG9pY2VzIGluIGFkZHJlc3MgYXNzaWdubWVudCB3aXRoaW4gYSBuZXR3b3JrLg0KPiA+ IA0KPiA+IHAuNg0KPiA+IFNvbWUgb2YgdGhlc2UgcGFyYXMgc2hvdWxkIGJlIGluIGEgc2VjdGlv biBhYm91dCBJUHY2IG5ldHdvcmsgcmVjb25uYWlzc2FuY2UsDQo+ID4gaG93IHRvIGJlc3QgbWl0 aWdhdGUgYWdhaW5zdCBzY2FubmluZywgYW5kIGhvdyB0byBpbnZlbnRvcnkgeW91ciBvd24gbmV0 d29yaw0KPiA+IGVsZW1lbnRzLg0KPiA+IA0KPiA+IHAuNg0KPiA+IEFsbCBtZW50aW9ucyBvZiA0 OTQxIHNob3VsZCBiZSByZXBsYWNlZCB3aXRoIDg5ODEuDQo+ID4gDQo+ID4gcC43DQo+ID4gQ2Fu IHVzZSA3NzIxIGFuZCA4OTgxIHRvZ2V0aGVyLg0KPiA+IA0KPiA+IHAuNw0KPiA+IFdoeSBhcmUg REhDUCBhbmQgRE5TIGxpbXBlZCB0b2dldGhlcj8gIFRoZSBETlMgaXMgb25seSBhYm91dCBETlNT RUMsIHNvIGNhbGwgaXQNCj4gPiB0aGF0Pw0KPiA+IA0KPiA+IHAuNw0KPiA+ID8/P0V2ZW4gaWYg dGhlIHVzZSBvZiBESENQPz8/IC0gdGhpcyByZWFkcyBiYWRseS4gIFJhdGhlciA4NTA0IHRhbGtz IGFib3V0IHRoaXMgaW4NCj4gPiA2LjUsIHdoZXJlIFJGQzc4NDQgaXMgbWVudGlvbmVkIGZvciBl eGFtcGxlLiAgVGhpcyBzaG91bGQgYmUgaW4gYSB1c2VyIHByaXZhY3kNCj4gPiBzZWN0aW9uIChp ZiB0aGlzIGRvY3VtZW50IGhhZCBvbmUpLiAgU2VjdGlvbiA4LjQgaXMgYWxzbyB1c2VmdWwgYWR2 aWNlLg0KPiA+IA0KPiA+IHAuOA0KPiA+IFRoZSBmaXJzdCBwYXJhIGlzIHZlcnkgbXVkZGxlZC4N Cj4gPiANCj4gPiBwLjgNCj4gPiBJbiAyLjEuNyB0aGlzIGNhbiBhbHNvIGJlIHVzZWZ1bCBmb3Ig QUNMIGNvbnRyb2xzLCBpZiBvbmUgYWRtaW4gLyBjb250cm9sDQo+ID4gc3lzdGVtIHNpdHMgaW4g YSBwcmVmaXggb2YgaXRzIG93bi4NCj4gPiANCj4gPiBwLjEwDQo+ID4gVGhpcyBpcyByZWFsbHkg YWJvdXQgaGFuZGxpbmcgb2YgZnJhZ21lbnRlZCBwYWNrZXRzICh0aGUgdG9waWMpIG5vdCB0aGUN Cj4gPiBmcmFnbWVudCBoZWFkZXIgaXRzZWxmIEFsc28gdGhpcyBpcyBjb3ZlcmVkIGluIDIuMy4y LjEgYXMgd2VsbC4NCj4gPiANCj4gPiBwLjEwDQo+ID4gSW4gMi4yLCB0aGUgaW50cm8gY2FuIHNh eSB0aGVzZSBpc3N1ZXMgaGF2ZSBwYXJhbGxlbHMgaW4gSVB2NC4NCj4gPiANCj4gPiBwLjExDQo+ ID4gRmlyc3QgbGluZSwgc2F5IHRoZSBhdHRhY2sgY2FuIHR5cGljYWxseSBoYXBwZW4gZnJvbSBh IGxhcmdlIGFkZHJlc3Mgc2NhbiBpZg0KPiA+IHBlcm1pdHRlZCBpbnRvIHRoZSBuZXR3b3JrPw0K PiA+IA0KPiA+IHAuMTENCj4gPiBCdWxsZXQgMSAtIHRoYXQgY29udHJhZGljdHMgdGhlIGNvbW1l bnRzIG9uIHByZWRpY3RhYmxlIGFkZHJlc3NpbmcuDQo+ID4gQnVsbGV0IDIgLSBob3c/ICBTb21l IGNsdWVzIGhlcmUgd291bGQgYmUgdXNlZnVsLg0KPiA+IA0KPiA+IHAuMTINCj4gPiA/Pz9DdXJy ZW50Pz8/IC0gcmVhbGx5PyBBbGwgY3VycmVudCBpbXBsZW1lbnRhdGlvbnM/ICBEZWxldGUgPz8/ Y3VycmVudD8/PyBvciByZXBsYWNlDQo+ID4gd2l0aCA/Pz9uYWl2ZT8/PyBtYXliZS4NCj4gPiAN Cj4gPiBwLjEyDQo+ID4gPz8/Q29tbXVuaWNhdGUgZGlyZWN0bHk/Pz8gLSBhdCBMMj8gIElmIHNv LCB3aHk/DQo+ID4gDQo+ID4gcC4xMg0KPiA+IEFuIGV4YW1wbGUgb2YgYSByZWNvbW1lbmRhdGlv bnMgc2VjdGlvbiBoZXJlLCB3aGVyZSBvdGhlciBzZWN0aW9ucyB3aXRoIGFkdmljZQ0KPiA+IGFy ZSBub3QgdGl0bGVkIGFzIHN1Y2guIFNlZSB0aGUgR2VuZXJhbCBjb21tZW50IG9uIHRoaXMuDQo+ ID4gDQo+ID4gcC4xMw0KPiA+ID8/P1RyaXZpYWw/Pz8gY2FzZXMgLSBhcmVuPz8/dCB0aGVzZSBj b21tb24gb25lcywgbGlrZSBlZGdlIHN3aXRjaGVzIGluIGFuIGVudGVycHJpc2U/DQo+ID4gDQo+ ID4gcC4xMw0KPiA+IFdoeSA/Pz9ob3N0aWxlPz8/PyAgRGVsZXRlPw0KPiA+IA0KPiA+IHAuMTQN Cj4gPiBJbiAyLjMuNSBsYXN0IHBhcmEsIHdoYXQgYWJvdXQgbUROUywgQm9uam91cj8gICBUaG91 Z2ggdGhlIEROUyBTRCB3b3JrIGlzIG5vdw0KPiA+IG9uIHVuaWNhc3QgZGlzY292ZXJ5Lg0KPiA+ IA0KPiA+IHAuMjENCj4gPiBNYXliZSBhZGQgaGVyZSA4MDIuMXggYXMgYW4gZXhhbXBsZSBvZiB0 aGUgdmFsdWUgb2YgUkFESVVTIGxvZ3MsIGFuZCBhZGQgaW4NCj4gPiBoZXJlIGFzIGJ1bGxldHMg aW5mbyBoYXJ2ZXN0ZWQgZnJvbSBzd2l0Y2hlcyBhbmQgKHNheSkgcm91dGVyIE5EUCBzeXNsb2cN Cj4gPiAodGhvdWdoIHRoYXQ/Pz9zIEkgc3VwcG9zZSB0aGUgNHRoIGJ1bGxldCkuICBUaGVzZSBh cmUgbWVudGlvbmVkIGluIDIuNi4xLjcgYnV0DQo+ID4gc2hvdWxkIGJlIHNwbGl0IG91dCBhdCB0 aGUgc2FtZSBsZXZlbCBhcyB0aGUgb3RoZXIgdG9waWNzIGhlcmUuDQo+ID4gDQo+ID4gcC4yOA0K PiA+IFRoZSB0ZXh0IGlzIDIuNi4yLjIgcmVwZWF0cyBlYXJsaWVyIHRleHQuDQo+ID4gU2ltaWxh cmx5IHRleHQgaW4gMi42LjIuMyBpcyByZXBlYXRlZCBmb3JtIGJlZm9yZS4NCj4gPiANCj4gPiBw LjI5DQo+ID4gSW4gMi42LjIuNCBwcmVzdW1hYmx5IGFsc28gYSByYXBpZCBncm93dGggaW4gTkQg Y2FjaGUgc2l6ZSBpcyBhbiBpbmRpY2F0b3IuDQo+ID4gDQo+ID4gcC4yOQ0KPiA+IEluIDIuNyBw b2ludCB0byBSRkMgNDk0Mg0KPiA+IA0KPiA+IHAuMzANCj4gPiBTaG91bGQgUkZDIDYwOTIgYmUg bWVudGlvbmVkIGhlcmU/DQo+ID4gQW5kIHRoYXQgdGhlIGJlc3QgZGVmZW5jZSBhZ2FpbnN0IElQ djYgYXR0YWNrcyBuID8/P0lQdjQgb25seT8/PyBuZXR3b3JrcyBpcyB0bw0KPiA+IGRlcGxveSBh bmQgbWFuYWdlIElQdjY/DQo+ID4gDQo+ID4gcC4zMQ0KPiA+IEZpcnN0IGJ1bGxldCBvbiB0aGlz IHBhZ2UgLSBidXQgaXNuPz8/dCB0aGlzIHRoZSBzYW1lIGFzIGlmIHRoZSB0cmFmZmljIGlzIG5v dA0KPiA+IHR1bm5lbGxlZD8gIFdoeSBkb2VzIHR1bm5lbGxpbmcgYWRkIHRoZSByZXF1aXJlbWVu dD8gIFRoZSBzYW1lIGFwcGxpZXMgb24gdGhlDQo+ID4gZmlyc3QgcGFyYSBvbiBwLjMyDQo+ID4g DQo+ID4gcC4zMQ0KPiA+IE1heWJlIHNheSBoZXJlIHRoZSBtaXRpZ2F0aW9ucyBjYW4gYWxzbyBi cmVhayB0dW5uZWwgYnJva2VycyAobWlnaHQgYmUgZGVzaXJlZCwNCj4gPiBidXQgdXNlcnMgd2ls bCBub3RpY2U/Pz8pPz8/LiBNYXliZSB0dW5uZWxzIHRvIHNwZWNpZmljIGJyb2tlcnMgY2FuIGJl IGFsbG93ZWQuDQo+ID4gDQo+ID4gcC4zMg0KPiA+IElTQVRBUCwgaW4gMjAyMT8gIFNhbWUgd2l0 aCA2cmQuICBHZW5lcmFsIGFkdmljZSBzaG91bGQgYmUgZGVwbG95IG5hdGl2ZSwgYXZvaWQNCj4g PiB0dW5uZWxzLg0KPiA+IA0KPiA+IHAuMzMNCj4gPiBTYW1lIGZvciA2dG80Lg0KPiA+IA0KPiA+ IHAuMzQNCj4gPiBUZXJlZG8gdGhvdWdoLCBpcyB0aGF0IHN0aWxsIGluY2x1ZGVkIGluIFdpbmRv d3MgYW5kIFhCb1gsIGFzIGEgTVMgdGhpbmc/DQo+ID4gDQo+ID4gcC4zNg0KPiA+IE1heWJlIGNp dGUgR2VvZmYgSHVzdG9uPz8/cyBibG9nIG9uIHRoaXMgLSBpdD8/P3MgdmVyeSBnb29kLiAgTWF5 YmUgdGhlcmU/Pz9zIGEgbW9yZQ0KPiA+IHJlY2VudCB1cGRhdGUgdGhvdWdoIC0NCj4gPiBodHRw czovL2Jsb2cuYXBuaWMubmV0LzIwMTYvMDYvMDkvbGV0cy10YWxrLWlwdjYtZG5zNjQtZG5zc2Vj Ly4gSG9zdCBDTEFUIGlzDQo+ID4gYXBwbGljYWJsZSBoZXJlPyAgKEhlbmNlIGEgc2l0ZSBzaG91 bGQgc3VwcG9ydCB0aGUgNjRQUkVGIFJBIG9wdGlvbj8gIFJGQzg3ODENCj4gPiANCj4gPiBwLjM4 DQo+ID4gSW4gMi44LCB0byBiZSBmYWlyIElQdjQgaXMgYWxzbyBoYXJkZW5lZCBhIGxvdCBvZiBs YXRlIGR1ZSB0byB0aGUgcHJldmFsZW5jZSBvZg0KPiA+IHVzZSBvZiBkZXZpY2VzIGluIFdpRmkg aG90c3BvdHMgZXRjLg0KPiA+IA0KPiA+IHAuMzcNCj4gPiBBbHNvIFJGQzYwOTIgb24gc2VjdGlv biAzLjE/DQo+ID4gDQo+ID4gcC4zOA0KPiA+ID8/P1doZXJlIFJGQzE5MTggYWRkcmVzcyBhcmUg b2Z0ZW4gdXNlZD8/PyAtIGFkZCA/Pz9vZnRlbj8/PywgdGhlIHRleHQgaW1wbGllcyBhbGwNCj4g PiBlbnRlcnByaXNlcyB1c2UgdjQgTkFULg0KPiA+IA0KPiA+IHAuNDENCj4gPiBPbmx5IDIgbm9y bWF0aXZlIHJlZmVyZW5jZXM/DQo+ID4gDQo+ID4gTml0czoNCj4gPiANCj4gPiBwLjENCj4gPiA/ Pz9UaGUgSW50ZXJuZXQ/Pz8gLSB5b3UgcHJvYmFibHkgbWVhbiA/Pz9hbiBJU1AgbmV0d29yaz8/ Pw0KPiA+ID8/P0Rlc2NyaWJlcyB0aGUgc2VjdXJpdHk/Pz8gLSBkZWxldGUgPz8/dGhlPz8/DQo+ ID4gDQo+ID4gcC40DQo+ID4gPz8/V2hpY2ggYXJlIHRoZSBzd2l0Y2g/Pz8gZGVsZXRlID8/P3do aWNoIGFyZT8/Pw0KPiA+IA0KPiA+IHAuOA0KPiA+IFZhcnlpbmcgLT4gdmFyaW91cw0KPiA+IA0K PiA+IHAuMTANCj4gPiBpcHY2IC0+IElQdjYNCj4gPiANCj4gPiBwLjE4DQo+ID4gUm91dGVyIHBy b2Nlc3NvciAtIGFkZCByIHRvID8/P3JvdXRlPz8/DQo+ID4gDQo+ID4gPz8/DQo+ID4gVGltDQo+ ID4gDQo+ID4gDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPiBPUFNFQyBtYWlsaW5nIGxpc3QNCj4gPiBPUFNFQ0BpZXRmLm9yZw0KPiA+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzZWMNCj4gDQo+IC0tIA0KPiBF bm5vIFJleQ0KPiANCj4gQ2VsbDogKzQ5IDE3MyA2NzQ1OTAyDQo+IFR3aXR0ZXI6IEBFbm5vX0lu c2ludWF0b3INCj4gDQo+IA0KPiAtLSANCj4gVGhlIGNvbXB1dGluZyBzY2llbnRpc3TigJlzIG1h aW4gY2hhbGxlbmdlIGlzIG5vdCB0byBnZXQgY29uZnVzZWQgYnkgdGhlDQo+IGNvbXBsZXhpdGll cyBvZiBoaXMgb3duIG1ha2luZy4gDQo+ICAgLS0gRS4gVy4gRGlqa3N0cmENCg0K From nobody Wed Apr 21 08:51:58 2021 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE713A2D47 for ; Wed, 21 Apr 2021 08:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 W6vr7emGuWNi for ; Wed, 21 Apr 2021 08:51:48 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2EDD3A2D19 for ; Wed, 21 Apr 2021 08:51:42 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id u25so9957357ljg.7 for ; Wed, 21 Apr 2021 08:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hCsFLwoggKeFuwuqvlVbf76obDqjwP5P9dwQuvp6Xvw=; b=FQg0sW/6pKCO0FSieHMDTb1/3U02bt9IOWRcz/+qqVlmJZtm/pfziE/vXBbNYaUI2G DzOD7VcW4NkafI2xWI0HItP8FdfspgGnJF6S6DJEuqU8aL3bY9nFgf4jMo5pK9h1C5Pn 93hrKB0vYYoRLbgzIV+KRCnfWuCqYQjSVu+adkdQUQgLvoXuAWJV7G7j6aaiOJRvgEb2 SSw9Fvy1pSDEVAqjycx+6jWJM9jH0u2fbRdhYUfO5QDkHZh8RlacJGxLgbOsh9gYwM67 9Nh89NlTo81l3I1XidOZ0Uaff5/YuCLvo0sDq5fqbhCA1cdV+2ATk+yziF0OhGuXzmki OKqA== 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=hCsFLwoggKeFuwuqvlVbf76obDqjwP5P9dwQuvp6Xvw=; b=gvlYI7CC7H7CvPaRvZB8Qt/YjhffZC0LDcLk+eCjIiGqivoPfHHAQPA/3+c17dRqp5 1aZcIfKbv3tSvlNh5fnHRJDMb+wwESRNtPJLxhbgfJJRHUWYtPXPwo/qN0G32eaFsT0a WQKQlXHcxdetgtts/s7/vP+W3dN6hT0DrDIB7ypvxO3TUDscbhBAtgEEpUtbkjQ500wy 7cmUbtRaN4cvxKG9szZ8t3bD4o43PW9SLE19SwG285/5whxvfPCs5hkSruPCDVNQKoHO egVmMXR7k0ze/Hg0ykVG7HyBMalVccvQSHAU4wdHtYWxhF3IhYvF3esKZtn3XmEikexQ 6VJQ== X-Gm-Message-State: AOAM531G1MjAWTi5azjGuJk2TiKWL7SZ/QrFE5pGyADvlb5v5VmiEw2b LCaNv+EVuncgPH5qz7oXr89YhUPPwER60Mh1XkO9Qw== X-Google-Smtp-Source: ABdhPJyMi0SH4T2rM8HLIHXsUAniobnB7QNgzIuIM6a+ikkbvpbe5bYBO68PFUfFVpfDGSl+DZYMANWbn8T19fMalSQ= X-Received: by 2002:a2e:bc0c:: with SMTP id b12mr19081496ljf.502.1619020295619; Wed, 21 Apr 2021 08:51:35 -0700 (PDT) MIME-Version: 1.0 References: <161778675730.8077.2835666586607648895@ietfa.amsl.com> <20210410184555.GE91991@ernw.de> In-Reply-To: From: Warren Kumari Date: Wed, 21 Apr 2021 11:50:59 -0400 Message-ID: To: Tim Chown Cc: Enno Rey , ops-dir , "last-call@ietf.org" , opsec wg mailing list , "draft-ietf-opsec-v6.all@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009ada6e05c07d898f" Archived-At: Subject: Re: [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-25 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2021 15:51:57 -0000 --0000000000009ada6e05c07d898f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Apr 21, 2021 at 9:41 AM Tim Chown wrote: > Hi, > > I=E2=80=99ve not yet seen any comments as proposed by Warren, and the rev= iew is > due (the deadline was a shorter than usual one). I can go ahead and look > to determine the changes from the diff view. > > A fairly main point was whether any summary recommendations would be > added, given the document=E2=80=99s length, and the variation in style th= rough the > document, with some sections having recommendations subsections, others > not. There is a lot of good advice in the text, but it=E2=80=99s a long = read as > is, and there=E2=80=99s likely a couple of pages of key bullet points tha= t could be > added. > > When is the draft coming back to the IESG? > Actually, it is on tomorrow's telechat. Do you think that this is important enough to hold the document? Keeping in mind that the document has been many years in the making... W > > Tim > > > On 13 Apr 2021, at 21:59, Warren Kumari wrote: > > > > Just a quick note to say thanks to Tim for the excellent and detailed > review, and to the authors for addressing it... > > > > I took a quick skim through the diffs, and it was a little tricky for m= e > to tel which all of the comments had been addressed -- authors, if you ge= t > a chance, could you reply noting which comments were folded into -26? > > W > > > > On Sat, Apr 10, 2021 at 2:46 PM Enno Rey wrote: > > Hi Tim, > > > > thanks so much for another detailed look at the draft. > > Your feeling that it has been in the making for a while is correct (tel= l > me about it ;-), still we think that the operational security guidance fo= r > IPv6 hasn't change much over time, and it might even be more needed than > ever (given current momentum of IPv6 uptake). > > I went through your below points, and for many of them I've performed > according clarifications/enhancements of the draft. A new version has the= n > been uploaded. > > > > Wish you a great weekend > > > > Enno > > > > > > > > > > On Wed, Apr 07, 2021 at 02:12:37AM -0700, Tim Chown via Datatracker > wrote: > > > Reviewer: Tim Chown > > > Review result: Has Issues > > > > > > Hi, > > > > > > I have reviewed this document (draft-ietf-opsec-v6-25) as part of the > > > Operational directorate's ongoing effort to review all IETF documents > being > > > processed by the IESG.?? These comments were written with the intent = of > > > improving the operational aspects of the IETF drafts. Comments that > are not > > > addressed in last call may be included in AD reviews during the IESG > review.?? > > > Document editors and WG chairs should treat these comments just like > any other > > > last call comments. > > > > > > This draft analyses operational security issues related to the > deployment of > > > IPv6, and describes appropriate mechanisms and practices to mitigate > potential > > > threats. > > > > > > I had previously reviewed the draft as an OPS-DIR Early Review in Jul= y > 2018, > > > and again since then, so am familiar with the document and its histor= y. > > > > > > General comments: > > > > > > The document has evolved over time with many topics added, and has an > > > inevitable ???Frankenstein??? feel to it. The document would be much > better for a > > > rewrite, but that would be significant work, and would delay > publication > > > further. The material in the document is good, and the advice is > valuable, so > > > the focus should be on publishing it sooner rather than later, and > thus the > > > issues with structure are probably best overlooked. > > > > > > An example of the historical evolution of the document are the > instances where > > > the same topic os covered multiple times. This would ideally be > avoided. > > > > > > The section most in need of attention is 2.1, where many aspects of > addressing > > > are weaved together: allocations, assignments, assignment to hosts, > ULAs, > > > stable and temporary addresses, etc. This might be better presented > as a > > > section listing addressing related security issues, such as privacy > for users, > > > first hop security, network manageability, implications of > multi-addressed > > > hosts, address accountability (which isn???t mentioned here?), avoidi= ng > > > renumbering (if that is security?), etc. > > > > > > There are also some sections which summarise recommendations, or > reinforce > > > them, and others that do not. For a document of over 50 pages, which > is quite > > > a long read, it would be desirable to have a summary of the key > > > recommendations, either at the end of each 2nd level topic, or as a > standalone > > > section at the end of the document where the key points of each 2nd > level topic > > > are summarised. > > > > > > Is it worth citing examples of security toolkits readers can explore, > like the > > > THC kit, SI6 Networks, etc, maybe Scapy? > > > > > > Specific comments: > > > > > > p.3 > > > I don???t understand why NPTv6 is mentioned here, this early. Just > say that some > > > security issues have IPv4 equivalents, like ND attacks and ARP > attacks, and > > > some do not, like IPv6 EHs or hop by hop DoS. The NAT discussion > should be in > > > a standalone section, and be neutral there. > > > > > > p.4 > > > Why mention the specific example of multi-homed networks? What do > you mean by > > > the exception? Is it that multi-homing is out of scope, and so are > unmanaged > > > networks? > > > > > > p.4 > > > Again, NPTv6 is mentioned. This section is titled ???addressing > architecture??? > > > but this bit of text is about reasons for going PA, PI, or becoming a= n > LIR, > > > which is not architecture. > > > > > > p.4 > > > In the 7934 para, RFC8981 should be mentioned as it???s a significant > reason of > > > devices having more addresses. > > > > > > p.5 > > > ULAs are also useful where the prefix changes, for stable internal > addressing > > > as the global prefix changes? Typically in residential networks. > > > > > > p.5 > > > Section 2.1.4 is really about choices in address assignment within a > network. > > > > > > p.6 > > > Some of these paras should be in a section about IPv6 network > reconnaissance, > > > how to best mitigate against scanning, and how to inventory your own > network > > > elements. > > > > > > p.6 > > > All mentions of 4941 should be replaced with 8981. > > > > > > p.7 > > > Can use 7721 and 8981 together. > > > > > > p.7 > > > Why are DHCP and DNS limped together? The DNS is only about DNSSEC, > so call it > > > that? > > > > > > p.7 > > > ???Even if the use of DHCP??? - this reads badly. Rather 8504 talks > about this in > > > 6.5, where RFC7844 is mentioned for example. This should be in a use= r > privacy > > > section (if this document had one). Section 8.4 is also useful advic= e. > > > > > > p.8 > > > The first para is very muddled. > > > > > > p.8 > > > In 2.1.7 this can also be useful for ACL controls, if one admin / > control > > > system sits in a prefix of its own. > > > > > > p.10 > > > This is really about handling of fragmented packets (the topic) not t= he > > > fragment header itself Also this is covered in 2.3.2.1 as well. > > > > > > p.10 > > > In 2.2, the intro can say these issues have parallels in IPv4. > > > > > > p.11 > > > First line, say the attack can typically happen from a large address > scan if > > > permitted into the network? > > > > > > p.11 > > > Bullet 1 - that contradicts the comments on predictable addressing. > > > Bullet 2 - how? Some clues here would be useful. > > > > > > p.12 > > > ???Current??? - really? All current implementations? Delete > ???current??? or replace > > > with ???naive??? maybe. > > > > > > p.12 > > > ???Communicate directly??? - at L2? If so, why? > > > > > > p.12 > > > An example of a recommendations section here, where other sections > with advice > > > are not titled as such. See the General comment on this. > > > > > > p.13 > > > ???Trivial??? cases - aren???t these common ones, like edge switches > in an enterprise? > > > > > > p.13 > > > Why ???hostile???? Delete? > > > > > > p.14 > > > In 2.3.5 last para, what about mDNS, Bonjour? Though the DNS SD wor= k > is now > > > on unicast discovery. > > > > > > p.21 > > > Maybe add here 802.1x as an example of the value of RADIUS logs, and > add in > > > here as bullets info harvested from switches and (say) router NDP > syslog > > > (though that???s I suppose the 4th bullet). These are mentioned in > 2.6.1.7 but > > > should be split out at the same level as the other topics here. > > > > > > p.28 > > > The text is 2.6.2.2 repeats earlier text. > > > Similarly text in 2.6.2.3 is repeated form before. > > > > > > p.29 > > > In 2.6.2.4 presumably also a rapid growth in ND cache size is an > indicator. > > > > > > p.29 > > > In 2.7 point to RFC 4942 > > > > > > p.30 > > > Should RFC 6092 be mentioned here? > > > And that the best defence against IPv6 attacks n ???IPv4 only??? > networks is to > > > deploy and manage IPv6? > > > > > > p.31 > > > First bullet on this page - but isn???t this the same as if the > traffic is not > > > tunnelled? Why does tunnelling add the requirement? The same applie= s > on the > > > first para on p.32 > > > > > > p.31 > > > Maybe say here the mitigations can also break tunnel brokers (might b= e > desired, > > > but users will notice???)???. Maybe tunnels to specific brokers can b= e > allowed. > > > > > > p.32 > > > ISATAP, in 2021? Same with 6rd. General advice should be deploy > native, avoid > > > tunnels. > > > > > > p.33 > > > Same for 6to4. > > > > > > p.34 > > > Teredo though, is that still included in Windows and XBoX, as a MS > thing? > > > > > > p.36 > > > Maybe cite Geoff Huston???s blog on this - it???s very good. Maybe > there???s a more > > > recent update though - > > > https://blog.apnic.net/2016/06/09/lets-talk-ipv6-dns64-dnssec/. Host > CLAT is > > > applicable here? (Hence a site should support the 64PREF RA option? > RFC8781 > > > > > > p.38 > > > In 2.8, to be fair IPv4 is also hardened a lot of late due to the > prevalence of > > > use of devices in WiFi hotspots etc. > > > > > > p.37 > > > Also RFC6092 on section 3.1? > > > > > > p.38 > > > ???Where RFC1918 address are often used??? - add ???often???, the tex= t > implies all > > > enterprises use v4 NAT. > > > > > > p.41 > > > Only 2 normative references? > > > > > > Nits: > > > > > > p.1 > > > ???The Internet??? - you probably mean ???an ISP network??? > > > ???Describes the security??? - delete ???the??? > > > > > > p.4 > > > ???Which are the switch??? delete ???which are??? > > > > > > p.8 > > > Varying -> various > > > > > > p.10 > > > ipv6 -> IPv6 > > > > > > p.18 > > > Router processor - add r to ???route??? > > > > > > ??? > > > Tim > > > > > > > > > _______________________________________________ > > > OPSEC mailing list > > > OPSEC@ietf.org > > > https://www.ietf.org/mailman/listinfo/opsec > > > > -- > > Enno Rey > > > > Cell: +49 173 6745902 > > Twitter: @Enno_Insinuator > > > > > > -- > > The computing scientist=E2=80=99s main challenge is not to get confused= by the > > complexities of his own making. > > -- E. W. Dijkstra > > --=20 The computing scientist=E2=80=99s main challenge is not to get confused by = the complexities of his own making. -- E. W. Dijkstra --0000000000009ada6e05c07d898f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Apr 21, 2021 at 9:41 AM Tim = Chown <Tim.Chown@jisc.ac.uk&= gt; wrote:
Hi,
I=E2=80=99ve not yet seen any comments as proposed by Warren, and the revie= w is due (the deadline was a shorter than usual one).=C2=A0 I can go ahead = and look to determine the changes from the diff view.

A fairly main point was whether any summary recommendations would be added,= given the document=E2=80=99s length, and the variation in style through th= e document, with some sections having recommendations subsections, others n= ot.=C2=A0 There is a lot of good advice in the text, but it=E2=80=99s a lon= g read as is, and there=E2=80=99s likely a couple of pages of key bullet po= ints that could be added.

When is the draft coming back to the IESG?

<= div>
A= ctually, it is on tomorrow's telechat. Do you think that this is import= ant enough to hold the document?=C2=A0 Keeping in mind that the document ha= s been many years in the making...

W

=C2=A0
=

Tim

> On 13 Apr 2021, at 21:59, Warren Kumari <warren@kumari.net> wrote:
>
> Just a quick note to say thanks to Tim for the excellent and detailed = review, and to the authors for addressing it...
>
> I took a quick skim through the diffs, and it was a little tricky for = me to tel which all of the comments had been addressed -- authors, if you g= et a chance, could you reply noting which comments were folded into -26? > W
>
> On Sat, Apr 10, 2021 at 2:46 PM Enno Rey <erey@ernw.de> wrote:
> Hi Tim,
>
> thanks so much for another detailed look at the draft.
> Your feeling that it has been in the making for a while is correct (te= ll me about it ;-), still we think that the operational security guidance f= or IPv6 hasn't change much over time, and it might even be more needed = than ever (given current momentum of IPv6 uptake).
> I went through your below points, and for many of them I've perfor= med according clarifications/enhancements of the draft. A new version has t= hen been uploaded.
>
> Wish you a great weekend
>
> Enno
>
>
>
>
> On Wed, Apr 07, 2021 at 02:12:37AM -0700, Tim Chown via Datatracker wr= ote:
> > Reviewer: Tim Chown
> > Review result: Has Issues
> >
> > Hi,
> >
> > I have reviewed this document (draft-ietf-opsec-v6-25) as part of= the
> > Operational directorate's ongoing effort to review all IETF d= ocuments being
> > processed by the IESG.?? These comments were written with the int= ent of
> > improving the operational aspects of the IETF drafts. Comments th= at are not
> > addressed in last call may be included in AD reviews during the I= ESG review.??
> > Document editors and WG chairs should treat these comments just l= ike any other
> > last call comments.
> >
> > This draft analyses operational security issues related to the de= ployment of
> > IPv6, and describes appropriate mechanisms and practices to mitig= ate potential
> > threats.
> >
> > I had previously reviewed the draft as an OPS-DIR Early Review in= July 2018,
> > and again since then, so am familiar with the document and its hi= story.
> >
> > General comments:
> >
> > The document has evolved over time with many topics added, and ha= s an
> > inevitable ???Frankenstein??? feel to it.=C2=A0 The document woul= d be much better for a
> > rewrite, but that would be significant work, and would delay publ= ication
> > further.=C2=A0 The material in the document is good, and the advi= ce is valuable, so
> > the focus should be on publishing it sooner rather than later, an= d thus the
> > issues with structure are probably best overlooked.
> >
> > An example of the historical evolution of the document are the in= stances where
> > the same topic os covered multiple times.=C2=A0 This would ideall= y be avoided.
> >
> > The section most in need of attention is 2.1, where many aspects = of addressing
> > are weaved together: allocations, assignments, assignment to host= s, ULAs,
> > stable and temporary addresses, etc.=C2=A0 This might be better p= resented as a
> > section listing addressing related security issues, such as priva= cy for users,
> > first hop security, network manageability, implications of multi-= addressed
> > hosts, address accountability (which isn???t mentioned here?), av= oiding
> > renumbering (if that is security?), etc.
> >
> > There are also some sections which summarise recommendations, or = reinforce
> > them, and others that do not.=C2=A0 For a document of over 50 pag= es, which is quite
> > a long read, it would be desirable to have a summary of the key > > recommendations, either at the end of each 2nd level topic, or as= a standalone
> > section at the end of the document where the key points of each 2= nd level topic
> > are summarised.
> >
> > Is it worth citing examples of security toolkits readers can expl= ore, like the
> > THC kit, SI6 Networks, etc, maybe Scapy?
> >
> > Specific comments:
> >
> > p.3
> > I don???t understand why NPTv6 is mentioned here, this early.=C2= =A0 Just say that some
> > security issues have IPv4 equivalents, like ND attacks and ARP at= tacks, and
> > some do not, like IPv6 EHs or hop by hop DoS.=C2=A0 =C2=A0The NAT= discussion should be in
> > a standalone section, and be neutral there.
> >
> > p.4
> > Why mention the specific example of multi-homed networks?=C2=A0 = =C2=A0What do you mean by
> > the exception?=C2=A0 Is it that multi-homing is out of scope, and= so are unmanaged
> > networks?
> >
> > p.4
> > Again, NPTv6 is mentioned.=C2=A0 This section is titled ???addres= sing architecture???
> > but this bit of text is about reasons for going PA, PI, or becomi= ng an LIR,
> > which is not architecture.
> >
> > p.4
> > In the 7934 para, RFC8981 should be mentioned as it???s a signifi= cant reason of
> > devices having more addresses.
> >
> > p.5
> > ULAs are also useful where the prefix changes, for stable interna= l addressing
> > as the global prefix changes?=C2=A0 Typically in residential netw= orks.
> >
> > p.5
> > Section 2.1.4 is really about choices in address assignment withi= n a network.
> >
> > p.6
> > Some of these paras should be in a section about IPv6 network rec= onnaissance,
> > how to best mitigate against scanning, and how to inventory your = own network
> > elements.
> >
> > p.6
> > All mentions of 4941 should be replaced with 8981.
> >
> > p.7
> > Can use 7721 and 8981 together.
> >
> > p.7
> > Why are DHCP and DNS limped together?=C2=A0 The DNS is only about= DNSSEC, so call it
> > that?
> >
> > p.7
> > ???Even if the use of DHCP??? - this reads badly.=C2=A0 Rather 85= 04 talks about this in
> > 6.5, where RFC7844 is mentioned for example.=C2=A0 This should be= in a user privacy
> > section (if this document had one).=C2=A0 Section 8.4 is also use= ful advice.
> >
> > p.8
> > The first para is very muddled.
> >
> > p.8
> > In 2.1.7 this can also be useful for ACL controls, if one admin /= control
> > system sits in a prefix of its own.
> >
> > p.10
> > This is really about handling of fragmented packets (the topic) n= ot the
> > fragment header itself Also this is covered in 2.3.2.1 as well. > >
> > p.10
> > In 2.2, the intro can say these issues have parallels in IPv4. > >
> > p.11
> > First line, say the attack can typically happen from a large addr= ess scan if
> > permitted into the network?
> >
> > p.11
> > Bullet 1 - that contradicts the comments on predictable addressin= g.
> > Bullet 2 - how?=C2=A0 Some clues here would be useful.
> >
> > p.12
> > ???Current??? - really? All current implementations?=C2=A0 Delete= ???current??? or replace
> > with ???naive??? maybe.
> >
> > p.12
> > ???Communicate directly??? - at L2?=C2=A0 If so, why?
> >
> > p.12
> > An example of a recommendations section here, where other section= s with advice
> > are not titled as such. See the General comment on this.
> >
> > p.13
> > ???Trivial??? cases - aren???t these common ones, like edge switc= hes in an enterprise?
> >
> > p.13
> > Why ???hostile????=C2=A0 Delete?
> >
> > p.14
> > In 2.3.5 last para, what about mDNS, Bonjour?=C2=A0 =C2=A0Though = the DNS SD work is now
> > on unicast discovery.
> >
> > p.21
> > Maybe add here 802.1x as an example of the value of RADIUS logs, = and add in
> > here as bullets info harvested from switches and (say) router NDP= syslog
> > (though that???s I suppose the 4th bullet).=C2=A0 These are menti= oned in 2.6.1.7 but
> > should be split out at the same level as the other topics here. > >
> > p.28
> > The text is 2.6.2.2 repeats earlier text.
> > Similarly text in 2.6.2.3 is repeated form before.
> >
> > p.29
> > In 2.6.2.4 presumably also a rapid growth in ND cache size is an = indicator.
> >
> > p.29
> > In 2.7 point to RFC 4942
> >
> > p.30
> > Should RFC 6092 be mentioned here?
> > And that the best defence against IPv6 attacks n ???IPv4 only??? = networks is to
> > deploy and manage IPv6?
> >
> > p.31
> > First bullet on this page - but isn???t this the same as if the t= raffic is not
> > tunnelled?=C2=A0 Why does tunnelling add the requirement?=C2=A0 T= he same applies on the
> > first para on p.32
> >
> > p.31
> > Maybe say here the mitigations can also break tunnel brokers (mig= ht be desired,
> > but users will notice???)???. Maybe tunnels to specific brokers c= an be allowed.
> >
> > p.32
> > ISATAP, in 2021?=C2=A0 Same with 6rd.=C2=A0 General advice should= be deploy native, avoid
> > tunnels.
> >
> > p.33
> > Same for 6to4.
> >
> > p.34
> > Teredo though, is that still included in Windows and XBoX, as a M= S thing?
> >
> > p.36
> > Maybe cite Geoff Huston???s blog on this - it???s very good.=C2= =A0 Maybe there???s a more
> > recent update though -
> > https://blog.apnic.net/2016/= 06/09/lets-talk-ipv6-dns64-dnssec/. Host CLAT is
> > applicable here?=C2=A0 (Hence a site should support the 64PREF RA= option?=C2=A0 RFC8781
> >
> > p.38
> > In 2.8, to be fair IPv4 is also hardened a lot of late due to the= prevalence of
> > use of devices in WiFi hotspots etc.
> >
> > p.37
> > Also RFC6092 on section 3.1?
> >
> > p.38
> > ???Where RFC1918 address are often used??? - add ???often???, the= text implies all
> > enterprises use v4 NAT.
> >
> > p.41
> > Only 2 normative references?
> >
> > Nits:
> >
> > p.1
> > ???The Internet??? - you probably mean ???an ISP network???
> > ???Describes the security??? - delete ???the???
> >
> > p.4
> > ???Which are the switch??? delete ???which are???
> >
> > p.8
> > Varying -> various
> >
> > p.10
> > ipv6 -> IPv6
> >
> > p.18
> > Router processor - add r to ???route???
> >
> > ???
> > Tim
> >
> >
> > _______________________________________________
> > OPSEC mailing list
> > OPSEC@ietf.or= g
> > https://www.ietf.org/mailman/listinfo/opsec=
>
> --
> Enno Rey
>
> Cell: +49 173 6745902
> Twitter: @Enno_Insinuator
>
>
> --
> The computing scientist=E2=80=99s main challenge is not to get confuse= d by the
> complexities of his own making.
>=C2=A0 =C2=A0-- E. W. Dijkstra



--
The computing scientist=E2=80= =99s main challenge is not to get confused by the
complexities of his ow= n making.
=C2=A0 -- E. W. Dijkstra
--0000000000009ada6e05c07d898f-- From nobody Wed Apr 21 09:36:46 2021 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77433A2E90; Wed, 21 Apr 2021 09:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrNyP3geOvkg; Wed, 21 Apr 2021 09:36:38 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140048.outbound.protection.outlook.com [40.107.14.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 114893A2EE3; Wed, 21 Apr 2021 09:36:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b+jbFBwe0vYVBFTvCYjZ7D0BSUTfmDuORKzznFgGFVtdAOFA9SOwQIrV/W6T+OB58Bg0qPUPThUAUTiiVYGBPTcI07HAq50Bf7zOd/jWREp6HInwBPWpk4BtV+IScRlUegFiwiDzne4N8lzcNHUK4ZHG1CbQ8SOmnfaUADMM1HeLXPOy6oAAVAD9q79pXRCnCSXAVezPQEl81pya9teUyNjIRO+qHYSJctrw0B2QDv6IRY1MXO3SeVf7EFeDU6NRGAsKSUTnrmcyp1EinmYQDuKiGTOb1TJF+7ff90HG3tqCh8rt6LV0n+C0faMYMgkEfpHgebIMt7/VmmYMLGMvPQ== 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=Rdjk3quQGfmd5dLY1GqrjS4g0oMp3iRkj8YZVXFoyCY=; b=OdI1QlnMom+dRhPvns67oHLVf8XI126oX9zm9984c9J3ltQwCXccXGNKZQdtCEZOZWuLsUnxFV1byQ5lY69+Lq59oRwwSE76oivc0s2gvn/n/Cx2mrT+57M7N7lFIMquzxuoUmRHFPXaWqtoLocY+WxVQebmdTKXQkIw9C4dMAtWbbbPGKazK3ELVVKvm3iHAb2IFjReYrg0zH2i0lKGFVb20PEFupqiYefSG3Aonz+0/4kqk00oqpQxiACwMo64eX897713h02nt30R1yrgmQ9eXsEKOKvFyXFfDw7HXGFO1ayRrTJO3w38J7IDBc373BTlNxYha6e42V9w4/pVGw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jisc.ac.uk; dmarc=pass action=none header.from=jisc.ac.uk; dkim=pass header.d=jisc.ac.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Rdjk3quQGfmd5dLY1GqrjS4g0oMp3iRkj8YZVXFoyCY=; b=kj354YK/ctwIVLqjQOqBO0JLOl4BGC+lPmHgTCdqvljGUDJjeg1MaQjEMEPMN9QrhNbAkW9+Kj2SUXmKBuevRPfXFRpkWZWfxeCdhLuJT3Cww29B53AXLTENo5VI2tc06+ygVfF5crVh1TOJuCato93dVb+29sZeAlHpaKMxpJU= Received: from DB9PR07MB7771.eurprd07.prod.outlook.com (2603:10a6:10:2a6::15) by DB7PR07MB4459.eurprd07.prod.outlook.com (2603:10a6:5:31::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.6; Wed, 21 Apr 2021 16:36:27 +0000 Received: from DB9PR07MB7771.eurprd07.prod.outlook.com ([fe80::6011:1efb:4348:f34f]) by DB9PR07MB7771.eurprd07.prod.outlook.com ([fe80::6011:1efb:4348:f34f%5]) with mapi id 15.20.4065.020; Wed, 21 Apr 2021 16:36:27 +0000 From: Tim Chown To: Warren Kumari CC: Enno Rey , ops-dir , "last-call@ietf.org" , opsec wg mailing list , "draft-ietf-opsec-v6.all@ietf.org" Thread-Topic: [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-25 Thread-Index: AQHXLjnDyQdRJCPbVUCT8CaQwzD7p6qy81iAgAwYLgCAACRFgIAADLSA Date: Wed, 21 Apr 2021 16:36:27 +0000 Message-ID: References: <161778675730.8077.2835666586607648895@ietfa.amsl.com> <20210410184555.GE91991@ernw.de> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3654.60.0.2.21) authentication-results: kumari.net; dkim=none (message not signed) header.d=none;kumari.net; dmarc=none action=none header.from=jisc.ac.uk; x-originating-ip: [2001:a88:d510:1101:d4e9:7dc6:5af9:ea6e] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 396f6ca1-e3a4-48d2-8542-08d904e39c6a x-ms-traffictypediagnostic: DB7PR07MB4459: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HpUxvUwfjWPex0h59va6JqZAiZtkkMfhzEdWuNOL8jYymkKoRiCwgAjeU2qclPfnFfV4Fh4u/X+vV9bwnH0bGGchLt7d2OQI6RQyrK5UhqUazkFFKw86T4Mm2bRAjZI+0NIBaFsUHqTFFbR+QjzVTIP8L37UPM8OWsyxN2vuQ5cEXOXPOzuNmabhFRGlkU+7LTNip440Ec5tX/38fdZSgf6Zuz5k1A/pP0aPmJkDl+6WmBvnD5icfmSJKh3iic+om3PWNDlIUiuYwBqeSINrOsNs0Zy2/nfvZBNZF4sZZxPGiz0u62jAhTqC5vTZ2YX7tOaRIqQN07W8Dj3lY6OfgbZFdtcGtNEpKxi0EPOIohp5OXNVBTmFLt/tX5TMoAaHXbDlPTjqgsgoYUzPWlTuvYtrsR509Tguy9NzLwI30Z2QRdirr5RARshF8FDa7ABifPE1XOAK4QMuCYgwyKNl/ow4LsCo2PSJALO6OsBcJ4iS0v9pl8AvGyONzSpAO063dY8KhuHmmMOwZEHGiFT4TxLiVwnahBNjtkEk3VeJZvCIQkoaLV3rQmbnA3lKGQgLXCHBLc1EEr2HVuOS7cmJdhKsfWhVJwLvZ/aONY/HU6pc7feA49c98nwmyKrKFSVLCoQzspFqnGv4cY+em4TjqQ71pn4qTKbmQ7bUOOuQNX4= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB9PR07MB7771.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39840400004)(346002)(136003)(396003)(366004)(376002)(6506007)(4326008)(786003)(71200400001)(8676002)(4744005)(54906003)(38100700002)(2906002)(316002)(122000001)(8936002)(6916009)(478600001)(2616005)(53546011)(33656002)(91956017)(76116006)(64756008)(66556008)(6512007)(66476007)(66946007)(186003)(66446008)(86362001)(36756003)(5660300002)(6486002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?UWlCYnU4aXNVTldGUkt0ZGtQUjZoMWFZSEJNM3BLZ29IaWk4MHdQdEJuTHBP?= =?utf-8?B?bFNybktkU3p2Z0c0aFFiMkY0aUlNYXRWRWxxZVNaRTVjQjJzMUtWV0s4ZTls?= =?utf-8?B?MkJ2eld2Z1ZweFp4SUhreDhqRXdCMmY0czRSQjdTSmJzMmpBWjhVLy9DczJE?= =?utf-8?B?YzNORmhHYzg5eTNDaUh5NHR2UEZnZUI1akxjUThhdTdweUpWQ1RwNmJsQW5r?= =?utf-8?B?MlMyT1ViWWtHcWhxL3V3cUZKZVlZRDlyRnFCZXdud0EySkRYZFFGRExIbnNk?= =?utf-8?B?VzViYXk3aUxkaGMrdHdLSzdOam81ZzNIdVNNQ1VzM2Q0eGhsTUVHeThKOFFx?= =?utf-8?B?U1MwNDhseVFwZXpTS1BMQTYwemYwL01XbE10TWNtZjhGaS9KUnBTeTFpY2ZK?= =?utf-8?B?TzFCOFpkVmxaSTQ2WWwxVStodGpQWGp5SHFLWDdWMUNNQ3FtN2N6S3N5UE5G?= =?utf-8?B?OCt0R1lNeWNaR2ViYjdJWC9YM0pqQTN4WU9lTE5QN0N5dGRpeEdZK1hSVC9o?= =?utf-8?B?d0dmbENwb29wTWhRbUcxTXU4QUFIWEJDRTFuOVg2U3pUNU05ZjdnWXBYaEo4?= =?utf-8?B?b1pBWlMyQm8xd0lBaGxqRENuU0JLek9ESWkvVTBIOHZkOGFrbFNMYzJLc3BW?= =?utf-8?B?V1hHRGFNSWdRQXdTc1EwOWtXR01sdEY3QWdtV1dzQkhwTDNDamZuQmhHNXJn?= =?utf-8?B?bllLK0NJYXZzOGtmQUlMZ21qK29QVzlMTUgvei9NU0hmc2FyblFzY2JFRU9J?= =?utf-8?B?Y0FiSXhCY1FBZjJ0QllML3hiYVNqZ3RKWE1kR2E4aklMWHRDdk8yb0Z5cjJF?= =?utf-8?B?bnEzKzBGZFptOCtBcDljUW5aR3lBeC9NaGEvRGRUQkpndkkvbjI5R2dvLzBR?= =?utf-8?B?TVQyVjBSMmFhN2puL1pmbDI0Y213Z00ySk5YMUh5ZTY2SndTZkh2SmdMMk4z?= =?utf-8?B?MnNwR3hzSWo4RzdwMHgwQ1g2VTVET2dMWmVSUzViNllUMU5wbVBHWjhSbXZi?= =?utf-8?B?cUtQeHZrdnR5bzlIZE9WNmY2UGczU0hMSVAxbFFBcU4xaW1ZemsxdXRQSGNa?= =?utf-8?B?NFUxSEFmSlNjRmdpOXA0UkRzNlQ3RHJvL3ZWL2N6c0J3QTdVYmlnMFJBa2R4?= =?utf-8?B?cU42YnJXbVlWRnU0MTZLNEFjNzZHSm9wTGF0M0I1Vng2eTBaS2VrcmdsUi9n?= =?utf-8?B?WWR5UnB6NXpNam5YeWcvbUdFWWdnOERWdEJVUU13YUlWOElmT1d0Zm40b29y?= =?utf-8?B?UlNMR1lUcEhMbkNXSlN1SENyeWplMHZDdVRjb3gzMmE1UEhjQ1djWmNMaENI?= =?utf-8?B?dlZlM0R5N3FUWDRQdFlqMnA5M29PVE5aQ0U2T1hHRHp3a0djbXdqeFBnM2ho?= =?utf-8?B?SUU3RmJLNkxvcWtzL1JmUjRqdEdVRUJHTXlBUHF6a29xei96OXgvTFRsK3lS?= =?utf-8?B?YlJDcGdrdHFaMzJBWGNvMGlpMFk1WWVrbXBHZ0V5U0ZLdGQ4NWdEaGZrNFVF?= =?utf-8?B?STdpZ2NuVFBlYzBrTXZWbmhabHJiNWNnSkd1UExLaWQ2aXgvT0l6WGg0dG05?= =?utf-8?B?UHZFaFlSZzNCMHR3R0dlWncvWkhKNUtHczBGcWZzMm9PT2o0UmhKQVRjYXcv?= =?utf-8?B?WUpBQW44ck81L0lIcjdzaWJadU1oSnZ6clFrUzJGbGtLT2I1MHQxQzZrajNZ?= =?utf-8?B?WjM0VWxsaUVHK3BLM0Y0ZW5UT3FkODVXN0tRaWM3RlUwKzlaZXNIUVB3cnhH?= =?utf-8?B?T1lwSE01RXZ2dmg3NHJsOE9qTWpoY1gvdG5wT3pJTXFNRkZkNjM5aDhTWStR?= =?utf-8?B?RXVFV1BzeGUrUUlCRC8rdDhvazNtK21MYnN6dHNHcytrSGpIUmd1dHE2cmNM?= =?utf-8?B?aUQrK2JLcEhUWXNRNXN2RVN1SGM0b241VVl1NnE5YytyRGc9PQ==?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <3CAECA64C0DAC54CA168009FA6F7555F@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB9PR07MB7771.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 396f6ca1-e3a4-48d2-8542-08d904e39c6a X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2021 16:36:27.7133 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yJg13YcU05HnO+YsthNQf9ROuBQCB/RlF1UGgcG44NL9UbCwwNovVeqMEQNYaGd2CPgBEYFuCyGudqyQPnAeHg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4459 Archived-At: Subject: Re: [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-25 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2021 16:36:44 -0000 PiBPbiAyMSBBcHIgMjAyMSwgYXQgMTY6NTAsIFdhcnJlbiBLdW1hcmkgPHdhcnJlbkBrdW1hcmku bmV0PiB3cm90ZToNCj4gDQo+IEFjdHVhbGx5LCBpdCBpcyBvbiB0b21vcnJvdydzIHRlbGVjaGF0 LiBEbyB5b3UgdGhpbmsgdGhhdCB0aGlzIGlzIGltcG9ydGFudCBlbm91Z2ggdG8gaG9sZCB0aGUg ZG9jdW1lbnQ/ICBLZWVwaW5nIGluIG1pbmQgdGhhdCB0aGUgZG9jdW1lbnQgaGFzIGJlZW4gbWFu eSB5ZWFycyBpbiB0aGUgbWFraW5nLi4uDQoNCkl04oCZcyBvbmUgb2YgdGhvc2Ugd2hlcmUgd2Vy ZSB5b3Ugd3JpdGluZyBpdCBmcm9tIHNjcmF0Y2gsIHlvdeKAmWQgbW9zdCBsaWtlbHkgaW5jbHVk ZSBhIHNob3J0IGtleSByZWNvbW1lbmRhdGlvbnMgc2VjdGlvbi4gIEJ1dCB3aXRoIGl0IGhhdmlu ZyBldm9sdmVkIG92ZXIgbWFueSB5ZWFycywgZXNwZWNpYWxseSBzZWN0aW9uIDIsIGl04oCZcyB1 bmRlcnN0YW5kYWJsZSB0aGF0IGl0IGhhcyBzb21ldGhpbmcgb2YgYSBGcmFua2Vuc3RlaW4gZmVl bC4NCg0KQnV0IHRoZSBhZHZpY2UgdGhhdCBpcyBpbiB0aGVyZSBpcyBnb29kLCBldmVuIHdoZW4g cmVwZWF0ZWQgaW4gYSBmZXcgcGxhY2VzLiAgSXQgd291bGQgZG8gbm8gaGFybSB0byBzaGlwIGl0 LiAgSeKAmW0gc3VyZSB0aGUgYXV0aG9ycyB3b3VsZCBiZSB2ZXJ5IGhhcHB5IHRvIHNlZSBpdCBw dWJsaXNoZWQgOikNCg0KSeKAmWxsIHRyeSB0byBjaGVjayB0aGUgZGlmZnMgdG9uaWdodC4NCg0K VGltDQoNCg0K From nobody Wed Apr 21 11:37:06 2021 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C583A0FC3; Wed, 21 Apr 2021 11:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.918 X-Spam-Level: X-Spam-Status: No, score=-11.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=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=inPKoGv9; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=KswvtUqd Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NI8n4oUfKHyK; Wed, 21 Apr 2021 11:36:59 -0700 (PDT) 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 23F2D3A3260; Wed, 21 Apr 2021 11:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18544; q=dns/txt; s=iport; t=1619030209; x=1620239809; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=UC3eO4WEHgSjPtlgvc/2ScjtOjwBBIufIoWaeyr9p3E=; b=inPKoGv9AmjxEWLwD7NR6lsG5JnUYDVayqf9o/+NRLOjgx8uHkey4sWS ffkp9VQQYgignB1h7EV/4ZObxFtHE1qd844gXiS8zxmXkCJboKO1Lpmd8 rYtss8VNxNsZy7Fm/j8qj63m8l1duuwyFAdGSmFDZyIpqoF72NRAiDSux M=; IronPort-PHdr: =?us-ascii?q?A9a23=3AsVovaR8vQ+5k0f9uWNfoyV9lXQAupqn0MwgJ6?= =?us-ascii?q?5Eul7NJdOG58o//OFDEjd1vjUTCG4zQre9H2KLasKHlDGoH55vJ8HUPa4dFW?= =?us-ascii?q?BJNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YkpUA824blaUv37hpTIXE?= =?us-ascii?q?w/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxnec4M?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AXKROR6uNwCZyV43e1iTuKnND7skCZ4cji2?= =?us-ascii?q?hD6mlwRA09T+WxrOrrtOgH1BPylTYaUGwhn9fFA6WbXXbA7/dOgLU5FYyJGC?= =?us-ascii?q?3ronGhIo0n14vtxDX8Bzbzn9Qy6Y5JSII7MtH5CDFB4vrSyAOzH888hPyO96?= =?us-ascii?q?61jenTpk0dMj1CQYsI1XYfNi+wFEpqSA5aQboVfaDspvZvjTymZHgRc4CfDn?= =?us-ascii?q?4KQ+DMq7Tw5ezbSDQBAAMq7xTLsCih76T0HwPd8hAVVT5OxrlKyxmHryXS4K?= =?us-ascii?q?K/v/anjiLNzmO71eUWpPLN6PtmQPaNhM8cNyn2hm+TBLhJdrWesFkO0ZqSwX?= =?us-ascii?q?kwlt2kmWZEA+1S7DfrcnixsV/R3WDboUoTwlvD7XPdvnf5u8z+Q1sBeoh8rK?= =?us-ascii?q?ZUaAHQ5UZlnPwU6tMw40uju5BaDQzNkU3GjrCiPXwH5ynEw0YKquIdg2dSVo?= =?us-ascii?q?ETctZq3PEi1XlIG5QNFj+S0vFALMBSDdrR7PsTUVSWY2GxhBgW/PWQX28+Fh?= =?us-ascii?q?rDf04ausb96UkuoFlFySIjtagit0ZF0Kh4Z4hP5uzCPKgtvqpJVNUqYaV0A/?= =?us-ascii?q?pEaderC0TWKCi8dV66EBDCLuUqKnjNo5n47PEe/+exYqEFy5M0hdDoTE5Yj2?= =?us-ascii?q?gvYEjjYPf+mKFjw1ToeiGQTD7twsZR69xSobvnXofmNiWFVRQIn9a/pe4cRu?= =?us-ascii?q?nWQey6Np4TI/KLFxqoJa95mynFH7VCI3gXV8MY/vwhXUiVn87NIor28uPBdv?= =?us-ascii?q?LeI6fsDCYkVmvzDmBrZkmrGOxwqmSQHlPoihnYXH3gPmbl+4hrLaTc9+8PjI?= =?us-ascii?q?gBX7c86jQ9uBCc3IWmODdCuqs5cA9VO7X8iJ62omGw4CLN52VtMRxNE1ZN7N?= =?us-ascii?q?zbIih3jD5PF3mxXacIut2Zd2wX9mCAPAVDQ8TfFxMaoU9296KxJ5mZ3jsjFN?= =?us-ascii?q?qjL2KfgxIo1TS3ZqZZvpfGydbue5s+AJpjcrd2Dx/3Gxt8nhsvtH1OcxYeRk?= =?us-ascii?q?jUFirnjKKsiJB8PpCES/BMxCOQZeJEo3PWskuR4fw1TnwARji0TIq8mgA1XQ?= =?us-ascii?q?dZgVV37o4SiLeNgiyUNGM6meg0WWc8NVi/MfZjNkClbJ8Rsq33cAtwJF369A?= =?us-ascii?q?CyulUWQC7W0Gk8wkbmNjaZfPnXBEE1gAEp7o/atHVudmuceEpsbGtdqoMVLx?= =?us-ascii?q?Wbhl9DlcmWe6G0z2ydLnwFz+11CkCaXRIiZiVz2tuwyBmZ3AynKExj7JAvMu?= =?us-ascii?q?vBZY5TLI370m+xKYGOiKENF+JV+pEgL9z1ruoXS4ukCn2oBS/jB/hs0wKYoW?= =?us-ascii?q?tNAlgGlFA01fzvwxHr926+wTo2BufTOk1vQ/UBL8ib9HWMfYfF7LxpydY0t/?= =?us-ascii?q?C3KGP/d5qPzrzWdSdKLnro0CSLZvBtrZBfpqQpsrRvW5HdTDvTzXlCmBEzNt?= =?us-ascii?q?39mk9bQKN15tn6S8JSVt1XfyJS5VwyktuTaEMtrwztG+c7OUg3kGWzBaLB35?= =?us-ascii?q?PY7b40RkGRrgr5PleStyVb4vfeRiOGkboXEbg5L2haYFU1gU4Ss9+qZsnVEk?= =?us-ascii?q?GnZutD9F21PjumfLhRRLOMFL8Qohx5iuv41NO/Zm79wkTdrDF7KqVB/yK7Ws?= =?us-ascii?q?u0GhuLAvMN/NqgO1iA65HarvKbnXPyU3+8ZEsZj4EeKhBVYcRHlzU4jIo4li?= =?us-ascii?q?K1Ubf6p0o5k11YpTFr/2SdrbSO8SPeBwVBNwacn5BdGT9UOXKMhd7e8eeZ2G?= =?us-ascii?q?/miQI1kaXrBQNVZJVWB9MUToLrNC9gJsgboa6w88MU81B+SQZrC3R5lSv00O?= =?us-ascii?q?xn16qowfneW+XtDnHzJFIKkAQ1cLJcj2gssmFPc8+38JK7bEEWD4czco4C2r?= =?us-ascii?q?w=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DLAAC9b4Bg/4oNJK1aDgwBAQEBAQE?= =?us-ascii?q?BAQEBAwEBAQESAQEBAQICAQEBAUCBUoFTKSgHd1o2MQKEQYNIA4U5iE8lA4o?= =?us-ascii?q?yhHqKFYFCgREDVAsBAQENAQEdCwoCBAEBhFACF4FeAiU4EwIDAQEMAQEFAQE?= =?us-ascii?q?BAgEGBHEThVANhkQBAQEDAQEBIQQNDAEBLAsBCwQCAQgRAQIBAgECAiYCAgI?= =?us-ascii?q?fBgsVAgEFCAIEAQ0FgnEBglUDDiEBDj6dTwKKH3p/M4EBggQBAQaBMwGEDA0?= =?us-ascii?q?LghMDBoEQKgGCeIJxgRqCXYFMgionHIFJQoETJwwQgV+BAD6CHkIBAYErARI?= =?us-ascii?q?BKBAjgl02giuBWQEEbD4mAQMiEBEQFA45BRsdTBgFEQEBFxEJAh4Pi2WEV4M?= =?us-ascii?q?aQowDmUAJMFsKgw2Ja4xyeYU8BCGDUD6QWpAglSGCEolfgxmPYQtsg18CAgI?= =?us-ascii?q?CBAUCDgEBBoEjSCNpcHAVOyoBggoBATJQFwIOVo1JgSQBCIJDhFk7hQREAXM?= =?us-ascii?q?NKwIGAQkBAQMJfIlNLIE8XgEB?= X-IronPort-AV: E=Sophos;i="5.82,240,1613433600"; d="scan'208";a="617793145" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Apr 2021 18:36:47 +0000 Received: from mail.cisco.com (xbe-aln-002.cisco.com [173.36.7.17]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 13LIal57011241 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 21 Apr 2021 18:36:47 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xbe-aln-002.cisco.com (173.36.7.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Wed, 21 Apr 2021 13:36:47 -0500 Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 21 Apr 2021 14:36:46 -0400 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Wed, 21 Apr 2021 13:36:46 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LBRe5POsSLX+aIBdO6iC2MceOXivwP4DzjMq8Gnjf/P9CsafkkB92r/pnHR8kEZ3plSySOQu02IH232bVCMkhUmfD1/JvfenCV34bE7BeJfwWAb/VwAcIDl33MojWy/xZxEakG6kXfaaRlR0cmxlAXHjvZzXwMdUtKNyjEcxAz8ndLNycH1XdAj/IOAFOKpa3pxQuuzBcmPB9obr5XG9C72I9V1pCikrg1gVRvhONyGoqq0JcmFfnkR+AeM9zRWwpb/HMxIb7aAErd0SSmQtug30Z7GPF96M5XHj/3Ak6cvQnF5e+M3YF9FLSbI8zKB0ntldEZ15R/4Fzi2YuRxwoA== 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=UC3eO4WEHgSjPtlgvc/2ScjtOjwBBIufIoWaeyr9p3E=; b=Erk6apEswyqPumL1mP2ycwiOVz2txbC8vR7/KZRk27u1Xbh/1ts6NsaW7y24n0GYABdWwSRUwowovhBtX8V1aQPn/Uzz8NUCIVeSDAHebZF7nltpDanZg1498PTkhG6RpX3M5tGd50I5eiyuCMbdDGRP7JkWMuRHI97ZoVSXOT9op2hhGx6nCl/k9b/n3spFlD0bJ2k55sUg+LvUn38yvW4CDr1Tq28Pu9PLKE1HnMQeSeJrHxqv8QoUXrGVbIg1vWSecm0lgOFIAWbAHdrOv2WxWbI9HqCSEYbFQtYVLaGKBBuZIC+S9X/K60KuPrGKoZuKcMEjCJma6ECaEp1rDA== 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=UC3eO4WEHgSjPtlgvc/2ScjtOjwBBIufIoWaeyr9p3E=; b=KswvtUqdNU7/v136Xgk8W/W+3MzMH8eECZmOEAKII6BHjWB04brcSwoXvfp4PwzF0npzzUHFfeGnGoJ/yny5hMvonHpRw6XEtcLExQ6Y9MemCvNDzmWeKbqy8oxkXW+WoEbORa/GMksAfd83XX4zVKk8Gf0wJInOKQeApr9lzpY= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB4902.namprd11.prod.outlook.com (2603:10b6:510:37::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.18; Wed, 21 Apr 2021 18:36:43 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::dcdf:3910:b85d:6eba]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::dcdf:3910:b85d:6eba%7]) with mapi id 15.20.4042.018; Wed, 21 Apr 2021 18:36:43 +0000 From: "Eric Vyncke (evyncke)" To: Tim Chown , Warren Kumari CC: Enno Rey , ops-dir , "last-call@ietf.org" , opsec wg mailing list , "draft-ietf-opsec-v6.all@ietf.org" Thread-Topic: [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-25 Thread-Index: AQHXMKgZj/+7ZqKZcU+tLkkn5Tbgbaq/BqqAgAB0GAA= Date: Wed, 21 Apr 2021 18:36:43 +0000 Message-ID: References: <161778675730.8077.2835666586607648895@ietfa.amsl.com> <20210410184555.GE91991@ernw.de> 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/16.48.21041102 authentication-results: jisc.ac.uk; dkim=none (message not signed) header.d=none;jisc.ac.uk; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2a02:578:8557:600:c5b5:b093:c1de:6ad3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 87919593-9fb4-464c-8a0c-08d904f46959 x-ms-traffictypediagnostic: PH0PR11MB4902: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +oIhSLHIyHnAgIS60v4YIXUqaHGmttU5suKnegQwKiL6kNUF53PnJCva773OwV1UQAnwSDYaBY1Aqxjc9fUqC+eh8ikp5gsIjKvw0urpPpHWCYyuW3B2+6etmTwZUsxojguSayXjgsdJYhOYRQD+OGYJxbhY8AzEpvick86Fkn6qJNdSQA4FA5ezYoqxD06FrAPSeY7J/6XP9BwAroDcFhAMKThd/JnVSt7awAwE+tIXO8liOvtxLfQYqlQ8/u6MVcwCSGwROg1KMWtweQJ28bhMnjKqJDR4/fEv5kg+XZrIylNI30GaZv2ClDJu3zxhFgc9ic+kjScWgoFuSvM9RY6ZXPA11L/Qxdib4V8quIalC3iAZDf1kfUYbcil/MQAaOVggmZGyk/5FdmeJV8lYqgpymZZhSK37UD2fvlLAQeh0sxff6msoAjJSCJyb7MKKXhESX6Vp9ghx1LYeDmkSmG/QS1AuflhyaGYQ+mNymXSfoGKHQ9oPMKcLohS2WjIhGU0UVbAhUBNR9CrPAhvYf1PKTSDAO15g/mWl0AfuLaVbw1rFQzywoLQmIxiYUtq106NrxXKeYrfNspWCNKkz/jZq1KYuZSwcnGmPKFm6TaoZeFtTSv/HnYq1O4IGlHcgNdFTHW88DWkwsJN0wZKGivGxcZ5UV6sSGaf6ONRj8VvHui4dVH/FYSIGe/MEroqrDYH4ISKL6mCHqtrR4dptYbm+DudghlgBMBXmMmkhKT4x5pSAPCnegmVvdVrwqgN x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(366004)(346002)(39860400002)(376002)(396003)(66574015)(122000001)(86362001)(4326008)(71200400001)(8936002)(66476007)(36756003)(2906002)(33656002)(478600001)(38100700002)(966005)(6506007)(53546011)(6512007)(2616005)(83380400001)(66446008)(64756008)(8676002)(76116006)(186003)(6486002)(30864003)(91956017)(54906003)(110136005)(66556008)(5660300002)(316002)(66946007)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?YVlvUVQxT1dhaVplMHlMZnZGNjZRLzM3ZEM5S1BkZnlEQWd0Zi8wSzA5L0xE?= =?utf-8?B?NENjajNrMFJLc1NEQ0FBTVdCc1g1L00yd0IwZjRkdGJ0aUh2UFd0Ny9CZVNK?= =?utf-8?B?eXgwaHJ0L2xaRFl1ejJyZENvWm1tM1RnWmphWGNBaC9rWG14Ym40ek9INmhO?= =?utf-8?B?VUVTVVFJcmtrS3hIUTI1ZE8wQWN5V0NkTC9IRnNLSHR2MGZYSlhQSGNObjdV?= =?utf-8?B?KzBMOGx3d1ZOMENkekFRVFRTWHJ3aHBxVFNRMDJwaWtpeGU4d2lyM1lpTWp0?= =?utf-8?B?TFZmMFg2SFVmYmJnU3M2dW5XTFo5SUJqSUFZaW45RllIMlk1ZnVvQ2dNaDIz?= =?utf-8?B?bVk5bjd3Q04wY3YxbmwvRXJqeDVmRWxvVjdtYVpCcG9Xd1MvcWg2WmJ0ZzJt?= =?utf-8?B?WjVHZWYzcDgyUWVJY2xTK1NaT0NsR0RmbmpOdUlXWjdhZ2ZwQW1RVGhua2lR?= =?utf-8?B?VTNQclJhNHl4NmRFV0tWZWF1MWpuam9BaXFNWU5Hblo1MDE1K0gySjFqT21C?= =?utf-8?B?TkY1OHk5eTNNYVNBRHFwV0oyUmtBcHBjRTVwckl1dVJSODJHZVJDVkxZYnhs?= =?utf-8?B?Ni9idHM3YkN4Vks4dUc2bFN2R0dwK0hrY1pNUkNnWlQvRVdCYkswUEdpQjJp?= =?utf-8?B?MTI3Rk1aSUFTVUZOYUthWTc4UlliR3ZFcnNlRTZHSTMrUVN5MU9nMXRZMEVG?= =?utf-8?B?NGU4Sm90Y2xkMFJoN09lbE9Gd0dZVUx4djNnUUEwc1Z6TTJTcXVkc2kvNDRh?= =?utf-8?B?clJCWWROYS8zOHFld0tzVGo3eWNVU3lwcDl3SjM5Uy9BY09BVU1JcG5jVHRC?= =?utf-8?B?dHVUQ2tYenlicXoyMU9EV1lXRFFrQXpuVjJJOTJzUFlnUjQvdC8xeDM5dHRa?= =?utf-8?B?VkI4Z0xBUlFvK004cmdSc0xlbGozalNsNktUT3pOL0xUQmljb21qcXdybHc5?= =?utf-8?B?d2pWd2o2UW1ZdHVVYXdzMllKQXlCRmh3Ly9EbzJtRHpkb0tPRmpOcS9mWjJG?= =?utf-8?B?aC9PVWk2WHlnR0ZHL1BTZitvbFIyZXNGNjFyWWlpL2VlbjVpd2o2cDZUbTdW?= =?utf-8?B?ZmhPWXlKSUpjOWVTeXJCRGVvNzMzQmtFblduSitvdWFBL0pXR0UvOXJ3akJK?= =?utf-8?B?NWE5VFFIQmRFWWtCeU9pSXMxWWFxSTUxZFBSMElPM21Fd1M5MXhRQUNDc05U?= =?utf-8?B?eFNDa0FRSkZsVFIxaEVvZDlGZnJycTJscGlvenNGSkx5RHhZc21VOHJzNW4v?= =?utf-8?B?eThDYTBVeTRIREdRVlFtZUVhbFVoS1A3QUNSSkthMVhrTFdjQlN6Z016OXNQ?= =?utf-8?B?eTJycG44Q2tta01xMHJzMGM4ZUVkWmV6cHgrTG1IWkxlaEZKZU4vNW1vK2ZL?= =?utf-8?B?d2NtdDBBSGhxS3Q5OWRHU1JSMHhzNlBLbzg4SkhjK3ZwTk5mL1dENFlJcjdo?= =?utf-8?B?ZnJMdkVNalh5STZHbWF5YUFpUWpkcmEzRWJDT1ZGVUloV1c1TWNTRThHckxi?= =?utf-8?B?VkhvTG54TkJlWEdvS0s3VVBmblZMVEkxandyamhjV1FKZUJVUXJZVXRIREFt?= =?utf-8?B?VkFLOHBXdFUwZy9rdmRxRVBUN0Z1TlpjSWovb2lkT3dEWkd5S21OdUphMFU1?= =?utf-8?B?OTV0bXdlUitvZk53V0s1Nm1SMG04QVpyRUZnZGtyOWtiTW1LYU96UnVydFRP?= =?utf-8?B?Ris3MXR1NDR0WmFsbjVVbXZhbTNZVHJBOXZJaDNRMjZkeUZyRTZ3MHVsa1Jh?= =?utf-8?B?azdtbFV5UEVwc1NPRjFjcjFETlE1U3VzUkp4TmZ6TzdzMS9GUUVmSnQ5TEZF?= =?utf-8?B?amtxcWY1OFN1Q0FkSHg2cTFTVElZUUR0aDQxV1AvK2g5cUtteStXVjY4ejht?= =?utf-8?B?Ti81ZXRRWVBYTlJsODhOeDA5TFNMNTZOSGlSNm5QOUoxU0E9PQ==?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <5E9B725364B4404099B790ED7411EC70@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 87919593-9fb4-464c-8a0c-08d904f46959 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2021 18:36:43.4298 (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: 8OEyTPxe2lNtUMckRCVa8ySKu0ZgPlyAafTppV/mP8SaJpvxgdSfpmDmySPMl3WRsENOOnkgz5g1BHL2ps/bzg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4902 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.17, xbe-aln-002.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: Re: [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-25 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2021 18:37:05 -0000 VGltLCBXYXJyZW4sDQoNClJlcGx5aW5nIHdpdGggb25seSB0aGUgYXV0aG9yIGhhdCAoYW5kIGFm dGVyIGNvbnN1bHRhdGlvbiB3aXRoIG15IGNvLWF1dGhvcnMpIG9uIHRoaXMgZW1haWwgYWZ0ZXIg aGF2aW5nIHJlYWQgV2FycmVuJ3MgYW5kIFRpbSdzIHJlcGxpZXMuDQoNClRpbSwgSSBkbyBub3Qg a25vdyB3aGV0aGVyIHlvdSByZW1lbWJlciBhbGwgdGhlIHBhaW5mdWwgam91cm5leSBvZiB0aGlz IGRvY3VtZW50IGJ1dCB0aGUgYXV0aG9ycyBkbyA6LSkgDQoNCmEpIHRoZSBlYXJseSB2ZXJzaW9u cyBvZiB0aGUgSS1EIGluY2x1ZGVkIGEgbG90IG9mICdyZWNvbW1lbmRhdGlvbicgd29yZGluZyBi dXQgdGhlIE9QU0VDIFdHIHJlcXVlc3RlZCB1cyB0byByZW1vdmUgdGhlbSAodGhpcyBpcyBhbHNv IHRoZSByZWFzb24gd2h5IGl0IGlzIG5vdCBhIEJDUCkNCg0KYikgZ2V0dGluZyBhIHN1bW1hcnkg d291bGQgYmUgYSBuaWNlIGlkZWEgYnV0LCBhZ2FpbiwgdG8gcmVhY2ggdGhlIFdHIGNvbnNlbnN1 cywgd2UgaGFkIHRvIG1ha2Ugc29tZSByZWNvbW1lbmRhdGlvbiB3aXRoIHJlc3RyaWN0aW9ucyBh bmQgY2F2ZWF0cyBmb3Igc3BlY2lhbCBjYXNlcyAoZS5nLiwgcmVtZW1iZXIgdGhlIFVMQSwgUkEt Z3VhcmQgIGRpc2N1c3Npb25zID8pLi4uIGhlbmNlLCBJIGRvIG5vdCB0aGluayB0aGF0IHRoaXMg aXMgcG9zc2libHkgdG8gbWFrZSBhIHNob3J0IHN1bW1hcnkgd2l0aG91dCBpbmNsdWRpbmcgdGhl IHJlc3RyaWN0aW9ucy9zcGVjaWZpY3MgLi4uIHNvIHRoZSBzdW1tYXJ5IGxpc3Qgd2lsbCBiZSB2 ZXJ5IHZlcnkgbG9uZyBhbmQgbm90IHZlcnkgdXNlZnVsDQoNCkFsbCB0aGUgb3RoZXIgbGFzdCBj YWxsIGNvbW1lbnRzIGFuZCB0aGUgSUVTRyBDT01NRU5UIHBvaW50cyAgd2lsbCBiZSBhZGRyZXNz ZWQgb25jZSBhbGwgZmVlZGJhY2sgaXMgY29sbGVjdGVkLCAgIGJ5IGVpdGhlciB1cGRhdGluZyB0 aGUgdGV4dCBvciBleHBsYWluaW5nIG91ciBwb2ludHMgb2YgdmlldyBvbiB0aGUgY29tbWVudC4N Cg0KVGhhbmsgeW91IGFnYWluIGZvciB5b3VyIHJldmlldyBhbmQgdGhlIGRpc2N1c3Npb24NCg0K UmVnYXJkcw0KDQotw6lyaWMNCg0K77u/LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IFRpbSBDaG93biA8VGltLkNob3duQGppc2MuYWMudWs+DQpEYXRlOiBXZWRuZXNkYXksIDIxIEFw cmlsIDIwMjEgYXQgMTU6NDENClRvOiBXYXJyZW4gS3VtYXJpIDx3YXJyZW5Aa3VtYXJpLm5ldD4N CkNjOiBFbm5vIFJleSA8ZXJleUBlcm53LmRlPiwgb3BzLWRpciA8b3BzLWRpckBpZXRmLm9yZz4s ICJsYXN0LWNhbGxAaWV0Zi5vcmciIDxsYXN0LWNhbGxAaWV0Zi5vcmc+LCBvcHNlYyB3ZyBtYWls aW5nIGxpc3QgPG9wc2VjQGlldGYub3JnPiwgImRyYWZ0LWlldGYtb3BzZWMtdjYuYWxsQGlldGYu b3JnIiA8ZHJhZnQtaWV0Zi1vcHNlYy12Ni5hbGxAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09Q U0VDXSBPcHNkaXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLW9wc2VjLXY2LTI1DQpS ZXNlbnQtRnJvbTogPGFsaWFzLWJvdW5jZXNAaWV0Zi5vcmc+DQpSZXNlbnQtVG86IEVyaWMgVnlu Y2tlIDxldnluY2tlQGNpc2NvLmNvbT4sIEtpcmFuIEt1bWFyIENoaXR0aW1hbmVuaSA8a2suY2hp dHRpbWFuZW5pQGdtYWlsLmNvbT4sIE1lcmlrZSBLYWVvIDxtZXJpa2VAZG91Ymxlc2hvdHNlY3Vy aXR5LmNvbT4sIDxlcmV5QGVybncuZGU+LCA8ZnVycnkxM0BnbWFpbC5jb20+LCBSb24gQm9uaWNh IDxyYm9uaWNhQGp1bmlwZXIubmV0PiwgPHJ3aWx0b25AY2lzY28uY29tPiwgPHdhcnJlbkBrdW1h cmkubmV0PiwgR3lhbiBNaXNocmEgPGhheWFidXNhZ3NtQGdtYWlsLmNvbT4sIDxoYXlhYnVzYWdz bUBnbWFpbC5jb20+DQpSZXNlbnQtRGF0ZTogV2VkbmVzZGF5LCAyMSBBcHJpbCAyMDIxIGF0IDE1 OjQxDQoNCiAgICBIaSwNCg0KICAgIEnigJl2ZSBub3QgeWV0IHNlZW4gYW55IGNvbW1lbnRzIGFz IHByb3Bvc2VkIGJ5IFdhcnJlbiwgYW5kIHRoZSByZXZpZXcgaXMgZHVlICh0aGUgZGVhZGxpbmUg d2FzIGEgc2hvcnRlciB0aGFuIHVzdWFsIG9uZSkuICBJIGNhbiBnbyBhaGVhZCBhbmQgbG9vayB0 byBkZXRlcm1pbmUgdGhlIGNoYW5nZXMgZnJvbSB0aGUgZGlmZiB2aWV3Lg0KDQogICAgQSBmYWly bHkgbWFpbiBwb2ludCB3YXMgd2hldGhlciBhbnkgc3VtbWFyeSByZWNvbW1lbmRhdGlvbnMgd291 bGQgYmUgYWRkZWQsIGdpdmVuIHRoZSBkb2N1bWVudOKAmXMgbGVuZ3RoLCBhbmQgdGhlIHZhcmlh dGlvbiBpbiBzdHlsZSB0aHJvdWdoIHRoZSBkb2N1bWVudCwgd2l0aCBzb21lIHNlY3Rpb25zIGhh dmluZyByZWNvbW1lbmRhdGlvbnMgc3Vic2VjdGlvbnMsIG90aGVycyBub3QuICBUaGVyZSBpcyBh IGxvdCBvZiBnb29kIGFkdmljZSBpbiB0aGUgdGV4dCwgYnV0IGl04oCZcyBhIGxvbmcgcmVhZCBh cyBpcywgYW5kIHRoZXJl4oCZcyBsaWtlbHkgYSBjb3VwbGUgb2YgcGFnZXMgb2Yga2V5IGJ1bGxl dCBwb2ludHMgdGhhdCBjb3VsZCBiZSBhZGRlZC4NCg0KICAgIFdoZW4gaXMgdGhlIGRyYWZ0IGNv bWluZyBiYWNrIHRvIHRoZSBJRVNHPw0KDQogICAgVGltDQoNCiAgICA+IE9uIDEzIEFwciAyMDIx LCBhdCAyMTo1OSwgV2FycmVuIEt1bWFyaSA8d2FycmVuQGt1bWFyaS5uZXQ+IHdyb3RlOg0KICAg ID4gDQogICAgPiBKdXN0IGEgcXVpY2sgbm90ZSB0byBzYXkgdGhhbmtzIHRvIFRpbSBmb3IgdGhl IGV4Y2VsbGVudCBhbmQgZGV0YWlsZWQgcmV2aWV3LCBhbmQgdG8gdGhlIGF1dGhvcnMgZm9yIGFk ZHJlc3NpbmcgaXQuLi4NCiAgICA+IA0KICAgID4gSSB0b29rIGEgcXVpY2sgc2tpbSB0aHJvdWdo IHRoZSBkaWZmcywgYW5kIGl0IHdhcyBhIGxpdHRsZSB0cmlja3kgZm9yIG1lIHRvIHRlbCB3aGlj aCBhbGwgb2YgdGhlIGNvbW1lbnRzIGhhZCBiZWVuIGFkZHJlc3NlZCAtLSBhdXRob3JzLCBpZiB5 b3UgZ2V0IGEgY2hhbmNlLCBjb3VsZCB5b3UgcmVwbHkgbm90aW5nIHdoaWNoIGNvbW1lbnRzIHdl cmUgZm9sZGVkIGludG8gLTI2Pw0KICAgID4gVw0KICAgID4gDQogICAgPiBPbiBTYXQsIEFwciAx MCwgMjAyMSBhdCAyOjQ2IFBNIEVubm8gUmV5IDxlcmV5QGVybncuZGU+IHdyb3RlOg0KICAgID4g SGkgVGltLA0KICAgID4gDQogICAgPiB0aGFua3Mgc28gbXVjaCBmb3IgYW5vdGhlciBkZXRhaWxl ZCBsb29rIGF0IHRoZSBkcmFmdC4NCiAgICA+IFlvdXIgZmVlbGluZyB0aGF0IGl0IGhhcyBiZWVu IGluIHRoZSBtYWtpbmcgZm9yIGEgd2hpbGUgaXMgY29ycmVjdCAodGVsbCBtZSBhYm91dCBpdCA7 LSksIHN0aWxsIHdlIHRoaW5rIHRoYXQgdGhlIG9wZXJhdGlvbmFsIHNlY3VyaXR5IGd1aWRhbmNl IGZvciBJUHY2IGhhc24ndCBjaGFuZ2UgbXVjaCBvdmVyIHRpbWUsIGFuZCBpdCBtaWdodCBldmVu IGJlIG1vcmUgbmVlZGVkIHRoYW4gZXZlciAoZ2l2ZW4gY3VycmVudCBtb21lbnR1bSBvZiBJUHY2 IHVwdGFrZSkuDQogICAgPiBJIHdlbnQgdGhyb3VnaCB5b3VyIGJlbG93IHBvaW50cywgYW5kIGZv ciBtYW55IG9mIHRoZW0gSSd2ZSBwZXJmb3JtZWQgYWNjb3JkaW5nIGNsYXJpZmljYXRpb25zL2Vu aGFuY2VtZW50cyBvZiB0aGUgZHJhZnQuIEEgbmV3IHZlcnNpb24gaGFzIHRoZW4gYmVlbiB1cGxv YWRlZC4NCiAgICA+IA0KICAgID4gV2lzaCB5b3UgYSBncmVhdCB3ZWVrZW5kDQogICAgPiANCiAg ICA+IEVubm8NCiAgICA+IA0KICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4gT24gV2VkLCBB cHIgMDcsIDIwMjEgYXQgMDI6MTI6MzdBTSAtMDcwMCwgVGltIENob3duIHZpYSBEYXRhdHJhY2tl ciB3cm90ZToNCiAgICA+ID4gUmV2aWV3ZXI6IFRpbSBDaG93bg0KICAgID4gPiBSZXZpZXcgcmVz dWx0OiBIYXMgSXNzdWVzDQogICAgPiA+IA0KICAgID4gPiBIaSwNCiAgICA+ID4gDQogICAgPiA+ IEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IChkcmFmdC1pZXRmLW9wc2VjLXY2LTI1KSBh cyBwYXJ0IG9mIHRoZQ0KICAgID4gPiBPcGVyYXRpb25hbCBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcg ZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcNCiAgICA+ID4gcHJvY2Vz c2VkIGJ5IHRoZSBJRVNHLj8/IFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiB3aXRoIHRoZSBp bnRlbnQgb2YNCiAgICA+ID4gaW1wcm92aW5nIHRoZSBvcGVyYXRpb25hbCBhc3BlY3RzIG9mIHRo ZSBJRVRGIGRyYWZ0cy4gQ29tbWVudHMgdGhhdCBhcmUgbm90DQogICAgPiA+IGFkZHJlc3NlZCBp biBsYXN0IGNhbGwgbWF5IGJlIGluY2x1ZGVkIGluIEFEIHJldmlld3MgZHVyaW5nIHRoZSBJRVNH IHJldmlldy4/Pw0KICAgID4gPiBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxk IHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXINCiAgICA+ID4gbGFzdCBj YWxsIGNvbW1lbnRzLg0KICAgID4gPiANCiAgICA+ID4gVGhpcyBkcmFmdCBhbmFseXNlcyBvcGVy YXRpb25hbCBzZWN1cml0eSBpc3N1ZXMgcmVsYXRlZCB0byB0aGUgZGVwbG95bWVudCBvZg0KICAg ID4gPiBJUHY2LCBhbmQgZGVzY3JpYmVzIGFwcHJvcHJpYXRlIG1lY2hhbmlzbXMgYW5kIHByYWN0 aWNlcyB0byBtaXRpZ2F0ZSBwb3RlbnRpYWwNCiAgICA+ID4gdGhyZWF0cy4NCiAgICA+ID4gDQog ICAgPiA+IEkgaGFkIHByZXZpb3VzbHkgcmV2aWV3ZWQgdGhlIGRyYWZ0IGFzIGFuIE9QUy1ESVIg RWFybHkgUmV2aWV3IGluIEp1bHkgMjAxOCwNCiAgICA+ID4gYW5kIGFnYWluIHNpbmNlIHRoZW4s IHNvIGFtIGZhbWlsaWFyIHdpdGggdGhlIGRvY3VtZW50IGFuZCBpdHMgaGlzdG9yeS4NCiAgICA+ ID4gDQogICAgPiA+IEdlbmVyYWwgY29tbWVudHM6DQogICAgPiA+IA0KICAgID4gPiBUaGUgZG9j dW1lbnQgaGFzIGV2b2x2ZWQgb3ZlciB0aW1lIHdpdGggbWFueSB0b3BpY3MgYWRkZWQsIGFuZCBo YXMgYW4NCiAgICA+ID4gaW5ldml0YWJsZSA/Pz9GcmFua2Vuc3RlaW4/Pz8gZmVlbCB0byBpdC4g IFRoZSBkb2N1bWVudCB3b3VsZCBiZSBtdWNoIGJldHRlciBmb3IgYQ0KICAgID4gPiByZXdyaXRl LCBidXQgdGhhdCB3b3VsZCBiZSBzaWduaWZpY2FudCB3b3JrLCBhbmQgd291bGQgZGVsYXkgcHVi bGljYXRpb24NCiAgICA+ID4gZnVydGhlci4gIFRoZSBtYXRlcmlhbCBpbiB0aGUgZG9jdW1lbnQg aXMgZ29vZCwgYW5kIHRoZSBhZHZpY2UgaXMgdmFsdWFibGUsIHNvDQogICAgPiA+IHRoZSBmb2N1 cyBzaG91bGQgYmUgb24gcHVibGlzaGluZyBpdCBzb29uZXIgcmF0aGVyIHRoYW4gbGF0ZXIsIGFu ZCB0aHVzIHRoZQ0KICAgID4gPiBpc3N1ZXMgd2l0aCBzdHJ1Y3R1cmUgYXJlIHByb2JhYmx5IGJl c3Qgb3Zlcmxvb2tlZC4NCiAgICA+ID4gDQogICAgPiA+IEFuIGV4YW1wbGUgb2YgdGhlIGhpc3Rv cmljYWwgZXZvbHV0aW9uIG9mIHRoZSBkb2N1bWVudCBhcmUgdGhlIGluc3RhbmNlcyB3aGVyZQ0K ICAgID4gPiB0aGUgc2FtZSB0b3BpYyBvcyBjb3ZlcmVkIG11bHRpcGxlIHRpbWVzLiAgVGhpcyB3 b3VsZCBpZGVhbGx5IGJlIGF2b2lkZWQuDQogICAgPiA+IA0KICAgID4gPiBUaGUgc2VjdGlvbiBt b3N0IGluIG5lZWQgb2YgYXR0ZW50aW9uIGlzIDIuMSwgd2hlcmUgbWFueSBhc3BlY3RzIG9mIGFk ZHJlc3NpbmcNCiAgICA+ID4gYXJlIHdlYXZlZCB0b2dldGhlcjogYWxsb2NhdGlvbnMsIGFzc2ln bm1lbnRzLCBhc3NpZ25tZW50IHRvIGhvc3RzLCBVTEFzLA0KICAgID4gPiBzdGFibGUgYW5kIHRl bXBvcmFyeSBhZGRyZXNzZXMsIGV0Yy4gIFRoaXMgbWlnaHQgYmUgYmV0dGVyIHByZXNlbnRlZCBh cyBhDQogICAgPiA+IHNlY3Rpb24gbGlzdGluZyBhZGRyZXNzaW5nIHJlbGF0ZWQgc2VjdXJpdHkg aXNzdWVzLCBzdWNoIGFzIHByaXZhY3kgZm9yIHVzZXJzLA0KICAgID4gPiBmaXJzdCBob3Agc2Vj dXJpdHksIG5ldHdvcmsgbWFuYWdlYWJpbGl0eSwgaW1wbGljYXRpb25zIG9mIG11bHRpLWFkZHJl c3NlZA0KICAgID4gPiBob3N0cywgYWRkcmVzcyBhY2NvdW50YWJpbGl0eSAod2hpY2ggaXNuPz8/ dCBtZW50aW9uZWQgaGVyZT8pLCBhdm9pZGluZw0KICAgID4gPiByZW51bWJlcmluZyAoaWYgdGhh dCBpcyBzZWN1cml0eT8pLCBldGMuDQogICAgPiA+IA0KICAgID4gPiBUaGVyZSBhcmUgYWxzbyBz b21lIHNlY3Rpb25zIHdoaWNoIHN1bW1hcmlzZSByZWNvbW1lbmRhdGlvbnMsIG9yIHJlaW5mb3Jj ZQ0KICAgID4gPiB0aGVtLCBhbmQgb3RoZXJzIHRoYXQgZG8gbm90LiAgRm9yIGEgZG9jdW1lbnQg b2Ygb3ZlciA1MCBwYWdlcywgd2hpY2ggaXMgcXVpdGUNCiAgICA+ID4gYSBsb25nIHJlYWQsIGl0 IHdvdWxkIGJlIGRlc2lyYWJsZSB0byBoYXZlIGEgc3VtbWFyeSBvZiB0aGUga2V5DQogICAgPiA+ IHJlY29tbWVuZGF0aW9ucywgZWl0aGVyIGF0IHRoZSBlbmQgb2YgZWFjaCAybmQgbGV2ZWwgdG9w aWMsIG9yIGFzIGEgc3RhbmRhbG9uZQ0KICAgID4gPiBzZWN0aW9uIGF0IHRoZSBlbmQgb2YgdGhl IGRvY3VtZW50IHdoZXJlIHRoZSBrZXkgcG9pbnRzIG9mIGVhY2ggMm5kIGxldmVsIHRvcGljDQog ICAgPiA+IGFyZSBzdW1tYXJpc2VkLg0KICAgID4gPiANCiAgICA+ID4gSXMgaXQgd29ydGggY2l0 aW5nIGV4YW1wbGVzIG9mIHNlY3VyaXR5IHRvb2xraXRzIHJlYWRlcnMgY2FuIGV4cGxvcmUsIGxp a2UgdGhlDQogICAgPiA+IFRIQyBraXQsIFNJNiBOZXR3b3JrcywgZXRjLCBtYXliZSBTY2FweT8N CiAgICA+ID4gDQogICAgPiA+IFNwZWNpZmljIGNvbW1lbnRzOg0KICAgID4gPiANCiAgICA+ID4g cC4zDQogICAgPiA+IEkgZG9uPz8/dCB1bmRlcnN0YW5kIHdoeSBOUFR2NiBpcyBtZW50aW9uZWQg aGVyZSwgdGhpcyBlYXJseS4gIEp1c3Qgc2F5IHRoYXQgc29tZQ0KICAgID4gPiBzZWN1cml0eSBp c3N1ZXMgaGF2ZSBJUHY0IGVxdWl2YWxlbnRzLCBsaWtlIE5EIGF0dGFja3MgYW5kIEFSUCBhdHRh Y2tzLCBhbmQNCiAgICA+ID4gc29tZSBkbyBub3QsIGxpa2UgSVB2NiBFSHMgb3IgaG9wIGJ5IGhv cCBEb1MuICAgVGhlIE5BVCBkaXNjdXNzaW9uIHNob3VsZCBiZSBpbg0KICAgID4gPiBhIHN0YW5k YWxvbmUgc2VjdGlvbiwgYW5kIGJlIG5ldXRyYWwgdGhlcmUuDQogICAgPiA+IA0KICAgID4gPiBw LjQNCiAgICA+ID4gV2h5IG1lbnRpb24gdGhlIHNwZWNpZmljIGV4YW1wbGUgb2YgbXVsdGktaG9t ZWQgbmV0d29ya3M/ICAgV2hhdCBkbyB5b3UgbWVhbiBieQ0KICAgID4gPiB0aGUgZXhjZXB0aW9u PyAgSXMgaXQgdGhhdCBtdWx0aS1ob21pbmcgaXMgb3V0IG9mIHNjb3BlLCBhbmQgc28gYXJlIHVu bWFuYWdlZA0KICAgID4gPiBuZXR3b3Jrcz8NCiAgICA+ID4gDQogICAgPiA+IHAuNA0KICAgID4g PiBBZ2FpbiwgTlBUdjYgaXMgbWVudGlvbmVkLiAgVGhpcyBzZWN0aW9uIGlzIHRpdGxlZCA/Pz9h ZGRyZXNzaW5nIGFyY2hpdGVjdHVyZT8/Pw0KICAgID4gPiBidXQgdGhpcyBiaXQgb2YgdGV4dCBp cyBhYm91dCByZWFzb25zIGZvciBnb2luZyBQQSwgUEksIG9yIGJlY29taW5nIGFuIExJUiwNCiAg ICA+ID4gd2hpY2ggaXMgbm90IGFyY2hpdGVjdHVyZS4NCiAgICA+ID4gDQogICAgPiA+IHAuNA0K ICAgID4gPiBJbiB0aGUgNzkzNCBwYXJhLCBSRkM4OTgxIHNob3VsZCBiZSBtZW50aW9uZWQgYXMg aXQ/Pz9zIGEgc2lnbmlmaWNhbnQgcmVhc29uIG9mDQogICAgPiA+IGRldmljZXMgaGF2aW5nIG1v cmUgYWRkcmVzc2VzLg0KICAgID4gPiANCiAgICA+ID4gcC41DQogICAgPiA+IFVMQXMgYXJlIGFs c28gdXNlZnVsIHdoZXJlIHRoZSBwcmVmaXggY2hhbmdlcywgZm9yIHN0YWJsZSBpbnRlcm5hbCBh ZGRyZXNzaW5nDQogICAgPiA+IGFzIHRoZSBnbG9iYWwgcHJlZml4IGNoYW5nZXM/ICBUeXBpY2Fs bHkgaW4gcmVzaWRlbnRpYWwgbmV0d29ya3MuDQogICAgPiA+IA0KICAgID4gPiBwLjUNCiAgICA+ ID4gU2VjdGlvbiAyLjEuNCBpcyByZWFsbHkgYWJvdXQgY2hvaWNlcyBpbiBhZGRyZXNzIGFzc2ln bm1lbnQgd2l0aGluIGEgbmV0d29yay4NCiAgICA+ID4gDQogICAgPiA+IHAuNg0KICAgID4gPiBT b21lIG9mIHRoZXNlIHBhcmFzIHNob3VsZCBiZSBpbiBhIHNlY3Rpb24gYWJvdXQgSVB2NiBuZXR3 b3JrIHJlY29ubmFpc3NhbmNlLA0KICAgID4gPiBob3cgdG8gYmVzdCBtaXRpZ2F0ZSBhZ2FpbnN0 IHNjYW5uaW5nLCBhbmQgaG93IHRvIGludmVudG9yeSB5b3VyIG93biBuZXR3b3JrDQogICAgPiA+ IGVsZW1lbnRzLg0KICAgID4gPiANCiAgICA+ID4gcC42DQogICAgPiA+IEFsbCBtZW50aW9ucyBv ZiA0OTQxIHNob3VsZCBiZSByZXBsYWNlZCB3aXRoIDg5ODEuDQogICAgPiA+IA0KICAgID4gPiBw LjcNCiAgICA+ID4gQ2FuIHVzZSA3NzIxIGFuZCA4OTgxIHRvZ2V0aGVyLg0KICAgID4gPiANCiAg ICA+ID4gcC43DQogICAgPiA+IFdoeSBhcmUgREhDUCBhbmQgRE5TIGxpbXBlZCB0b2dldGhlcj8g IFRoZSBETlMgaXMgb25seSBhYm91dCBETlNTRUMsIHNvIGNhbGwgaXQNCiAgICA+ID4gdGhhdD8N CiAgICA+ID4gDQogICAgPiA+IHAuNw0KICAgID4gPiA/Pz9FdmVuIGlmIHRoZSB1c2Ugb2YgREhD UD8/PyAtIHRoaXMgcmVhZHMgYmFkbHkuICBSYXRoZXIgODUwNCB0YWxrcyBhYm91dCB0aGlzIGlu DQogICAgPiA+IDYuNSwgd2hlcmUgUkZDNzg0NCBpcyBtZW50aW9uZWQgZm9yIGV4YW1wbGUuICBU aGlzIHNob3VsZCBiZSBpbiBhIHVzZXIgcHJpdmFjeQ0KICAgID4gPiBzZWN0aW9uIChpZiB0aGlz IGRvY3VtZW50IGhhZCBvbmUpLiAgU2VjdGlvbiA4LjQgaXMgYWxzbyB1c2VmdWwgYWR2aWNlLg0K ICAgID4gPiANCiAgICA+ID4gcC44DQogICAgPiA+IFRoZSBmaXJzdCBwYXJhIGlzIHZlcnkgbXVk ZGxlZC4NCiAgICA+ID4gDQogICAgPiA+IHAuOA0KICAgID4gPiBJbiAyLjEuNyB0aGlzIGNhbiBh bHNvIGJlIHVzZWZ1bCBmb3IgQUNMIGNvbnRyb2xzLCBpZiBvbmUgYWRtaW4gLyBjb250cm9sDQog ICAgPiA+IHN5c3RlbSBzaXRzIGluIGEgcHJlZml4IG9mIGl0cyBvd24uDQogICAgPiA+IA0KICAg ID4gPiBwLjEwDQogICAgPiA+IFRoaXMgaXMgcmVhbGx5IGFib3V0IGhhbmRsaW5nIG9mIGZyYWdt ZW50ZWQgcGFja2V0cyAodGhlIHRvcGljKSBub3QgdGhlDQogICAgPiA+IGZyYWdtZW50IGhlYWRl ciBpdHNlbGYgQWxzbyB0aGlzIGlzIGNvdmVyZWQgaW4gMi4zLjIuMSBhcyB3ZWxsLg0KICAgID4g PiANCiAgICA+ID4gcC4xMA0KICAgID4gPiBJbiAyLjIsIHRoZSBpbnRybyBjYW4gc2F5IHRoZXNl IGlzc3VlcyBoYXZlIHBhcmFsbGVscyBpbiBJUHY0Lg0KICAgID4gPiANCiAgICA+ID4gcC4xMQ0K ICAgID4gPiBGaXJzdCBsaW5lLCBzYXkgdGhlIGF0dGFjayBjYW4gdHlwaWNhbGx5IGhhcHBlbiBm cm9tIGEgbGFyZ2UgYWRkcmVzcyBzY2FuIGlmDQogICAgPiA+IHBlcm1pdHRlZCBpbnRvIHRoZSBu ZXR3b3JrPw0KICAgID4gPiANCiAgICA+ID4gcC4xMQ0KICAgID4gPiBCdWxsZXQgMSAtIHRoYXQg Y29udHJhZGljdHMgdGhlIGNvbW1lbnRzIG9uIHByZWRpY3RhYmxlIGFkZHJlc3NpbmcuDQogICAg PiA+IEJ1bGxldCAyIC0gaG93PyAgU29tZSBjbHVlcyBoZXJlIHdvdWxkIGJlIHVzZWZ1bC4NCiAg ICA+ID4gDQogICAgPiA+IHAuMTINCiAgICA+ID4gPz8/Q3VycmVudD8/PyAtIHJlYWxseT8gQWxs IGN1cnJlbnQgaW1wbGVtZW50YXRpb25zPyAgRGVsZXRlID8/P2N1cnJlbnQ/Pz8gb3IgcmVwbGFj ZQ0KICAgID4gPiB3aXRoID8/P25haXZlPz8/IG1heWJlLg0KICAgID4gPiANCiAgICA+ID4gcC4x Mg0KICAgID4gPiA/Pz9Db21tdW5pY2F0ZSBkaXJlY3RseT8/PyAtIGF0IEwyPyAgSWYgc28sIHdo eT8NCiAgICA+ID4gDQogICAgPiA+IHAuMTINCiAgICA+ID4gQW4gZXhhbXBsZSBvZiBhIHJlY29t bWVuZGF0aW9ucyBzZWN0aW9uIGhlcmUsIHdoZXJlIG90aGVyIHNlY3Rpb25zIHdpdGggYWR2aWNl DQogICAgPiA+IGFyZSBub3QgdGl0bGVkIGFzIHN1Y2guIFNlZSB0aGUgR2VuZXJhbCBjb21tZW50 IG9uIHRoaXMuDQogICAgPiA+IA0KICAgID4gPiBwLjEzDQogICAgPiA+ID8/P1RyaXZpYWw/Pz8g Y2FzZXMgLSBhcmVuPz8/dCB0aGVzZSBjb21tb24gb25lcywgbGlrZSBlZGdlIHN3aXRjaGVzIGlu IGFuIGVudGVycHJpc2U/DQogICAgPiA+IA0KICAgID4gPiBwLjEzDQogICAgPiA+IFdoeSA/Pz9o b3N0aWxlPz8/PyAgRGVsZXRlPw0KICAgID4gPiANCiAgICA+ID4gcC4xNA0KICAgID4gPiBJbiAy LjMuNSBsYXN0IHBhcmEsIHdoYXQgYWJvdXQgbUROUywgQm9uam91cj8gICBUaG91Z2ggdGhlIERO UyBTRCB3b3JrIGlzIG5vdw0KICAgID4gPiBvbiB1bmljYXN0IGRpc2NvdmVyeS4NCiAgICA+ID4g DQogICAgPiA+IHAuMjENCiAgICA+ID4gTWF5YmUgYWRkIGhlcmUgODAyLjF4IGFzIGFuIGV4YW1w bGUgb2YgdGhlIHZhbHVlIG9mIFJBRElVUyBsb2dzLCBhbmQgYWRkIGluDQogICAgPiA+IGhlcmUg YXMgYnVsbGV0cyBpbmZvIGhhcnZlc3RlZCBmcm9tIHN3aXRjaGVzIGFuZCAoc2F5KSByb3V0ZXIg TkRQIHN5c2xvZw0KICAgID4gPiAodGhvdWdoIHRoYXQ/Pz9zIEkgc3VwcG9zZSB0aGUgNHRoIGJ1 bGxldCkuICBUaGVzZSBhcmUgbWVudGlvbmVkIGluIDIuNi4xLjcgYnV0DQogICAgPiA+IHNob3Vs ZCBiZSBzcGxpdCBvdXQgYXQgdGhlIHNhbWUgbGV2ZWwgYXMgdGhlIG90aGVyIHRvcGljcyBoZXJl Lg0KICAgID4gPiANCiAgICA+ID4gcC4yOA0KICAgID4gPiBUaGUgdGV4dCBpcyAyLjYuMi4yIHJl cGVhdHMgZWFybGllciB0ZXh0Lg0KICAgID4gPiBTaW1pbGFybHkgdGV4dCBpbiAyLjYuMi4zIGlz IHJlcGVhdGVkIGZvcm0gYmVmb3JlLg0KICAgID4gPiANCiAgICA+ID4gcC4yOQ0KICAgID4gPiBJ biAyLjYuMi40IHByZXN1bWFibHkgYWxzbyBhIHJhcGlkIGdyb3d0aCBpbiBORCBjYWNoZSBzaXpl IGlzIGFuIGluZGljYXRvci4NCiAgICA+ID4gDQogICAgPiA+IHAuMjkNCiAgICA+ID4gSW4gMi43 IHBvaW50IHRvIFJGQyA0OTQyDQogICAgPiA+IA0KICAgID4gPiBwLjMwDQogICAgPiA+IFNob3Vs ZCBSRkMgNjA5MiBiZSBtZW50aW9uZWQgaGVyZT8NCiAgICA+ID4gQW5kIHRoYXQgdGhlIGJlc3Qg ZGVmZW5jZSBhZ2FpbnN0IElQdjYgYXR0YWNrcyBuID8/P0lQdjQgb25seT8/PyBuZXR3b3JrcyBp cyB0bw0KICAgID4gPiBkZXBsb3kgYW5kIG1hbmFnZSBJUHY2Pw0KICAgID4gPiANCiAgICA+ID4g cC4zMQ0KICAgID4gPiBGaXJzdCBidWxsZXQgb24gdGhpcyBwYWdlIC0gYnV0IGlzbj8/P3QgdGhp cyB0aGUgc2FtZSBhcyBpZiB0aGUgdHJhZmZpYyBpcyBub3QNCiAgICA+ID4gdHVubmVsbGVkPyAg V2h5IGRvZXMgdHVubmVsbGluZyBhZGQgdGhlIHJlcXVpcmVtZW50PyAgVGhlIHNhbWUgYXBwbGll cyBvbiB0aGUNCiAgICA+ID4gZmlyc3QgcGFyYSBvbiBwLjMyDQogICAgPiA+IA0KICAgID4gPiBw LjMxDQogICAgPiA+IE1heWJlIHNheSBoZXJlIHRoZSBtaXRpZ2F0aW9ucyBjYW4gYWxzbyBicmVh ayB0dW5uZWwgYnJva2VycyAobWlnaHQgYmUgZGVzaXJlZCwNCiAgICA+ID4gYnV0IHVzZXJzIHdp bGwgbm90aWNlPz8/KT8/Py4gTWF5YmUgdHVubmVscyB0byBzcGVjaWZpYyBicm9rZXJzIGNhbiBi ZSBhbGxvd2VkLg0KICAgID4gPiANCiAgICA+ID4gcC4zMg0KICAgID4gPiBJU0FUQVAsIGluIDIw MjE/ICBTYW1lIHdpdGggNnJkLiAgR2VuZXJhbCBhZHZpY2Ugc2hvdWxkIGJlIGRlcGxveSBuYXRp dmUsIGF2b2lkDQogICAgPiA+IHR1bm5lbHMuDQogICAgPiA+IA0KICAgID4gPiBwLjMzDQogICAg PiA+IFNhbWUgZm9yIDZ0bzQuDQogICAgPiA+IA0KICAgID4gPiBwLjM0DQogICAgPiA+IFRlcmVk byB0aG91Z2gsIGlzIHRoYXQgc3RpbGwgaW5jbHVkZWQgaW4gV2luZG93cyBhbmQgWEJvWCwgYXMg YSBNUyB0aGluZz8NCiAgICA+ID4gDQogICAgPiA+IHAuMzYNCiAgICA+ID4gTWF5YmUgY2l0ZSBH ZW9mZiBIdXN0b24/Pz9zIGJsb2cgb24gdGhpcyAtIGl0Pz8/cyB2ZXJ5IGdvb2QuICBNYXliZSB0 aGVyZT8/P3MgYSBtb3JlDQogICAgPiA+IHJlY2VudCB1cGRhdGUgdGhvdWdoIC0NCiAgICA+ID4g aHR0cHM6Ly9ibG9nLmFwbmljLm5ldC8yMDE2LzA2LzA5L2xldHMtdGFsay1pcHY2LWRuczY0LWRu c3NlYy8uIEhvc3QgQ0xBVCBpcw0KICAgID4gPiBhcHBsaWNhYmxlIGhlcmU/ICAoSGVuY2UgYSBz aXRlIHNob3VsZCBzdXBwb3J0IHRoZSA2NFBSRUYgUkEgb3B0aW9uPyAgUkZDODc4MQ0KICAgID4g PiANCiAgICA+ID4gcC4zOA0KICAgID4gPiBJbiAyLjgsIHRvIGJlIGZhaXIgSVB2NCBpcyBhbHNv IGhhcmRlbmVkIGEgbG90IG9mIGxhdGUgZHVlIHRvIHRoZSBwcmV2YWxlbmNlIG9mDQogICAgPiA+ IHVzZSBvZiBkZXZpY2VzIGluIFdpRmkgaG90c3BvdHMgZXRjLg0KICAgID4gPiANCiAgICA+ID4g cC4zNw0KICAgID4gPiBBbHNvIFJGQzYwOTIgb24gc2VjdGlvbiAzLjE/DQogICAgPiA+IA0KICAg ID4gPiBwLjM4DQogICAgPiA+ID8/P1doZXJlIFJGQzE5MTggYWRkcmVzcyBhcmUgb2Z0ZW4gdXNl ZD8/PyAtIGFkZCA/Pz9vZnRlbj8/PywgdGhlIHRleHQgaW1wbGllcyBhbGwNCiAgICA+ID4gZW50 ZXJwcmlzZXMgdXNlIHY0IE5BVC4NCiAgICA+ID4gDQogICAgPiA+IHAuNDENCiAgICA+ID4gT25s eSAyIG5vcm1hdGl2ZSByZWZlcmVuY2VzPw0KICAgID4gPiANCiAgICA+ID4gTml0czoNCiAgICA+ ID4gDQogICAgPiA+IHAuMQ0KICAgID4gPiA/Pz9UaGUgSW50ZXJuZXQ/Pz8gLSB5b3UgcHJvYmFi bHkgbWVhbiA/Pz9hbiBJU1AgbmV0d29yaz8/Pw0KICAgID4gPiA/Pz9EZXNjcmliZXMgdGhlIHNl Y3VyaXR5Pz8/IC0gZGVsZXRlID8/P3RoZT8/Pw0KICAgID4gPiANCiAgICA+ID4gcC40DQogICAg PiA+ID8/P1doaWNoIGFyZSB0aGUgc3dpdGNoPz8/IGRlbGV0ZSA/Pz93aGljaCBhcmU/Pz8NCiAg ICA+ID4gDQogICAgPiA+IHAuOA0KICAgID4gPiBWYXJ5aW5nIC0+IHZhcmlvdXMNCiAgICA+ID4g DQogICAgPiA+IHAuMTANCiAgICA+ID4gaXB2NiAtPiBJUHY2DQogICAgPiA+IA0KICAgID4gPiBw LjE4DQogICAgPiA+IFJvdXRlciBwcm9jZXNzb3IgLSBhZGQgciB0byA/Pz9yb3V0ZT8/Pw0KICAg ID4gPiANCiAgICA+ID4gPz8/DQogICAgPiA+IFRpbQ0KICAgID4gPiANCiAgICA+ID4gDQogICAg PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAg PiA+IE9QU0VDIG1haWxpbmcgbGlzdA0KICAgID4gPiBPUFNFQ0BpZXRmLm9yZw0KICAgID4gPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2VjDQogICAgPiANCiAgICA+ IC0tIA0KICAgID4gRW5ubyBSZXkNCiAgICA+IA0KICAgID4gQ2VsbDogKzQ5IDE3MyA2NzQ1OTAy DQogICAgPiBUd2l0dGVyOiBARW5ub19JbnNpbnVhdG9yDQogICAgPiANCiAgICA+IA0KICAgID4g LS0gDQogICAgPiBUaGUgY29tcHV0aW5nIHNjaWVudGlzdOKAmXMgbWFpbiBjaGFsbGVuZ2UgaXMg bm90IHRvIGdldCBjb25mdXNlZCBieSB0aGUNCiAgICA+IGNvbXBsZXhpdGllcyBvZiBoaXMgb3du IG1ha2luZy4gDQogICAgPiAgIC0tIEUuIFcuIERpamtzdHJhDQoNCg0K From nobody Thu Apr 22 01:01:24 2021 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB14F3A1BD0; Thu, 22 Apr 2021 01:01:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-opsec-v6@ietf.org, opsec-chairs@ietf.org, opsec@ietf.org, Gyan Mishra X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <161907847829.28799.9576185174254810049@ietfa.amsl.com> Date: Thu, 22 Apr 2021 01:01:18 -0700 Archived-At: Subject: [OPSEC] Murray Kucherawy's No Objection on draft-ietf-opsec-v6-26: (with COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2021 08:01:19 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-opsec-v6-26: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this work. It's a useful document to have. I don't have much to add that my fellow ADs have not already mentioned. One procedural nit: The shepherd writeup lacks an answer to the question "Why is this the proper type of RFC?" (I realize "Informational" is the right answer here. I would just prefer it if shepherds answered it anyway.) It is also almost 18 months old. From nobody Thu Apr 22 02:58:41 2021 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C4D3A0B69; Thu, 22 Apr 2021 02:58:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-opsec-v6@ietf.org, opsec-chairs@ietf.org, opsec@ietf.org, Gyan Mishra , hayabusagsm@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <161908551601.25452.9693102407659417221@ietfa.amsl.com> Date: Thu, 22 Apr 2021 02:58:36 -0700 Archived-At: Subject: [OPSEC] Robert Wilton's No Objection on draft-ietf-opsec-v6-26: (with COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2021 09:58:37 -0000 Robert Wilton has entered the following ballot position for draft-ietf-opsec-v6-26: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, I would like to thank the authors for persevering with this document that has been in development for a long time. I was also like to thank Tim for his detailed OPSDIR reviews. I found the document informative to read, but in terms of the technical content, I don't have anything further to add beyond the other reviews comments. My overriding impression from reading this document (both due to the text and large number of references) is that deploying IPv6 seems to be very complex. I don't know how that complexity compares to v4 deployments. In several cases, this document alludes to different alternatives to how particular IPv6 features may be deployed, and the operational security considerations as they pertain to those choices. Not for this document, but it makes me wonder whether some useful future work in this area might be some BCP recommendations for how IPv6 should be deployed in particular types of networks .. although it is entirely possible that ship has already sailed, or there is too much variation on how v6 is being deployed to make such a recommendation. Regards, Rob From nobody Thu Apr 22 03:53:42 2021 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7FC13A1073; Thu, 22 Apr 2021 03:53:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tim Chown via Datatracker To: Cc: draft-ietf-opsec-v6.all@ietf.org, last-call@ietf.org, opsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161908882063.14230.2228639706548726690@ietfa.amsl.com> Reply-To: Tim Chown Date: Thu, 22 Apr 2021 03:53:40 -0700 Archived-At: Subject: [OPSEC] Opsdir telechat review of draft-ietf-opsec-v6-26 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2021 10:53:41 -0000 Reviewer: Tim Chown Review result: Ready Hi, I have reviewed this document (draft-ietf-opsec-v6-26) as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This draft analyses operational security issues related to the deployment of IPv6, and describes appropriate mechanisms and practices to mitigate potential threats. I have previously reviewed this draft three times in as many years, the most recent being my OPS DIR review of the previous -25 version. General comments: The nature of this beast remains the same as the -25 version, and my general comments from that version all still apply. The draft has a lot of good advice, provided by authors with significant expertise in the IPv6 security field. It could be better structured and could give some summary points for readers not prepared to read 50 pages, but in my view ia) it is far better to publish this document than hold it up much longer and b) certainly no harm can be done by publishing it as is; there is nothing wrong and no bad advice. Perhaps someone else can write a blog-style summary of the key points and link to the full RFC once published. So, overall, given the history and the time the authors have spent to date, I would support publication. It’s good enough. Specific comments: Having re-read the draft and the diffs to -25, I counted that10 of the 39 specific comments I made about the -25 version of the draft have been addressed, the rest remain open. No direct response was provided to the -25 review, so it’s not possible to understand what some comments were addressed and the others not. There is nothing wrong in the text as such, but some significant improvements that could be made., but I understand why the authors would rather get the document shipped. Nits: All nits reported in my previous review are addressed. One new nit was introduced in 2.3.2.4: "unless specific use cases such as the presence of devices Homenet devices emitting router advertisements preclude this" Something's not right there. — Tim From nobody Thu Apr 22 03:55:50 2021 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00313A1084; Thu, 22 Apr 2021 03:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARiwIx2WJlz7; Thu, 22 Apr 2021 03:55:40 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40056.outbound.protection.outlook.com [40.107.4.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F2A73A1085; Thu, 22 Apr 2021 03:55:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=U6fzIuoRP1xa2MeVUGfa7FwVDZdXMzTw986oeMFZMcKZmDFfvMPjLlDTpn2Ax7aSBccDm6nOaOYBw2flQgSFbwayIdCfuKlo+JaYo0IWsh3Fz0r6jjg+bMk+Jg9BGyMs1lltM4qbi3Tss1Nk+9ADXr6so71bKIMlwc6JJZX7ZOCfa3BX5BORz2BBPVEIundZFwj4hKZ2iKC1tFThs9SS/Z8aqZJ+Y/1NEcnLys++zmQJ13pqGdDMVqHV/BwN8Af7z883fAxTLv8NdWCALH25DeRP7E7RKDsF1BgTrfsWnn4iuKq6QG0GuY4ZJtkTDj6+lTUwYsSREhiBj40Z9saBwQ== 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=3HhBzKcqRaRXewyG+SKlhyZc5uUxYXV/YxiJu5IsWis=; b=I+C1CCnUEGsaYFMuGJ88YsAG4ywenYr/gHb13BLOOZ21ew/O8/J+zZ82eh8X4X6xZWguNwSk+y1xUux/pp23/gbGrPEGPXXNxeGk8fB2FjkqIwcRw8Owk+bSZO2QoinNBgvEyMH7V3Yn0Ky+iEuioIVoBSudaSZKybcFp5VjYqj/SS318UMz36APDItcQ1QZZZgultdXn5dpXbnANA9hp3TU/02K5/l7vXduV1BOSXVPs9ZczXpe8PHLnUElVaQqa/SAgvNEfrHm2SaEKcDxR0I+GBUJrQCo7lKskA/CIaQnrJkVFbXjWOjuhLRUlMinJTffGPHTQBU/RQKkzd/byg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jisc.ac.uk; dmarc=pass action=none header.from=jisc.ac.uk; dkim=pass header.d=jisc.ac.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3HhBzKcqRaRXewyG+SKlhyZc5uUxYXV/YxiJu5IsWis=; b=Pe7z8u1aNtk3pj+vVywRZdI/iqAunIZUw+Ggw4YIqYzNk3fgedrNWod32Lf9srOWfKgok77zShauVPq/dTn6Ems7pDNjpOii1MkaLH2HVdqeqAnRiGg+2dKbg12rrXuYE0HcqYgFYt6OAIoXp317gtqNOLRW1J9HeE8q11Wqs+o= Received: from DB9PR07MB7771.eurprd07.prod.outlook.com (2603:10a6:10:2a6::15) by DB6PR0701MB2279.eurprd07.prod.outlook.com (2603:10a6:4:50::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.6; Thu, 22 Apr 2021 10:55:36 +0000 Received: from DB9PR07MB7771.eurprd07.prod.outlook.com ([fe80::6011:1efb:4348:f34f]) by DB9PR07MB7771.eurprd07.prod.outlook.com ([fe80::6011:1efb:4348:f34f%5]) with mapi id 15.20.4065.022; Thu, 22 Apr 2021 10:55:36 +0000 From: Tim Chown To: "Eric Vyncke (evyncke)" CC: Warren Kumari , Enno Rey , ops-dir , "last-call@ietf.org" , opsec wg mailing list , "draft-ietf-opsec-v6.all@ietf.org" Thread-Topic: [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-25 Thread-Index: AQHXLjnDyQdRJCPbVUCT8CaQwzD7p6qy81iAgAwYLgCAAFKTgIABEYCA Date: Thu, 22 Apr 2021 10:55:36 +0000 Message-ID: References: <161778675730.8077.2835666586607648895@ietfa.amsl.com> <20210410184555.GE91991@ernw.de> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3654.60.0.2.21) authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=jisc.ac.uk; x-originating-ip: [2001:a88:d510:1101:a45e:c59c:a7bf:b7b0] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 14ecc4a9-3e18-443a-a0e2-08d9057d28f8 x-ms-traffictypediagnostic: DB6PR0701MB2279: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: iaycVzuuuLOILFxE0MBymp4B5Y/jcEPDA8liwYaPacd9kC8t4vPL6j1HoW8VNkdoe+FcKooynVS8vcbd5DRKUTKv0UE2wWTSLJRW5T8sBsAYr1gFz9xuRDTIwaX7o/OhMZ0V7xklMPuppyWMIp6UOkwMvnjmzo04uv178kewYelqBHKsfvsqUlthmJrOrSQ+8h23WBV+FayJeDt2N7dy9jdzXc6Dj8j/i7ZrEr62LBsJ8nhpSdiFSHaIfInr8F5qXxlH2DUm9FbY7TzSECwczx09mKAomfUqvkjkIv8NVizUYQpHYawKg1ZrUT/kH0VgjdLXCjOgTZ22u0RWMRecdNSC1gryMqdDRwMG2mB0OgaMlUzf0cwnybFa1FhOHjHUJb61xCzxpclat3LAKYoLrd9u1SD+T0fUgEPGn4gUcifMANS9SvC8/qlqZENVYp4Ylo2/5ehlJ7rp06jo+dSbHay3U1GnnWkuDTnkCqfP4gy5fw0/dl0f+Xn2SVtZRieOOOqudI9ZrR/Onpl5jK2a9tPDB8aYCJHYdPmgyja9vNU8jeHw1o2MnzLT0RdKJA7n/1LAkR0YSYMRL3v7lCTxloqz40x6Bmf/XySmuPe974VK1BZlx25Z02giAeR2t6Gg5dbyGkT5lQAje56GszZSUXUho9MK1WSsgi8GmThgRugWPkOTqRqDhN7Q2J0n41sdK4UHhdlRUaYCLBz9+uUgQwEdU/o86faLQQbv5f0gCr8= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB9PR07MB7771.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(39850400004)(346002)(366004)(396003)(136003)(38100700002)(966005)(186003)(66556008)(66574015)(71200400001)(86362001)(6506007)(122000001)(4326008)(53546011)(83380400001)(33656002)(478600001)(64756008)(66476007)(66946007)(66446008)(2616005)(8676002)(76116006)(8936002)(91956017)(6512007)(5660300002)(36756003)(30864003)(6916009)(2906002)(786003)(316002)(54906003)(6486002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?WlZpcWp0Z1NpR1dOOW5XZU1veWl0ckZJWFZ0NWJRNjdjRmJjZ09INVpqdG5W?= =?utf-8?B?Q0Y5cTZmbUJxZjBTdmJPdUVKUmRZSEdxMEozVTc0Rit4Vm4vRzdwWitFYzBt?= =?utf-8?B?OXRXRTFTTFQ2TXNaMjdOTk9ET2pydVNXSU5ibWtIU2FaR1VGVDVWQU5rUmh5?= =?utf-8?B?SnFuNU9BVU5BVlBtUFNucTh2VkRVa3NQZ3ZkSGV0a1l0V2I3SkRFNkxjS3d6?= =?utf-8?B?cWJmTEFQT2o0cGF1Y2RGaUdad0EybzJkK09BVjI3bjhFakV0OGNjOTlVTjQ3?= =?utf-8?B?TncxQWtzL0lCVDQ0cUh3MHZqUGRJRWJxSy9tbEYxankxZlZ5elJodmlibU12?= =?utf-8?B?NGZrc0Uwb2RjSjRvbTZtTUJkeTk4R01lZ0t4RmFva0F5WlBtRm9NWG9KTVVI?= =?utf-8?B?cW5aS0RCalRmV2VmcnNtQTZnTTZKM3NuZXRlcjNWTzZ1NEhQbmpOZ0tKaGsv?= =?utf-8?B?dWpsdVlCeCtNa1JYTGVDNEpLUTVHOW5wOTN2WFhvaFVsc3dNMld2aE9VV2JZ?= =?utf-8?B?WFlQRCtkdG4vMW14Zzl1WnpSQ0FjNi9ycWpYa2xieEVTdDFac3JqSFd4TlFG?= =?utf-8?B?SDFZQWtvdU12U0ROcXM5ak9pK3IyNk9KMk9PSGp5VnJyMGFXMnphZlpGanJx?= =?utf-8?B?bFNycFFtSTJoZmtYdDJtOWtDb3hoS2tQK0Roc1BneFZ2anV4bmJwUDZ5L2Nx?= =?utf-8?B?MjBtQ1FBVTdrYzFrMHh6VC9DRUtOcGpwOFhVVDZvRFY2RnpEZXZiUVg5V0Mw?= =?utf-8?B?UDVQUFVSYXliNElkQVZ2V2NQYmhIQk1NRU53L1hPcHpMVXc2RHUyaERoMUxB?= =?utf-8?B?M0I3b2l1Mm5IbTF5TzU0WFdGS0hOc3g3cXVnaXFWckJpSUpNRXROaTcyVXlz?= =?utf-8?B?Qm9UekpnRWRUZm5kSDA5SC9yV1o3MVBSSkdoUWdCV0RpU1JJWnZORlE2LzBC?= =?utf-8?B?a0dsei84dXV6WEdYSE5RejFFUTJRRXNyM21FNWhhekkzTmJKYjQ1aW5BOVRo?= =?utf-8?B?V212SGloMnJFbDR1aXNacVNNd2RsbElnanVmTUw3Q2tDeHU5cG0xYlNFY3E2?= =?utf-8?B?d0xzZmxla3poZ1lpYjJtRnVkZUZZa0J0Ris2YVhidGV4MmZOVFAweU42Ylkw?= =?utf-8?B?em1PU0sxYSt6L2JGWHRTLzJLOTVEMWUwdFVpMWtZOUZKdWtnODlKTlFrS3cr?= =?utf-8?B?MmRySGV4eWxDOXZGZ1B6dE5MZzJ0UW11V2U0UTRxbnpXVUtCSzU0aVplSzhS?= =?utf-8?B?aFA2b2xKMTJMVk00VmhJUHY3cnByYVhQcEZyY0xZclZRdnY3MDY3WFU2c3BS?= =?utf-8?B?SWh1YXRJWUlybzdSYVdrYVhTNldKM21GRDRRRkMzRW9oS0syRnRUVXhKVm1y?= =?utf-8?B?Rk1lUTU5M1dOUjJURmpwL2RJc3dYc3BCUGVDbFpoR1BkZURObjJjRXFGTjNs?= =?utf-8?B?MmR2Ujg4TDNGSHB2MGVDMVNCRWNGU29ZbCszTFBiTmJvNE0zZVBkK093eTRr?= =?utf-8?B?YUtYRm9aQnRVNzI0SEJ1bDRwNS9WV25Jd0QrL3RjeWx4OHYzNXJYcGhkYy9x?= =?utf-8?B?ZE53cHh3VEVrNWJ1cnhlYVNXOWlPM3BkVVI0VXhoRVhieDhjUkJvVTEwS0Ji?= =?utf-8?B?QkJSUXR6NmNYamIzc0w2Zlpjd09kRzF5b2R4N05nQXRtOERkM2pteTd5Mm9G?= =?utf-8?B?VG1uYVBqallwUHZoeW5mS1pDdXdjanBpWG0vMis3UUtXdld5YStoNUNOVkc0?= =?utf-8?B?UHpDQm16enJMVXRrRUxMSGtyb004N21UdVhyS3Bqc2dlL0IvQS9ncERCRUlT?= =?utf-8?B?dXpvaW5XVWk4UjljelVDSnc3ZDgvNGNteGZFWlo5SkorYm83aUNjcldXeWMr?= =?utf-8?B?UUdGb2ljY3NTT1NxRVBDLzZTK3JIdWFFclYrL0FwWlZnR3c9PQ==?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB9PR07MB7771.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 14ecc4a9-3e18-443a-a0e2-08d9057d28f8 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2021 10:55:36.4526 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: tbdgBWPzTMSqepJ1SIqCNMSg+XFHKb2YItfd8NFRfcF3P48RNRNJBpYxCd+/MWOtrdIlEnlcSfGXYOXBtyMZUA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2279 Archived-At: Subject: Re: [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-25 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2021 10:55:46 -0000 SGksDQoNCknigJl2ZSBjaGVja2VkIHRocm91Z2ggLTI2IGFuZCBjb21wYXJlZCBhcyBiZXN0IGFz IEkgY2FuIHRvIC0yNSwgYW5kIHN1Ym1pdHRlZCB0aGUgcmV2aWV3Lg0KDQpJ4oCZbSBoYXBweSBl bm91Z2ggdG8gcHV0IGEg4oCYUmVhZHnigJkgdGFnIG9uIGl0LiAgSXQgY291bGQgYWx3YXlzIGJl IGJldHRlciwgYnV0IGF0IDUwIHBhZ2VzLCBJIGZ1bGx5IHVuZGVyc3RhbmQgd2h5IHNoaXBwaW5n IGl0IGlzIGRlc2lyYWJsZS4gIEkgY2Fu4oCZdCBzZWUgYW55dGhpbmcgc3BlY2lmaWNhbGx5IHdy b25nIGluIHRoZSB0ZXh0IDopDQoNClRpbQ0KDQo+IE9uIDIxIEFwciAyMDIxLCBhdCAxOTozNiwg RXJpYyBWeW5ja2UgKGV2eW5ja2UpIDxldnluY2tlQGNpc2NvLmNvbT4gd3JvdGU6DQo+IA0KPiBU aW0sIFdhcnJlbiwNCj4gDQo+IFJlcGx5aW5nIHdpdGggb25seSB0aGUgYXV0aG9yIGhhdCAoYW5k IGFmdGVyIGNvbnN1bHRhdGlvbiB3aXRoIG15IGNvLWF1dGhvcnMpIG9uIHRoaXMgZW1haWwgYWZ0 ZXIgaGF2aW5nIHJlYWQgV2FycmVuJ3MgYW5kIFRpbSdzIHJlcGxpZXMuDQo+IA0KPiBUaW0sIEkg ZG8gbm90IGtub3cgd2hldGhlciB5b3UgcmVtZW1iZXIgYWxsIHRoZSBwYWluZnVsIGpvdXJuZXkg b2YgdGhpcyBkb2N1bWVudCBidXQgdGhlIGF1dGhvcnMgZG8gOi0pIA0KPiANCj4gYSkgdGhlIGVh cmx5IHZlcnNpb25zIG9mIHRoZSBJLUQgaW5jbHVkZWQgYSBsb3Qgb2YgJ3JlY29tbWVuZGF0aW9u JyB3b3JkaW5nIGJ1dCB0aGUgT1BTRUMgV0cgcmVxdWVzdGVkIHVzIHRvIHJlbW92ZSB0aGVtICh0 aGlzIGlzIGFsc28gdGhlIHJlYXNvbiB3aHkgaXQgaXMgbm90IGEgQkNQKQ0KPiANCj4gYikgZ2V0 dGluZyBhIHN1bW1hcnkgd291bGQgYmUgYSBuaWNlIGlkZWEgYnV0LCBhZ2FpbiwgdG8gcmVhY2gg dGhlIFdHIGNvbnNlbnN1cywgd2UgaGFkIHRvIG1ha2Ugc29tZSByZWNvbW1lbmRhdGlvbiB3aXRo IHJlc3RyaWN0aW9ucyBhbmQgY2F2ZWF0cyBmb3Igc3BlY2lhbCBjYXNlcyAoZS5nLiwgcmVtZW1i ZXIgdGhlIFVMQSwgUkEtZ3VhcmQgIGRpc2N1c3Npb25zID8pLi4uIGhlbmNlLCBJIGRvIG5vdCB0 aGluayB0aGF0IHRoaXMgaXMgcG9zc2libHkgdG8gbWFrZSBhIHNob3J0IHN1bW1hcnkgd2l0aG91 dCBpbmNsdWRpbmcgdGhlIHJlc3RyaWN0aW9ucy9zcGVjaWZpY3MgLi4uIHNvIHRoZSBzdW1tYXJ5 IGxpc3Qgd2lsbCBiZSB2ZXJ5IHZlcnkgbG9uZyBhbmQgbm90IHZlcnkgdXNlZnVsDQo+IA0KPiBB bGwgdGhlIG90aGVyIGxhc3QgY2FsbCBjb21tZW50cyBhbmQgdGhlIElFU0cgQ09NTUVOVCBwb2lu dHMgIHdpbGwgYmUgYWRkcmVzc2VkIG9uY2UgYWxsIGZlZWRiYWNrIGlzIGNvbGxlY3RlZCwgICBi eSBlaXRoZXIgdXBkYXRpbmcgdGhlIHRleHQgb3IgZXhwbGFpbmluZyBvdXIgcG9pbnRzIG9mIHZp ZXcgb24gdGhlIGNvbW1lbnQuDQo+IA0KPiBUaGFuayB5b3UgYWdhaW4gZm9yIHlvdXIgcmV2aWV3 IGFuZCB0aGUgZGlzY3Vzc2lvbg0KPiANCj4gUmVnYXJkcw0KPiANCj4gLcOpcmljDQo+IA0KPiDv u78tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBUaW0gQ2hvd24gPFRpbS5DaG93 bkBqaXNjLmFjLnVrPg0KPiBEYXRlOiBXZWRuZXNkYXksIDIxIEFwcmlsIDIwMjEgYXQgMTU6NDEN Cj4gVG86IFdhcnJlbiBLdW1hcmkgPHdhcnJlbkBrdW1hcmkubmV0Pg0KPiBDYzogRW5ubyBSZXkg PGVyZXlAZXJudy5kZT4sIG9wcy1kaXIgPG9wcy1kaXJAaWV0Zi5vcmc+LCAibGFzdC1jYWxsQGll dGYub3JnIiA8bGFzdC1jYWxsQGlldGYub3JnPiwgb3BzZWMgd2cgbWFpbGluZyBsaXN0IDxvcHNl Y0BpZXRmLm9yZz4sICJkcmFmdC1pZXRmLW9wc2VjLXY2LmFsbEBpZXRmLm9yZyIgPGRyYWZ0LWll dGYtb3BzZWMtdjYuYWxsQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW09QU0VDXSBPcHNkaXIg bGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLW9wc2VjLXY2LTI1DQo+IFJlc2VudC1Gcm9t OiA8YWxpYXMtYm91bmNlc0BpZXRmLm9yZz4NCj4gUmVzZW50LVRvOiBFcmljIFZ5bmNrZSA8ZXZ5 bmNrZUBjaXNjby5jb20+LCBLaXJhbiBLdW1hciBDaGl0dGltYW5lbmkgPGtrLmNoaXR0aW1hbmVu aUBnbWFpbC5jb20+LCBNZXJpa2UgS2FlbyA8bWVyaWtlQGRvdWJsZXNob3RzZWN1cml0eS5jb20+ LCA8ZXJleUBlcm53LmRlPiwgPGZ1cnJ5MTNAZ21haWwuY29tPiwgUm9uIEJvbmljYSA8cmJvbmlj YUBqdW5pcGVyLm5ldD4sIDxyd2lsdG9uQGNpc2NvLmNvbT4sIDx3YXJyZW5Aa3VtYXJpLm5ldD4s IEd5YW4gTWlzaHJhIDxoYXlhYnVzYWdzbUBnbWFpbC5jb20+LCA8aGF5YWJ1c2Fnc21AZ21haWwu Y29tPg0KPiBSZXNlbnQtRGF0ZTogV2VkbmVzZGF5LCAyMSBBcHJpbCAyMDIxIGF0IDE1OjQxDQo+ IA0KPiAgICBIaSwNCj4gDQo+ICAgIEnigJl2ZSBub3QgeWV0IHNlZW4gYW55IGNvbW1lbnRzIGFz IHByb3Bvc2VkIGJ5IFdhcnJlbiwgYW5kIHRoZSByZXZpZXcgaXMgZHVlICh0aGUgZGVhZGxpbmUg d2FzIGEgc2hvcnRlciB0aGFuIHVzdWFsIG9uZSkuICBJIGNhbiBnbyBhaGVhZCBhbmQgbG9vayB0 byBkZXRlcm1pbmUgdGhlIGNoYW5nZXMgZnJvbSB0aGUgZGlmZiB2aWV3Lg0KPiANCj4gICAgQSBm YWlybHkgbWFpbiBwb2ludCB3YXMgd2hldGhlciBhbnkgc3VtbWFyeSByZWNvbW1lbmRhdGlvbnMg d291bGQgYmUgYWRkZWQsIGdpdmVuIHRoZSBkb2N1bWVudOKAmXMgbGVuZ3RoLCBhbmQgdGhlIHZh cmlhdGlvbiBpbiBzdHlsZSB0aHJvdWdoIHRoZSBkb2N1bWVudCwgd2l0aCBzb21lIHNlY3Rpb25z IGhhdmluZyByZWNvbW1lbmRhdGlvbnMgc3Vic2VjdGlvbnMsIG90aGVycyBub3QuICBUaGVyZSBp cyBhIGxvdCBvZiBnb29kIGFkdmljZSBpbiB0aGUgdGV4dCwgYnV0IGl04oCZcyBhIGxvbmcgcmVh ZCBhcyBpcywgYW5kIHRoZXJl4oCZcyBsaWtlbHkgYSBjb3VwbGUgb2YgcGFnZXMgb2Yga2V5IGJ1 bGxldCBwb2ludHMgdGhhdCBjb3VsZCBiZSBhZGRlZC4NCj4gDQo+ICAgIFdoZW4gaXMgdGhlIGRy YWZ0IGNvbWluZyBiYWNrIHRvIHRoZSBJRVNHPw0KPiANCj4gICAgVGltDQo+IA0KPj4gT24gMTMg QXByIDIwMjEsIGF0IDIxOjU5LCBXYXJyZW4gS3VtYXJpIDx3YXJyZW5Aa3VtYXJpLm5ldD4gd3Jv dGU6DQo+PiANCj4+IEp1c3QgYSBxdWljayBub3RlIHRvIHNheSB0aGFua3MgdG8gVGltIGZvciB0 aGUgZXhjZWxsZW50IGFuZCBkZXRhaWxlZCByZXZpZXcsIGFuZCB0byB0aGUgYXV0aG9ycyBmb3Ig YWRkcmVzc2luZyBpdC4uLg0KPj4gDQo+PiBJIHRvb2sgYSBxdWljayBza2ltIHRocm91Z2ggdGhl IGRpZmZzLCBhbmQgaXQgd2FzIGEgbGl0dGxlIHRyaWNreSBmb3IgbWUgdG8gdGVsIHdoaWNoIGFs bCBvZiB0aGUgY29tbWVudHMgaGFkIGJlZW4gYWRkcmVzc2VkIC0tIGF1dGhvcnMsIGlmIHlvdSBn ZXQgYSBjaGFuY2UsIGNvdWxkIHlvdSByZXBseSBub3Rpbmcgd2hpY2ggY29tbWVudHMgd2VyZSBm b2xkZWQgaW50byAtMjY/DQo+PiBXDQo+PiANCj4+IE9uIFNhdCwgQXByIDEwLCAyMDIxIGF0IDI6 NDYgUE0gRW5ubyBSZXkgPGVyZXlAZXJudy5kZT4gd3JvdGU6DQo+PiBIaSBUaW0sDQo+PiANCj4+ IHRoYW5rcyBzbyBtdWNoIGZvciBhbm90aGVyIGRldGFpbGVkIGxvb2sgYXQgdGhlIGRyYWZ0Lg0K Pj4gWW91ciBmZWVsaW5nIHRoYXQgaXQgaGFzIGJlZW4gaW4gdGhlIG1ha2luZyBmb3IgYSB3aGls ZSBpcyBjb3JyZWN0ICh0ZWxsIG1lIGFib3V0IGl0IDstKSwgc3RpbGwgd2UgdGhpbmsgdGhhdCB0 aGUgb3BlcmF0aW9uYWwgc2VjdXJpdHkgZ3VpZGFuY2UgZm9yIElQdjYgaGFzbid0IGNoYW5nZSBt dWNoIG92ZXIgdGltZSwgYW5kIGl0IG1pZ2h0IGV2ZW4gYmUgbW9yZSBuZWVkZWQgdGhhbiBldmVy IChnaXZlbiBjdXJyZW50IG1vbWVudHVtIG9mIElQdjYgdXB0YWtlKS4NCj4+IEkgd2VudCB0aHJv dWdoIHlvdXIgYmVsb3cgcG9pbnRzLCBhbmQgZm9yIG1hbnkgb2YgdGhlbSBJJ3ZlIHBlcmZvcm1l ZCBhY2NvcmRpbmcgY2xhcmlmaWNhdGlvbnMvZW5oYW5jZW1lbnRzIG9mIHRoZSBkcmFmdC4gQSBu ZXcgdmVyc2lvbiBoYXMgdGhlbiBiZWVuIHVwbG9hZGVkLg0KPj4gDQo+PiBXaXNoIHlvdSBhIGdy ZWF0IHdlZWtlbmQNCj4+IA0KPj4gRW5ubw0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiBPbiBXZWQs IEFwciAwNywgMjAyMSBhdCAwMjoxMjozN0FNIC0wNzAwLCBUaW0gQ2hvd24gdmlhIERhdGF0cmFj a2VyIHdyb3RlOg0KPj4+IFJldmlld2VyOiBUaW0gQ2hvd24NCj4+PiBSZXZpZXcgcmVzdWx0OiBI YXMgSXNzdWVzDQo+Pj4gDQo+Pj4gSGksDQo+Pj4gDQo+Pj4gSSBoYXZlIHJldmlld2VkIHRoaXMg ZG9jdW1lbnQgKGRyYWZ0LWlldGYtb3BzZWMtdjYtMjUpIGFzIHBhcnQgb2YgdGhlDQo+Pj4gT3Bl cmF0aW9uYWwgZGlyZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYg ZG9jdW1lbnRzIGJlaW5nDQo+Pj4gcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLj8/IFRoZXNlIGNvbW1l bnRzIHdlcmUgd3JpdHRlbiB3aXRoIHRoZSBpbnRlbnQgb2YNCj4+PiBpbXByb3ZpbmcgdGhlIG9w ZXJhdGlvbmFsIGFzcGVjdHMgb2YgdGhlIElFVEYgZHJhZnRzLiBDb21tZW50cyB0aGF0IGFyZSBu b3QNCj4+PiBhZGRyZXNzZWQgaW4gbGFzdCBjYWxsIG1heSBiZSBpbmNsdWRlZCBpbiBBRCByZXZp ZXdzIGR1cmluZyB0aGUgSUVTRyByZXZpZXcuPz8NCj4+PiBEb2N1bWVudCBlZGl0b3JzIGFuZCBX RyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIN Cj4+PiBsYXN0IGNhbGwgY29tbWVudHMuDQo+Pj4gDQo+Pj4gVGhpcyBkcmFmdCBhbmFseXNlcyBv cGVyYXRpb25hbCBzZWN1cml0eSBpc3N1ZXMgcmVsYXRlZCB0byB0aGUgZGVwbG95bWVudCBvZg0K Pj4+IElQdjYsIGFuZCBkZXNjcmliZXMgYXBwcm9wcmlhdGUgbWVjaGFuaXNtcyBhbmQgcHJhY3Rp Y2VzIHRvIG1pdGlnYXRlIHBvdGVudGlhbA0KPj4+IHRocmVhdHMuDQo+Pj4gDQo+Pj4gSSBoYWQg cHJldmlvdXNseSByZXZpZXdlZCB0aGUgZHJhZnQgYXMgYW4gT1BTLURJUiBFYXJseSBSZXZpZXcg aW4gSnVseSAyMDE4LA0KPj4+IGFuZCBhZ2FpbiBzaW5jZSB0aGVuLCBzbyBhbSBmYW1pbGlhciB3 aXRoIHRoZSBkb2N1bWVudCBhbmQgaXRzIGhpc3RvcnkuDQo+Pj4gDQo+Pj4gR2VuZXJhbCBjb21t ZW50czoNCj4+PiANCj4+PiBUaGUgZG9jdW1lbnQgaGFzIGV2b2x2ZWQgb3ZlciB0aW1lIHdpdGgg bWFueSB0b3BpY3MgYWRkZWQsIGFuZCBoYXMgYW4NCj4+PiBpbmV2aXRhYmxlID8/P0ZyYW5rZW5z dGVpbj8/PyBmZWVsIHRvIGl0LiAgVGhlIGRvY3VtZW50IHdvdWxkIGJlIG11Y2ggYmV0dGVyIGZv ciBhDQo+Pj4gcmV3cml0ZSwgYnV0IHRoYXQgd291bGQgYmUgc2lnbmlmaWNhbnQgd29yaywgYW5k IHdvdWxkIGRlbGF5IHB1YmxpY2F0aW9uDQo+Pj4gZnVydGhlci4gIFRoZSBtYXRlcmlhbCBpbiB0 aGUgZG9jdW1lbnQgaXMgZ29vZCwgYW5kIHRoZSBhZHZpY2UgaXMgdmFsdWFibGUsIHNvDQo+Pj4g dGhlIGZvY3VzIHNob3VsZCBiZSBvbiBwdWJsaXNoaW5nIGl0IHNvb25lciByYXRoZXIgdGhhbiBs YXRlciwgYW5kIHRodXMgdGhlDQo+Pj4gaXNzdWVzIHdpdGggc3RydWN0dXJlIGFyZSBwcm9iYWJs eSBiZXN0IG92ZXJsb29rZWQuDQo+Pj4gDQo+Pj4gQW4gZXhhbXBsZSBvZiB0aGUgaGlzdG9yaWNh bCBldm9sdXRpb24gb2YgdGhlIGRvY3VtZW50IGFyZSB0aGUgaW5zdGFuY2VzIHdoZXJlDQo+Pj4g dGhlIHNhbWUgdG9waWMgb3MgY292ZXJlZCBtdWx0aXBsZSB0aW1lcy4gIFRoaXMgd291bGQgaWRl YWxseSBiZSBhdm9pZGVkLg0KPj4+IA0KPj4+IFRoZSBzZWN0aW9uIG1vc3QgaW4gbmVlZCBvZiBh dHRlbnRpb24gaXMgMi4xLCB3aGVyZSBtYW55IGFzcGVjdHMgb2YgYWRkcmVzc2luZw0KPj4+IGFy ZSB3ZWF2ZWQgdG9nZXRoZXI6IGFsbG9jYXRpb25zLCBhc3NpZ25tZW50cywgYXNzaWdubWVudCB0 byBob3N0cywgVUxBcywNCj4+PiBzdGFibGUgYW5kIHRlbXBvcmFyeSBhZGRyZXNzZXMsIGV0Yy4g IFRoaXMgbWlnaHQgYmUgYmV0dGVyIHByZXNlbnRlZCBhcyBhDQo+Pj4gc2VjdGlvbiBsaXN0aW5n IGFkZHJlc3NpbmcgcmVsYXRlZCBzZWN1cml0eSBpc3N1ZXMsIHN1Y2ggYXMgcHJpdmFjeSBmb3Ig dXNlcnMsDQo+Pj4gZmlyc3QgaG9wIHNlY3VyaXR5LCBuZXR3b3JrIG1hbmFnZWFiaWxpdHksIGlt cGxpY2F0aW9ucyBvZiBtdWx0aS1hZGRyZXNzZWQNCj4+PiBob3N0cywgYWRkcmVzcyBhY2NvdW50 YWJpbGl0eSAod2hpY2ggaXNuPz8/dCBtZW50aW9uZWQgaGVyZT8pLCBhdm9pZGluZw0KPj4+IHJl bnVtYmVyaW5nIChpZiB0aGF0IGlzIHNlY3VyaXR5PyksIGV0Yy4NCj4+PiANCj4+PiBUaGVyZSBh cmUgYWxzbyBzb21lIHNlY3Rpb25zIHdoaWNoIHN1bW1hcmlzZSByZWNvbW1lbmRhdGlvbnMsIG9y IHJlaW5mb3JjZQ0KPj4+IHRoZW0sIGFuZCBvdGhlcnMgdGhhdCBkbyBub3QuICBGb3IgYSBkb2N1 bWVudCBvZiBvdmVyIDUwIHBhZ2VzLCB3aGljaCBpcyBxdWl0ZQ0KPj4+IGEgbG9uZyByZWFkLCBp dCB3b3VsZCBiZSBkZXNpcmFibGUgdG8gaGF2ZSBhIHN1bW1hcnkgb2YgdGhlIGtleQ0KPj4+IHJl Y29tbWVuZGF0aW9ucywgZWl0aGVyIGF0IHRoZSBlbmQgb2YgZWFjaCAybmQgbGV2ZWwgdG9waWMs IG9yIGFzIGEgc3RhbmRhbG9uZQ0KPj4+IHNlY3Rpb24gYXQgdGhlIGVuZCBvZiB0aGUgZG9jdW1l bnQgd2hlcmUgdGhlIGtleSBwb2ludHMgb2YgZWFjaCAybmQgbGV2ZWwgdG9waWMNCj4+PiBhcmUg c3VtbWFyaXNlZC4NCj4+PiANCj4+PiBJcyBpdCB3b3J0aCBjaXRpbmcgZXhhbXBsZXMgb2Ygc2Vj dXJpdHkgdG9vbGtpdHMgcmVhZGVycyBjYW4gZXhwbG9yZSwgbGlrZSB0aGUNCj4+PiBUSEMga2l0 LCBTSTYgTmV0d29ya3MsIGV0YywgbWF5YmUgU2NhcHk/DQo+Pj4gDQo+Pj4gU3BlY2lmaWMgY29t bWVudHM6DQo+Pj4gDQo+Pj4gcC4zDQo+Pj4gSSBkb24/Pz90IHVuZGVyc3RhbmQgd2h5IE5QVHY2 IGlzIG1lbnRpb25lZCBoZXJlLCB0aGlzIGVhcmx5LiAgSnVzdCBzYXkgdGhhdCBzb21lDQo+Pj4g c2VjdXJpdHkgaXNzdWVzIGhhdmUgSVB2NCBlcXVpdmFsZW50cywgbGlrZSBORCBhdHRhY2tzIGFu ZCBBUlAgYXR0YWNrcywgYW5kDQo+Pj4gc29tZSBkbyBub3QsIGxpa2UgSVB2NiBFSHMgb3IgaG9w IGJ5IGhvcCBEb1MuICAgVGhlIE5BVCBkaXNjdXNzaW9uIHNob3VsZCBiZSBpbg0KPj4+IGEgc3Rh bmRhbG9uZSBzZWN0aW9uLCBhbmQgYmUgbmV1dHJhbCB0aGVyZS4NCj4+PiANCj4+PiBwLjQNCj4+ PiBXaHkgbWVudGlvbiB0aGUgc3BlY2lmaWMgZXhhbXBsZSBvZiBtdWx0aS1ob21lZCBuZXR3b3Jr cz8gICBXaGF0IGRvIHlvdSBtZWFuIGJ5DQo+Pj4gdGhlIGV4Y2VwdGlvbj8gIElzIGl0IHRoYXQg bXVsdGktaG9taW5nIGlzIG91dCBvZiBzY29wZSwgYW5kIHNvIGFyZSB1bm1hbmFnZWQNCj4+PiBu ZXR3b3Jrcz8NCj4+PiANCj4+PiBwLjQNCj4+PiBBZ2FpbiwgTlBUdjYgaXMgbWVudGlvbmVkLiAg VGhpcyBzZWN0aW9uIGlzIHRpdGxlZCA/Pz9hZGRyZXNzaW5nIGFyY2hpdGVjdHVyZT8/Pw0KPj4+ IGJ1dCB0aGlzIGJpdCBvZiB0ZXh0IGlzIGFib3V0IHJlYXNvbnMgZm9yIGdvaW5nIFBBLCBQSSwg b3IgYmVjb21pbmcgYW4gTElSLA0KPj4+IHdoaWNoIGlzIG5vdCBhcmNoaXRlY3R1cmUuDQo+Pj4g DQo+Pj4gcC40DQo+Pj4gSW4gdGhlIDc5MzQgcGFyYSwgUkZDODk4MSBzaG91bGQgYmUgbWVudGlv bmVkIGFzIGl0Pz8/cyBhIHNpZ25pZmljYW50IHJlYXNvbiBvZg0KPj4+IGRldmljZXMgaGF2aW5n IG1vcmUgYWRkcmVzc2VzLg0KPj4+IA0KPj4+IHAuNQ0KPj4+IFVMQXMgYXJlIGFsc28gdXNlZnVs IHdoZXJlIHRoZSBwcmVmaXggY2hhbmdlcywgZm9yIHN0YWJsZSBpbnRlcm5hbCBhZGRyZXNzaW5n DQo+Pj4gYXMgdGhlIGdsb2JhbCBwcmVmaXggY2hhbmdlcz8gIFR5cGljYWxseSBpbiByZXNpZGVu dGlhbCBuZXR3b3Jrcy4NCj4+PiANCj4+PiBwLjUNCj4+PiBTZWN0aW9uIDIuMS40IGlzIHJlYWxs eSBhYm91dCBjaG9pY2VzIGluIGFkZHJlc3MgYXNzaWdubWVudCB3aXRoaW4gYSBuZXR3b3JrLg0K Pj4+IA0KPj4+IHAuNg0KPj4+IFNvbWUgb2YgdGhlc2UgcGFyYXMgc2hvdWxkIGJlIGluIGEgc2Vj dGlvbiBhYm91dCBJUHY2IG5ldHdvcmsgcmVjb25uYWlzc2FuY2UsDQo+Pj4gaG93IHRvIGJlc3Qg bWl0aWdhdGUgYWdhaW5zdCBzY2FubmluZywgYW5kIGhvdyB0byBpbnZlbnRvcnkgeW91ciBvd24g bmV0d29yaw0KPj4+IGVsZW1lbnRzLg0KPj4+IA0KPj4+IHAuNg0KPj4+IEFsbCBtZW50aW9ucyBv ZiA0OTQxIHNob3VsZCBiZSByZXBsYWNlZCB3aXRoIDg5ODEuDQo+Pj4gDQo+Pj4gcC43DQo+Pj4g Q2FuIHVzZSA3NzIxIGFuZCA4OTgxIHRvZ2V0aGVyLg0KPj4+IA0KPj4+IHAuNw0KPj4+IFdoeSBh cmUgREhDUCBhbmQgRE5TIGxpbXBlZCB0b2dldGhlcj8gIFRoZSBETlMgaXMgb25seSBhYm91dCBE TlNTRUMsIHNvIGNhbGwgaXQNCj4+PiB0aGF0Pw0KPj4+IA0KPj4+IHAuNw0KPj4+ID8/P0V2ZW4g aWYgdGhlIHVzZSBvZiBESENQPz8/IC0gdGhpcyByZWFkcyBiYWRseS4gIFJhdGhlciA4NTA0IHRh bGtzIGFib3V0IHRoaXMgaW4NCj4+PiA2LjUsIHdoZXJlIFJGQzc4NDQgaXMgbWVudGlvbmVkIGZv ciBleGFtcGxlLiAgVGhpcyBzaG91bGQgYmUgaW4gYSB1c2VyIHByaXZhY3kNCj4+PiBzZWN0aW9u IChpZiB0aGlzIGRvY3VtZW50IGhhZCBvbmUpLiAgU2VjdGlvbiA4LjQgaXMgYWxzbyB1c2VmdWwg YWR2aWNlLg0KPj4+IA0KPj4+IHAuOA0KPj4+IFRoZSBmaXJzdCBwYXJhIGlzIHZlcnkgbXVkZGxl ZC4NCj4+PiANCj4+PiBwLjgNCj4+PiBJbiAyLjEuNyB0aGlzIGNhbiBhbHNvIGJlIHVzZWZ1bCBm b3IgQUNMIGNvbnRyb2xzLCBpZiBvbmUgYWRtaW4gLyBjb250cm9sDQo+Pj4gc3lzdGVtIHNpdHMg aW4gYSBwcmVmaXggb2YgaXRzIG93bi4NCj4+PiANCj4+PiBwLjEwDQo+Pj4gVGhpcyBpcyByZWFs bHkgYWJvdXQgaGFuZGxpbmcgb2YgZnJhZ21lbnRlZCBwYWNrZXRzICh0aGUgdG9waWMpIG5vdCB0 aGUNCj4+PiBmcmFnbWVudCBoZWFkZXIgaXRzZWxmIEFsc28gdGhpcyBpcyBjb3ZlcmVkIGluIDIu My4yLjEgYXMgd2VsbC4NCj4+PiANCj4+PiBwLjEwDQo+Pj4gSW4gMi4yLCB0aGUgaW50cm8gY2Fu IHNheSB0aGVzZSBpc3N1ZXMgaGF2ZSBwYXJhbGxlbHMgaW4gSVB2NC4NCj4+PiANCj4+PiBwLjEx DQo+Pj4gRmlyc3QgbGluZSwgc2F5IHRoZSBhdHRhY2sgY2FuIHR5cGljYWxseSBoYXBwZW4gZnJv bSBhIGxhcmdlIGFkZHJlc3Mgc2NhbiBpZg0KPj4+IHBlcm1pdHRlZCBpbnRvIHRoZSBuZXR3b3Jr Pw0KPj4+IA0KPj4+IHAuMTENCj4+PiBCdWxsZXQgMSAtIHRoYXQgY29udHJhZGljdHMgdGhlIGNv bW1lbnRzIG9uIHByZWRpY3RhYmxlIGFkZHJlc3NpbmcuDQo+Pj4gQnVsbGV0IDIgLSBob3c/ICBT b21lIGNsdWVzIGhlcmUgd291bGQgYmUgdXNlZnVsLg0KPj4+IA0KPj4+IHAuMTINCj4+PiA/Pz9D dXJyZW50Pz8/IC0gcmVhbGx5PyBBbGwgY3VycmVudCBpbXBsZW1lbnRhdGlvbnM/ICBEZWxldGUg Pz8/Y3VycmVudD8/PyBvciByZXBsYWNlDQo+Pj4gd2l0aCA/Pz9uYWl2ZT8/PyBtYXliZS4NCj4+ PiANCj4+PiBwLjEyDQo+Pj4gPz8/Q29tbXVuaWNhdGUgZGlyZWN0bHk/Pz8gLSBhdCBMMj8gIElm IHNvLCB3aHk/DQo+Pj4gDQo+Pj4gcC4xMg0KPj4+IEFuIGV4YW1wbGUgb2YgYSByZWNvbW1lbmRh dGlvbnMgc2VjdGlvbiBoZXJlLCB3aGVyZSBvdGhlciBzZWN0aW9ucyB3aXRoIGFkdmljZQ0KPj4+ IGFyZSBub3QgdGl0bGVkIGFzIHN1Y2guIFNlZSB0aGUgR2VuZXJhbCBjb21tZW50IG9uIHRoaXMu DQo+Pj4gDQo+Pj4gcC4xMw0KPj4+ID8/P1RyaXZpYWw/Pz8gY2FzZXMgLSBhcmVuPz8/dCB0aGVz ZSBjb21tb24gb25lcywgbGlrZSBlZGdlIHN3aXRjaGVzIGluIGFuIGVudGVycHJpc2U/DQo+Pj4g DQo+Pj4gcC4xMw0KPj4+IFdoeSA/Pz9ob3N0aWxlPz8/PyAgRGVsZXRlPw0KPj4+IA0KPj4+IHAu MTQNCj4+PiBJbiAyLjMuNSBsYXN0IHBhcmEsIHdoYXQgYWJvdXQgbUROUywgQm9uam91cj8gICBU aG91Z2ggdGhlIEROUyBTRCB3b3JrIGlzIG5vdw0KPj4+IG9uIHVuaWNhc3QgZGlzY292ZXJ5Lg0K Pj4+IA0KPj4+IHAuMjENCj4+PiBNYXliZSBhZGQgaGVyZSA4MDIuMXggYXMgYW4gZXhhbXBsZSBv ZiB0aGUgdmFsdWUgb2YgUkFESVVTIGxvZ3MsIGFuZCBhZGQgaW4NCj4+PiBoZXJlIGFzIGJ1bGxl dHMgaW5mbyBoYXJ2ZXN0ZWQgZnJvbSBzd2l0Y2hlcyBhbmQgKHNheSkgcm91dGVyIE5EUCBzeXNs b2cNCj4+PiAodGhvdWdoIHRoYXQ/Pz9zIEkgc3VwcG9zZSB0aGUgNHRoIGJ1bGxldCkuICBUaGVz ZSBhcmUgbWVudGlvbmVkIGluIDIuNi4xLjcgYnV0DQo+Pj4gc2hvdWxkIGJlIHNwbGl0IG91dCBh dCB0aGUgc2FtZSBsZXZlbCBhcyB0aGUgb3RoZXIgdG9waWNzIGhlcmUuDQo+Pj4gDQo+Pj4gcC4y OA0KPj4+IFRoZSB0ZXh0IGlzIDIuNi4yLjIgcmVwZWF0cyBlYXJsaWVyIHRleHQuDQo+Pj4gU2lt aWxhcmx5IHRleHQgaW4gMi42LjIuMyBpcyByZXBlYXRlZCBmb3JtIGJlZm9yZS4NCj4+PiANCj4+ PiBwLjI5DQo+Pj4gSW4gMi42LjIuNCBwcmVzdW1hYmx5IGFsc28gYSByYXBpZCBncm93dGggaW4g TkQgY2FjaGUgc2l6ZSBpcyBhbiBpbmRpY2F0b3IuDQo+Pj4gDQo+Pj4gcC4yOQ0KPj4+IEluIDIu NyBwb2ludCB0byBSRkMgNDk0Mg0KPj4+IA0KPj4+IHAuMzANCj4+PiBTaG91bGQgUkZDIDYwOTIg YmUgbWVudGlvbmVkIGhlcmU/DQo+Pj4gQW5kIHRoYXQgdGhlIGJlc3QgZGVmZW5jZSBhZ2FpbnN0 IElQdjYgYXR0YWNrcyBuID8/P0lQdjQgb25seT8/PyBuZXR3b3JrcyBpcyB0bw0KPj4+IGRlcGxv eSBhbmQgbWFuYWdlIElQdjY/DQo+Pj4gDQo+Pj4gcC4zMQ0KPj4+IEZpcnN0IGJ1bGxldCBvbiB0 aGlzIHBhZ2UgLSBidXQgaXNuPz8/dCB0aGlzIHRoZSBzYW1lIGFzIGlmIHRoZSB0cmFmZmljIGlz IG5vdA0KPj4+IHR1bm5lbGxlZD8gIFdoeSBkb2VzIHR1bm5lbGxpbmcgYWRkIHRoZSByZXF1aXJl bWVudD8gIFRoZSBzYW1lIGFwcGxpZXMgb24gdGhlDQo+Pj4gZmlyc3QgcGFyYSBvbiBwLjMyDQo+ Pj4gDQo+Pj4gcC4zMQ0KPj4+IE1heWJlIHNheSBoZXJlIHRoZSBtaXRpZ2F0aW9ucyBjYW4gYWxz byBicmVhayB0dW5uZWwgYnJva2VycyAobWlnaHQgYmUgZGVzaXJlZCwNCj4+PiBidXQgdXNlcnMg d2lsbCBub3RpY2U/Pz8pPz8/LiBNYXliZSB0dW5uZWxzIHRvIHNwZWNpZmljIGJyb2tlcnMgY2Fu IGJlIGFsbG93ZWQuDQo+Pj4gDQo+Pj4gcC4zMg0KPj4+IElTQVRBUCwgaW4gMjAyMT8gIFNhbWUg d2l0aCA2cmQuICBHZW5lcmFsIGFkdmljZSBzaG91bGQgYmUgZGVwbG95IG5hdGl2ZSwgYXZvaWQN Cj4+PiB0dW5uZWxzLg0KPj4+IA0KPj4+IHAuMzMNCj4+PiBTYW1lIGZvciA2dG80Lg0KPj4+IA0K Pj4+IHAuMzQNCj4+PiBUZXJlZG8gdGhvdWdoLCBpcyB0aGF0IHN0aWxsIGluY2x1ZGVkIGluIFdp bmRvd3MgYW5kIFhCb1gsIGFzIGEgTVMgdGhpbmc/DQo+Pj4gDQo+Pj4gcC4zNg0KPj4+IE1heWJl IGNpdGUgR2VvZmYgSHVzdG9uPz8/cyBibG9nIG9uIHRoaXMgLSBpdD8/P3MgdmVyeSBnb29kLiAg TWF5YmUgdGhlcmU/Pz9zIGEgbW9yZQ0KPj4+IHJlY2VudCB1cGRhdGUgdGhvdWdoIC0NCj4+PiBo dHRwczovL2Jsb2cuYXBuaWMubmV0LzIwMTYvMDYvMDkvbGV0cy10YWxrLWlwdjYtZG5zNjQtZG5z c2VjLy4gSG9zdCBDTEFUIGlzDQo+Pj4gYXBwbGljYWJsZSBoZXJlPyAgKEhlbmNlIGEgc2l0ZSBz aG91bGQgc3VwcG9ydCB0aGUgNjRQUkVGIFJBIG9wdGlvbj8gIFJGQzg3ODENCj4+PiANCj4+PiBw LjM4DQo+Pj4gSW4gMi44LCB0byBiZSBmYWlyIElQdjQgaXMgYWxzbyBoYXJkZW5lZCBhIGxvdCBv ZiBsYXRlIGR1ZSB0byB0aGUgcHJldmFsZW5jZSBvZg0KPj4+IHVzZSBvZiBkZXZpY2VzIGluIFdp RmkgaG90c3BvdHMgZXRjLg0KPj4+IA0KPj4+IHAuMzcNCj4+PiBBbHNvIFJGQzYwOTIgb24gc2Vj dGlvbiAzLjE/DQo+Pj4gDQo+Pj4gcC4zOA0KPj4+ID8/P1doZXJlIFJGQzE5MTggYWRkcmVzcyBh cmUgb2Z0ZW4gdXNlZD8/PyAtIGFkZCA/Pz9vZnRlbj8/PywgdGhlIHRleHQgaW1wbGllcyBhbGwN Cj4+PiBlbnRlcnByaXNlcyB1c2UgdjQgTkFULg0KPj4+IA0KPj4+IHAuNDENCj4+PiBPbmx5IDIg bm9ybWF0aXZlIHJlZmVyZW5jZXM/DQo+Pj4gDQo+Pj4gTml0czoNCj4+PiANCj4+PiBwLjENCj4+ PiA/Pz9UaGUgSW50ZXJuZXQ/Pz8gLSB5b3UgcHJvYmFibHkgbWVhbiA/Pz9hbiBJU1AgbmV0d29y az8/Pw0KPj4+ID8/P0Rlc2NyaWJlcyB0aGUgc2VjdXJpdHk/Pz8gLSBkZWxldGUgPz8/dGhlPz8/ DQo+Pj4gDQo+Pj4gcC40DQo+Pj4gPz8/V2hpY2ggYXJlIHRoZSBzd2l0Y2g/Pz8gZGVsZXRlID8/ P3doaWNoIGFyZT8/Pw0KPj4+IA0KPj4+IHAuOA0KPj4+IFZhcnlpbmcgLT4gdmFyaW91cw0KPj4+ IA0KPj4+IHAuMTANCj4+PiBpcHY2IC0+IElQdjYNCj4+PiANCj4+PiBwLjE4DQo+Pj4gUm91dGVy IHByb2Nlc3NvciAtIGFkZCByIHRvID8/P3JvdXRlPz8/DQo+Pj4gDQo+Pj4gPz8/DQo+Pj4gVGlt DQo+Pj4gDQo+Pj4gDQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+PiBPUFNFQyBtYWlsaW5nIGxpc3QNCj4+PiBPUFNFQ0BpZXRmLm9yZw0KPj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzZWMNCj4+IA0KPj4gLS0g DQo+PiBFbm5vIFJleQ0KPj4gDQo+PiBDZWxsOiArNDkgMTczIDY3NDU5MDINCj4+IFR3aXR0ZXI6 IEBFbm5vX0luc2ludWF0b3INCj4+IA0KPj4gDQo+PiAtLSANCj4+IFRoZSBjb21wdXRpbmcgc2Np ZW50aXN04oCZcyBtYWluIGNoYWxsZW5nZSBpcyBub3QgdG8gZ2V0IGNvbmZ1c2VkIGJ5IHRoZQ0K Pj4gY29tcGxleGl0aWVzIG9mIGhpcyBvd24gbWFraW5nLiANCj4+ICAtLSBFLiBXLiBEaWprc3Ry YQ0KPiANCj4gDQoNCg== From nobody Thu Apr 22 04:11:47 2021 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6253B3A11B8; Thu, 22 Apr 2021 04:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.618 X-Spam-Level: X-Spam-Status: No, score=-9.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=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=Caam24u8; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=fyFEg1MS Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULaOX-caKGX2; Thu, 22 Apr 2021 04:11:35 -0700 (PDT) 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 5DAEA3A11AF; Thu, 22 Apr 2021 04:11:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20782; q=dns/txt; s=iport; t=1619089895; x=1620299495; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=qOunUvTedYgWZUGaJLMQVa1Zqm51ZFy0HHd6h9pkVgU=; b=Caam24u8WLP+se8SqTaH0bRp84fRfmk9o+1wu1nM6lyfm6zF9CZ0jQwQ 8ki+5tCNyMRNQ4dzBZYXSeeVWoqmcaU8mODU5Or+dCo1VC6XZCeIS6hau +/SoXpJgVofiXTIHN0mCjGht/MeosQjNx6i/zDZG6lFR2BSirycXiAYbs U=; X-IPAS-Result: =?us-ascii?q?A0A+AABvWYFgmIYNJK1aDgwBAQEBAQEBAQEBAwEBAQESA?= =?us-ascii?q?QEBAQICAQEBAUCBUoFTKSh+WhIkMQKEQYNIA4U5iGoDijKEeooVgUKBEQNUC?= =?us-ascii?q?wEBAQ0BAR0LCgIEAQGEUAIXgWACJTgTAgMBAQEDAgMBAQEBAQUBAQECAQYEF?= =?us-ascii?q?AEBAQEBAQEBaIVQDYZEAQEBAwEBASEEDQwBASwLAQsEAgEIEQECAQIBAgImA?= =?us-ascii?q?gICHwYLFQIBBQgCBA4FgnEBglUDDiEBDj6ccwKKH3p/M4EBggQBAQaBMwGDf?= =?us-ascii?q?Q0LghMDBoEQKgGCeIJxgRqEKYIqJxyBSUKBEyccgV+BAD6CHkIBAYErARIBI?= =?us-ascii?q?QcQI4JdNoIrgVkBBGwCPCYBAyIQERAUDjkFGx1LARgFEQEBFxEJAh4Pi2aEW?= =?us-ascii?q?IMbQowDmUIJMFsKgw6JcIx0eYU8BCGDUD6QXJAjlzeJZIMZj2MLbYNfAgQCB?= =?us-ascii?q?AUCDgEBBoEjSCFrcHAVOyoBggoBATJQFwIOVo1JGYELAQiCQ4RZO4UERAFzD?= =?us-ascii?q?SsCBgEJAQEDCXyJTSyBPF4BAQ?= IronPort-PHdr: A9a23:GiAcWRJcuOORKo2leNmcuZMyDhhPgJ39IxIV55w7irlHbqWk+dH4M VfC4el25HfLXJ7QrftPzffV4OjsWm0FtJCGtn1KMJlBTAQMhshemQs8SNWEBkv2IL+PDWQ6E c1OWUUj8yS9Nk5YS8T/fFaUq3b08D1BUhn6PBB+c+LyHIOahs+r1ue0rpvUZQgAhDe0bb5oa husqgCEvcgNiowkIaE0mXP0 IronPort-HdrOrdr: A9a23:+vTx3qEgMISPyL8dpLqF+ZXXdLJzesId70hD6mlYcjYQWtCEls yogfQQ3QL1jjFUY307hdWcIsC7IE/03aVepa0cJ62rUgWjgmunK4l+8ZDvqgePJwTXzcQY76 tpdsFFZ+HYJVJxgd/mpCyxFNg9yNeKmZrY+tv25V0Fd3AMV4hL6QBlBgGHVm1aLTM2RaYRPp ya+8ZBun6EcXMYcsy0ChA+Lpb+jvfMk4/rZgNDOgUu7xOAgSjtxLnxFRWZ2Rl2aUIN/Z4J92 /Znwvlopiyqv3T8G6c60b/zbRz3OHgxNxKGdCWhqEuSgnEpw60aO1aKsa/lR8vpuXH0idOrP DtpFMaM913+zfteAiO0GfQ8i3B9Bpr1HP401+fhhLY0I7EbRY3EdBIi44cUjax0TtbgPhG3K hG332UuvNsZHuq9kmQlru4NS1CrUa6rWEvluQelRVkIPYjQYVMpo8S9l49KuZnIAvG6ZsqGO QrLMbQ6Oc+SyLjU1nlv3JiyNHpY3IrHh3ueDl6huWp1VFt7RRE5npd4PZasmYL9Zo7RZUBzf /DKL5UmLZHSdJTRb5hBc8aKPHHT1DlcFbpCia/MF7nHKYINzbmsJjs+og44+msZdgh0IYyop LcS1lV3FRCP37GOImr5tlm4xrNSGKyUXDG0cdF/aV0vbX6Wf7NPTCcTkst1++tue8WDMGee/ vbAuMQP9bTaU/VXapZ1Qz3XJdfbVMEVtcOh9o9U1WS5s3RLInnsfHabebTKLLhHS1MYBKnPl IzGBzIYOlQ5EGiXXH1xDLLXWn2R0D59ZVsVKjWltJjkLQlB8lpiEw4mF657saEJXlpqaotZn ZzJ7vhj+e+rWmy9mDY8nVxNnNmfx1oyYSld0kPiR4BMkvyf7pGkc6YY3pu0HyOIQI6SdjXHg 5Zr1F+4rm2MJSU2CAnB7ucQySnpkpWgEjPY4YXm6WF68ugUIg/FIwaVKt4EhiOCwZ4gh9wqG BIaBYNQ0jWEj+Gs9T+sLUkQMXkM/VsigaiJsBZ7U/FvUKHvMc1Wz8wRDi1S/Oahg4oWhtZjl B86LUknbKFgDqjQFFP3dgQARlpUiC3CKgDJBmZbI9U84qbCT1YfCOvv3imrD0dPkDt7F4fg2 T9Kzb8Q4C6PnNt/lZC0qjr91tocH66ZEwYUAEnjaRNUULbp310zeiHIo203mf5UCpd/sgtdB fYfDAVPgRig+qS6SfQsjODGXI6r69eYdD1BKg/cr3Vx3OmIJCJk6ZDBPNP4JN5LrnVw502eP 6EdxTQJD31DP5B4X3nml81fCZzs3UqivXuxVns63W5xmc2Bb7ILE1hXKxzGaDR00H0A/KJ2o 5+l9Q7oK+5NXjwcMePzcjsHnR+AwKWpW69VOczr59I+ao0qbtoBpHeFT/FzmtO0hl7LMD6ki olMelGyaGEPo9kZMoJfS1FulIvidSUNUMu9hXsHfVWRyBls1bLe9eSp7bYo7smBUOM4AP2JF mE6iVYu/PIRTGK27IWA785SF4mJ3QU+TBn5qePZofQAAKle6VY8F22PmS0fbVdRKKGcI9g5S pS8pWNhauaZiD40AffsX9nOapI6X+gWt73DwSWG+JEmubKd2ikk++v+oq0gzj2QzfgNBhdio 1BaEAKbsNMzjMll5Y61yCuSqrx5kIp+mEulg1PhxrowMyh5myeAERNdQveiZ9SVSNIMneJgd /emNLonEjV8XxAw93bCExUfttSANAeQYj8Mjd2JaErzcqV1rtqhj4GfQwnAGE9gi3sxu9q3b +23/PJRu3pYE2YT24p6HpCHY57nisitGFGfYy/9PuGE3AqKtI= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,242,1613433600"; d="scan'208";a="674230284" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Apr 2021 11:11:34 +0000 Received: from mail.cisco.com (xbe-aln-007.cisco.com [173.36.7.22]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 13MBBXIT008242 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Thu, 22 Apr 2021 11:11:33 GMT Received: from xfe-aln-005.cisco.com (173.37.135.125) by xbe-aln-007.cisco.com (173.36.7.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Thu, 22 Apr 2021 06:11:33 -0500 Received: from xfe-aln-003.cisco.com (173.37.135.123) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Thu, 22 Apr 2021 06:11:33 -0500 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-003.cisco.com (173.37.135.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Thu, 22 Apr 2021 06:11:33 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TYG7ZYVWXY5STyGy3wMWJxN9F5zhyRSi3qfgIYUYh92zBW8/+r2LcdWmCxkjOu71yhcW1OzdcNqBUJoNMNzysD6IBuIk0pkAez8BAsW0UQ+MUTLfzvr0WVP1tSbDJGVFiDTmUOKYJsXgtDKwLHt7NKvrvp/8MeAxrgeUAbZA7+SSG+l0yBFsD7vXZwdCAk5JDwO1NpRovw30yMLJK8j8L/dBwJrZJiMUT6kFSHDhbqGp1TiE4b6oaJ4iCbMN9yOo3MJxjbyW0Or/m7Ojw9zsuXXXIRRFV6nKCELIkULPwCJe97Ki9pPiEgYVZKk9JrNH1A+sb3kon7rTqr8oMxJw1g== 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=qOunUvTedYgWZUGaJLMQVa1Zqm51ZFy0HHd6h9pkVgU=; b=XjWQY3zoXDK+xnNHQX8SGs3VwGym/LI4hDizzQfkUpvAkvOrr+iXZsEHqoyfphMsRESrLbqHSW80d4m+JqYfYsGW7zNrby8y5PEuXskA0tDcjgHc0OoQNVJIdNMWnGkRJivfsrZApkqm1S7s5jkCgxObZMpo94fbBXDiNDrJsD9DPGQGdDzNlhwpuVlJQYyOP2/EmQg0UfXph2yAAWGc4blb2SAbZgR/TZqrW6iKFDwfja3Go0NQZeLTL5zg5HmSK+dqAqm/Uf7Ezta/JxeiCZp1rfIyZYLd/u41uZohY2jXoVnsEC7PGoD5QT5vOi74UrKP1K/bd6aei9ku+lG8yg== 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=qOunUvTedYgWZUGaJLMQVa1Zqm51ZFy0HHd6h9pkVgU=; b=fyFEg1MSLQJjKlSStoPOqUwUGQ2SjCTYIPRoSBzn3c+7Zgei+6Z9PfqPDr5FwPCJ8v17VOt9Mu/VgAQfW3sYrS/Uh7DoOHEr2Y/4KOo7XpjHFIsw9Bp4/Gj5GefVdL4NVLwH2CKxfAfKk/W6byKd8uXlrgFsfpLseFwC5QO0oUg= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB4902.namprd11.prod.outlook.com (2603:10b6:510:37::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.18; Thu, 22 Apr 2021 11:11:32 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::dcdf:3910:b85d:6eba]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::dcdf:3910:b85d:6eba%7]) with mapi id 15.20.4042.018; Thu, 22 Apr 2021 11:11:32 +0000 From: "Eric Vyncke (evyncke)" To: Tim Chown CC: Warren Kumari , Enno Rey , ops-dir , "last-call@ietf.org" , "opsec wg mailing list" , "draft-ietf-opsec-v6.all@ietf.org" Thread-Topic: [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-25 Thread-Index: AQHXMKgZj/+7ZqKZcU+tLkkn5Tbgbaq/BqqAgAB0GACAAO/6AIAAJfmA Date: Thu, 22 Apr 2021 11:11:32 +0000 Message-ID: <4BDF1579-CB77-4B1F-ADCE-8813C859FDEB@cisco.com> References: <161778675730.8077.2835666586607648895@ietfa.amsl.com> <20210410184555.GE91991@ernw.de> 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/16.48.21041102 authentication-results: jisc.ac.uk; dkim=none (message not signed) header.d=none;jisc.ac.uk; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:f511:d5df:8e87:fb6c] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b00cd789-fca4-46c7-bfbb-08d9057f6292 x-ms-traffictypediagnostic: PH0PR11MB4902: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gf4ZS7XqsJ9ruPRtHlGxvl87G7FJ5dyD4/zodhgFBwgDsRMYWKtHLkVUAdboYQvuDrZQ2oZRc2L0xpzf9oZPUBgs0sRi/rGXgDcyDRW11KEdJK0Y6eT7Vct3dPLFPbyxF3/PMKFzEyQdFFR52UWnDdbtoqHpJu7m7dPEu/SikAAxS4rDDxcavh6XtU3oV9otnXYFZmnvl7AYot5R8B+BIhrmwBL7zhGwc4Cr8QrdcH6I58fsIoeWAgfIhWW3kK4Yz/0S0yiv04SQF2LY1HBRjVw3UhlY2+l84zglSo+4Z0jJ+72PO269o/3cJ6fGbfjEM0yQoU0T432OuxERDAH5J+iRatnf/nc3tuEiEqvGUSHy2Ut+XSS3fhG3RSb8DKPQklbaNCfWd3qab0PLrqecpvvaaMj8Dx4I2sQ8oHiYcfftZ0Ry93vJwybyFu6uT3v0O0IDt9uqyg4Hx5Lay1x3mja+SmQw3dDV2AveZ96g4rY8QSSA28/7eCnZ8hf4E72fXymQuYQ+pcSljfozAGdInlCdOJnOkePSpudQDpWBVbxHV3aJirCv0hv+DZLduXcd60xwHexo+merAdmv/dSUaVV5P44eCZxQP4cH+LCZdyLcgsZ85UCUuNfv+ZuOvMaqRHwbfwocrMeZw0hauwM4MEx1AJugqq09A6HJgnPGKMdAsZx2vPAALBPEaGv6dzbJZGg/VuL209TmINNmsYUidx0YnKhy/Oz1j/8HwQAnrM4= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(136003)(346002)(366004)(376002)(396003)(71200400001)(36756003)(122000001)(66476007)(86362001)(4326008)(66574015)(33656002)(6512007)(8936002)(2906002)(478600001)(6916009)(2616005)(966005)(53546011)(6506007)(64756008)(83380400001)(8676002)(66946007)(6486002)(38100700002)(66446008)(76116006)(186003)(91956017)(54906003)(30864003)(316002)(5660300002)(66556008)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?d1A5MWNXSkN4TzQrQlgySlRCYUU2cDBKemp2Vzd2S0dIY0daSm5BUXNJaHlH?= =?utf-8?B?UE1kYWdxU09YeXZnZjVHZmN5SDVmbzFpZlJJSFdqY25OM1FZdEtsb2JDcEU5?= =?utf-8?B?OEMycGg1ZTE1b1VmeHVqM0VuRWY2ajVqaC8ydmhPNDV1bDRRN0J5c0FXMmQ1?= =?utf-8?B?aDZjMXJZUnlnTkFhVEhJQ1h1RVBOZlZUVFUwdW9qSlhxU3hRclQ0ZitGZCtz?= =?utf-8?B?MTF5RUFhZEtyaXhOZFU5cjEvSEs1dS9XL0pKcDRPa0thdW5UdjhzT0ZRL2Vw?= =?utf-8?B?eXNTWndYdkF5NkE5UzZhN0h0bnlEV2FUNE51cVVIaDlVakdUNmlVMklacFpy?= =?utf-8?B?TTVVU09TWjYzWk5zd1NsejVlWUVpZ0lQcXoyUVJyMFg5Qk1tK1NJTUh2c1Qz?= =?utf-8?B?MlZWbFBSNHd0OWlWMVFqd1ZsNDROOE5xVFVpWHV3M2VEUnByYjVoWjBIWk9D?= =?utf-8?B?QlhMMmQxT3FwUk5rWFJ6V2piRTlsallybGFVMlhKQzhPT3RIekdiczJMWVlu?= =?utf-8?B?eUZhSVc4ZGcwUmRoMkpxRlFQM3h6RTZsWmtUOURqSlpHS3crU3hJWkJyTm9R?= =?utf-8?B?Y2JJNFRBR242aGJGaUFFRzdUaEtaTTBUQVgyeXhXZnVRMzFsU0ZKckw5dkZO?= =?utf-8?B?bEQ5a0huYklLQU9DRWNBUHEzRUd2VHlwZnpwbCtTaVNPcUlqczhBbmhTNDlv?= =?utf-8?B?S29rS1FYUGZXQVNQMUtDMU8wc3hXR09QTFdpeTZ2ZG9CbUlTcHF2VWNrN20z?= =?utf-8?B?MW53SzhOZHlZa1oyeGFKMG5kUHhKQ3RaLy9YTmwvajVIZzFOcW9mMkNDbjFN?= =?utf-8?B?SzZVYnJrN2VVODVDUHdlZzA0Nk5sbW16eWJkQnNVc3Bwd2sxOWNFTkIvSGZh?= =?utf-8?B?akl3NzlYNXFtQVd3QTh5QWFRbDJKVEZjZWhuWkNaOE11cDZxTDd1VENrb3B5?= =?utf-8?B?VFNscHFzdDhxV1ZxL3IrbHJBYm5VWGo1R2pZZzRXYS9RNEkraFQ0Wkg3L2ZF?= =?utf-8?B?ZEhQWlE4cnM4WkdXY3dISURudGtLclU2YWNKSlZuaHUyK1FNRDI3WWZUWkVZ?= =?utf-8?B?bmFkdG5EczUrNGNhWTdVWURFU3BYTWtSaWIzYzRsYmN1MWtyWDJ0WGkxcmFw?= =?utf-8?B?ekJGQWY2OERkN1VPcUVuMzA3UEtZdysxZmkrRkkyZ1c2SkVPZEQ2Mk5uY0VO?= =?utf-8?B?UlRRTGxpWEg3eG5ySXVNU01oazAxelhnU1NlSUt4ZWlwUitnOG5UanhGbGpE?= =?utf-8?B?ZHMxQXhZY3NhM21DbDExRzI1RUdxZGF2NlY2UWtINCtYUWMyelFRRVF6ZmZR?= =?utf-8?B?RmpwZGNIajlGbHVwai9EaTNuQ3BvQ3Q4eFI5TUdhVjdiZDFkdkRYZi81ZjAx?= =?utf-8?B?ZlZMbWtRdVpmZHkrVHYvYlZCV0doZEJzanF4YjdYMWluOXpoVlo1a2FaMjlV?= =?utf-8?B?VGtKc0tyUXVJSFFaVllwK1RQdEMrS2FSUXcza3ZZdzFjbjkrYThyZmZ3VjZC?= =?utf-8?B?ZmtSRHRVNmlsYW1FWVBNMUFCaWNhV3NISVh2TXM4MjhzS0Q4UzR2dTh0bUx6?= =?utf-8?B?TGxqTzBrL3d0ekxrMjBzMmhsalRkRDVNM0ZuVnZhMTVsK01mRnFld1MxTFJB?= =?utf-8?B?eFREQjErdFpHRjMrd3J3VFMzbkZXMDRYYTBjejJlcHRHTXlKb0YyUzJ2dEww?= =?utf-8?B?RW9BaG43YzM2VFRJUUtpc05IOGFHOGFWcWFmQ1h5T0lEZHllZXRTaTI1V245?= =?utf-8?B?TEtTOVdqUlhWdjBTZW91S3Z1V2xmRTh1dTVPa3JwQ3B3RnVoWXZiOXZ0bWsv?= =?utf-8?B?Nk8vSTRyaVFOODdiek13bmhubUw0aENSNFBYWU5jK1JCcGxqL0JUcmlFYzVp?= =?utf-8?Q?99mSIMUyybNaE?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <09972292F85FB645954CC981F9CEAFCD@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b00cd789-fca4-46c7-bfbb-08d9057f6292 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2021 11:11:32.0703 (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: u78gaIDnhMsNwFcjOTaBrWIfSbwkpAr1bYkjeTD2oELrE4QSCmgW2DG7c5JMPf6p8dEF0DdNzNBbJl2p8lFF/Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4902 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.22, xbe-aln-007.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-25 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2021 11:11:42 -0000 VGhhbmsgeW91IFRpbSBmb3IgdGhlIHJlLWNoZWNrIG9mIHRoZSBkb2N1bWVudC4NCg0KUmVnYXJk cw0KDQotw6lyaWMNCg0K77u/LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFRpbSBD aG93biA8VGltLkNob3duQGppc2MuYWMudWs+DQpEYXRlOiBUaHVyc2RheSwgMjIgQXByaWwgMjAy MSBhdCAxMjo1NQ0KVG86IEVyaWMgVnluY2tlIDxldnluY2tlQGNpc2NvLmNvbT4NCkNjOiBXYXJy ZW4gS3VtYXJpIDx3YXJyZW5Aa3VtYXJpLm5ldD4sIEVubm8gUmV5IDxlcmV5QGVybncuZGU+LCBv cHMtZGlyIDxvcHMtZGlyQGlldGYub3JnPiwgImxhc3QtY2FsbEBpZXRmLm9yZyIgPGxhc3QtY2Fs bEBpZXRmLm9yZz4sIG9wc2VjIHdnIG1haWxpbmcgbGlzdCA8b3BzZWNAaWV0Zi5vcmc+LCAiZHJh ZnQtaWV0Zi1vcHNlYy12Ni5hbGxAaWV0Zi5vcmciIDxkcmFmdC1pZXRmLW9wc2VjLXY2LmFsbEBp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT1BTRUNdIE9wc2RpciBsYXN0IGNhbGwgcmV2aWV3IG9m IGRyYWZ0LWlldGYtb3BzZWMtdjYtMjUNClJlc2VudC1Gcm9tOiA8YWxpYXMtYm91bmNlc0BpZXRm Lm9yZz4NClJlc2VudC1UbzogRXJpYyBWeW5ja2UgPGV2eW5ja2VAY2lzY28uY29tPiwgS2lyYW4g S3VtYXIgQ2hpdHRpbWFuZW5pIDxray5jaGl0dGltYW5lbmlAZ21haWwuY29tPiwgTWVyaWtlIEth ZW8gPG1lcmlrZUBkb3VibGVzaG90c2VjdXJpdHkuY29tPiwgPGVyZXlAZXJudy5kZT4sIDxmdXJy eTEzQGdtYWlsLmNvbT4sIFJvbiBCb25pY2EgPHJib25pY2FAanVuaXBlci5uZXQ+LCA8d2FycmVu QGt1bWFyaS5uZXQ+LCA8cndpbHRvbkBjaXNjby5jb20+LCBHeWFuIE1pc2hyYSA8aGF5YWJ1c2Fn c21AZ21haWwuY29tPiwgPGhheWFidXNhZ3NtQGdtYWlsLmNvbT4NClJlc2VudC1EYXRlOiBUaHVy c2RheSwgMjIgQXByaWwgMjAyMSBhdCAxMjo1NQ0KDQogICAgSGksDQoNCiAgICBJ4oCZdmUgY2hl Y2tlZCB0aHJvdWdoIC0yNiBhbmQgY29tcGFyZWQgYXMgYmVzdCBhcyBJIGNhbiB0byAtMjUsIGFu ZCBzdWJtaXR0ZWQgdGhlIHJldmlldy4NCg0KICAgIEnigJltIGhhcHB5IGVub3VnaCB0byBwdXQg YSDigJhSZWFkeeKAmSB0YWcgb24gaXQuICBJdCBjb3VsZCBhbHdheXMgYmUgYmV0dGVyLCBidXQg YXQgNTAgcGFnZXMsIEkgZnVsbHkgdW5kZXJzdGFuZCB3aHkgc2hpcHBpbmcgaXQgaXMgZGVzaXJh YmxlLiAgSSBjYW7igJl0IHNlZSBhbnl0aGluZyBzcGVjaWZpY2FsbHkgd3JvbmcgaW4gdGhlIHRl eHQgOikNCg0KICAgIFRpbQ0KDQogICAgPiBPbiAyMSBBcHIgMjAyMSwgYXQgMTk6MzYsIEVyaWMg VnluY2tlIChldnluY2tlKSA8ZXZ5bmNrZUBjaXNjby5jb20+IHdyb3RlOg0KICAgID4gDQogICAg PiBUaW0sIFdhcnJlbiwNCiAgICA+IA0KICAgID4gUmVwbHlpbmcgd2l0aCBvbmx5IHRoZSBhdXRo b3IgaGF0IChhbmQgYWZ0ZXIgY29uc3VsdGF0aW9uIHdpdGggbXkgY28tYXV0aG9ycykgb24gdGhp cyBlbWFpbCBhZnRlciBoYXZpbmcgcmVhZCBXYXJyZW4ncyBhbmQgVGltJ3MgcmVwbGllcy4NCiAg ICA+IA0KICAgID4gVGltLCBJIGRvIG5vdCBrbm93IHdoZXRoZXIgeW91IHJlbWVtYmVyIGFsbCB0 aGUgcGFpbmZ1bCBqb3VybmV5IG9mIHRoaXMgZG9jdW1lbnQgYnV0IHRoZSBhdXRob3JzIGRvIDot KSANCiAgICA+IA0KICAgID4gYSkgdGhlIGVhcmx5IHZlcnNpb25zIG9mIHRoZSBJLUQgaW5jbHVk ZWQgYSBsb3Qgb2YgJ3JlY29tbWVuZGF0aW9uJyB3b3JkaW5nIGJ1dCB0aGUgT1BTRUMgV0cgcmVx dWVzdGVkIHVzIHRvIHJlbW92ZSB0aGVtICh0aGlzIGlzIGFsc28gdGhlIHJlYXNvbiB3aHkgaXQg aXMgbm90IGEgQkNQKQ0KICAgID4gDQogICAgPiBiKSBnZXR0aW5nIGEgc3VtbWFyeSB3b3VsZCBi ZSBhIG5pY2UgaWRlYSBidXQsIGFnYWluLCB0byByZWFjaCB0aGUgV0cgY29uc2Vuc3VzLCB3ZSBo YWQgdG8gbWFrZSBzb21lIHJlY29tbWVuZGF0aW9uIHdpdGggcmVzdHJpY3Rpb25zIGFuZCBjYXZl YXRzIGZvciBzcGVjaWFsIGNhc2VzIChlLmcuLCByZW1lbWJlciB0aGUgVUxBLCBSQS1ndWFyZCAg ZGlzY3Vzc2lvbnMgPykuLi4gaGVuY2UsIEkgZG8gbm90IHRoaW5rIHRoYXQgdGhpcyBpcyBwb3Nz aWJseSB0byBtYWtlIGEgc2hvcnQgc3VtbWFyeSB3aXRob3V0IGluY2x1ZGluZyB0aGUgcmVzdHJp Y3Rpb25zL3NwZWNpZmljcyAuLi4gc28gdGhlIHN1bW1hcnkgbGlzdCB3aWxsIGJlIHZlcnkgdmVy eSBsb25nIGFuZCBub3QgdmVyeSB1c2VmdWwNCiAgICA+IA0KICAgID4gQWxsIHRoZSBvdGhlciBs YXN0IGNhbGwgY29tbWVudHMgYW5kIHRoZSBJRVNHIENPTU1FTlQgcG9pbnRzICB3aWxsIGJlIGFk ZHJlc3NlZCBvbmNlIGFsbCBmZWVkYmFjayBpcyBjb2xsZWN0ZWQsICAgYnkgZWl0aGVyIHVwZGF0 aW5nIHRoZSB0ZXh0IG9yIGV4cGxhaW5pbmcgb3VyIHBvaW50cyBvZiB2aWV3IG9uIHRoZSBjb21t ZW50Lg0KICAgID4gDQogICAgPiBUaGFuayB5b3UgYWdhaW4gZm9yIHlvdXIgcmV2aWV3IGFuZCB0 aGUgZGlzY3Vzc2lvbg0KICAgID4gDQogICAgPiBSZWdhcmRzDQogICAgPiANCiAgICA+IC3DqXJp Yw0KICAgID4gDQogICAgPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgID4gRnJvbTog VGltIENob3duIDxUaW0uQ2hvd25AamlzYy5hYy51az4NCiAgICA+IERhdGU6IFdlZG5lc2RheSwg MjEgQXByaWwgMjAyMSBhdCAxNTo0MQ0KICAgID4gVG86IFdhcnJlbiBLdW1hcmkgPHdhcnJlbkBr dW1hcmkubmV0Pg0KICAgID4gQ2M6IEVubm8gUmV5IDxlcmV5QGVybncuZGU+LCBvcHMtZGlyIDxv cHMtZGlyQGlldGYub3JnPiwgImxhc3QtY2FsbEBpZXRmLm9yZyIgPGxhc3QtY2FsbEBpZXRmLm9y Zz4sIG9wc2VjIHdnIG1haWxpbmcgbGlzdCA8b3BzZWNAaWV0Zi5vcmc+LCAiZHJhZnQtaWV0Zi1v cHNlYy12Ni5hbGxAaWV0Zi5vcmciIDxkcmFmdC1pZXRmLW9wc2VjLXY2LmFsbEBpZXRmLm9yZz4N CiAgICA+IFN1YmplY3Q6IFJlOiBbT1BTRUNdIE9wc2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRy YWZ0LWlldGYtb3BzZWMtdjYtMjUNCiAgICA+IFJlc2VudC1Gcm9tOiA8YWxpYXMtYm91bmNlc0Bp ZXRmLm9yZz4NCiAgICA+IFJlc2VudC1UbzogRXJpYyBWeW5ja2UgPGV2eW5ja2VAY2lzY28uY29t PiwgS2lyYW4gS3VtYXIgQ2hpdHRpbWFuZW5pIDxray5jaGl0dGltYW5lbmlAZ21haWwuY29tPiwg TWVyaWtlIEthZW8gPG1lcmlrZUBkb3VibGVzaG90c2VjdXJpdHkuY29tPiwgPGVyZXlAZXJudy5k ZT4sIDxmdXJyeTEzQGdtYWlsLmNvbT4sIFJvbiBCb25pY2EgPHJib25pY2FAanVuaXBlci5uZXQ+ LCA8cndpbHRvbkBjaXNjby5jb20+LCA8d2FycmVuQGt1bWFyaS5uZXQ+LCBHeWFuIE1pc2hyYSA8 aGF5YWJ1c2Fnc21AZ21haWwuY29tPiwgPGhheWFidXNhZ3NtQGdtYWlsLmNvbT4NCiAgICA+IFJl c2VudC1EYXRlOiBXZWRuZXNkYXksIDIxIEFwcmlsIDIwMjEgYXQgMTU6NDENCiAgICA+IA0KICAg ID4gICAgSGksDQogICAgPiANCiAgICA+ICAgIEnigJl2ZSBub3QgeWV0IHNlZW4gYW55IGNvbW1l bnRzIGFzIHByb3Bvc2VkIGJ5IFdhcnJlbiwgYW5kIHRoZSByZXZpZXcgaXMgZHVlICh0aGUgZGVh ZGxpbmUgd2FzIGEgc2hvcnRlciB0aGFuIHVzdWFsIG9uZSkuICBJIGNhbiBnbyBhaGVhZCBhbmQg bG9vayB0byBkZXRlcm1pbmUgdGhlIGNoYW5nZXMgZnJvbSB0aGUgZGlmZiB2aWV3Lg0KICAgID4g DQogICAgPiAgICBBIGZhaXJseSBtYWluIHBvaW50IHdhcyB3aGV0aGVyIGFueSBzdW1tYXJ5IHJl Y29tbWVuZGF0aW9ucyB3b3VsZCBiZSBhZGRlZCwgZ2l2ZW4gdGhlIGRvY3VtZW504oCZcyBsZW5n dGgsIGFuZCB0aGUgdmFyaWF0aW9uIGluIHN0eWxlIHRocm91Z2ggdGhlIGRvY3VtZW50LCB3aXRo IHNvbWUgc2VjdGlvbnMgaGF2aW5nIHJlY29tbWVuZGF0aW9ucyBzdWJzZWN0aW9ucywgb3RoZXJz IG5vdC4gIFRoZXJlIGlzIGEgbG90IG9mIGdvb2QgYWR2aWNlIGluIHRoZSB0ZXh0LCBidXQgaXTi gJlzIGEgbG9uZyByZWFkIGFzIGlzLCBhbmQgdGhlcmXigJlzIGxpa2VseSBhIGNvdXBsZSBvZiBw YWdlcyBvZiBrZXkgYnVsbGV0IHBvaW50cyB0aGF0IGNvdWxkIGJlIGFkZGVkLg0KICAgID4gDQog ICAgPiAgICBXaGVuIGlzIHRoZSBkcmFmdCBjb21pbmcgYmFjayB0byB0aGUgSUVTRz8NCiAgICA+ IA0KICAgID4gICAgVGltDQogICAgPiANCiAgICA+PiBPbiAxMyBBcHIgMjAyMSwgYXQgMjE6NTks IFdhcnJlbiBLdW1hcmkgPHdhcnJlbkBrdW1hcmkubmV0PiB3cm90ZToNCiAgICA+PiANCiAgICA+ PiBKdXN0IGEgcXVpY2sgbm90ZSB0byBzYXkgdGhhbmtzIHRvIFRpbSBmb3IgdGhlIGV4Y2VsbGVu dCBhbmQgZGV0YWlsZWQgcmV2aWV3LCBhbmQgdG8gdGhlIGF1dGhvcnMgZm9yIGFkZHJlc3Npbmcg aXQuLi4NCiAgICA+PiANCiAgICA+PiBJIHRvb2sgYSBxdWljayBza2ltIHRocm91Z2ggdGhlIGRp ZmZzLCBhbmQgaXQgd2FzIGEgbGl0dGxlIHRyaWNreSBmb3IgbWUgdG8gdGVsIHdoaWNoIGFsbCBv ZiB0aGUgY29tbWVudHMgaGFkIGJlZW4gYWRkcmVzc2VkIC0tIGF1dGhvcnMsIGlmIHlvdSBnZXQg YSBjaGFuY2UsIGNvdWxkIHlvdSByZXBseSBub3Rpbmcgd2hpY2ggY29tbWVudHMgd2VyZSBmb2xk ZWQgaW50byAtMjY/DQogICAgPj4gVw0KICAgID4+IA0KICAgID4+IE9uIFNhdCwgQXByIDEwLCAy MDIxIGF0IDI6NDYgUE0gRW5ubyBSZXkgPGVyZXlAZXJudy5kZT4gd3JvdGU6DQogICAgPj4gSGkg VGltLA0KICAgID4+IA0KICAgID4+IHRoYW5rcyBzbyBtdWNoIGZvciBhbm90aGVyIGRldGFpbGVk IGxvb2sgYXQgdGhlIGRyYWZ0Lg0KICAgID4+IFlvdXIgZmVlbGluZyB0aGF0IGl0IGhhcyBiZWVu IGluIHRoZSBtYWtpbmcgZm9yIGEgd2hpbGUgaXMgY29ycmVjdCAodGVsbCBtZSBhYm91dCBpdCA7 LSksIHN0aWxsIHdlIHRoaW5rIHRoYXQgdGhlIG9wZXJhdGlvbmFsIHNlY3VyaXR5IGd1aWRhbmNl IGZvciBJUHY2IGhhc24ndCBjaGFuZ2UgbXVjaCBvdmVyIHRpbWUsIGFuZCBpdCBtaWdodCBldmVu IGJlIG1vcmUgbmVlZGVkIHRoYW4gZXZlciAoZ2l2ZW4gY3VycmVudCBtb21lbnR1bSBvZiBJUHY2 IHVwdGFrZSkuDQogICAgPj4gSSB3ZW50IHRocm91Z2ggeW91ciBiZWxvdyBwb2ludHMsIGFuZCBm b3IgbWFueSBvZiB0aGVtIEkndmUgcGVyZm9ybWVkIGFjY29yZGluZyBjbGFyaWZpY2F0aW9ucy9l bmhhbmNlbWVudHMgb2YgdGhlIGRyYWZ0LiBBIG5ldyB2ZXJzaW9uIGhhcyB0aGVuIGJlZW4gdXBs b2FkZWQuDQogICAgPj4gDQogICAgPj4gV2lzaCB5b3UgYSBncmVhdCB3ZWVrZW5kDQogICAgPj4g DQogICAgPj4gRW5ubw0KICAgID4+IA0KICAgID4+IA0KICAgID4+IA0KICAgID4+IA0KICAgID4+ IE9uIFdlZCwgQXByIDA3LCAyMDIxIGF0IDAyOjEyOjM3QU0gLTA3MDAsIFRpbSBDaG93biB2aWEg RGF0YXRyYWNrZXIgd3JvdGU6DQogICAgPj4+IFJldmlld2VyOiBUaW0gQ2hvd24NCiAgICA+Pj4g UmV2aWV3IHJlc3VsdDogSGFzIElzc3Vlcw0KICAgID4+PiANCiAgICA+Pj4gSGksDQogICAgPj4+ IA0KICAgID4+PiBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCAoZHJhZnQtaWV0Zi1vcHNl Yy12Ni0yNSkgYXMgcGFydCBvZiB0aGUNCiAgICA+Pj4gT3BlcmF0aW9uYWwgZGlyZWN0b3JhdGUn cyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nDQogICAg Pj4+IHByb2Nlc3NlZCBieSB0aGUgSUVTRy4/PyBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4g d2l0aCB0aGUgaW50ZW50IG9mDQogICAgPj4+IGltcHJvdmluZyB0aGUgb3BlcmF0aW9uYWwgYXNw ZWN0cyBvZiB0aGUgSUVURiBkcmFmdHMuIENvbW1lbnRzIHRoYXQgYXJlIG5vdA0KICAgID4+PiBh ZGRyZXNzZWQgaW4gbGFzdCBjYWxsIG1heSBiZSBpbmNsdWRlZCBpbiBBRCByZXZpZXdzIGR1cmlu ZyB0aGUgSUVTRyByZXZpZXcuPz8NCiAgICA+Pj4gRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hh aXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyDQogICAg Pj4+IGxhc3QgY2FsbCBjb21tZW50cy4NCiAgICA+Pj4gDQogICAgPj4+IFRoaXMgZHJhZnQgYW5h bHlzZXMgb3BlcmF0aW9uYWwgc2VjdXJpdHkgaXNzdWVzIHJlbGF0ZWQgdG8gdGhlIGRlcGxveW1l bnQgb2YNCiAgICA+Pj4gSVB2NiwgYW5kIGRlc2NyaWJlcyBhcHByb3ByaWF0ZSBtZWNoYW5pc21z IGFuZCBwcmFjdGljZXMgdG8gbWl0aWdhdGUgcG90ZW50aWFsDQogICAgPj4+IHRocmVhdHMuDQog ICAgPj4+IA0KICAgID4+PiBJIGhhZCBwcmV2aW91c2x5IHJldmlld2VkIHRoZSBkcmFmdCBhcyBh biBPUFMtRElSIEVhcmx5IFJldmlldyBpbiBKdWx5IDIwMTgsDQogICAgPj4+IGFuZCBhZ2FpbiBz aW5jZSB0aGVuLCBzbyBhbSBmYW1pbGlhciB3aXRoIHRoZSBkb2N1bWVudCBhbmQgaXRzIGhpc3Rv cnkuDQogICAgPj4+IA0KICAgID4+PiBHZW5lcmFsIGNvbW1lbnRzOg0KICAgID4+PiANCiAgICA+ Pj4gVGhlIGRvY3VtZW50IGhhcyBldm9sdmVkIG92ZXIgdGltZSB3aXRoIG1hbnkgdG9waWNzIGFk ZGVkLCBhbmQgaGFzIGFuDQogICAgPj4+IGluZXZpdGFibGUgPz8/RnJhbmtlbnN0ZWluPz8/IGZl ZWwgdG8gaXQuICBUaGUgZG9jdW1lbnQgd291bGQgYmUgbXVjaCBiZXR0ZXIgZm9yIGENCiAgICA+ Pj4gcmV3cml0ZSwgYnV0IHRoYXQgd291bGQgYmUgc2lnbmlmaWNhbnQgd29yaywgYW5kIHdvdWxk IGRlbGF5IHB1YmxpY2F0aW9uDQogICAgPj4+IGZ1cnRoZXIuICBUaGUgbWF0ZXJpYWwgaW4gdGhl IGRvY3VtZW50IGlzIGdvb2QsIGFuZCB0aGUgYWR2aWNlIGlzIHZhbHVhYmxlLCBzbw0KICAgID4+ PiB0aGUgZm9jdXMgc2hvdWxkIGJlIG9uIHB1Ymxpc2hpbmcgaXQgc29vbmVyIHJhdGhlciB0aGFu IGxhdGVyLCBhbmQgdGh1cyB0aGUNCiAgICA+Pj4gaXNzdWVzIHdpdGggc3RydWN0dXJlIGFyZSBw cm9iYWJseSBiZXN0IG92ZXJsb29rZWQuDQogICAgPj4+IA0KICAgID4+PiBBbiBleGFtcGxlIG9m IHRoZSBoaXN0b3JpY2FsIGV2b2x1dGlvbiBvZiB0aGUgZG9jdW1lbnQgYXJlIHRoZSBpbnN0YW5j ZXMgd2hlcmUNCiAgICA+Pj4gdGhlIHNhbWUgdG9waWMgb3MgY292ZXJlZCBtdWx0aXBsZSB0aW1l cy4gIFRoaXMgd291bGQgaWRlYWxseSBiZSBhdm9pZGVkLg0KICAgID4+PiANCiAgICA+Pj4gVGhl IHNlY3Rpb24gbW9zdCBpbiBuZWVkIG9mIGF0dGVudGlvbiBpcyAyLjEsIHdoZXJlIG1hbnkgYXNw ZWN0cyBvZiBhZGRyZXNzaW5nDQogICAgPj4+IGFyZSB3ZWF2ZWQgdG9nZXRoZXI6IGFsbG9jYXRp b25zLCBhc3NpZ25tZW50cywgYXNzaWdubWVudCB0byBob3N0cywgVUxBcywNCiAgICA+Pj4gc3Rh YmxlIGFuZCB0ZW1wb3JhcnkgYWRkcmVzc2VzLCBldGMuICBUaGlzIG1pZ2h0IGJlIGJldHRlciBw cmVzZW50ZWQgYXMgYQ0KICAgID4+PiBzZWN0aW9uIGxpc3RpbmcgYWRkcmVzc2luZyByZWxhdGVk IHNlY3VyaXR5IGlzc3Vlcywgc3VjaCBhcyBwcml2YWN5IGZvciB1c2VycywNCiAgICA+Pj4gZmly c3QgaG9wIHNlY3VyaXR5LCBuZXR3b3JrIG1hbmFnZWFiaWxpdHksIGltcGxpY2F0aW9ucyBvZiBt dWx0aS1hZGRyZXNzZWQNCiAgICA+Pj4gaG9zdHMsIGFkZHJlc3MgYWNjb3VudGFiaWxpdHkgKHdo aWNoIGlzbj8/P3QgbWVudGlvbmVkIGhlcmU/KSwgYXZvaWRpbmcNCiAgICA+Pj4gcmVudW1iZXJp bmcgKGlmIHRoYXQgaXMgc2VjdXJpdHk/KSwgZXRjLg0KICAgID4+PiANCiAgICA+Pj4gVGhlcmUg YXJlIGFsc28gc29tZSBzZWN0aW9ucyB3aGljaCBzdW1tYXJpc2UgcmVjb21tZW5kYXRpb25zLCBv ciByZWluZm9yY2UNCiAgICA+Pj4gdGhlbSwgYW5kIG90aGVycyB0aGF0IGRvIG5vdC4gIEZvciBh IGRvY3VtZW50IG9mIG92ZXIgNTAgcGFnZXMsIHdoaWNoIGlzIHF1aXRlDQogICAgPj4+IGEgbG9u ZyByZWFkLCBpdCB3b3VsZCBiZSBkZXNpcmFibGUgdG8gaGF2ZSBhIHN1bW1hcnkgb2YgdGhlIGtl eQ0KICAgID4+PiByZWNvbW1lbmRhdGlvbnMsIGVpdGhlciBhdCB0aGUgZW5kIG9mIGVhY2ggMm5k IGxldmVsIHRvcGljLCBvciBhcyBhIHN0YW5kYWxvbmUNCiAgICA+Pj4gc2VjdGlvbiBhdCB0aGUg ZW5kIG9mIHRoZSBkb2N1bWVudCB3aGVyZSB0aGUga2V5IHBvaW50cyBvZiBlYWNoIDJuZCBsZXZl bCB0b3BpYw0KICAgID4+PiBhcmUgc3VtbWFyaXNlZC4NCiAgICA+Pj4gDQogICAgPj4+IElzIGl0 IHdvcnRoIGNpdGluZyBleGFtcGxlcyBvZiBzZWN1cml0eSB0b29sa2l0cyByZWFkZXJzIGNhbiBl eHBsb3JlLCBsaWtlIHRoZQ0KICAgID4+PiBUSEMga2l0LCBTSTYgTmV0d29ya3MsIGV0YywgbWF5 YmUgU2NhcHk/DQogICAgPj4+IA0KICAgID4+PiBTcGVjaWZpYyBjb21tZW50czoNCiAgICA+Pj4g DQogICAgPj4+IHAuMw0KICAgID4+PiBJIGRvbj8/P3QgdW5kZXJzdGFuZCB3aHkgTlBUdjYgaXMg bWVudGlvbmVkIGhlcmUsIHRoaXMgZWFybHkuICBKdXN0IHNheSB0aGF0IHNvbWUNCiAgICA+Pj4g c2VjdXJpdHkgaXNzdWVzIGhhdmUgSVB2NCBlcXVpdmFsZW50cywgbGlrZSBORCBhdHRhY2tzIGFu ZCBBUlAgYXR0YWNrcywgYW5kDQogICAgPj4+IHNvbWUgZG8gbm90LCBsaWtlIElQdjYgRUhzIG9y IGhvcCBieSBob3AgRG9TLiAgIFRoZSBOQVQgZGlzY3Vzc2lvbiBzaG91bGQgYmUgaW4NCiAgICA+ Pj4gYSBzdGFuZGFsb25lIHNlY3Rpb24sIGFuZCBiZSBuZXV0cmFsIHRoZXJlLg0KICAgID4+PiAN CiAgICA+Pj4gcC40DQogICAgPj4+IFdoeSBtZW50aW9uIHRoZSBzcGVjaWZpYyBleGFtcGxlIG9m IG11bHRpLWhvbWVkIG5ldHdvcmtzPyAgIFdoYXQgZG8geW91IG1lYW4gYnkNCiAgICA+Pj4gdGhl IGV4Y2VwdGlvbj8gIElzIGl0IHRoYXQgbXVsdGktaG9taW5nIGlzIG91dCBvZiBzY29wZSwgYW5k IHNvIGFyZSB1bm1hbmFnZWQNCiAgICA+Pj4gbmV0d29ya3M/DQogICAgPj4+IA0KICAgID4+PiBw LjQNCiAgICA+Pj4gQWdhaW4sIE5QVHY2IGlzIG1lbnRpb25lZC4gIFRoaXMgc2VjdGlvbiBpcyB0 aXRsZWQgPz8/YWRkcmVzc2luZyBhcmNoaXRlY3R1cmU/Pz8NCiAgICA+Pj4gYnV0IHRoaXMgYml0 IG9mIHRleHQgaXMgYWJvdXQgcmVhc29ucyBmb3IgZ29pbmcgUEEsIFBJLCBvciBiZWNvbWluZyBh biBMSVIsDQogICAgPj4+IHdoaWNoIGlzIG5vdCBhcmNoaXRlY3R1cmUuDQogICAgPj4+IA0KICAg ID4+PiBwLjQNCiAgICA+Pj4gSW4gdGhlIDc5MzQgcGFyYSwgUkZDODk4MSBzaG91bGQgYmUgbWVu dGlvbmVkIGFzIGl0Pz8/cyBhIHNpZ25pZmljYW50IHJlYXNvbiBvZg0KICAgID4+PiBkZXZpY2Vz IGhhdmluZyBtb3JlIGFkZHJlc3Nlcy4NCiAgICA+Pj4gDQogICAgPj4+IHAuNQ0KICAgID4+PiBV TEFzIGFyZSBhbHNvIHVzZWZ1bCB3aGVyZSB0aGUgcHJlZml4IGNoYW5nZXMsIGZvciBzdGFibGUg aW50ZXJuYWwgYWRkcmVzc2luZw0KICAgID4+PiBhcyB0aGUgZ2xvYmFsIHByZWZpeCBjaGFuZ2Vz PyAgVHlwaWNhbGx5IGluIHJlc2lkZW50aWFsIG5ldHdvcmtzLg0KICAgID4+PiANCiAgICA+Pj4g cC41DQogICAgPj4+IFNlY3Rpb24gMi4xLjQgaXMgcmVhbGx5IGFib3V0IGNob2ljZXMgaW4gYWRk cmVzcyBhc3NpZ25tZW50IHdpdGhpbiBhIG5ldHdvcmsuDQogICAgPj4+IA0KICAgID4+PiBwLjYN CiAgICA+Pj4gU29tZSBvZiB0aGVzZSBwYXJhcyBzaG91bGQgYmUgaW4gYSBzZWN0aW9uIGFib3V0 IElQdjYgbmV0d29yayByZWNvbm5haXNzYW5jZSwNCiAgICA+Pj4gaG93IHRvIGJlc3QgbWl0aWdh dGUgYWdhaW5zdCBzY2FubmluZywgYW5kIGhvdyB0byBpbnZlbnRvcnkgeW91ciBvd24gbmV0d29y aw0KICAgID4+PiBlbGVtZW50cy4NCiAgICA+Pj4gDQogICAgPj4+IHAuNg0KICAgID4+PiBBbGwg bWVudGlvbnMgb2YgNDk0MSBzaG91bGQgYmUgcmVwbGFjZWQgd2l0aCA4OTgxLg0KICAgID4+PiAN CiAgICA+Pj4gcC43DQogICAgPj4+IENhbiB1c2UgNzcyMSBhbmQgODk4MSB0b2dldGhlci4NCiAg ICA+Pj4gDQogICAgPj4+IHAuNw0KICAgID4+PiBXaHkgYXJlIERIQ1AgYW5kIEROUyBsaW1wZWQg dG9nZXRoZXI/ICBUaGUgRE5TIGlzIG9ubHkgYWJvdXQgRE5TU0VDLCBzbyBjYWxsIGl0DQogICAg Pj4+IHRoYXQ/DQogICAgPj4+IA0KICAgID4+PiBwLjcNCiAgICA+Pj4gPz8/RXZlbiBpZiB0aGUg dXNlIG9mIERIQ1A/Pz8gLSB0aGlzIHJlYWRzIGJhZGx5LiAgUmF0aGVyIDg1MDQgdGFsa3MgYWJv dXQgdGhpcyBpbg0KICAgID4+PiA2LjUsIHdoZXJlIFJGQzc4NDQgaXMgbWVudGlvbmVkIGZvciBl eGFtcGxlLiAgVGhpcyBzaG91bGQgYmUgaW4gYSB1c2VyIHByaXZhY3kNCiAgICA+Pj4gc2VjdGlv biAoaWYgdGhpcyBkb2N1bWVudCBoYWQgb25lKS4gIFNlY3Rpb24gOC40IGlzIGFsc28gdXNlZnVs IGFkdmljZS4NCiAgICA+Pj4gDQogICAgPj4+IHAuOA0KICAgID4+PiBUaGUgZmlyc3QgcGFyYSBp cyB2ZXJ5IG11ZGRsZWQuDQogICAgPj4+IA0KICAgID4+PiBwLjgNCiAgICA+Pj4gSW4gMi4xLjcg dGhpcyBjYW4gYWxzbyBiZSB1c2VmdWwgZm9yIEFDTCBjb250cm9scywgaWYgb25lIGFkbWluIC8g Y29udHJvbA0KICAgID4+PiBzeXN0ZW0gc2l0cyBpbiBhIHByZWZpeCBvZiBpdHMgb3duLg0KICAg ID4+PiANCiAgICA+Pj4gcC4xMA0KICAgID4+PiBUaGlzIGlzIHJlYWxseSBhYm91dCBoYW5kbGlu ZyBvZiBmcmFnbWVudGVkIHBhY2tldHMgKHRoZSB0b3BpYykgbm90IHRoZQ0KICAgID4+PiBmcmFn bWVudCBoZWFkZXIgaXRzZWxmIEFsc28gdGhpcyBpcyBjb3ZlcmVkIGluIDIuMy4yLjEgYXMgd2Vs bC4NCiAgICA+Pj4gDQogICAgPj4+IHAuMTANCiAgICA+Pj4gSW4gMi4yLCB0aGUgaW50cm8gY2Fu IHNheSB0aGVzZSBpc3N1ZXMgaGF2ZSBwYXJhbGxlbHMgaW4gSVB2NC4NCiAgICA+Pj4gDQogICAg Pj4+IHAuMTENCiAgICA+Pj4gRmlyc3QgbGluZSwgc2F5IHRoZSBhdHRhY2sgY2FuIHR5cGljYWxs eSBoYXBwZW4gZnJvbSBhIGxhcmdlIGFkZHJlc3Mgc2NhbiBpZg0KICAgID4+PiBwZXJtaXR0ZWQg aW50byB0aGUgbmV0d29yaz8NCiAgICA+Pj4gDQogICAgPj4+IHAuMTENCiAgICA+Pj4gQnVsbGV0 IDEgLSB0aGF0IGNvbnRyYWRpY3RzIHRoZSBjb21tZW50cyBvbiBwcmVkaWN0YWJsZSBhZGRyZXNz aW5nLg0KICAgID4+PiBCdWxsZXQgMiAtIGhvdz8gIFNvbWUgY2x1ZXMgaGVyZSB3b3VsZCBiZSB1 c2VmdWwuDQogICAgPj4+IA0KICAgID4+PiBwLjEyDQogICAgPj4+ID8/P0N1cnJlbnQ/Pz8gLSBy ZWFsbHk/IEFsbCBjdXJyZW50IGltcGxlbWVudGF0aW9ucz8gIERlbGV0ZSA/Pz9jdXJyZW50Pz8/ IG9yIHJlcGxhY2UNCiAgICA+Pj4gd2l0aCA/Pz9uYWl2ZT8/PyBtYXliZS4NCiAgICA+Pj4gDQog ICAgPj4+IHAuMTINCiAgICA+Pj4gPz8/Q29tbXVuaWNhdGUgZGlyZWN0bHk/Pz8gLSBhdCBMMj8g IElmIHNvLCB3aHk/DQogICAgPj4+IA0KICAgID4+PiBwLjEyDQogICAgPj4+IEFuIGV4YW1wbGUg b2YgYSByZWNvbW1lbmRhdGlvbnMgc2VjdGlvbiBoZXJlLCB3aGVyZSBvdGhlciBzZWN0aW9ucyB3 aXRoIGFkdmljZQ0KICAgID4+PiBhcmUgbm90IHRpdGxlZCBhcyBzdWNoLiBTZWUgdGhlIEdlbmVy YWwgY29tbWVudCBvbiB0aGlzLg0KICAgID4+PiANCiAgICA+Pj4gcC4xMw0KICAgID4+PiA/Pz9U cml2aWFsPz8/IGNhc2VzIC0gYXJlbj8/P3QgdGhlc2UgY29tbW9uIG9uZXMsIGxpa2UgZWRnZSBz d2l0Y2hlcyBpbiBhbiBlbnRlcnByaXNlPw0KICAgID4+PiANCiAgICA+Pj4gcC4xMw0KICAgID4+ PiBXaHkgPz8/aG9zdGlsZT8/Pz8gIERlbGV0ZT8NCiAgICA+Pj4gDQogICAgPj4+IHAuMTQNCiAg ICA+Pj4gSW4gMi4zLjUgbGFzdCBwYXJhLCB3aGF0IGFib3V0IG1ETlMsIEJvbmpvdXI/ICAgVGhv dWdoIHRoZSBETlMgU0Qgd29yayBpcyBub3cNCiAgICA+Pj4gb24gdW5pY2FzdCBkaXNjb3Zlcnku DQogICAgPj4+IA0KICAgID4+PiBwLjIxDQogICAgPj4+IE1heWJlIGFkZCBoZXJlIDgwMi4xeCBh cyBhbiBleGFtcGxlIG9mIHRoZSB2YWx1ZSBvZiBSQURJVVMgbG9ncywgYW5kIGFkZCBpbg0KICAg ID4+PiBoZXJlIGFzIGJ1bGxldHMgaW5mbyBoYXJ2ZXN0ZWQgZnJvbSBzd2l0Y2hlcyBhbmQgKHNh eSkgcm91dGVyIE5EUCBzeXNsb2cNCiAgICA+Pj4gKHRob3VnaCB0aGF0Pz8/cyBJIHN1cHBvc2Ug dGhlIDR0aCBidWxsZXQpLiAgVGhlc2UgYXJlIG1lbnRpb25lZCBpbiAyLjYuMS43IGJ1dA0KICAg ID4+PiBzaG91bGQgYmUgc3BsaXQgb3V0IGF0IHRoZSBzYW1lIGxldmVsIGFzIHRoZSBvdGhlciB0 b3BpY3MgaGVyZS4NCiAgICA+Pj4gDQogICAgPj4+IHAuMjgNCiAgICA+Pj4gVGhlIHRleHQgaXMg Mi42LjIuMiByZXBlYXRzIGVhcmxpZXIgdGV4dC4NCiAgICA+Pj4gU2ltaWxhcmx5IHRleHQgaW4g Mi42LjIuMyBpcyByZXBlYXRlZCBmb3JtIGJlZm9yZS4NCiAgICA+Pj4gDQogICAgPj4+IHAuMjkN CiAgICA+Pj4gSW4gMi42LjIuNCBwcmVzdW1hYmx5IGFsc28gYSByYXBpZCBncm93dGggaW4gTkQg Y2FjaGUgc2l6ZSBpcyBhbiBpbmRpY2F0b3IuDQogICAgPj4+IA0KICAgID4+PiBwLjI5DQogICAg Pj4+IEluIDIuNyBwb2ludCB0byBSRkMgNDk0Mg0KICAgID4+PiANCiAgICA+Pj4gcC4zMA0KICAg ID4+PiBTaG91bGQgUkZDIDYwOTIgYmUgbWVudGlvbmVkIGhlcmU/DQogICAgPj4+IEFuZCB0aGF0 IHRoZSBiZXN0IGRlZmVuY2UgYWdhaW5zdCBJUHY2IGF0dGFja3MgbiA/Pz9JUHY0IG9ubHk/Pz8g bmV0d29ya3MgaXMgdG8NCiAgICA+Pj4gZGVwbG95IGFuZCBtYW5hZ2UgSVB2Nj8NCiAgICA+Pj4g DQogICAgPj4+IHAuMzENCiAgICA+Pj4gRmlyc3QgYnVsbGV0IG9uIHRoaXMgcGFnZSAtIGJ1dCBp c24/Pz90IHRoaXMgdGhlIHNhbWUgYXMgaWYgdGhlIHRyYWZmaWMgaXMgbm90DQogICAgPj4+IHR1 bm5lbGxlZD8gIFdoeSBkb2VzIHR1bm5lbGxpbmcgYWRkIHRoZSByZXF1aXJlbWVudD8gIFRoZSBz YW1lIGFwcGxpZXMgb24gdGhlDQogICAgPj4+IGZpcnN0IHBhcmEgb24gcC4zMg0KICAgID4+PiAN CiAgICA+Pj4gcC4zMQ0KICAgID4+PiBNYXliZSBzYXkgaGVyZSB0aGUgbWl0aWdhdGlvbnMgY2Fu IGFsc28gYnJlYWsgdHVubmVsIGJyb2tlcnMgKG1pZ2h0IGJlIGRlc2lyZWQsDQogICAgPj4+IGJ1 dCB1c2VycyB3aWxsIG5vdGljZT8/Pyk/Pz8uIE1heWJlIHR1bm5lbHMgdG8gc3BlY2lmaWMgYnJv a2VycyBjYW4gYmUgYWxsb3dlZC4NCiAgICA+Pj4gDQogICAgPj4+IHAuMzINCiAgICA+Pj4gSVNB VEFQLCBpbiAyMDIxPyAgU2FtZSB3aXRoIDZyZC4gIEdlbmVyYWwgYWR2aWNlIHNob3VsZCBiZSBk ZXBsb3kgbmF0aXZlLCBhdm9pZA0KICAgID4+PiB0dW5uZWxzLg0KICAgID4+PiANCiAgICA+Pj4g cC4zMw0KICAgID4+PiBTYW1lIGZvciA2dG80Lg0KICAgID4+PiANCiAgICA+Pj4gcC4zNA0KICAg ID4+PiBUZXJlZG8gdGhvdWdoLCBpcyB0aGF0IHN0aWxsIGluY2x1ZGVkIGluIFdpbmRvd3MgYW5k IFhCb1gsIGFzIGEgTVMgdGhpbmc/DQogICAgPj4+IA0KICAgID4+PiBwLjM2DQogICAgPj4+IE1h eWJlIGNpdGUgR2VvZmYgSHVzdG9uPz8/cyBibG9nIG9uIHRoaXMgLSBpdD8/P3MgdmVyeSBnb29k LiAgTWF5YmUgdGhlcmU/Pz9zIGEgbW9yZQ0KICAgID4+PiByZWNlbnQgdXBkYXRlIHRob3VnaCAt DQogICAgPj4+IGh0dHBzOi8vYmxvZy5hcG5pYy5uZXQvMjAxNi8wNi8wOS9sZXRzLXRhbGstaXB2 Ni1kbnM2NC1kbnNzZWMvLiBIb3N0IENMQVQgaXMNCiAgICA+Pj4gYXBwbGljYWJsZSBoZXJlPyAg KEhlbmNlIGEgc2l0ZSBzaG91bGQgc3VwcG9ydCB0aGUgNjRQUkVGIFJBIG9wdGlvbj8gIFJGQzg3 ODENCiAgICA+Pj4gDQogICAgPj4+IHAuMzgNCiAgICA+Pj4gSW4gMi44LCB0byBiZSBmYWlyIElQ djQgaXMgYWxzbyBoYXJkZW5lZCBhIGxvdCBvZiBsYXRlIGR1ZSB0byB0aGUgcHJldmFsZW5jZSBv Zg0KICAgID4+PiB1c2Ugb2YgZGV2aWNlcyBpbiBXaUZpIGhvdHNwb3RzIGV0Yy4NCiAgICA+Pj4g DQogICAgPj4+IHAuMzcNCiAgICA+Pj4gQWxzbyBSRkM2MDkyIG9uIHNlY3Rpb24gMy4xPw0KICAg ID4+PiANCiAgICA+Pj4gcC4zOA0KICAgID4+PiA/Pz9XaGVyZSBSRkMxOTE4IGFkZHJlc3MgYXJl IG9mdGVuIHVzZWQ/Pz8gLSBhZGQgPz8/b2Z0ZW4/Pz8sIHRoZSB0ZXh0IGltcGxpZXMgYWxsDQog ICAgPj4+IGVudGVycHJpc2VzIHVzZSB2NCBOQVQuDQogICAgPj4+IA0KICAgID4+PiBwLjQxDQog ICAgPj4+IE9ubHkgMiBub3JtYXRpdmUgcmVmZXJlbmNlcz8NCiAgICA+Pj4gDQogICAgPj4+IE5p dHM6DQogICAgPj4+IA0KICAgID4+PiBwLjENCiAgICA+Pj4gPz8/VGhlIEludGVybmV0Pz8/IC0g eW91IHByb2JhYmx5IG1lYW4gPz8/YW4gSVNQIG5ldHdvcms/Pz8NCiAgICA+Pj4gPz8/RGVzY3Jp YmVzIHRoZSBzZWN1cml0eT8/PyAtIGRlbGV0ZSA/Pz90aGU/Pz8NCiAgICA+Pj4gDQogICAgPj4+ IHAuNA0KICAgID4+PiA/Pz9XaGljaCBhcmUgdGhlIHN3aXRjaD8/PyBkZWxldGUgPz8/d2hpY2gg YXJlPz8/DQogICAgPj4+IA0KICAgID4+PiBwLjgNCiAgICA+Pj4gVmFyeWluZyAtPiB2YXJpb3Vz DQogICAgPj4+IA0KICAgID4+PiBwLjEwDQogICAgPj4+IGlwdjYgLT4gSVB2Ng0KICAgID4+PiAN CiAgICA+Pj4gcC4xOA0KICAgID4+PiBSb3V0ZXIgcHJvY2Vzc29yIC0gYWRkIHIgdG8gPz8/cm91 dGU/Pz8NCiAgICA+Pj4gDQogICAgPj4+ID8/Pw0KICAgID4+PiBUaW0NCiAgICA+Pj4gDQogICAg Pj4+IA0KICAgID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KICAgID4+PiBPUFNFQyBtYWlsaW5nIGxpc3QNCiAgICA+Pj4gT1BTRUNAaWV0Zi5vcmcN CiAgICA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNlYw0KICAg ID4+IA0KICAgID4+IC0tIA0KICAgID4+IEVubm8gUmV5DQogICAgPj4gDQogICAgPj4gQ2VsbDog KzQ5IDE3MyA2NzQ1OTAyDQogICAgPj4gVHdpdHRlcjogQEVubm9fSW5zaW51YXRvcg0KICAgID4+ IA0KICAgID4+IA0KICAgID4+IC0tIA0KICAgID4+IFRoZSBjb21wdXRpbmcgc2NpZW50aXN04oCZ cyBtYWluIGNoYWxsZW5nZSBpcyBub3QgdG8gZ2V0IGNvbmZ1c2VkIGJ5IHRoZQ0KICAgID4+IGNv bXBsZXhpdGllcyBvZiBoaXMgb3duIG1ha2luZy4gDQogICAgPj4gIC0tIEUuIFcuIERpamtzdHJh DQogICAgPiANCiAgICA+IA0KDQoNCg== From nobody Fri Apr 23 11:03:32 2021 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07FE3A18C3 for ; Fri, 23 Apr 2021 11:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=kumari-net.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 jeGcpkvvf4nX for ; Fri, 23 Apr 2021 11:03:25 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA2653A18C0 for ; Fri, 23 Apr 2021 11:03:24 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id u20so56617250lja.13 for ; Fri, 23 Apr 2021 11:03:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9uQRhGQWSkS4l5ttE+8R2cud3lgeNv5bArF2K7HOXDM=; b=vstcsMH2rjYiJt/KMiD7fa1eQTxB71Ny5t8GO9JxK+rxrXzHWFTAIvqojwbb2yowfj G/mBi0uh42p+C73paFXZrXxIrGLbKNRE5EDEkRYTqN5zKky3qiOY/t/QJW8oX1eHDfvy rjb1yX9vF3ByCx6+lUk9WAtKCtJhh95hlGBRgtysTC6Kl54Sw+l4o4QDK5olywCLyytj asYWTUhsaGn7IKlFY3Exo7PhawJeJfUg/CCCMqyp8OqSY4oJeespsPTrTFM9xz6j5nso Q0/Nc0t75UKfLgEzJCpEdc8oPVIhXA5J3nZseubQ7YNPf9wM+KPmTFNi9nMMKGzogvZ+ 2rpw== 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=9uQRhGQWSkS4l5ttE+8R2cud3lgeNv5bArF2K7HOXDM=; b=HRT77GnpQc5hzKxkfgJkx2HS/ftzqwVUCFM5sPx4iODD/yclD/6zmZRIBz/FUNpizc phXu2NP74qxy9VPDST+ErBZ1C1eMv+iEvOg4iIq4t8e7vgMYpYQ1FU0myZ8mAf7U0MnF ObCvo0iDZ5ZMZ1/yjahoxvumcnXxXRG2j8CA6qe7jNhLkU0KgOdaBna2v1hYw/WlIXZ0 3REcgvDIUyf6JwhmhnPAufTIkB42e89Kny7y/jjkbdm33pt79se+gwm+Jw2lcxPgNsz6 w65veprCfvw3oi/XbFG21o/rxOZrl5Ui1uejUMLw2Um4OHFPXtGdEzRcvuATlYzfYBIu myOw== X-Gm-Message-State: AOAM531ASB7Kkg0DnAbXwGfBnTZdqF4guVR6oQCBWa7dmVslNHAnAeSG InsFUYTCUTJnDvyMPPNw6jPVBqs+8ljPAYbqss35Hw== X-Google-Smtp-Source: ABdhPJyn3cROGjQVY3NaJNC7O6ft+gEJCUa3464VdLQB19z9CvIWasTslQwO6d0zMMzzLvrE+8wMMg6ztn2YR66VmQw= X-Received: by 2002:a2e:9256:: with SMTP id v22mr3626953ljg.409.1619201000986; Fri, 23 Apr 2021 11:03:20 -0700 (PDT) MIME-Version: 1.0 References: <161778675730.8077.2835666586607648895@ietfa.amsl.com> <20210410184555.GE91991@ernw.de> <4BDF1579-CB77-4B1F-ADCE-8813C859FDEB@cisco.com> In-Reply-To: <4BDF1579-CB77-4B1F-ADCE-8813C859FDEB@cisco.com> From: Warren Kumari Date: Fri, 23 Apr 2021 14:02:44 -0400 Message-ID: To: "Eric Vyncke (evyncke)" Cc: Tim Chown , Enno Rey , ops-dir , opsec wg mailing list , "draft-ietf-opsec-v6.all@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007bec7205c0a79cbc" Archived-At: Subject: Re: [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-25 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2021 18:03:31 -0000 --0000000000007bec7205c0a79cbc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [ - last-call for clutter ] On Thu, Apr 22, 2021 at 7:11 AM Eric Vyncke (evyncke) wrote: > Thank you Tim for the re-check of the document. > Indeed, thank you Tim, both for the review, and for being flexible. This document has a long and storied history, and, while it certainly could be better, I think that it's one of those "it's better to ship something imperfect now, vs never getting around to shipping it" type document. W > > Regards > > -=C3=A9ric > > =EF=BB=BF-----Original Message----- > From: Tim Chown > Date: Thursday, 22 April 2021 at 12:55 > To: Eric Vyncke > Cc: Warren Kumari , Enno Rey , ops-dir < > ops-dir@ietf.org>, "last-call@ietf.org" , opsec wg > mailing list , "draft-ietf-opsec-v6.all@ietf.org" < > draft-ietf-opsec-v6.all@ietf.org> > Subject: Re: [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-25 > Resent-From: > Resent-To: Eric Vyncke , Kiran Kumar Chittimaneni < > kk.chittimaneni@gmail.com>, Merike Kaeo , = < > erey@ernw.de>, , Ron Bonica , < > warren@kumari.net>, , Gyan Mishra < > hayabusagsm@gmail.com>, > Resent-Date: Thursday, 22 April 2021 at 12:55 > > Hi, > > I=E2=80=99ve checked through -26 and compared as best as I can to -25= , and > submitted the review. > > I=E2=80=99m happy enough to put a =E2=80=98Ready=E2=80=99 tag on it. = It could always be > better, but at 50 pages, I fully understand why shipping it is desirable. > I can=E2=80=99t see anything specifically wrong in the text :) > > Tim > > > On 21 Apr 2021, at 19:36, Eric Vyncke (evyncke) > wrote: > > > > Tim, Warren, > > > > Replying with only the author hat (and after consultation with my > co-authors) on this email after having read Warren's and Tim's replies. > > > > Tim, I do not know whether you remember all the painful journey of > this document but the authors do :-) > > > > a) the early versions of the I-D included a lot of 'recommendation' > wording but the OPSEC WG requested us to remove them (this is also the > reason why it is not a BCP) > > > > b) getting a summary would be a nice idea but, again, to reach the > WG consensus, we had to make some recommendation with restrictions and > caveats for special cases (e.g., remember the ULA, RA-guard discussions > ?)... hence, I do not think that this is possibly to make a short summary > without including the restrictions/specifics ... so the summary list will > be very very long and not very useful > > > > All the other last call comments and the IESG COMMENT points will > be addressed once all feedback is collected, by either updating the tex= t > or explaining our points of view on the comment. > > > > Thank you again for your review and the discussion > > > > Regards > > > > -=C3=A9ric > > > > -----Original Message----- > > From: Tim Chown > > Date: Wednesday, 21 April 2021 at 15:41 > > To: Warren Kumari > > Cc: Enno Rey , ops-dir , " > last-call@ietf.org" , opsec wg mailing list < > opsec@ietf.org>, "draft-ietf-opsec-v6.all@ietf.org" < > draft-ietf-opsec-v6.all@ietf.org> > > Subject: Re: [OPSEC] Opsdir last call review of > draft-ietf-opsec-v6-25 > > Resent-From: > > Resent-To: Eric Vyncke , Kiran Kumar > Chittimaneni , Merike Kaeo < > merike@doubleshotsecurity.com>, , , Ron > Bonica , , , > Gyan Mishra , > > Resent-Date: Wednesday, 21 April 2021 at 15:41 > > > > Hi, > > > > I=E2=80=99ve not yet seen any comments as proposed by Warren, an= d the > review is due (the deadline was a shorter than usual one). I can go ahea= d > and look to determine the changes from the diff view. > > > > A fairly main point was whether any summary recommendations woul= d > be added, given the document=E2=80=99s length, and the variation in style= through > the document, with some sections having recommendations subsections, othe= rs > not. There is a lot of good advice in the text, but it=E2=80=99s a long = read as > is, and there=E2=80=99s likely a couple of pages of key bullet points tha= t could be > added. > > > > When is the draft coming back to the IESG? > > > > Tim > > > >> On 13 Apr 2021, at 21:59, Warren Kumari wrote: > >> > >> Just a quick note to say thanks to Tim for the excellent and > detailed review, and to the authors for addressing it... > >> > >> I took a quick skim through the diffs, and it was a little tricky > for me to tel which all of the comments had been addressed -- authors, if > you get a chance, could you reply noting which comments were folded into > -26? > >> W > >> > >> On Sat, Apr 10, 2021 at 2:46 PM Enno Rey wrote: > >> Hi Tim, > >> > >> thanks so much for another detailed look at the draft. > >> Your feeling that it has been in the making for a while is correct > (tell me about it ;-), still we think that the operational security > guidance for IPv6 hasn't change much over time, and it might even be more > needed than ever (given current momentum of IPv6 uptake). > >> I went through your below points, and for many of them I've > performed according clarifications/enhancements of the draft. A new versi= on > has then been uploaded. > >> > >> Wish you a great weekend > >> > >> Enno > >> > >> > >> > >> > >> On Wed, Apr 07, 2021 at 02:12:37AM -0700, Tim Chown via Datatracke= r > wrote: > >>> Reviewer: Tim Chown > >>> Review result: Has Issues > >>> > >>> Hi, > >>> > >>> I have reviewed this document (draft-ietf-opsec-v6-25) as part of > the > >>> Operational directorate's ongoing effort to review all IETF > documents being > >>> processed by the IESG.?? These comments were written with the > intent of > >>> improving the operational aspects of the IETF drafts. Comments > that are not > >>> addressed in last call may be included in AD reviews during the > IESG review.?? > >>> Document editors and WG chairs should treat these comments just > like any other > >>> last call comments. > >>> > >>> This draft analyses operational security issues related to the > deployment of > >>> IPv6, and describes appropriate mechanisms and practices to > mitigate potential > >>> threats. > >>> > >>> I had previously reviewed the draft as an OPS-DIR Early Review in > July 2018, > >>> and again since then, so am familiar with the document and its > history. > >>> > >>> General comments: > >>> > >>> The document has evolved over time with many topics added, and ha= s > an > >>> inevitable ???Frankenstein??? feel to it. The document would be > much better for a > >>> rewrite, but that would be significant work, and would delay > publication > >>> further. The material in the document is good, and the advice is > valuable, so > >>> the focus should be on publishing it sooner rather than later, an= d > thus the > >>> issues with structure are probably best overlooked. > >>> > >>> An example of the historical evolution of the document are the > instances where > >>> the same topic os covered multiple times. This would ideally be > avoided. > >>> > >>> The section most in need of attention is 2.1, where many aspects > of addressing > >>> are weaved together: allocations, assignments, assignment to > hosts, ULAs, > >>> stable and temporary addresses, etc. This might be better > presented as a > >>> section listing addressing related security issues, such as > privacy for users, > >>> first hop security, network manageability, implications of > multi-addressed > >>> hosts, address accountability (which isn???t mentioned here?), > avoiding > >>> renumbering (if that is security?), etc. > >>> > >>> There are also some sections which summarise recommendations, or > reinforce > >>> them, and others that do not. For a document of over 50 pages, > which is quite > >>> a long read, it would be desirable to have a summary of the key > >>> recommendations, either at the end of each 2nd level topic, or as > a standalone > >>> section at the end of the document where the key points of each > 2nd level topic > >>> are summarised. > >>> > >>> Is it worth citing examples of security toolkits readers can > explore, like the > >>> THC kit, SI6 Networks, etc, maybe Scapy? > >>> > >>> Specific comments: > >>> > >>> p.3 > >>> I don???t understand why NPTv6 is mentioned here, this early. > Just say that some > >>> security issues have IPv4 equivalents, like ND attacks and ARP > attacks, and > >>> some do not, like IPv6 EHs or hop by hop DoS. The NAT discussio= n > should be in > >>> a standalone section, and be neutral there. > >>> > >>> p.4 > >>> Why mention the specific example of multi-homed networks? What > do you mean by > >>> the exception? Is it that multi-homing is out of scope, and so > are unmanaged > >>> networks? > >>> > >>> p.4 > >>> Again, NPTv6 is mentioned. This section is titled ???addressing > architecture??? > >>> but this bit of text is about reasons for going PA, PI, or > becoming an LIR, > >>> which is not architecture. > >>> > >>> p.4 > >>> In the 7934 para, RFC8981 should be mentioned as it???s a > significant reason of > >>> devices having more addresses. > >>> > >>> p.5 > >>> ULAs are also useful where the prefix changes, for stable interna= l > addressing > >>> as the global prefix changes? Typically in residential networks. > >>> > >>> p.5 > >>> Section 2.1.4 is really about choices in address assignment withi= n > a network. > >>> > >>> p.6 > >>> Some of these paras should be in a section about IPv6 network > reconnaissance, > >>> how to best mitigate against scanning, and how to inventory your > own network > >>> elements. > >>> > >>> p.6 > >>> All mentions of 4941 should be replaced with 8981. > >>> > >>> p.7 > >>> Can use 7721 and 8981 together. > >>> > >>> p.7 > >>> Why are DHCP and DNS limped together? The DNS is only about > DNSSEC, so call it > >>> that? > >>> > >>> p.7 > >>> ???Even if the use of DHCP??? - this reads badly. Rather 8504 > talks about this in > >>> 6.5, where RFC7844 is mentioned for example. This should be in a > user privacy > >>> section (if this document had one). Section 8.4 is also useful > advice. > >>> > >>> p.8 > >>> The first para is very muddled. > >>> > >>> p.8 > >>> In 2.1.7 this can also be useful for ACL controls, if one admin / > control > >>> system sits in a prefix of its own. > >>> > >>> p.10 > >>> This is really about handling of fragmented packets (the topic) > not the > >>> fragment header itself Also this is covered in 2.3.2.1 as well. > >>> > >>> p.10 > >>> In 2.2, the intro can say these issues have parallels in IPv4. > >>> > >>> p.11 > >>> First line, say the attack can typically happen from a large > address scan if > >>> permitted into the network? > >>> > >>> p.11 > >>> Bullet 1 - that contradicts the comments on predictable addressin= g. > >>> Bullet 2 - how? Some clues here would be useful. > >>> > >>> p.12 > >>> ???Current??? - really? All current implementations? Delete > ???current??? or replace > >>> with ???naive??? maybe. > >>> > >>> p.12 > >>> ???Communicate directly??? - at L2? If so, why? > >>> > >>> p.12 > >>> An example of a recommendations section here, where other section= s > with advice > >>> are not titled as such. See the General comment on this. > >>> > >>> p.13 > >>> ???Trivial??? cases - aren???t these common ones, like edge > switches in an enterprise? > >>> > >>> p.13 > >>> Why ???hostile???? Delete? > >>> > >>> p.14 > >>> In 2.3.5 last para, what about mDNS, Bonjour? Though the DNS SD > work is now > >>> on unicast discovery. > >>> > >>> p.21 > >>> Maybe add here 802.1x as an example of the value of RADIUS logs, > and add in > >>> here as bullets info harvested from switches and (say) router NDP > syslog > >>> (though that???s I suppose the 4th bullet). These are mentioned > in 2.6.1.7 but > >>> should be split out at the same level as the other topics here. > >>> > >>> p.28 > >>> The text is 2.6.2.2 repeats earlier text. > >>> Similarly text in 2.6.2.3 is repeated form before. > >>> > >>> p.29 > >>> In 2.6.2.4 presumably also a rapid growth in ND cache size is an > indicator. > >>> > >>> p.29 > >>> In 2.7 point to RFC 4942 > >>> > >>> p.30 > >>> Should RFC 6092 be mentioned here? > >>> And that the best defence against IPv6 attacks n ???IPv4 only??? > networks is to > >>> deploy and manage IPv6? > >>> > >>> p.31 > >>> First bullet on this page - but isn???t this the same as if the > traffic is not > >>> tunnelled? Why does tunnelling add the requirement? The same > applies on the > >>> first para on p.32 > >>> > >>> p.31 > >>> Maybe say here the mitigations can also break tunnel brokers > (might be desired, > >>> but users will notice???)???. Maybe tunnels to specific brokers > can be allowed. > >>> > >>> p.32 > >>> ISATAP, in 2021? Same with 6rd. General advice should be deploy > native, avoid > >>> tunnels. > >>> > >>> p.33 > >>> Same for 6to4. > >>> > >>> p.34 > >>> Teredo though, is that still included in Windows and XBoX, as a M= S > thing? > >>> > >>> p.36 > >>> Maybe cite Geoff Huston???s blog on this - it???s very good. > Maybe there???s a more > >>> recent update though - > >>> https://blog.apnic.net/2016/06/09/lets-talk-ipv6-dns64-dnssec/. > Host CLAT is > >>> applicable here? (Hence a site should support the 64PREF RA > option? RFC8781 > >>> > >>> p.38 > >>> In 2.8, to be fair IPv4 is also hardened a lot of late due to the > prevalence of > >>> use of devices in WiFi hotspots etc. > >>> > >>> p.37 > >>> Also RFC6092 on section 3.1? > >>> > >>> p.38 > >>> ???Where RFC1918 address are often used??? - add ???often???, the > text implies all > >>> enterprises use v4 NAT. > >>> > >>> p.41 > >>> Only 2 normative references? > >>> > >>> Nits: > >>> > >>> p.1 > >>> ???The Internet??? - you probably mean ???an ISP network??? > >>> ???Describes the security??? - delete ???the??? > >>> > >>> p.4 > >>> ???Which are the switch??? delete ???which are??? > >>> > >>> p.8 > >>> Varying -> various > >>> > >>> p.10 > >>> ipv6 -> IPv6 > >>> > >>> p.18 > >>> Router processor - add r to ???route??? > >>> > >>> ??? > >>> Tim > >>> > >>> > >>> _______________________________________________ > >>> OPSEC mailing list > >>> OPSEC@ietf.org > >>> https://www.ietf.org/mailman/listinfo/opsec > >> > >> -- > >> Enno Rey > >> > >> Cell: +49 173 6745902 > >> Twitter: @Enno_Insinuator > >> > >> > >> -- > >> The computing scientist=E2=80=99s main challenge is not to get con= fused by > the > >> complexities of his own making. > >> -- E. W. Dijkstra > > > > > > > --=20 The computing scientist=E2=80=99s main challenge is not to get confused by = the complexities of his own making. -- E. W. Dijkstra --0000000000007bec7205c0a79cbc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[ - last-call for clutter ]=C2=A0
<= br>
On Thu,= Apr 22, 2021 at 7:11 AM Eric Vyncke (evyncke) <evyncke@cisco.com> wrote:
Thank you Tim for the re-check of the documen= t.

Indeed, thank you Tim, both for the rev= iew, and for being flexible.

This document has a long and storied hi= story, and, while it certainly=C2=A0could be better, I think that it's = one of those "it's better to ship something imperfect now, vs neve= r getting around to shipping it" type document.

W

=C2=A0

Regards

-=C3=A9ric

=EF=BB=BF-----Original Message-----
From: Tim Chown <Tim.Chown@jisc.ac.uk>
Date: Thursday, 22 April 2021 at 12:55
To: Eric Vyncke <= evyncke@cisco.com>
Cc: Warren Kumari <warren@kumari.net>, Enno Rey <erey@ernw.de>, ops-dir <ops-dir@ietf.org>, "last-call@ietf.org" <= ;last-call@ietf.org= >, opsec wg mailing list <opsec@ietf.org>, "draft-ietf-opsec-v6.all@ietf.org&= quot; <draft-ietf-opsec-v6.all@ietf.org>
Subject: Re: [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-25
Resent-From: <alias-bounces@ietf.org>
Resent-To: Eric Vyncke <evyncke@cisco.com>, Kiran Kumar Chittimaneni <kk.chittimaneni@gmail.co= m>, Merike Kaeo <merike@doubleshotsecurity.com>, <erey@ernw.de>, <furry13@gmail.com>, Ron B= onica <rbonica@= juniper.net>, <warren@kumari.net>, <rwilton@cisco.com>, Gyan Mishra <hayabusagsm@gmail.com>, &= lt;hayabusagsm@g= mail.com>
Resent-Date: Thursday, 22 April 2021 at 12:55

=C2=A0 =C2=A0 Hi,

=C2=A0 =C2=A0 I=E2=80=99ve checked through -26 and compared as best as I ca= n to -25, and submitted the review.

=C2=A0 =C2=A0 I=E2=80=99m happy enough to put a =E2=80=98Ready=E2=80=99 tag= on it.=C2=A0 It could always be better, but at 50 pages, I fully understan= d why shipping it is desirable.=C2=A0 I can=E2=80=99t see anything specific= ally wrong in the text :)

=C2=A0 =C2=A0 Tim

=C2=A0 =C2=A0 > On 21 Apr 2021, at 19:36, Eric Vyncke (evyncke) <evyncke@cisco.com>= ; wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Tim, Warren,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Replying with only the author hat (and after consultatio= n with my co-authors) on this email after having read Warren's and Tim&= #39;s replies.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Tim, I do not know whether you remember all the painful = journey of this document but the authors do :-)
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > a) the early versions of the I-D included a lot of '= recommendation' wording but the OPSEC WG requested us to remove them (t= his is also the reason why it is not a BCP)
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > b) getting a summary would be a nice idea but, again, to= reach the WG consensus, we had to make some recommendation with restrictio= ns and caveats for special cases (e.g., remember the ULA, RA-guard=C2=A0 di= scussions ?)... hence, I do not think that this is possibly to make a short= summary without including the restrictions/specifics ... so the summary li= st will be very very long and not very useful
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > All the other last call comments and the IESG COMMENT po= ints=C2=A0 will be addressed once all feedback is collected,=C2=A0 =C2=A0by= either updating the text or explaining our points of view on the comment.<= br> =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Thank you again for your review and the discussion
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Regards
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > -=C3=A9ric
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > -----Original Message-----
=C2=A0 =C2=A0 > From: Tim Chown <Tim.Chown@jisc.ac.uk>
=C2=A0 =C2=A0 > Date: Wednesday, 21 April 2021 at 15:41
=C2=A0 =C2=A0 > To: Warren Kumari <warren@kumari.net>
=C2=A0 =C2=A0 > Cc: Enno Rey <erey@ernw.de>, ops-dir <ops-dir@ietf.org>, "last-call@ietf.org" <last-call@ietf.org&= gt;, opsec wg mailing list <opsec@ietf.org>, "draft-ietf-opsec-v6.all@ietf.org"= <= draft-ietf-opsec-v6.all@ietf.org>
=C2=A0 =C2=A0 > Subject: Re: [OPSEC] Opsdir last call review of draft-ie= tf-opsec-v6-25
=C2=A0 =C2=A0 > Resent-From: <alias-bounces@ietf.org>
=C2=A0 =C2=A0 > Resent-To: Eric Vyncke <evyncke@cisco.com>, Kiran Kumar Chittimane= ni <kk.ch= ittimaneni@gmail.com>, Merike Kaeo <merike@doubleshotsecurity.com>= , <erey@ernw.de>= ;, <furry13@gmail= .com>, Ron Bonica <rbonica@juniper.net>, <rwilton@cisco.com>, <warren@kumari.net>, Gyan Mishra = <hayabusagsm@= gmail.com>, <hayabusagsm@gmail.com>
=C2=A0 =C2=A0 > Resent-Date: Wednesday, 21 April 2021 at 15:41
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 Hi,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 I=E2=80=99ve not yet seen any comments as p= roposed by Warren, and the review is due (the deadline was a shorter than u= sual one).=C2=A0 I can go ahead and look to determine the changes from the = diff view.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 A fairly main point was whether any summary= recommendations would be added, given the document=E2=80=99s length, and t= he variation in style through the document, with some sections having recom= mendations subsections, others not.=C2=A0 There is a lot of good advice in = the text, but it=E2=80=99s a long read as is, and there=E2=80=99s likely a = couple of pages of key bullet points that could be added.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 When is the draft coming back to the IESG?<= br> =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 Tim
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >> On 13 Apr 2021, at 21:59, Warren Kumari <warren@kumari.net> w= rote:
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> Just a quick note to say thanks to Tim for the excel= lent and detailed review, and to the authors for addressing it...
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> I took a quick skim through the diffs, and it was a = little tricky for me to tel which all of the comments had been addressed --= authors, if you get a chance, could you reply noting which comments were f= olded into -26?
=C2=A0 =C2=A0 >> W
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> On Sat, Apr 10, 2021 at 2:46 PM Enno Rey <erey@ernw.de> wrote:
=C2=A0 =C2=A0 >> Hi Tim,
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> thanks so much for another detailed look at the draf= t.
=C2=A0 =C2=A0 >> Your feeling that it has been in the making for a wh= ile is correct (tell me about it ;-), still we think that the operational s= ecurity guidance for IPv6 hasn't change much over time, and it might ev= en be more needed than ever (given current momentum of IPv6 uptake).
=C2=A0 =C2=A0 >> I went through your below points, and for many of th= em I've performed according clarifications/enhancements of the draft. A= new version has then been uploaded.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> Wish you a great weekend
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> Enno
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> On Wed, Apr 07, 2021 at 02:12:37AM -0700, Tim Chown = via Datatracker wrote:
=C2=A0 =C2=A0 >>> Reviewer: Tim Chown
=C2=A0 =C2=A0 >>> Review result: Has Issues
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> Hi,
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> I have reviewed this document (draft-ietf-opsec-= v6-25) as part of the
=C2=A0 =C2=A0 >>> Operational directorate's ongoing effort to = review all IETF documents being
=C2=A0 =C2=A0 >>> processed by the IESG.?? These comments were wri= tten with the intent of
=C2=A0 =C2=A0 >>> improving the operational aspects of the IETF dr= afts. Comments that are not
=C2=A0 =C2=A0 >>> addressed in last call may be included in AD rev= iews during the IESG review.??
=C2=A0 =C2=A0 >>> Document editors and WG chairs should treat thes= e comments just like any other
=C2=A0 =C2=A0 >>> last call comments.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> This draft analyses operational security issues = related to the deployment of
=C2=A0 =C2=A0 >>> IPv6, and describes appropriate mechanisms and p= ractices to mitigate potential
=C2=A0 =C2=A0 >>> threats.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> I had previously reviewed the draft as an OPS-DI= R Early Review in July 2018,
=C2=A0 =C2=A0 >>> and again since then, so am familiar with the do= cument and its history.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> General comments:
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> The document has evolved over time with many top= ics added, and has an
=C2=A0 =C2=A0 >>> inevitable ???Frankenstein??? feel to it.=C2=A0 = The document would be much better for a
=C2=A0 =C2=A0 >>> rewrite, but that would be significant work, and= would delay publication
=C2=A0 =C2=A0 >>> further.=C2=A0 The material in the document is g= ood, and the advice is valuable, so
=C2=A0 =C2=A0 >>> the focus should be on publishing it sooner rath= er than later, and thus the
=C2=A0 =C2=A0 >>> issues with structure are probably best overlook= ed.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> An example of the historical evolution of the do= cument are the instances where
=C2=A0 =C2=A0 >>> the same topic os covered multiple times.=C2=A0 = This would ideally be avoided.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> The section most in need of attention is 2.1, wh= ere many aspects of addressing
=C2=A0 =C2=A0 >>> are weaved together: allocations, assignments, a= ssignment to hosts, ULAs,
=C2=A0 =C2=A0 >>> stable and temporary addresses, etc.=C2=A0 This = might be better presented as a
=C2=A0 =C2=A0 >>> section listing addressing related security issu= es, such as privacy for users,
=C2=A0 =C2=A0 >>> first hop security, network manageability, impli= cations of multi-addressed
=C2=A0 =C2=A0 >>> hosts, address accountability (which isn???t men= tioned here?), avoiding
=C2=A0 =C2=A0 >>> renumbering (if that is security?), etc.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> There are also some sections which summarise rec= ommendations, or reinforce
=C2=A0 =C2=A0 >>> them, and others that do not.=C2=A0 For a docume= nt of over 50 pages, which is quite
=C2=A0 =C2=A0 >>> a long read, it would be desirable to have a sum= mary of the key
=C2=A0 =C2=A0 >>> recommendations, either at the end of each 2nd l= evel topic, or as a standalone
=C2=A0 =C2=A0 >>> section at the end of the document where the key= points of each 2nd level topic
=C2=A0 =C2=A0 >>> are summarised.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> Is it worth citing examples of security toolkits= readers can explore, like the
=C2=A0 =C2=A0 >>> THC kit, SI6 Networks, etc, maybe Scapy?
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> Specific comments:
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.3
=C2=A0 =C2=A0 >>> I don???t understand why NPTv6 is mentioned here= , this early.=C2=A0 Just say that some
=C2=A0 =C2=A0 >>> security issues have IPv4 equivalents, like ND a= ttacks and ARP attacks, and
=C2=A0 =C2=A0 >>> some do not, like IPv6 EHs or hop by hop DoS.=C2= =A0 =C2=A0The NAT discussion should be in
=C2=A0 =C2=A0 >>> a standalone section, and be neutral there.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.4
=C2=A0 =C2=A0 >>> Why mention the specific example of multi-homed = networks?=C2=A0 =C2=A0What do you mean by
=C2=A0 =C2=A0 >>> the exception?=C2=A0 Is it that multi-homing is = out of scope, and so are unmanaged
=C2=A0 =C2=A0 >>> networks?
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.4
=C2=A0 =C2=A0 >>> Again, NPTv6 is mentioned.=C2=A0 This section is= titled ???addressing architecture???
=C2=A0 =C2=A0 >>> but this bit of text is about reasons for going = PA, PI, or becoming an LIR,
=C2=A0 =C2=A0 >>> which is not architecture.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.4
=C2=A0 =C2=A0 >>> In the 7934 para, RFC8981 should be mentioned as= it???s a significant reason of
=C2=A0 =C2=A0 >>> devices having more addresses.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.5
=C2=A0 =C2=A0 >>> ULAs are also useful where the prefix changes, f= or stable internal addressing
=C2=A0 =C2=A0 >>> as the global prefix changes?=C2=A0 Typically in= residential networks.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.5
=C2=A0 =C2=A0 >>> Section 2.1.4 is really about choices in address= assignment within a network.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.6
=C2=A0 =C2=A0 >>> Some of these paras should be in a section about= IPv6 network reconnaissance,
=C2=A0 =C2=A0 >>> how to best mitigate against scanning, and how t= o inventory your own network
=C2=A0 =C2=A0 >>> elements.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.6
=C2=A0 =C2=A0 >>> All mentions of 4941 should be replaced with 898= 1.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.7
=C2=A0 =C2=A0 >>> Can use 7721 and 8981 together.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.7
=C2=A0 =C2=A0 >>> Why are DHCP and DNS limped together?=C2=A0 The = DNS is only about DNSSEC, so call it
=C2=A0 =C2=A0 >>> that?
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.7
=C2=A0 =C2=A0 >>> ???Even if the use of DHCP??? - this reads badly= .=C2=A0 Rather 8504 talks about this in
=C2=A0 =C2=A0 >>> 6.5, where RFC7844 is mentioned for example.=C2= =A0 This should be in a user privacy
=C2=A0 =C2=A0 >>> section (if this document had one).=C2=A0 Sectio= n 8.4 is also useful advice.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.8
=C2=A0 =C2=A0 >>> The first para is very muddled.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.8
=C2=A0 =C2=A0 >>> In 2.1.7 this can also be useful for ACL control= s, if one admin / control
=C2=A0 =C2=A0 >>> system sits in a prefix of its own.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.10
=C2=A0 =C2=A0 >>> This is really about handling of fragmented pack= ets (the topic) not the
=C2=A0 =C2=A0 >>> fragment header itself Also this is covered in 2= .3.2.1 as well.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.10
=C2=A0 =C2=A0 >>> In 2.2, the intro can say these issues have para= llels in IPv4.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.11
=C2=A0 =C2=A0 >>> First line, say the attack can typically happen = from a large address scan if
=C2=A0 =C2=A0 >>> permitted into the network?
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.11
=C2=A0 =C2=A0 >>> Bullet 1 - that contradicts the comments on pred= ictable addressing.
=C2=A0 =C2=A0 >>> Bullet 2 - how?=C2=A0 Some clues here would be u= seful.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.12
=C2=A0 =C2=A0 >>> ???Current??? - really? All current implementati= ons?=C2=A0 Delete ???current??? or replace
=C2=A0 =C2=A0 >>> with ???naive??? maybe.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.12
=C2=A0 =C2=A0 >>> ???Communicate directly??? - at L2?=C2=A0 If so,= why?
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.12
=C2=A0 =C2=A0 >>> An example of a recommendations section here, wh= ere other sections with advice
=C2=A0 =C2=A0 >>> are not titled as such. See the General comment = on this.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.13
=C2=A0 =C2=A0 >>> ???Trivial??? cases - aren???t these common ones= , like edge switches in an enterprise?
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.13
=C2=A0 =C2=A0 >>> Why ???hostile????=C2=A0 Delete?
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.14
=C2=A0 =C2=A0 >>> In 2.3.5 last para, what about mDNS, Bonjour?=C2= =A0 =C2=A0Though the DNS SD work is now
=C2=A0 =C2=A0 >>> on unicast discovery.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.21
=C2=A0 =C2=A0 >>> Maybe add here 802.1x as an example of the value= of RADIUS logs, and add in
=C2=A0 =C2=A0 >>> here as bullets info harvested from switches and= (say) router NDP syslog
=C2=A0 =C2=A0 >>> (though that???s I suppose the 4th bullet).=C2= =A0 These are mentioned in 2.6.1.7 but
=C2=A0 =C2=A0 >>> should be split out at the same level as the oth= er topics here.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.28
=C2=A0 =C2=A0 >>> The text is 2.6.2.2 repeats earlier text.
=C2=A0 =C2=A0 >>> Similarly text in 2.6.2.3 is repeated form befor= e.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.29
=C2=A0 =C2=A0 >>> In 2.6.2.4 presumably also a rapid growth in ND = cache size is an indicator.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.29
=C2=A0 =C2=A0 >>> In 2.7 point to RFC 4942
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.30
=C2=A0 =C2=A0 >>> Should RFC 6092 be mentioned here?
=C2=A0 =C2=A0 >>> And that the best defence against IPv6 attacks n= ???IPv4 only??? networks is to
=C2=A0 =C2=A0 >>> deploy and manage IPv6?
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.31
=C2=A0 =C2=A0 >>> First bullet on this page - but isn???t this the= same as if the traffic is not
=C2=A0 =C2=A0 >>> tunnelled?=C2=A0 Why does tunnelling add the req= uirement?=C2=A0 The same applies on the
=C2=A0 =C2=A0 >>> first para on p.32
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.31
=C2=A0 =C2=A0 >>> Maybe say here the mitigations can also break tu= nnel brokers (might be desired,
=C2=A0 =C2=A0 >>> but users will notice???)???. Maybe tunnels to s= pecific brokers can be allowed.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.32
=C2=A0 =C2=A0 >>> ISATAP, in 2021?=C2=A0 Same with 6rd.=C2=A0 Gene= ral advice should be deploy native, avoid
=C2=A0 =C2=A0 >>> tunnels.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.33
=C2=A0 =C2=A0 >>> Same for 6to4.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.34
=C2=A0 =C2=A0 >>> Teredo though, is that still included in Windows= and XBoX, as a MS thing?
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.36
=C2=A0 =C2=A0 >>> Maybe cite Geoff Huston???s blog on this - it???= s very good.=C2=A0 Maybe there???s a more
=C2=A0 =C2=A0 >>> recent update though -
=C2=A0 =C2=A0 >>> https://blo= g.apnic.net/2016/06/09/lets-talk-ipv6-dns64-dnssec/. Host CLAT is
=C2=A0 =C2=A0 >>> applicable here?=C2=A0 (Hence a site should supp= ort the 64PREF RA option?=C2=A0 RFC8781
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.38
=C2=A0 =C2=A0 >>> In 2.8, to be fair IPv4 is also hardened a lot o= f late due to the prevalence of
=C2=A0 =C2=A0 >>> use of devices in WiFi hotspots etc.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.37
=C2=A0 =C2=A0 >>> Also RFC6092 on section 3.1?
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.38
=C2=A0 =C2=A0 >>> ???Where RFC1918 address are often used??? - add= ???often???, the text implies all
=C2=A0 =C2=A0 >>> enterprises use v4 NAT.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.41
=C2=A0 =C2=A0 >>> Only 2 normative references?
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> Nits:
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.1
=C2=A0 =C2=A0 >>> ???The Internet??? - you probably mean ???an ISP= network???
=C2=A0 =C2=A0 >>> ???Describes the security??? - delete ???the???<= br> =C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.4
=C2=A0 =C2=A0 >>> ???Which are the switch??? delete ???which are??= ?
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.8
=C2=A0 =C2=A0 >>> Varying -> various
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.10
=C2=A0 =C2=A0 >>> ipv6 -> IPv6
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> p.18
=C2=A0 =C2=A0 >>> Router processor - add r to ???route???
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> ???
=C2=A0 =C2=A0 >>> Tim
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> _______________________________________________<= br> =C2=A0 =C2=A0 >>> OPSEC mailing list
=C2=A0 =C2=A0 >>> OPSEC@ietf.org
=C2=A0 =C2=A0 >>> https://www.ietf.org/mailman/l= istinfo/opsec
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> --
=C2=A0 =C2=A0 >> Enno Rey
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> Cell: +49 173 6745902
=C2=A0 =C2=A0 >> Twitter: @Enno_Insinuator
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> --
=C2=A0 =C2=A0 >> The computing scientist=E2=80=99s main challenge is = not to get confused by the
=C2=A0 =C2=A0 >> complexities of his own making.
=C2=A0 =C2=A0 >>=C2=A0 -- E. W. Dijkstra
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >




--
The computing scientist=E2=80= =99s main challenge is not to get confused by the
complexities of his ow= n making.
=C2=A0 -- E. W. Dijkstra
--0000000000007bec7205c0a79cbc-- From nobody Sun Apr 25 21:34:31 2021 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEB73A17A0; Sun, 25 Apr 2021 21:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.847 X-Spam-Level: X-Spam-Status: No, score=-0.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_IMAGE_ONLY_16=1.092, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 zKkOLPlk7UAI; Sun, 25 Apr 2021 21:34:25 -0700 (PDT) Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (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 8EB1F3A179E; Sun, 25 Apr 2021 21:34:25 -0700 (PDT) Received: by mail-pj1-x102c.google.com with SMTP id gq23-20020a17090b1057b0290151869af68bso4407215pjb.4; Sun, 25 Apr 2021 21:34:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=bEQCyu31P6luX3IrlSSsiqdCLRUzLoZlxfovgI6LiI0=; b=g57Xlw1j33m+lKd8DSyO8AngtguLq0DCTQ3IPuKl0MlrGTIWxGZ6nnBD3gVwkgleqo 6nfo9S3BXlJw4zPDik+QQkxxEEALojC6MCiYDV7/gzbtVnfmoD2ufb4JU/goklOSwRoo vveCXd5PMYxszcyJ+6dXb419W+VEXnvu3FfxpR9IxO9CwJqVZbcYKmIn1qRSgVw7wG9o 1O4SotHeUM1hhBY2QD14rA2ynP4DZXLxJFc/pAnLfvYBWC8SDqc7HPdiPdHadU6Ui4Nn hSIm+oTFulPUmcVnAy7j8YFYu2TyhpdSY8wdjabm51iZpoHhto1el/V7tDVbp2iYWHFi LCMg== 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=bEQCyu31P6luX3IrlSSsiqdCLRUzLoZlxfovgI6LiI0=; b=BXy1MjbLFcnhuuaOqUj33JkPUhA5BXTs6olxw5KouXn7o1cz/bHkI7OKlt6YT8I3wf vc/KGgYkhfQvInjFsOiID47NSrvJzwAkiVlGXQCqMCX5pXkuTpxNOTQR/oIaOagdPB9O eK5dPXkRYFvHQ5k2oqjQbRQy4gmkel7PEVTh4Dkyeh+Jb5FRBJjugCQYflpjF5JCL5AF hF6IP4vhxF6fK4L3xhDyRjFMeNQDnlvn5PztaSRq2EjrteP/UUx9bi6t85fmZ9bq80ZP BgGuPSIti9A1tYFKDcjmNUckI6o4nVpFV+wKXlf4JI72xafdebHd25kFsHbg/j+dicbQ vS2Q== X-Gm-Message-State: AOAM5334UuOKw7qIlddP/M2Ouok9ElVmvBlqlIZfjnXZxKRmzR33dyVl HZTBTEUSa5u6lgzjvyIsvsw5fWEx/7OljKkorC7QTYz7c4c= X-Google-Smtp-Source: ABdhPJyCdJosGJ9irrA2pUxTksgyOCxqC8s3WaDyQ8UYG9xCIeQJuz9C9NJ9G4mifGOB5I/npC2Rbppg2ZUmzXrTMy0= X-Received: by 2002:a17:90b:ecc:: with SMTP id gz12mr20589397pjb.215.1619411662522; Sun, 25 Apr 2021 21:34:22 -0700 (PDT) MIME-Version: 1.0 From: Gyan Mishra Date: Sun, 25 Apr 2021 22:36:48 -0400 Message-ID: To: opsec WG , OpSec Chairs , "Eric Vyncke (evyncke)" Content-Type: multipart/alternative; boundary="000000000000e3ce8305c0d8a8ea" Archived-At: Subject: [OPSEC] draft-ietf-opsec-v6-24 - Shepherd Review update X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2021 04:34:30 -0000 --000000000000e3ce8305c0d8a8ea Content-Type: text/plain; charset="UTF-8" Hi Eric I will do another final Shepherd review now of the draft as this draft as it is on its way to publication. Kind Regards *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* --000000000000e3ce8305c0d8a8ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Eric

I = will do another final Shepherd review now of the draft as this draft as it= =C2=A0is on its way to publication.

Kind Regards


Gyan Mishra

Network Solutions Architect=C2=A0

Email <= a href=3D"mailto:gyan.s.mishra@verizon.com" target=3D"_blank">gyan.s.mishra= @verizon.com=

M 301 502-1347


--000000000000e3ce8305c0d8a8ea-- From nobody Mon Apr 26 00:31:02 2021 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47EC83A10DA; Mon, 26 Apr 2021 00:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.607 X-Spam-Level: X-Spam-Status: No, score=-9.607 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=JSxR7uLp; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=g0ei9hLh Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JtcFuoZZEow; Mon, 26 Apr 2021 00:30:56 -0700 (PDT) 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 34C813A10D6; Mon, 26 Apr 2021 00:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8343; q=dns/txt; s=iport; t=1619422256; x=1620631856; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=UZKqzudHGx8h6IaaM4YwlSITBrW7oPhMensitRAvfyM=; b=JSxR7uLpRpaf/XXq5baTJimbooejeZuUlJr6znR1qBHKyYVo5jjnLIzD 9NwI8EkeFdHODoYCw8ogp/th44HtLinSFUhB+KtzlqIJKRpixnUsqvmzX p9hkgEl/JwG5hN83xDXR+ieSwhirPqtOb78+n3DzzR8eW3VPTK3x9T06K 8=; IronPort-PHdr: =?us-ascii?q?A9a23=3AIWN4qhLdtglUUfJF7dmcuZUyDhhPgJ39IxIV5?= =?us-ascii?q?5w7irlHbqWk+dH4MVfC4el25HfGWIza77RPjO+F+6zjWGlV55GHvThCdZFXT?= =?us-ascii?q?BYKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGF8P3ZlmUqXq3vnYeH?= =?us-ascii?q?xzlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8NhKz+A7QrcIRx4BlL/VZ9?= =?us-ascii?q?w=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3ANRQuhqxJpOkJIUecuHuHKrPxZu8kLtp033?= =?us-ascii?q?Aq2lEZdDV8Sebdv9yynfgdyB//gCsQXnZlotybJKycWxrnlKJdybI6eZOvRh?= =?us-ascii?q?PvtmftFoFt6oP+3ybtcheRysd07o0lSaR3DbTLYmRSpczx7BCkV/Mpx9ea+K?= =?us-ascii?q?6l7N2us0tFZwdsdq1m8kNdAgGUDkV5SGB9dOUEPbCb4ddKoCflRGQPYq2Adz?= =?us-ascii?q?c4dsXgh/mOrpLpZhYaGwUqgTPvsRqE4KP3eiLopis2fChIxd4ZgA34uiz/op?= =?us-ascii?q?6uqvSqjiLbvlWjkqh+vPvE5p99CNeXis4TQw+cyzqAQIh6QbWNsHQUjYiUmS?= =?us-ascii?q?0XueLBqRshIMh/gkm5FgrezHeduHiD7B8U53Dv0lOei3f4yPaJPg4SMdZLho?= =?us-ascii?q?5Sb3Limi0dlex8y65C0ia4sJdaHHr77V3AzuXITB1jmw6Ip2Mjm4co/hpieL?= =?us-ascii?q?YZAYUhybA3zQdwKtMtDSj64IcoHK1FF8fH/stbdluccjTwonRv6MbEZAVyIj?= =?us-ascii?q?62Bmw5/uCF2Tlfm350i2ECwtYEo3sG/JUhD7FZ+uX/NLhynr0mdL5UUYtNQM?= =?us-ascii?q?M6BeenAG3ERhzBdEiIJ078Ka0BM3XR77n6/asy/+PvXJAT1pM9lNDgXTpjxC?= =?us-ascii?q?wPUnOrLffL8IxA8xjLTmn4dy/q0Nti659wvaC5S6HsNSGFVVAyg8qtq/gSGa?= =?us-ascii?q?TgKrKOEaMTJ8WmAXrlGI5P0QG7cYJVM2MiXMocvct+W1/mmLONFqTa8sjgNN?= =?us-ascii?q?rDLrvkFjgpHknlBGEYYTT1LMJcqkSiWnryhgnNS2rgE3aPu65YIez/xaw+2Y?= =?us-ascii?q?INPopDvkw+klKi/PyGLjVEr+gxZ0txILTul6uhvmmo9WPU72FkUyAtS3p90f?= =?us-ascii?q?HFaTdntAUKO0T7ffIooNOEY11f23OBO1tiVc/MCRVeoF524KqzKJSVyUkZeo?= =?us-ascii?q?uaG1Pfq0FWiGOBTp8alKHG2NzsfYkgCI06HIZrEx/QKhBzkQF2iWtKZQMeXH?= =?us-ascii?q?XDHjf2hajNtu1NOMjvM/1HxCaiO4p9tG/Wv0T0n7BQelIrGxqVFfOxrSlrbT?= =?us-ascii?q?xOnVF1+7IYm9O76EeSAFp6pv85Pl1KYHmQG5RcAm2+Fd5ps4GuXh1sRmGXgj?= =?us-ascii?q?HfrBc/dgPRhhgvr12kCzGIcvfWBVcYgFRk6+LB9VN5cXj1RTMrVllzrZB9GW?= =?us-ascii?q?Paunx6zO+MYe6p33GMb0YZq9ttQw3tfSEfOUdnydyxyXeu6Ua/PGRjyZM0Mu?= =?us-ascii?q?PHCrM/N7nVx3O2MYWN0boLBvlO4f9eRZ3Tm/5OVeKUYAmOKjzkT+svxgyOv3?= =?us-ascii?q?4gURME40UMgLft2Bf/6nK/02N6Cf3OIE5+T7VeJ92H9WDrS7KJ15p+5OhF99?= =?us-ascii?q?eYIyH0atScz7vQYCMGIhTPoXSuR+VtsItKp8sJxc1ONoieVSGN2GBM3R04Is?= =?us-ascii?q?uxnEQCQL5j6LSEPoN0ZcQddy9Q41JBrqXCEGI79gjtRuMud1AkiHHWe8mE5L?= =?us-ascii?q?fFsrIjCEyMrgmYAyjWzwRNu/PeGyeT378TDKw9ZXlMYE8n8XJ44aeMcZbTBA?= =?us-ascii?q?jCTZANwHOqdnumNLlTR6iOFe9O8lJ049SUk/SWcCS90gbKpjd/Kr9P9WHiQc?= =?us-ascii?q?7aOnP5JcdYt9ihfVKLie+25cT2ijH9Qz6ycV4Zio1IblZ4VLULthAyyIkslj?= =?us-ascii?q?GvQan2qF8/m1RQ4Tt7hkfgs7LWlVvzDAVDK0nFmZ1YUjlYL2iQgcnE+eae0m?= =?us-ascii?q?7h4DIt4+i1KG5AOtdUG9YRSYDrLyBhbcgI1YTYjZYSvg=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BmAQC1aoZg/4wNJK1XAxwBAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBggEEAQELAYEiMFEHd1o2MYRDg0gDhTmIbIoyihqEdoFCgRE?= =?us-ascii?q?DVAsBAQENAQEoCgIEAQGEUAIXgWICJTcGDgIDAQEMAQEFAQEBAgEGBHEThVA?= =?us-ascii?q?NhkQBAQEBAyMKEwEBOA8CAQgHBwMDAQIoAwICAh8RFAkIAgQBEhuCVgGBflc?= =?us-ascii?q?DLwEOnkgCih96gTKBAYIEAQEGgTMBg2QNC4ITCYEjFwGCeIQJAQGCXYN2Jxy?= =?us-ascii?q?BSUKBOgwQgl8+gh5CAYEsARIBOAkBFRGCUBcfgiuDMlIGKoFjUpQsh3KeEFs?= =?us-ascii?q?Kgw6JcYd2hXiFPAQhg1GXc4lMhk+MX4F5ghKJZoMZlDwCAgICBAUCDgEBBoF?= =?us-ascii?q?qJGlwcBVlAYI+CUcXAg6OH4Nwil1zAjYCBgEJAQEDCXyMFAEB?= X-IronPort-AV: E=Sophos;i="5.82,251,1613433600"; d="scan'208,217";a="863238378" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Apr 2021 07:30:54 +0000 Received: from mail.cisco.com (xbe-aln-004.cisco.com [173.36.7.19]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 13Q7Uspj028107 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 26 Apr 2021 07:30:54 GMT Received: from xfe-aln-004.cisco.com (173.37.135.124) by xbe-aln-004.cisco.com (173.36.7.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Mon, 26 Apr 2021 02:30:46 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Mon, 26 Apr 2021 02:30:46 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 26 Apr 2021 03:30:45 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n2I22+cR4V9rxnyo6QaEDg1Sipxc8sW3nJ+IVajefHNXSlDGgJTjp4OTLxqmr6VW/r5muqkeuY+mhtnKfeFOY8A7Y5uaZ7jzJB3uNzYSf+4pTOCZllDCrHFOL7K87E4x9Rw9eoKNmUUv7diJ77+6SXigxtY8VDbvvIdhfQ7IqYNSWLcf80WUI+eEiwAWSS2JeG70rBaZqzt5o3XFUHvQf3JqQroT32NiMwvDbUqpPnUEL2d9q1cEQqYr9mx473Pmjl5fqx1OJf6Kxz7nbKZrgp0na/I0XdeTkkRQ8PRzaxjEgKrOHdmhfbRzNnv3TAGWd+4huaxNezZizDYg1t3m/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UZKqzudHGx8h6IaaM4YwlSITBrW7oPhMensitRAvfyM=; b=QcKLgpAbXGwxUkW6KKJaJw7X05+JJMW75cZsswTn6/iGnsGWpR97r50OnlrVxusaQrHjdorMIIKkp7+5e5JrsYBpyV8+BTEQBexXT3DcD3utww9xOrNz1Ojq+F8oUSw3ahMszI2rJpWeFbzbZebMvcAsgfw3llDQPfQzu3SGam0lZQcmqzvIm04CwZeN4kzmUZ3E3B4w2mGTmuIPMXtY1Gq+jZvTmwAAw+NtfPfLwZ2EOPh2msvuunFM0w41N0hq6wUdmGnemPaDJ3eGfrjQqksL12Fya4XJ34AYpBz0Qiv1nFba59HKgLznaCjsDOUSll+MlNueSksA5GQNe7G4GQ== 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=UZKqzudHGx8h6IaaM4YwlSITBrW7oPhMensitRAvfyM=; b=g0ei9hLhrKMcg7xyLp3WRAdlMkBK42YW24l21GyE6kqOzXKxUYZQ9MmbT3IL8xpTrJvHKVQYqLELZnYlx1NJTwnIFFS2kYzPu/YXXJXk7MPpCyQ3qu4q6OqBbPDUkWDhVBm7b/mmCnm3hpb49yLy7foNtPyINj5bz0WRycL2hvc= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB4822.namprd11.prod.outlook.com (2603:10b6:510:39::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.23; Mon, 26 Apr 2021 07:30:43 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::dcdf:3910:b85d:6eba]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::dcdf:3910:b85d:6eba%7]) with mapi id 15.20.4065.026; Mon, 26 Apr 2021 07:30:43 +0000 From: "Eric Vyncke (evyncke)" To: Gyan Mishra , opsec WG , "OpSec Chairs" Thread-Topic: draft-ietf-opsec-v6-24 - Shepherd Review update Thread-Index: AQHXOlV2xh4Xz5y010iwrKWChJtOUqrGiP2A Date: Mon, 26 Apr 2021 07:30:43 +0000 Message-ID: <0B38A56C-B339-4226-86E6-D6E89B799018@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/16.48.21041102 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2a02:578:8557:600:44d3:ae72:139f:90af] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 84d02c16-a6a8-4456-40c4-08d908853333 x-ms-traffictypediagnostic: PH0PR11MB4822: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jgwf+mEibQ0duEpFUHcyCfJzzd7l7/GlpaLNychcm+PFgujU1N6fVMLN35L3HlxwrKM8WAR6X6aS41AinMPaSHdDIqcyOuhLkDVfLvPIo07P9q+9LrGoi0iMCpM9OGkv7B9yd8qdS6azsXGL2lwILe2NIRrIJxozu15HhF2Ger5v5iXBdxwt6XEQUp9TLRIJhaWpez7JbIJnIUwKHCDenV5jzJg80X+QSagSauJBdLOhxzxNaNG/raImE4du0Dg32r3+5R8PODhCUZM0Zzxp/1OgNU0pusr6EF2wgPJ5eqbhAjjl78ydGzdqVNMrXhSWraXdodNFJAJZhcG4SLpueo1lmKltZ3yrKjouACydOUiWkvLxdNtkTwY7TYTN0WNyUgHQVQ37G1bjzfnK43ao1nnJIrKz59bSmNQL/Z6DbUENCDlCsHWr1yrHOQYnva/Pw5RV4Neqq81OWgi1DGzTyBLWN0p2YjboJEyAe0w1AwV//5m14oprrzwV4dwygvBmi66ZuzoTWsOQ51ZTBxs4Y9kuX+QoMsRIZzmRKto8vJpq7JcEi59J+BjQ6vBj1+LOkmc75kkrkl5jmhKa8athTFQP/7Sr/q/64texvTK4K5RScK9+Wfogn52DjA59PQQ7W97GU8kNT/x5xGONC4iIsJ//wv34AEx6dFgTW/rqVGs4M3kINvj5E4fIavxqHbUL+V31KMlilKmhxmK5n8fKuKhi92hxQumY9UPeEcM/MIwq+NkOfhWpjBL97Os5j6Uc x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(366004)(346002)(39860400002)(136003)(396003)(4744005)(6512007)(2616005)(15650500001)(186003)(86362001)(2906002)(478600001)(66946007)(8676002)(76116006)(66556008)(66476007)(33656002)(91956017)(66446008)(64756008)(71200400001)(83380400001)(6486002)(166002)(8936002)(5660300002)(38100700002)(122000001)(53546011)(6506007)(36756003)(316002)(110136005)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?Z3BJaU9mcTJHUlVPMW41Q3hhZm9jSTMwdm5rQWtXRkZUTXFEcE9ER3N1RkR3?= =?utf-8?B?enROa0FuaTZYbzJNaDJVdytwQ3RCbXBqeUFUVmhUcXF4ekV4N09RQmtJeGNE?= =?utf-8?B?MXhiU29PVW1FYU9yOGRtTk9tSDZaSjJpNUp6Z1U2YU85WXcrcmQwMXdBNjlD?= =?utf-8?B?T29TV1BBQzBHallEOEVqZkdMU2Zva1VUQmJWQ0V0ZzBYd3doQkVBbjQrcVox?= =?utf-8?B?NEIwZDBwN1dLblFZNGh4YzI2d3ZyeWtUZE9YelF6Y1drb2FtR0dqMXFtaUw2?= =?utf-8?B?SEtwbEt6cmhHUXVWYjBDbm9oZjI2ZTkzT0tSR0w4RXJOVnk5RG9DYWdka0JH?= =?utf-8?B?dEVnZnQ1cWtnOGZBTGUwNSt1VlYvcTlieU10STJzd0tEQ3dLc2NKOVVGdzYw?= =?utf-8?B?N3hGOGpEaVlmdjNQTVhCT1dXYVE4THN1MDdoVi9QTUI3MXdpQnJMcisrd1NI?= =?utf-8?B?ejBBSzBzenUvczZxa1h0a0xwUWZHaHdQTEVLbWNGNHBaeENHbzFKMSsxSzVw?= =?utf-8?B?VzM0L0lQeVZYcnpsSm9pdnhyRWdyWmNGaElPRFVtaGZpZkJqMFNHVStIbXJy?= =?utf-8?B?Vkt0SGptMFpWM3RvNFgwSk9rZmJBRHJBbzR2ZXduUTBaN1dRcmV1V3c0SkZE?= =?utf-8?B?Y1RKL2htL3A4VTh4dVppck1SZ2hyOHdxOUlvZyt4MGJIVWlremxYMy9CZXNB?= =?utf-8?B?dkFocytVM0xVLzl4U3ExNGxKM3ZQeW1INmVxM1dTR2VpSjRDeXhyYkFPblFx?= =?utf-8?B?bW5YRGJGR0NJUjE4T3pPQy8rdWVVc0JPVnc1eWpWNlpxQ2ZCZnpoMjE2bGpo?= =?utf-8?B?V0N2R1dwWnlSR25EUXZEVkYvSEd5R3NoS0k1TTVqRmhoY1U5SEcvRWMrbFlF?= =?utf-8?B?NVhOTWI0d1gzYlRyUUpaSlgwcEtkVGVVRWhuaGl5VVA3U3RmbkNLUm9JYldW?= =?utf-8?B?M25qN1VpbHh2SDBDN1dSMlVld0h6ZFJPZjBCNW51dzBRZ2xYSlpRaUE5SVl4?= =?utf-8?B?YTRqR3pveTdZYmI1TGQwOW1Bbi9uYWd2eHNOUGhlRnZLaDZqbkU2VGFOK2tw?= =?utf-8?B?OXMyOHBjcDg5NUJDZGs1Vms5NjFoK0lsaXBjaVo1UXNQcnBLRmQ1dDA0YmFW?= =?utf-8?B?OUlDQ1R3VldhZmpwRFJYUzM3N1hWd3gxZithOWlHcXRFRWZFc09sTTNUM0lq?= =?utf-8?B?RHV6bmhJd1JoNGFSVXdwTEMySXhXUStZbjEwdlp2RHh1Q3JQdkdtUk1CL2VG?= =?utf-8?B?cFlZaFgxaWliUVRZTUdRbHpUZnRxMlMrbWxBd2JwNGhUMFdESVFpMFZ1bkVT?= =?utf-8?B?VnpKSHRoNEw1cXNlbFpCSmN4dDNwNjFiMzlEdkdia1h3UXc2T1hwWmNpY2d1?= =?utf-8?B?bUNMVXpPakw0VG1sWE5sUEdZdnYrb2NXVUtPT3QyU1J3d3NvNVB0cEl4Z2dQ?= =?utf-8?B?ZUJuYmZiSGJPSE5QSmVLRVUraHdVMm85K2htcjFqSjVndXM4bCtybGdNTFVP?= =?utf-8?B?eGlFaW1MY05iZG5yRUZOQSs3ZzJsWU14K09ZWVY0MmZXQS9Vbm92VW4rdUVV?= =?utf-8?B?S3lleHdGOFFMaGtVYXlLM1cyS0JMQStoWkNwb29NbzFXZS9ZUStKWWFYQ3hI?= =?utf-8?B?VnNQZ1paMDBkRGFtMDhNMVhja1F5KzIydzY1S3grUXdGcnIzYU41RUpoejBn?= =?utf-8?B?b01tR2xpTzJlNmlPcC8yTmJpVEt1aVpmdHlFZHcyQjExOFRKRDZrNkU1UzhE?= =?utf-8?B?L1F1UXhlWGhwRTFLNlp6aC96Unc5UWRQcjkrVThMckx4NEJiL2lPY016WDly?= =?utf-8?B?UHc3cDJOL2ovK1FVVjRaNTQrSExQUHpoZmlYbDhIdHNrUEY0N0dCVy9GNXUz?= =?utf-8?Q?EWmFjIwARMcwh?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_0B38A56CB339422686E6D6E89B799018ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 84d02c16-a6a8-4456-40c4-08d908853333 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2021 07:30:43.0991 (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: z3LTId+q2IWFbntR82gilTxmJPNnbRLnNYsFo/Ome730fUXaradQLksf5hovtdlT8gXKmEd8S1IKhg8M3KBwkw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4822 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.19, xbe-aln-004.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [OPSEC] draft-ietf-opsec-v6-24 - Shepherd Review update X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2021 07:31:01 -0000 --_000_0B38A56CB339422686E6D6E89B799018ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmsgeW91IEd5YW4NCg0KLcOpcmljDQoNCkZyb206IEd5YW4gTWlzaHJhIDxoYXlhYnVzYWdz bUBnbWFpbC5jb20+DQpEYXRlOiBNb25kYXksIDI2IEFwcmlsIDIwMjEgYXQgMDY6MzQNClRvOiBv cHNlYyBXRyA8b3BzZWNAaWV0Zi5vcmc+LCBPcFNlYyBDaGFpcnMgPG9wc2VjLWNoYWlyc0BpZXRm Lm9yZz4sIEVyaWMgVnluY2tlIDxldnluY2tlQGNpc2NvLmNvbT4NClN1YmplY3Q6IGRyYWZ0LWll dGYtb3BzZWMtdjYtMjQgLSBTaGVwaGVyZCBSZXZpZXcgdXBkYXRlDQoNCg0KSGkgRXJpYw0KDQpJ IHdpbGwgZG8gYW5vdGhlciBmaW5hbCBTaGVwaGVyZCByZXZpZXcgbm93IG9mIHRoZSBkcmFmdCBh cyB0aGlzIGRyYWZ0IGFzIGl0IGlzIG9uIGl0cyB3YXkgdG8gcHVibGljYXRpb24uDQoNCktpbmQg UmVnYXJkcw0KDQoNCltodHRwOi8vc3M3LnZ6dy5jb20vaXMvaW1hZ2UvVmVyaXpvbldpcmVsZXNz L3Z6LWxvZ28tZW1haWxdPGh0dHA6Ly93d3cudmVyaXpvbi5jb20vPg0KDQpHeWFuIE1pc2hyYQ0K DQpOZXR3b3JrIFNvbHV0aW9ucyBBcmNoaXRlY3QNCg0KRW1haWwgZ3lhbi5zLm1pc2hyYUB2ZXJp em9uLmNvbTxtYWlsdG86Z3lhbi5zLm1pc2hyYUB2ZXJpem9uLmNvbT4NCg0KTSAzMDEgNTAyLTEz NDcNCg0K --_000_0B38A56CB339422686E6D6E89B799018ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2VvcmdpYTsN CglwYW5vc2UtMToyIDQgNSAyIDUgNCA1IDIgMyAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBw dCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iZW4tQkUiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiPlRoYW5rIHlvdSBHeWFu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkZSIj4tw6lyaWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+R3lhbiBNaXNocmEgJmx0 O2hheWFidXNhZ3NtQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+TW9uZGF5LCAyNiBB cHJpbCAyMDIxIGF0IDA2OjM0PGJyPg0KPGI+VG86IDwvYj5vcHNlYyBXRyAmbHQ7b3BzZWNAaWV0 Zi5vcmcmZ3Q7LCBPcFNlYyBDaGFpcnMgJmx0O29wc2VjLWNoYWlyc0BpZXRmLm9yZyZndDssIEVy aWMgVnluY2tlICZsdDtldnluY2tlQGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+ ZHJhZnQtaWV0Zi1vcHNlYy12Ni0yNCAtIFNoZXBoZXJkIFJldmlldyB1cGRhdGU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiciBjbGVh cj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkhpIEVyaWM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SSB3aWxsIGRvIGFub3RoZXIgZmluYWwgU2hlcGhl cmQgcmV2aWV3IG5vdyBvZiB0aGUgZHJhZnQgYXMgdGhpcyBkcmFmdCBhcyBpdCZuYnNwO2lzIG9u IGl0cyB3YXkgdG8gcHVibGljYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPktpbmQgUmVnYXJkczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMjIyMjIyIj48YSBocmVmPSJodHRwOi8vd3d3LnZl cml6b24uY29tLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojMjIyMjIyO3Rl eHQtZGVjb3JhdGlvbjpub25lIj48c3BhbiBzdHlsZT0iY29sb3I6IzExNTVDQyI+PGltZyBib3Jk ZXI9IjAiIHdpZHRoPSI4MSIgaGVpZ2h0PSIxOCIgc3R5bGU9IndpZHRoOi44NDM3aW47aGVpZ2h0 Oi4xODc1aW4iIGlkPSJfeDAwMDBfaTEwMjUiIHNyYz0iaHR0cDovL3NzNy52encuY29tL2lzL2lt YWdlL1Zlcml6b25XaXJlbGVzcy92ei1sb2dvLWVtYWlsIj48L3NwYW4+PC9zcGFuPjwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJn aW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MGNtO21hcmdpbi1sZWZ0OjM2LjBwdDttc28tbGlu ZS1oZWlnaHQtYWx0OjkuNzVwdCI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+R3lhbiBNaXNocmE8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MGNtO21hcmdpbi1sZWZ0 OjM2LjBwdDttc28tbGluZS1oZWlnaHQtYWx0OjkuNzVwdCI+DQo8aT48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7R2VvcmdpYSZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+TmV0d29yayBT b2x1dGlvbnMgQXJjaGl0ZWN0Jm5ic3A7PC9zcGFuPjwvaT48c3BhbiBzdHlsZT0iY29sb3I6IzIy MjIyMiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tbGVmdDozNi4w cHQ7bXNvLWxpbmUtaGVpZ2h0LWFsdDo5Ljc1cHQiPg0KPGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7R2VvcmdpYSZxdW90OyxzZXJpZjtjb2xvcjpibGFj ayI+RW1haWwgPGEgaHJlZj0ibWFpbHRvOmd5YW4ucy5taXNocmFAdmVyaXpvbi5jb20iIHRhcmdl dD0iX2JsYW5rIj4NCmd5YW4ucy5taXNocmFAdmVyaXpvbi5jb208L2E+PC9zcGFuPjwvaT48c3Bh biBzdHlsZT0iY29sb3I6IzIyMjIyMiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjEy LjBwdDttYXJnaW4tbGVmdDozNi4wcHQ7bXNvLWxpbmUtaGVpZ2h0LWFsdDo5Ljc1cHQiPg0KPGk+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0dlb3JnaWEmcXVvdDssc2VyaWY7Y29sb3I6 YmxhY2siPk0gMzAxIDUwMi0xMzQ3PC9zcGFuPjwvaT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_0B38A56CB339422686E6D6E89B799018ciscocom_-- From nobody Mon Apr 26 01:09:27 2021 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F7A3A1272; Mon, 26 Apr 2021 01:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWAXoBZS8S4c; Mon, 26 Apr 2021 01:09:16 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80083.outbound.protection.outlook.com [40.107.8.83]) (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 795873A1270; Mon, 26 Apr 2021 01:09:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GTC4gY28T3i3tU1S3ITTaN1H0O55qfsGtOIxEx1/aNvZfGQTkH2j1bYu7WzyV2AlSJJ+cZqClAQJQVOhAspd4VJi8z5EROPiICb0sIFskeO8iIYzdyVMCHpLG7gJdNcaNL4N6N46lNRReSfBZoXj/pGhzzs7ZDseu6+yV0J2bMMBayqq3oFudIh6+bi0CouHc412cASsxDS5M6r+chDStpQPn3CIWDxiRhk2Gr7FQbdHQjoZJ4G0f3100cIj4jsLqmPveRahNuQU12QGuQN4g5YY4Ws7McpOjiIIrNHocy+ZV+Sl70pClnC3VwadE0Tf33b4DKewg7i9yXeF8hNZjw== 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=7/bStvS2Ir3td6rfP0J1cwAzCBVtgFIEBMgZwH5WONY=; b=JzTv8DmECLIzy7l9z+xeflvGF0a1Akn2G+2Sp2KYcn5iN1oLlqg021kkFMgiESSXfb7/UZ/r/NTWiAJ2OtPiJH0PH0rnD1e4e9BPOz7hZVlpW9/0EZLiqT7tDDqGwxWvAKHRfy1EaGUnjSRmQ45qjo4fecarjhzZAEeNshfB2TfGhf3TVaCe1ratRPUpbBFeXQmfe+Ze33RU7ZexXOKs7m9uKCKsM4TnmZwq970mFnr0JfL1TRGmkzmYl6+9cuzyT8yxS4m6rlzy8gLBw7zoVZbpSYXny0gHpdojTjF4tXkX1UHY8mkUtfd6hI1ZJERgFbLbvuN5BMLfrd//sXMyKQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jisc.ac.uk; dmarc=pass action=none header.from=jisc.ac.uk; dkim=pass header.d=jisc.ac.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7/bStvS2Ir3td6rfP0J1cwAzCBVtgFIEBMgZwH5WONY=; b=aDtAcjYY4z0c0U/P+A3b/sT6CO8SCICGoQQ+70NouJ6yHTEuHXSDP4+p0RvCPCkN7h9bORFj61elBAXe1poq2GnJr7KFxwt3bbAAtq6up++jmBsd+vkhv+axbu6w9kLXKdENbFmcWhc04oe8bWVe4IA/CcNswH/cdsPrW45/Kpw= Received: from DB9PR07MB7771.eurprd07.prod.outlook.com (2603:10a6:10:2a6::15) by DBBPR07MB7467.eurprd07.prod.outlook.com (2603:10a6:10:1ea::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4087.21; Mon, 26 Apr 2021 08:09:09 +0000 Received: from DB9PR07MB7771.eurprd07.prod.outlook.com ([fe80::6011:1efb:4348:f34f]) by DB9PR07MB7771.eurprd07.prod.outlook.com ([fe80::6011:1efb:4348:f34f%5]) with mapi id 15.20.4087.024; Mon, 26 Apr 2021 08:09:09 +0000 From: Tim Chown To: Warren Kumari CC: "Eric Vyncke (evyncke)" , Enno Rey , ops-dir , opsec wg mailing list , "draft-ietf-opsec-v6.all@ietf.org" Thread-Topic: [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-25 Thread-Index: AQHXLjnDyQdRJCPbVUCT8CaQwzD7p6qy81iAgAwYLgCAAFKTgIABEYCAgAIJ3ISABBD0AA== Date: Mon, 26 Apr 2021 08:09:08 +0000 Message-ID: References: <161778675730.8077.2835666586607648895@ietfa.amsl.com> <20210410184555.GE91991@ernw.de> <4BDF1579-CB77-4B1F-ADCE-8813C859FDEB@cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3654.60.0.2.21) authentication-results: kumari.net; dkim=none (message not signed) header.d=none;kumari.net; dmarc=none action=none header.from=jisc.ac.uk; x-originating-ip: [2001:a88:d510:1101:e592:a024:b594:1ec5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 28c1eb9e-d6ea-46e3-8360-08d9088a9192 x-ms-traffictypediagnostic: DBBPR07MB7467: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oAdAMqwjUL6p8ebPWcxxyqs44luWtWfn6Ju/tWleZGuNxa2wZqGp0imb9w/m6UkWe2YYph0iNw2XAcLPmChkbyL1sMWp2Xm9TAw4YYlM+xWtLwB546ys0KwbKOXfyVs88+FglbRwoA9wxafnaadj2CApaXF79cw/M5yP8lLVazUfzQN8F3WHAdJ46YGsTvwY3r6WJz/so6FDD+XzfBcoapsYf8c+d7HvSwm7JhlcWdhjGea8/7OMfzGoZKsQP3lzTrnsTuJerv9RPn/bysoIJCp7TNu2RR0RRj6B61QHq+g5Prwrm4/hybLOKJ/f0YLItgryrVXiBemSQcz6ocwabPbdPxSsDh0X23aFVCWTUGKiaXgTBUk4mt3KGUIgGXBdF8rCopa65HJRkEquGtZgs0sXKGkDVwrqjI3cfM3r+l0cnnayAkwFZSr4xF3zPPT3Lb0DColqaMVWw7SEi5/RgFrAGS+47PEuFxipPI16Grjbk11ul4rpNhyhzg+2hlWPCBKbwhx6A5IANqcxjaqdoIxrqQahvk8PsgEs/jmatfnZqIbUbKxAsno/EwG3WoUvWZzeM01ct+I5QGFPifNFRxa0aDZ0Xjq2VzAJF7ocNYOS0iv48ZCsfDRjLTQNHe8Lt6NHw6sMzYVHSIB4cLw05NHE3zAsi8LHpDfa19MUJi0= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB9PR07MB7771.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(136003)(366004)(376002)(39850400004)(8936002)(91956017)(8676002)(76116006)(4744005)(66446008)(64756008)(66556008)(66476007)(66946007)(36756003)(86362001)(33656002)(5660300002)(186003)(2616005)(478600001)(6512007)(2906002)(4326008)(71200400001)(53546011)(6506007)(38100700002)(122000001)(6916009)(54906003)(6486002)(786003)(316002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?2X+RWqy/kllcBmRLsFB8I1Q4vkyx3wO+yg7L/jb0TZGO6ebsy9nsa6bK8q5Y?= =?us-ascii?Q?c8PzDrlpP8hlYxkPLmDJC7yc5ZlwqJPniea3ExRsFyOhVLWknu+q3yWnwhcV?= =?us-ascii?Q?DCSOfNbErqrrEagDUdfh0KSNoO6PozHWAvD7zSNcgMSMxhTiks3erZRouTjI?= =?us-ascii?Q?hvW+lbodlvLoLjor0aYiZaJB8tVVH45atH99dirTCGKn8r5ZBX+5H4Ot0yp5?= =?us-ascii?Q?kAkzEsvuq0GnmukZpwmpL9BxgV2pzJ/7VcYaIW3fke1i/w+PmXgnZ7AqbOlG?= =?us-ascii?Q?HLtv7ku9Ebx987zfDpLnHBpltBzv/nzHxmJOTjXbx4a2hDgwp6+IW+VwYnK/?= =?us-ascii?Q?+hF1atR7WgTIgvXAMrtSrbIH8F9LK8DVt23skdjWTSlQhdsecuemDi/JRHqJ?= =?us-ascii?Q?nEtG+38R2DTqaQPJNMmMLvX+rCbzDb31/4/EOL04FJKiqVOE6J3rfy9UnD8t?= =?us-ascii?Q?IewnNMXqnuaLK45Mo3lNt/gGXSzjfPVL4ROUzrC2SGErbivCxchtqPQ2bmlq?= =?us-ascii?Q?UIn+/XjhrZp46p6p2oXGUC/mxTDEn+h+PLIg8nh3ZXyVONtOADJSU9G7sUvc?= =?us-ascii?Q?93ErpE2kCjdMRQvbNgrOHXUVT4CTO+S7mLtVKdC58KEefWAavFqYk+f06hTx?= =?us-ascii?Q?POVehdZ8aB25ufyFPLu3qVl/IhXH9Y/PFapDzxHyjqxRnN2kQdom5/HMFzJR?= =?us-ascii?Q?99YXS9CFKf7TuGHlQXvLOXeG4yVZCEvN4/99iQyQKRcQJHa2cPr9Qx0271Vf?= =?us-ascii?Q?fSHFrUtKvALYwI1+7hRSRpbSL/mIy05WiI0yz7DzgH9gfF8K+fWcGlVS33sf?= =?us-ascii?Q?TCYOcO+8/+QVX7FOAbtGUzsCdZRsqsZFLbWtV5HRkvX2VddSSiWfvrlYpzTK?= =?us-ascii?Q?VcPyo4zouUpP3FyCMZXDZoyeYpH6eTbmy1sNngUoBJzecj9G0ScEEce8H6j6?= =?us-ascii?Q?Yl/jKnTQE0pnfhMlbZ+GdZHIuZWgvbQ+7hQapHmbvt0angqxOaZc79fcwO76?= =?us-ascii?Q?kvEsoPfNQYPxMt5D5t0nDfMRamEmis4RvJKdXOO+ZCCBjZGmjocOlFXvuelz?= =?us-ascii?Q?MS4jO1bgiv0KfUBO+3MYOnBYyT+Nfb6nnXXYqGEaKknTqcg2fuJNPNQLGcrn?= =?us-ascii?Q?mxYHO0Jsdvia/sqdI+GpEHMJFM8k/ge9PAD4V2EQw3O6QU/pd9hC4cOlAbnB?= =?us-ascii?Q?FLRf5XqgeqrlBHdrA/b+8omrEfHPIg5Fkdbcb0c9YMUg61WWJB9ThPF7XvVN?= =?us-ascii?Q?nPRcYTeB6FoAw/Mnb82VVc+aBMklqORGM3PSW2TNHT43IyKyndREkfi+nnUY?= =?us-ascii?Q?JaEORZ9psG5LmQWVsos8QhT9N1AMItWUlPZ+qYqE+oKN4tlH6Qp4M6Exifdj?= =?us-ascii?Q?etfgP0dUIlCVgHvRgKBr2LJASv6S6n6jo+2npYM7392orkSSZA=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB9PR07MB7771.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 28c1eb9e-d6ea-46e3-8360-08d9088a9192 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2021 08:09:08.9248 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: NcXo3kk5OwejeFCQbp2XP50gtJSw5UpNdbIDBJloM75AhrBDXBNqmQOgmtWUZRYKEv6FUdPf+R9vqS7mzMLJog== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR07MB7467 Archived-At: Subject: Re: [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-25 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2021 08:09:22 -0000 > On 23 Apr 2021, at 19:02, Warren Kumari wrote: >=20 > [ - last-call for clutter ]=20 >=20 > On Thu, Apr 22, 2021 at 7:11 AM Eric Vyncke (evyncke) = wrote: > Thank you Tim for the re-check of the document. >=20 > Indeed, thank you Tim, both for the review, and for being flexible. >=20 > This document has a long and storied history, and, while it certainly cou= ld be better, I think that it's one of those "it's better to ship something= imperfect now, vs never getting around to shipping it" type document. Agreed, and I think Eric, Enno and the authors deserve some kind of enduran= ce medal for this :) Tim= From nobody Tue Apr 27 07:46:06 2021 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 373FA3A0D87; Tue, 27 Apr 2021 07:46:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: opsec-chairs@ietf.org, opsec@ietf.org, rbonica@juniper.net, warren@kumari.net X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161953476520.17795.987752280958234830@ietfa.amsl.com> Date: Tue, 27 Apr 2021 07:46:05 -0700 Archived-At: Subject: [OPSEC] opsec - New Meeting Session Request for IETF 111 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2021 14:46:05 -0000 A new meeting session request has just been submitted by Ron Bonica, a Chair of the opsec working group. --------------------------------------------------------- Working Group Name: Operational Security Capabilities for IP Network Infrastructure Area Name: Operations and Management Area Session Requester: Ron Bonica Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: 6man v6ops spring lsr People who must be present: Ron Bonica Warren "Ace" Kumari Jen Linkova Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Apr 29 16:39:30 2021 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37DB33A1831; Thu, 29 Apr 2021 16:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 oCL4UE8u0k45; Thu, 29 Apr 2021 16:39:24 -0700 (PDT) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 E7FC73A1834; Thu, 29 Apr 2021 16:39:23 -0700 (PDT) Received: by mail-pf1-x430.google.com with SMTP id 10so4691250pfl.1; Thu, 29 Apr 2021 16:39:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t8UAYcwKZQTIyvYETVrdDLFNjxbeIhloApb1VbIHpG4=; b=KhWKRoodGyynWqadAPj+bGqTMB8SccGIBpQVINyFP06JX0B9vWXC/xEfYV8q+Cxbfq ohAfEYVIqtMnEzRXwPMBLr6YjfQGawTc2a6Shxk3EY6JazN7B584vqLYfubvhjsOWE7H FCCUeSb9I+jZTHlSQUaLoMnR+Ts4ESaXkEi45C53cbujRo+EqbCteNPiIhot6zyqiK8k DxnhZBZ9wMoNWgbD5BHmctA3NFktNGz5wDX3SAX1z7Yz2SCq4n5cplRg/Cu89OUKyxOf QOr4tGNOiHQdTvSCjSOMrUJY4x+cWaqReiLmgv+ljWvIaSGhYi8g1ZPciSUAf4u+Zs/T 9uIw== 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=t8UAYcwKZQTIyvYETVrdDLFNjxbeIhloApb1VbIHpG4=; b=ibqIyE+FYxViPqNQlqMkxyNbVaokFcmIavXXZEBkBDkb2QF0GfzpFLArMsqSucVbZs vAZkVNTBXL10cSGY+2k0ih8SaKUOjMCHIwkWhOUTuj8icgbPy5hxD+wTRwiK7WjPYrem S+F+iSNpIg8qbGwxUeNV1L6IF8SgulGvO3cJKkMbeJxxohetqaFLxs2U3R/mQ2WyV/yN LNnOah77uPgEvctxViLos7edkcqFPIv9aJv98CWwnnVsYfcmFUOO84Xaw5udHnGvzbzx g0GKppxlV8Ykd3Ec7KHArMOn6zUgS0uw4fox0JXbdi18Ti6gmEQOXjlgRckr6k72xNUE wBWw== X-Gm-Message-State: AOAM532A0uEFKLquzSp+v05qkbXUwuSNIA3SElwZ2tSGDuo0GVv0Xum7 cmaTVf9tOa9CQBhJecb8RR5TOmC3Na3rNeQhrMc= X-Google-Smtp-Source: ABdhPJy7fadd5RG5d34mIf26+SMUpgPhsUZLq6huOUM05gD2eZ586Wr6jzw2Vqfz3vXbthCpOnRx973W3jQkbO4Inr4= X-Received: by 2002:a65:6095:: with SMTP id t21mr2000536pgu.383.1619739561969; Thu, 29 Apr 2021 16:39:21 -0700 (PDT) MIME-Version: 1.0 References: <0B38A56C-B339-4226-86E6-D6E89B799018@cisco.com> In-Reply-To: <0B38A56C-B339-4226-86E6-D6E89B799018@cisco.com> From: Gyan Mishra Date: Thu, 29 Apr 2021 19:38:59 -0400 Message-ID: To: "Eric Vyncke (evyncke)" Cc: OpSec Chairs , opsec WG Content-Type: multipart/alternative; boundary="000000000000384ae305c12501cf" Archived-At: Subject: Re: [OPSEC] draft-ietf-opsec-v6-24 - Shepherd Review update X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2021 23:39:29 -0000 --000000000000384ae305c12501cf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Eric Shepherd Review below: Abstract =E2=80=9C This document is only applicable to managed networks, such as enterprise networks.=E2=80=9D Should we mention service provider public internet and private networks are applicable Introduction Maybe mention extension headers as that has been a huge difference as well as security issue When mentioning ARP and ND difference maybe mention that now ICMPv6 now takes on the role of L2 Mac to L3 address mapping and maybe along the same line of thinking of broadcast versus multicast mention that broadcast no longer exist in IPv6. 2.1 Addressing Architecture Rewording of what RFC 7934 states related to multiple addresses Old In [RFC7934 ], it is recommended that IPv6 network deployments provide multiple IPv6 addresses from each prefix to general-purpose hosts and it specifically does not recommend limiting a host to only one IPv6 address per prefix. The way it=E2=80=99s worded it appears that it=E2=80= =99s recommended that the network provide more then one address. New RFC 7934 states that most general-purpose IPv6 networks, hosts have the ability to configure additional IPv6 addresses from the link prefix(es) without explicit requests to the network as there are host functions that require more then one address. Maybe also mention at the end of the paragraph that having multiple addresses on a host provides challenges to the NOC in troubleshooting and MTTR. Section 2.1.1 ULAs although less likely to have overlap due to pseudo random algorithm there is no guarantee of not having an overlap. Operators of with large internal corporate networks that are subject to mergers and acquisitions it is recommended to not use ULA. ULA does not guarantee uniqueness where GUA does for internal deployments. 2.1.2 Many operators reserve a /64 block for all P2P addresses in their infrastructure and allocate a /127 out of this reserved /64 prefix for each p2p interface. This is a routing related caveat related to addressing. So as all routing protocols use LL next hop most vendors have a command similar to cisco =E2=80=9CIPv6 enable=E2=80=9D that allows for processing and forwa= rding of IPv6 packets without an IPv6 address configured on an interface. The caveat here is in traceroute the interface next hop is not shown in the trace and so for the NOC makes troubleshooting more difficult. However it does make deployments or IPv6 on routed backbone nodes much quicker as no address planning is required. I actually use this method in lab environments all the time and it=E2=80=99s very handy. Also mention that on eBGP tie connections GUI or = ULA as well is not required to save on address planning and peering can be done using link local. However care must be taken as the caveat is LL is not reachable beyond local link and ping or OAM of link if required that will not work. The same operationalissue goes for a routed interfaces using LL and no IPv6 address are now not pingable to ensure each link is Up and reachable by NMS. On P2P when using /127 it is recommended to disable DAD as the subnet router anycast is used and so DAD could fail and place the IPv6 interface in a =E2=80=9Ctentative=E2=80=9D state. 2.14 I believe what was meant is stable but random not =E2=80=9Cnot-stable as fo= r server functions should always be stable address. Maybe worth mentioning and use of static stable address for servers and not SLAAC address. Old Typical deployments will have a mix of stable and non-stable addresses; the stable addresses being either predictable (e.g., ::25 for a mail server) or obfuscated (i.e., appearing as a random 64-bit number). New Typical deployments will have a mix of stable predictable and stable random addresses; the stable addresses being either predictable (e.g., ::25 for a mail server) or obfuscated (i.e., appearing as a random 64-bit number). The Mention the double edged sword trade off as far as importance when it comes to using random changing address used for privacy for broadband users versus stable address for corporate network user community where security and traceability is of utmost importance. I believe what is being conveyed related to scanning is by pinging FF02::1 it is easy to discover all hosts on the network. Also may want to mention that all host have a local ND cache similar to a router ND cache as ICMPv6 is running between the router and all hosts NS/NA as well as RS/RA. 2.1.5 Should note that even though M and O bit is set the SLAAC address is also set as well. SLAAC has to be disabled manually on router via cisco command example =E2=80=9CIPv6 nd default no-advertise=E2=80=9D. For any router or P2P links mentioned also =E2=80=9CIPv6 ND RA suppress-all= =E2=80=9D cisco command example which suppress both periodic and response to unsolicited RS as routed link has static IP. On L2 switches which may have Mgmt interface that sits on the same subnet as upstream router pair L2 connected to closet switch once and address is placed on the L3 router interface the L2 router can act as a default gateway hijack as it sends an RA. This can impact all hosts on the subnet black hole. All L2 switches Mgmt L3 interface that sits on host subnets interface should have =E2=80=9CIPv6 nd ra suppress-all=E2=80=9D. For L2 ho= sts the recommended is to not enable IPv6 uncast-routing on hosts placing them in =E2=80=9Chost-mode=E2=80=9D versus acting as a router and now the L2 switch= can pick up default route via RA from upstream router pair. With that of course any use of SLAAC and RA advertisement to host requires RA guard. 2.2 Mention the DDOS denial of service issue related to HBH and DOH as their is no limit to the number of TLV options other than the maximum length of hbh options header 2048 that can be present as well as well as 0 byte TLVs are valid and also no limit to the number of extended headers stacked limited by the MTU. Also the cyclical cycle by operators filtering hbh and doh to avoid risk of ddos attack and management plane impact which impacts designers from developing new use cases for hbh and doh. This impacts the use of hbh and doh over the internet. Section 2.4 See this draft which I am Co-author has some details related to NPU and fixed function ASIC and separation of control plane and data plane criticality. Maybe add below draft as normative reference https://tools.ietf.org/html/draft-peng-v6ops-hbh-03 Mention the management plane which is impacted when packets are sent to the control plane. 3.1 Perimeter ACLs as well as firewall filters it is recommended to only permit directly adjacent ND packet as ND used RFC 5082 GTSM so TTL is set to 255 and which can be used as an attack vector. I have an perimeter IACL that is customized and had the DAD has the solicit node multicast address so DAD succeeds. 2.7.2.4 =E2=80=9CSecuring the routing protocol between CE and PE; in the case of 6P= E and 6VPE, link-local addresses (see [RFC7404 ]) can be used and as these addresses cannot be reached from outside of the link, the security of 6PE and 6VPE is even higher than an IPv4 BGP/MPLS IP VPN.=E2=80=9D When using LL peering on the PE-RR iBGP peeing or PE-PE ibgp peering make sure next-hop-self is used so the next hop is rewritten to loopback0 which is reachable as LL not reachable. Section 2.7.1 Mention Happy Eyeballs RFC 6555 and Happy Eyeballs 2 RFC 8305 - By default with dual stack IPv6 is preferred over IPv4 and that impacts access to host via TCP or UDP as well as operational impact so any ping trace or ssh done from the device IPV6 is used over IPV4. By default on dual stacked host a A/AAAAA request goes out and a A/AAAA reply comes back and the client creates IPv6 socket for TCP session to server with a TCP RTO retransmission timeout of 20 seconds approximately. With Happy Eyeballs 1 there is a simultaneous v6 end v6 connection with a 300ms preference for v6 establishes and within 300ms the failover of the session occurs from v6 to v4 thus not noticeable to the naked eye thus happiness with the eyeballs of the user. Section 2.7.2 We should include 4to6 which as well as 6to6 tunnels. Kind Regards Gyan On Mon, Apr 26, 2021 at 3:30 AM Eric Vyncke (evyncke) wrote: > Thank you Gyan > > > > -=C3=A9ric > > > > *From: *Gyan Mishra > *Date: *Monday, 26 April 2021 at 06:34 > *To: *opsec WG , OpSec Chairs , > Eric Vyncke > *Subject: *draft-ietf-opsec-v6-24 - Shepherd Review update > > > > > Hi Eric > > > > I will do another final Shepherd review now of the draft as this draft as > it is on its way to publication. > > > > Kind Regards > > > > > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mishra@verizon.com * > > *M 301 502-1347* > > > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* --000000000000384ae305c12501cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Hi Eric=C2=A0<= /div>

Shepherd Review below:

Abstract=C2=A0

=E2=80=9C=C2=A0This document is only applicable to managed
   networks, such as enterprise networks.=E2=80=9D

Should we mention service prov= ider public internet and private networks are applicable=C2=A0

Introduction=C2=A0

Maybe mention extension headers as that h= as been a huge difference as well as security issue
=
When mentioning ARP and ND difference maybe men= tion that now ICMPv6 now takes on the role of L2 Mac to L3 address mapping = and maybe along the same line of thinking of broadcast versus multicast men= tion that broadcast no longer exist in IPv6.

2.1 Addressing Architecture=C2=A0

Rewording of what RFC 7934 states related to= multiple addresses=C2=A0

Old=C2=A0

In [RFC7934], it is recommend=
ed that IPv6 network deployments provide multiple IPv6 addresses from each =
prefix to general-purpose hosts and
 it specifically does not recommend limiting a host to only one IPv6
   address per prefix. The way it=E2=80=99s worded it appears that it=E2=80=
=99s recommended 
that the network provide more then one address.

New 


RFC 7934 states that most general-purpose IPv6 networks, ho=
sts have the ability to configure additional IPv6 addresses from the link p=
refix(es) without
   explicit requests to the network as there are 
host functions that require more then=
 one address.

Mayb= e also mention at the end of the paragraph that having multiple addresses o= n a host provides challenges to the NOC in troubleshooting and MTTR.
<= div dir=3D"auto">
Section 2.1.1=C2=A0

ULAs although less likely to have = overlap due to pseudo random algorithm there is no guarantee of not having = an overlap.=C2=A0 Operators of with large internal corporate networks that = are subject to mergers =C2=A0and acquisitions it is recommended to not use = ULA.=C2=A0 ULA does not guarantee uniqueness where GUA does for internal de= ployments.=C2=A0

2.1.2= =C2=A0

Many operators reserve a /64 block=
 for all P2P  addresses in
   their infrastructure and allocate a /127 out of this reserved /64
   prefix for each p2p interface. 

This is a routing related caveat related to addressing.  So=
 as all routing protocols use LL next hop most vendors have a command simil=
ar to cisco =E2=80=9CIPv6 enable=E2=80=9D that allows for processing and fo=
rwarding of IPv6 packets without an IPv6 address configured on an interface=
.  The caveat here is in traceroute the interface next hop is not shown in =
the trace and so for the NOC makes troubleshooting more difficult.  However=
 it does make deployments or IPv6 on routed backbone nodes much quicker as =
no address planning is required.  I actually use this method in lab environ=
ments all the time and 
it=E2=80=99s very handy.  Also mention that on eBGP tie connect=
ions GUI or ULA as well is not required to save on address planning and 
peering can be=
 done using link local. However care must be taken as the caveat is LL is n=
ot reachable beyond local link and 
ping or OAM of link if required that will not work.=
  The same operationalissue goes for a routed interfaces using LL and 
no IPv6 address =
are now not pingable to ensure each link is Up and reachable by NMS.
<=
pre class=3D"newpage" style=3D"font-size:1em;margin-top:0px;margin-bottom:0=
px;break-before:page;font-family:monospace" dir=3D"auto">

On P2P when using /127 it is rec=
ommended to disable DAD as the subnet router anycast is used and so DAD cou=
ld fail and place the IPv6 interface in a =E2=80=9Ctentative=E2=80=9D state=
.

=

2.14 

I believe what was meant is st=
able but random not =E2=80=9Cnot-stable as for server functions should alwa=
ys be stable address. Maybe worth mentioning and use of static stable addre=
ss for servers and not SLAAC address. 

Old 

Typical deployments will=
 have a mix of stable and non-stable
   addresses; the stable addresses being either predictable (e.g., ::25
   for a mail server) or obfuscated (i.e., appearing as a random 64-bit
   number).

New 

Typical deployments will have a mix of stable predi=
ctable and stable random
   addresses; the stable addresses being either predictable (e.g., ::25
   for a mail server) or obfuscated (i.e., appearing as a random 64-bit
   number).  The 

M=
ention the double edged sword trade off as far as importance when it comes =
to using random changing address used for privacy=C2=A0
for broadband users versus stab=
le address for corporate network user community where security and traceabi=
lity is of utmost importance.

=
I believe what is being conveyed related to scannin= g is by pinging FF02::1 it is easy to discover all hosts on the network.=C2= =A0 Also may want to mention that all host have a local ND cache similar to= a router ND cache as ICMPv6 is running between the router and all hosts NS= /NA as well as RS/RA. =C2=A0

2.1.5=C2=A0

Should = note that even though M and O bit is set the SLAAC address is also set as w= ell.=C2=A0 SLAAC has to be disabled manually on router via cisco command ex= ample =E2=80=9CIPv6 nd default no-advertise=E2=80=9D. =C2=A0

For any router or P2P links mentioned= also =E2=80=9CIPv6 ND RA suppress-all=E2=80=9D cisco command example which= suppress both periodic and response to unsolicited RS as routed link has s= tatic IP. =C2=A0

On L2 s= witches which may have Mgmt interface that sits on the same subnet as upstr= eam router pair L2 connected to closet switch once and address is placed on= the L3 router interface the L2 router can act as a default gateway hijack = as it sends an RA.=C2=A0 This can impact all hosts on the subnet black hole= . All L2 switches Mgmt L3 interface that sits on host subnets interface sho= uld have =E2=80=9CIPv6 nd ra suppress-all=E2=80=9D.=C2=A0 For L2 hosts the = recommended is to not enable IPv6 uncast-routing on hosts placing them in = =E2=80=9Chost-mode=E2=80=9D versus acting as a router and now the L2 switch= can pick up default route via RA from upstream router pair.=C2=A0 With tha= t of course any use of SLAAC and RA advertisement to host requires RA guard= .

2.2=C2=A0

Mention the DDOS denial of service i= ssue related to HBH and DOH as their is no limit to the number of TLV optio= ns other than the maximum length of hbh options header 2048 that can be pre= sent as well as well as 0 byte TLVs are valid and also no limit to =C2=A0th= e number of extended headers stacked limited by the MTU.=C2=A0 Also the cyc= lical cycle by operators filtering hbh and doh to avoid risk of ddos attack= and management plane impact which impacts designers from developing new us= e cases for hbh and doh.=C2=A0 This impacts the use of hbh and doh over the= internet.

Section 2.4= =C2=A0

See this draft wh= ich I am Co-author has some details related to NPU and fixed function ASIC = and=C2=A0
separation of control plane and data plane= criticality.

Maybe add = below draft as normative reference=C2=A0
Men= tion the management plane which is impacted when packets are sent to the co= ntrol plane.


<= div dir=3D"auto">3.1=C2=A0

Perimeter ACLs as well as firewall filters it is recommended to only per= mit directly adjacent ND packet as ND used RFC 5082 GTSM so TTL is set to 2= 55 and which can be used as an attack vector. I have an perimeter IACL that= is customized and had the DAD has the solicit node multicast address so DA= D succeeds.

2.7.2.4=C2= =A0

=E2=80=9CSecuring the routing protoco=
l between CE and PE; in the case of 6PE and 6VPE, link-local addresses (see=
 [RFC7404]) can be used and as these addresses cannot be reache=
d from outside of the link, the security of 6PE and 6VPE is even higher tha=
n an IPv4 BGP/MPLS IP
VPN.=E2=80=9D

When= using LL peering on the PE-RR iBGP peeing or PE-PE ibgp peering make sure = next-hop-self is used so the next hop is rewritten to loopback0 which is re= achable as LL not reachable.

Section 2.7.1=C2=A0

Mention =C2=A0Happy Eyeballs RFC 6555 and Happy Eyeballs 2 RFC 8305 =C2=A0= - =C2=A0By default with dual stack IPv6 is preferred over IPv4 and that imp= acts access to host via TCP or UDP as well as operational impact so any pin= g trace or ssh done from the device IPV6 is used over IPV4. By default on d= ual stacked host a A/AAAAA request goes out and a A/AAAA reply comes back a= nd the client creates IPv6 socket for TCP session to server with a TCP =C2= =A0RTO retransmission timeout of 20 seconds approximately.=C2=A0 With Happy= Eyeballs 1 there is a simultaneous v6 end v6 connection with a 300ms prefe= rence for v6 establishes and within 300ms the failover of the session occur= s from v6 to v4 thus not noticeable to the naked eye thus happiness with th= e eyeballs of the user.

= Section 2.7.2=C2=A0

We s= hould include 4to6 which as well as 6to6 tunnels.
Kind Regards=C2=A0

Gyan=C2=A0


On Mon, Apr 26, 2021 at 3:30 AM Er= ic Vyncke (evyncke) <evyncke@cisco.= com> wrote:

Thank you Gyan

=C2=A0

-=C3=A9ric

=C2=A0

From: Gyan Mishra <hayabusagsm@gmail.com= >
Date: Monday, 26 April 2021 at 06:34
To: opsec WG <opsec@ietf.org>, OpSec Chairs <opsec-chairs@ietf.org>, Eric Vyncke <evyncke@cisco.com&= gt;
Subject: draft-ietf-opsec-v6-24 - Shepherd Review update

=C2=A0


Hi Eric

=C2=A0

I will do another final S= hepherd review now of the draft as this draft as it=C2=A0is on its way to p= ublication.

=C2=A0

Kind Regards

=C2=A0

Gyan Mishra

Network Solutions = Architect=C2=A0

Ema= il gyan.s.mishra@verizon.com

M 301 502-1347

=C2=A0

--
--000000000000384ae305c12501cf--