From nobody Fri May 7 14:32:31 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 659213A33EF; Fri, 7 May 2021 14:32:25 -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.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: opsec@ietf.org Message-ID: <162042314535.16740.4928883767082908198@ietfa.amsl.com> Date: Fri, 07 May 2021 14:32:25 -0700 Archived-At: Subject: [OPSEC] I-D Action: draft-ietf-opsec-v6-27.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, 07 May 2021 21:32:26 -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-27.txt Pages : 58 Date : 2021-05-07 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, service provider networks, or managed residential networks. 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-27 https://datatracker.ietf.org/doc/html/draft-ietf-opsec-v6-27 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-v6-27 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 Fri May 7 23:07: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 5E0CA3A3F46; Fri, 7 May 2021 23:06:50 -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=CJZ+14Ou; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=e6x0VDkr 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 FFpBiyn22kYp; Fri, 7 May 2021 23:06:45 -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 439AB3A3F43; Fri, 7 May 2021 23:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11582; q=dns/txt; s=iport; t=1620454005; x=1621663605; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=djn8dtZ0iNl0ISAkAxHBVez3O/IxMlSCXb5Q8RxRfX0=; b=CJZ+14OuUaQEHtRC0X3c+bPHySJDah53v6qZsA3BvFqcLXkMtEsDB7I0 6N67BcGo8v6Y6QCDerarqxdYj+LdjroAqEurA1mxKtyDK5W1ayY1Xq+6G 5xaDnUjgynTdmzKaNSivivswm4egC+7AjKiD675SvmYAHomF85yxr9cxW U=; X-IPAS-Result: =?us-ascii?q?A0DsAQAxKZZgmIMNJK1aHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?VeBU1F+WjYxhESDSAOFOYh0A4o0jyOBQoERA1QLAQEBDQEBMAoCBAEBhFACF?= =?us-ascii?q?4FsAiU4EwIEAQEBAQMCAwEBAQEFAQEFAQEBAgEGBBQBAQEBAQEBAWiFIwYnD?= =?us-ascii?q?YZEAQEBAQMjEQwBASUSAQsEAgEIEQMBAgMCJgICAh8RFAEICAIEAQ0FgnEBg?= =?us-ascii?q?lUDLwEOngICih96gTKBAYIGAQEGBASBOAIOQYMeDQuCEwmBECqCeYJxU0qCY?= =?us-ascii?q?YFOgiknHIFJQoEVJxyCXz6CHkICAQEBF4ERARIBCRiDFzaCK4FZcWQEIhkWA?= =?us-ascii?q?QEEHi4vGQgsBwECFBcCDxUEDpEUEweDMowUmgpbCoMSiX2NdwSFQAUig1WLE?= =?us-ascii?q?ZZElTCMAoMej1sIhGkCAgICBAUCDgEBBoFrIWtYEQdwFWUBgj4JRxcCDoE2j?= =?us-ascii?q?GkMDQmDToUUhUlzAjYCBgEJAQEDCXyMEwEB?= IronPort-PHdr: A9a23:9SodpRS2zdCI6rc8485GbvU+Qtpso6PLVj580XJvo79Bfam549LlJ kOMrflujVqcW4Ld5roEjufNqKnvVCQG5orJq3ENdpFAFnpnwcUblgAtGoiJXEv8KvO5YiM1E d5eElh/8CLzPU1cAs2rYVrUrzW75iITHROqMw1zK6z1F4fegt7x2fq1/sjYYh5Dg3y2ZrYhR Cg= IronPort-HdrOrdr: A9a23:68iAjqlYLppEJcZQcydqDw1+hIXpDfPvimdD5ihNYBxZY6Wkfp +V/cjzhCWbtN9OYh4dcIi7Sda9qXO1z+8T3WGIVY3SHDUOy1HYUr2KirGSgAEIeheOt9K1sJ 0BT0EQMqyKMbEXt7ee3OD8Kadd/DDlytHruQ699QYWcegCUcgJhG0VZnf5Yy9LrUt9dOcE/f Gnl6x6Tk+bCAwqh7OAdwA4tob41rn2vaOjRSRDKw8s6QGIgz/twqX9CQKk0hAXVC4K6as+8E De+jaJo5mLgrWe8FvxxmXT55NZlJ/K0d1YHvGBjcATN3HFlhuoXoJ8QLeP1QpF5N1HqWxa1+ UkkS1QZvib2EmhJl1dZiGdgDUI5QxerUMKD2Xo20cL7/aJGQ7SQPAx9L6xOiGpm3bI+usMjJ 6iGwmixsRq5dSqplWj2zGAbWAZqqL/y0BS4tI7njhRV5ATZ6RWqpFa9ERJEI0YFCa/84w/Fv JyZfusqMq+XGnqJUwxhFMfjeBEn05DVytuSXJy9fB9EwIm10yR6nFoivD3sk1wg67VeqM0r9 gsaJ4Y4I2mZvVmG56VKt1xNPeKNg== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,282,1613433600"; d="scan'208";a="711079967" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 May 2021 06:06:44 +0000 Received: from mail.cisco.com (xbe-rcd-006.cisco.com [173.37.102.21]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 14866ivO015629 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Sat, 8 May 2021 06:06:44 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xbe-rcd-006.cisco.com (173.37.102.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Sat, 8 May 2021 01:06:43 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 8 May 2021 02:06:42 -0400 Received: from NAM04-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Sat, 8 May 2021 02:06:42 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VgKs8zIfVjW1IrB3ov9dVXy2wtL73dlACdrxKCem7Ty2c/5G2KwWKORJuwX785AEgTUCVaR5FAJ5LpxuRjioUNWlbq/eGb3vHAbPQsBBuxaSh3xhLsvsuK1RS6ksn9hYY67gFoVhFdGnswObGklZ1ulguElbfauIhPXZ3aWBapul4iPQH5980q+j7fK2Af4xsOTgRsV6ZXr2x/htkvxXF2KZGXY73BFC1ITA6z7YDaeHpW2FHL93kYR5GD+/r+ZYSXyjNAO9Z52GAoXfekGLtb1+WLn3lY0UUVwkcuColJgw/6kzLpCWfTd88SDLbDT4DdQkXXR3qrE2m5U9dZD4KQ== 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=djn8dtZ0iNl0ISAkAxHBVez3O/IxMlSCXb5Q8RxRfX0=; b=WLNpK5UFv5GlCWHcAQzczxBZgbS0Mk9uYsI3ZxVlGSCRudmAIdY4K6ykzl8X+eBYIqnFOq5/f2U5WkMtJFEVnNz+zrXcxgA1JzBPBcAp/KMCB2JWlq0S1RJ63eUwNG2MWNr3MGDJQN6QVrqAKaRWwo5QKIgsuFDDzcu7cb2ZxwK1jQiz7nuXQpq4EJWiWND2t8SNScBIrybmJOI+i8YzTMePHhzLgBI8dq92BZTQtbJLelQBpxpjymCv3QvI8/v1s/E4dZaYDboKr0uOIP0YYTyaIpb9g2HUmfPOCRVEoaqzRn0tM3cVSf5ou9VibPpSZWCm8Y0bkv02cD0Z0rX92g== 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=djn8dtZ0iNl0ISAkAxHBVez3O/IxMlSCXb5Q8RxRfX0=; b=e6x0VDkrF46ob8YNwBwqWn61bOcivHNWQSDTmMqYKxVwSVmtbeP0cEu8TPs/+kjtKYF1igY5b8X6j4V5JKWH2pe9/tnWdIRHnovU1NDKAPNCw9jVo6TXAcmuMtE7cf7mk4mztntwvcBeTNs3e++XGTCFGVvOT2/6JdmN2qVsD6A= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB5014.namprd11.prod.outlook.com (2603:10b6:510:31::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.27; Sat, 8 May 2021 06:06:41 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::ccc:1b78:44b5:b74b]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::ccc:1b78:44b5:b74b%3]) with mapi id 15.20.4108.030; Sat, 8 May 2021 06:06:41 +0000 From: "Eric Vyncke (evyncke)" To: Lars Eggert , The IESG CC: "draft-ietf-opsec-v6@ietf.org" , "opsec-chairs@ietf.org" , "opsec@ietf.org" Thread-Topic: Lars Eggert's No Objection on draft-ietf-opsec-v6-25: (with COMMENT) Thread-Index: AQHXQ9BQY/10LTMxzk6NHhympChNvA== Date: Sat, 8 May 2021 06:06:41 +0000 Message-ID: <1AE53DA1-FCAF-403C-A2C1-52AE73ACE5F7@cisco.com> References: <161772120964.13732.17403156280296269605@ietfa.amsl.com> In-Reply-To: <161772120964.13732.17403156280296269605@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: eggert.org; dkim=none (message not signed) header.d=none;eggert.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:30b4:3b73:cd37:c39] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 93c288d3-7763-4744-dee9-08d911e77319 x-ms-traffictypediagnostic: PH0PR11MB5014: 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: SY/O/aQohCOCJXHLi5UgqpRIQv6c/zhgBYw7Z3XA6Tew9Muz3YmWH//vrni3jORwvC7ZpJKjQtLLkO2zDDKli6q7ZCEdGpBDWBIQ2cN0yGxQ0awi3jG1n4u1U6OPLjZ1GQ5tkhaQRMTGTmcRmAkXNDlzeuawsOnzZCrou9t6lNJ0uIxx2dPVD0pyRMkt1hgAHf5Wk0T4ZC8zuaGyvvS5w87cLPT6eSPSGmgHNVH/cVoQldsjE3KSdeFjzm9XYSebN7I9J+raVrG9WEVmh2tX4PjTN2gVolmQKhL8TfqxxS9KQxvc4qvBVBiZu1Pe0QHZWSE+H1feYSXGinLVrxP3TYM8cz88pjWuQl9UfL6+OeQNPoNugiA/oSfhy6ySHG+LTVv545L/+lh/QOyy/2mV9Qt1D6ieFgvEw8Vic3zDX8XNx08sz50l9aD1Y1BT/yKdcaHYqT+OFsfR8zNuC5xktF0p3s5KgwTSOUjWENGTNNPNI74OzpQTiZPZygTi9eQSQykeyeczCmEUzg3XTTTBQj5Ic2ekiXlYEaZqZwarXHgyjQdJ0ociMpfLKTRNZ4px1PLS5Gp57uISYs12rTYnrYuXm2wfCPEgSIvb2x1N0BX3YKtt1Fv2toSDATNZARBUDkl9Exiagrxx9n88hFBz+bvzde7w31L7RYB1trawa5awLSv/wOJHl62TmqBx+fXNdJdgmBIzhsRKvq/1uYGvheXcYVO4ZSZyvUNzSvmNoeM= 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)(346002)(396003)(136003)(376002)(366004)(53546011)(6506007)(122000001)(38100700002)(316002)(6512007)(8936002)(478600001)(83380400001)(36756003)(54906003)(71200400001)(110136005)(4326008)(64756008)(66946007)(66556008)(66476007)(5660300002)(76116006)(8676002)(33656002)(91956017)(186003)(2616005)(966005)(86362001)(6486002)(66446008)(2906002)(66574015)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?eVRvcFZpZE12eXlvQkJ4ZFZrcUxLdmwvaDlWVWtlUEhXdTFTcUM2ZWJpOC9w?= =?utf-8?B?Nnc5SlNqeXI0OVR6OG5VaDlFemtYZDVvdkJ6M2NoRFpRU0RBTVlSYnJ3WTl4?= =?utf-8?B?Y2xHeWsraGo2dkJwbEN4SlNXUXl4TndVK3ZkQkc2cFk0c3BHR2drTmFXUWpw?= =?utf-8?B?UzJrTXFCV3U1cGl2VHRrcnppb0s1bkFWNXBvU0V2aTZHSzVQSzZXczVpVnRE?= =?utf-8?B?VXY4bDRmODdHUUd3NEJrN1lzdTNIMW0wQXBoS1FCdjBPVVduUVViZUtGQzd5?= =?utf-8?B?RWxBWVFqU2JyMXZOSzVEQUlGdVRWSE5UTGFzY2ZiN1dhbmxFSnU5U3IrZk8x?= =?utf-8?B?a2dIbE9FaUVFT3RXSWVhbjkxd2w3VzBZZjJobHRqVUNPNkYrRUVjOVF5SHBD?= =?utf-8?B?RGNpRVloU3FpMUUzRVREQVUrVG0yYWtvTXByQk81b3NvV2d6SWRlZlBKMDcx?= =?utf-8?B?UnM4QVEwQlZ0QVVWQkk4TTBUZXVWSFhlVHZBenFKOGJGZjNCQWpFa3ZqT0Yv?= =?utf-8?B?NU1UeExEV2NrYVUvVUhkZSswS3NiaEh4U1I3eFRFdUljM3ZUdng4UUlGUHJN?= =?utf-8?B?NVhMWnVyRk5MSW9aU3oxNlRWY05FSGNETC93UkFtbXBmT05rTjk0TlZ1N3Rk?= =?utf-8?B?Vm5JSFl0RFRXUERIYTBXR0J3L0cwUm85Yk5UMXc1WXdsMWVaNzRwSmVFNEVY?= =?utf-8?B?RnFnUHIrVHVNWldGaDVEd3lGVE1qZEU1ZGVTMUluZG1OMmpETVdONU00QlAw?= =?utf-8?B?RUN3L3RWc0NRc0JvU3lIdjhBVHNqLytjS1ZRNlYxTEhld2dETFNBaW8vZW1h?= =?utf-8?B?WWlrRzFnQmQwL2FKYktUaDVmNForRW8zVW9oSmgyblMyckdhMFpLYWp2c081?= =?utf-8?B?d1Z2Y0l2VnQ1ZGtNVTFSNXpFNkExYkxKazJiVFluL3Zoajk5cE9rck5tY3Na?= =?utf-8?B?akJvUVcybzlrdFkwQUpWZVdlM3FtbVBZOVM1Z21BRFA0VlM3Yyt0RjNieEc0?= =?utf-8?B?OXpmaGpBeWpsQlZOL0N3WFRXOUdrclZ3YWxMMmhsMVFjRFJYUDl1ekg4ZEhJ?= =?utf-8?B?eEovV1JlZVVBMmJ4UHZUS0RzeE82cDB4S2tLMm9FK3hOVnVVVmxGckRZS2Ju?= =?utf-8?B?c2s5OGk3RU5hK1dhQWl5QlNBRURjb2w2QWhia3NvbkprbjZ6RjZqNWVDdkZU?= =?utf-8?B?S3F4bGhEZHZRaUtWUUFqeFJXL1M2RnNUSUxiU3VvcUU5aTdyNWhpS0pTZlBD?= =?utf-8?B?bm9DZW5NR04zTHJ1N2ZsU1pvNDVwb2xKbEU3R2FxSlh3MFhMWXp0L0RuS2py?= =?utf-8?B?V1V1S2FRT2l6RlIrK29tT3kzK0ZETVhZZ0k3eG5CcnZIZWo3SkZ4N3dtWW9u?= =?utf-8?B?MVJMcm83cTk2TG1zcURMa0ZzaVF0VElGK05rc3I4TU1BdlozVHVHbjVGTklz?= =?utf-8?B?U3lPVzc4Q0YwdjZUbW96SDF5SElGUENWU3UvMnZsMCtBS2JpL0p5b0xMYStN?= =?utf-8?B?OGhmUDJTbEpmNGtpOU5zSGtsRkpUcE1iQ2VoVDg3ZUEzcEVKdXo3bEZ5YTNM?= =?utf-8?B?Z1pGakdqZzFkSE5aUUdIbXc0aTh0VFRqUlV1dVQvbnU2RnhTVVR2Y0lPL24y?= =?utf-8?B?TVM0STJnK2pncDVEMmJkNE03TjN5ZVBqdnNUM3pLSlBxS1NPcWdISVkxRTB0?= =?utf-8?B?dFdFQXZLdFd3NkJRdXM1VTcxSVpGblBCdFY2azJnSlFjNkRtUSthdzVjRUJX?= =?utf-8?B?ZitTVm53dytnejN0WFJxV1dEREd4Tll5QXZJekt2ZndPZTAxMDEzRnNDTGZG?= =?utf-8?B?Wng2WUNLVWl4MnNNdUpCN0JuSnNCTkNjVFJGUTY5QWlZV1BLSWpua3R3TWt1?= =?utf-8?Q?O0Kp5CCQP3XrB?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <954B0EDF10D1B847A9A01B615CEB2FB2@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: 93c288d3-7763-4744-dee9-08d911e77319 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2021 06:06:41.4424 (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: O4OloNdNC3SZYXw2feLWXPgWm2pjfrNzM0kRxFWxxnVAcOhdhE7IYDsZpt+XgP2VLUDmvtgqCowsu9hSIsXVPA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5014 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.21, xbe-rcd-006.cisco.com X-Outbound-Node: alln-core-1.cisco.com 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, 08 May 2021 06:06:51 -0000 W1dlYXJpbmcgb25seSB0aGUgYXV0aG9ycycgaGF0XQ0KDQpIZWxsbyBMYXJzLA0KDQpUaGFuayB5 b3UgdmVyeSBtdWNoIGZvciB5b3VyIGRldGFpbGVkIHJldmlldy4gSSBrbm93IHRoYXQgaXQgdGFr ZXMgdGltZSBhbmQgZWZmb3J0IDstKQ0KDQpUb2dldGhlciB3aXRoIG15IGNvLWF1dGhvcnMsIHdl IGhhdmUgdXBsb2FkZWQgcmV2aXNpb24gLTI3LCB3aGljaCBzaG91bGQgYWRkcmVzc2VzIGFsbCB5 b3VyIGNvbW1lbnRzIGFuZCBuaXRzLg0KDQpUaGUgZGlmZiBpcyBhdDogaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtb3BzZWMtdjYtMjcNCg0KUmVnYXJkcw0KDQot w6lyaWMNCg0K77u/LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGllc2cgPGllc2ct Ym91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIExhcnMgRWdnZXJ0IHZpYSBEYXRhdHJhY2tl ciA8bm9yZXBseUBpZXRmLm9yZz4NClJlcGx5LVRvOiBMYXJzIEVnZ2VydCA8bGFyc0BlZ2dlcnQu b3JnPg0KRGF0ZTogVHVlc2RheSwgNiBBcHJpbCAyMDIxIGF0IDE3OjAwDQpUbzogVGhlIElFU0cg PGllc2dAaWV0Zi5vcmc+DQpDYzogImRyYWZ0LWlldGYtb3BzZWMtdjZAaWV0Zi5vcmciIDxkcmFm dC1pZXRmLW9wc2VjLXY2QGlldGYub3JnPiwgIm9wc2VjLWNoYWlyc0BpZXRmLm9yZyIgPG9wc2Vj LWNoYWlyc0BpZXRmLm9yZz4sICJvcHNlY0BpZXRmLm9yZyIgPG9wc2VjQGlldGYub3JnPiwgImhh eWFidXNhZ3NtQGdtYWlsLmNvbSIgPGhheWFidXNhZ3NtQGdtYWlsLmNvbT4NClN1YmplY3Q6IExh cnMgRWdnZXJ0J3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtb3BzZWMtdjYtMjU6ICh3aXRo IENPTU1FTlQpDQoNCiAgICBMYXJzIEVnZ2VydCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJh bGxvdCBwb3NpdGlvbiBmb3INCiAgICBkcmFmdC1pZXRmLW9wc2VjLXY2LTI1OiBObyBPYmplY3Rp b24NCg0KICAgIFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBp bnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KICAgIGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0 aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzDQogICAgaW50cm9kdWN0 b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQoNCg0KICAgIFBsZWFzZSByZWZlciB0byBodHRwczov L3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCiAgICBm b3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRp b25zLg0KDQoNCiAgICBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0 aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQogICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1vcHNlYy12Ni8NCg0KDQoNCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAg Q09NTUVOVDoNCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCiAgICBTZWN0aW9uIDIuMy4xLCBwYXJhZ3Jh cGggNiwgY29tbWVudDoNCiAgICA+ICAgIG8gIFR1bmluZyBvZiBORFAgcHJvY2VzcyAod2hlcmUg c3VwcG9ydGVkKS4NCg0KICAgIFR1bmluZyBpbiB3aGljaCB3YXk/DQoNCiAgICBTZWN0aW9uIDIu Ny4yLCBwYXJhZ3JhcGggMiwgY29tbWVudDoNCiAgICA+ICAgIFRoZXJlIGFyZSBtYW55IHR1bm5l bHMgdXNlZCBmb3Igc3BlY2lmaWMgdXNlIGNhc2VzLiAgRXhjZXB0IHdoZW4NCiAgICA+ICAgIHBy b3RlY3RlZCBieSBJUHNlYyBbUkZDNDMwMV0sIGFsbCB0aG9zZSB0dW5uZWxzIGhhdmUgYSBjb3Vw bGUgb2YNCiAgICA+ICAgIHNlY3VyaXR5IGlzc3VlcyBhcyBkZXNjcmliZWQgaW4gUkZDIDYxNjkg W1JGQzYxNjldOw0KDQogICAgSVBzZWMgaXMgbm90IHRoZSBvbmx5IHNlY3VyaXR5IG1lY2hhbmlz bSB0aGF0IHdpbGwgcHJvdGVjdCB0dW5uZWxzLCBtb3N0DQogICAgdHVubmVsIGVuY3J5cHRpb24g bWVjaGFuaXNtcyB3b3VsZC4NCg0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICBBbGwg Y29tbWVudHMgYmVsb3cgYXJlIHZlcnkgbWlub3IgY2hhbmdlIHN1Z2dlc3Rpb25zIHRoYXQgeW91 IG1heSBjaG9vc2UgdG8NCiAgICBpbmNvcnBvcmF0ZSBpbiBzb21lIHdheSAob3IgaWdub3JlKSwg YXMgeW91IHNlZSBmaXQuIFRoZXJlIGlzIG5vIG5lZWQgdG8gbGV0IG1lDQogICAga25vdyB3aGF0 IHlvdSBkaWQgd2l0aCB0aGVzZSBzdWdnZXN0aW9ucy4NCg0KICAgIFNlY3Rpb24gMi41LjMsIHBh cmFncmFwaCA0LCBuaXQ6DQogICAgPiAgICBNYW55IHJvdXRpbmcgcHJvdG9jb2xzIHN1cHBvcnQg dGhlIHVzZSBvZiBjcnlwdG9ncmFwaHkgdG8gcHJvdGVjdCB0aGUNCiAgICA+ICAgIHJvdXRpbmcg dXBkYXRlcywgdGhlIHVzZSBvZiB0aGlzIHByb3RlY3Rpb24gaXMgcmVjb21tZW5kZWQ7IFtSRkM4 MTc3XQ0KICAgID4gICAgaXMgYSBZQU5HIGRhdGEgbW9kZWwga2V5IGNoYWlucyBpbmNsdWRpbmcg dGhlIHJlbmV3YWwuDQogICAgPg0KDQogICAgSSBjYW4ndCBwYXJzZSB0aGUgcGFydCBhZnRlciB0 aGUgc2VtaWNvbG9uLg0KDQogICAgU2VjdGlvbiAyLjYuMi4yLCBwYXJhZ3JhcGggOSwgbml0Og0K ICAgIE1pZ2h0IGFsc28gd2FudCB0byBtZW50aW9uIGh0dHA6Ly93d3cuZW50cm9weS1pcC5jb20v IGFuZCBzaW1pbGFyIHRvb2xzLg0KDQogICAgU2VjdGlvbiAyLjIuMywgcGFyYWdyYXBoIDMsIG5p dDoNCiAgICAtICAgICAgIG5vdCBjb250YWluIHRoZSBlbnRpcmUgaXB2NiBoZWFkZXIgY2hhaW4g KGluY2x1ZGluZyB0aGUgdHJhbnNwb3J0LQ0KICAgIC0gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBeXg0KICAgICsgICAgICAgbm90IGNvbnRhaW4gdGhlIGVudGlyZSBJUHY2IGhlYWRlciBj aGFpbiAoaW5jbHVkaW5nIHRoZSB0cmFuc3BvcnQtDQogICAgKyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIF5eDQoNCiAgICBTZWN0aW9uIDIuMi4zLCBwYXJhZ3JhcGggNCwgbml0Og0KICAg IC0gICAgICAgY29udGFpbiB0aGUgZW50aXJlIGlwdjYgaGVhZGVyIGNoYWluIChpbmNsdWRpbmcg dGhlIHRyYW5zcG9ydC0NCiAgICAtICAgICAgICAgICAgICAgICAgICAgICAgICBeXg0KICAgICsg ICAgICAgY29udGFpbiB0aGUgZW50aXJlIElQdjYgaGVhZGVyIGNoYWluIChpbmNsdWRpbmcgdGhl IHRyYW5zcG9ydC0NCiAgICArICAgICAgICAgICAgICAgICAgICAgICAgICBeXg0KDQogICAgU2Vj dGlvbiAyLjIuNCwgcGFyYWdyYXBoIDIsIG5pdDoNCiAgICAtICAgIHRoZSB1cGRhdGVkIElQdjYg Tm9kZXMgUmVxdWlyZW1lbnQgc3RhbmRhcmQgW1JGQzg1MDRdIElQc2VjIGlzIGENCiAgICArICAg IHRoZSB1cGRhdGVkIElQdjYgTm9kZXMgUmVxdWlyZW1lbnQgc3RhbmRhcmQgW1JGQzg1MDRdLCBJ UHNlYyBpcyBhDQogICAgKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICsNCg0KICAgIFNlY3Rpb24gMi4zLCBwYXJhZ3JhcGggMiwgbml0Og0K ICAgIC0gICAgb3BlcmF0aW9ucyBzdWNoIGFzIGRpc2NvdmVyaW5nIG90aGVyIG5vZGVzIG9uIHRo ZSBsaW5rLCByZXNvbHZpbmcNCiAgICArICAgIG9wZXJhdGlvbnMsIHN1Y2ggYXMgZGlzY292ZXJp bmcgb3RoZXIgbm9kZXMgb24gdGhlIGxpbmssIHJlc29sdmluZw0KICAgICsgICAgICAgICAgICAg ICsNCg0KICAgIFNlY3Rpb24gMi4zLCBwYXJhZ3JhcGggMiwgbml0Og0KICAgIC0gICAgc2VjdXJl ZCwgTkRQIGlzIHZ1bG5lcmFibGUgdG8gdmFyaW91cyBhdHRhY2tzIHN1Y2ggYXMgcm91dGVyL25l aWdoYm9yDQogICAgKyAgICBzZWN1cmVkLCBORFAgaXMgdnVsbmVyYWJsZSB0byB2YXJpb3VzIGF0 dGFja3MsIHN1Y2ggYXMgcm91dGVyL25laWdoYm9yDQogICAgKyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICArDQoNCiAgICBTZWN0aW9uIDIuMywgcGFyYWdy YXBoIDIsIG5pdDoNCiAgICAtICAgIGRvY3VtZW50ZWQgaW4gSVB2NiBORCBUcnVzdCBNb2RlbHMg YW5kIFRocmVhdHMgW1JGQzM3NTZdIGFuZCBpbg0KDQogICAgU2VjdGlvbiAyLjMuMSwgcGFyYWdy YXBoIDIsIG5pdDoNCiAgICAtICAgIE5laWdoYm9yIERpc2NvdmVyeSBQcm90b2NvbCAoTkRQKSBj YW4gYmUgdnVsbmVyYWJsZSB0byByZW1vdGUgZGVuaWFsDQogICAgKyAgICBUaGUgTmVpZ2hib3Ig RGlzY292ZXJ5IFByb3RvY29sIChORFApIGNhbiBiZSB2dWxuZXJhYmxlIHRvIHJlbW90ZSBkZW5p YWwNCiAgICArICAgKysrKw0KDQogICAgU2VjdGlvbiAyLjMuMSwgcGFyYWdyYXBoIDYsIG5pdDoN CiAgICAtICAgIG8gIFVzaW5nIC8xMjcgb24gcG9pbnQtdG8tcG9pbnQgbGluayBwZXIgW1JGQzYx NjRdLg0KICAgICsgICAgbyAgVXNpbmcgYSAvMTI3IG9uIGEgcG9pbnQtdG8tcG9pbnQgbGluaywg cGVyIFtSRkM2MTY0XS4NCiAgICArICAgICAgICAgICAgICsrICAgICAgICsrICAgICAgICAgICAg ICAgICAgICArDQoNCiAgICBTZWN0aW9uIDIuMy4yLjMsIHBhcmFncmFwaCAyLCBuaXQ6DQogICAg LSAgICBvbi1saW5rIHByZWZpeDsgM0dQUCBTZWN0aW9uIDIuMy40IHVzZXMgYSBzaW1pbGFyIG1l Y2hhbmlzbS4NCiAgICArICAgIG9uLWxpbmsgcHJlZml4OyAzR1BQIChzZWUgU2VjdGlvbiAyLjMu NCkgdXNlcyBhIHNpbWlsYXIgbWVjaGFuaXNtLg0KICAgICsgICAgICAgICAgICAgICAgICAgICAg ICAgKysrKysgICAgICAgICAgICAgKw0KDQogICAgU2VjdGlvbiAyLjMuMywgcGFyYWdyYXBoIDIs IG5pdDoNCiAgICAtICAgIER5bmFtaWMgSG9zdCBDb25maWd1cmF0aW9uIFByb3RvY29sIGZvciBJ UHY2IChESENQdjYpLCBhcyBkZXNjcmliZWQNCiAgICAtICAgIGluIFtSRkM4NDE1XSwgZW5hYmxl cyBESENQIHNlcnZlcnMgdG8gcGFzcyBjb25maWd1cmF0aW9uIHBhcmFtZXRlcnMNCiAgICAtICAg IHN1Y2ggYXMgSVB2NiBuZXR3b3JrIGFkZHJlc3NlcyBhbmQgb3RoZXIgY29uZmlndXJhdGlvbiBp bmZvcm1hdGlvbiB0bw0KICAgIC0gICAgSVB2NiBub2RlcyBzdWNoIGFzIGEgaG9zdGlsZSByZWN1 cnNpdmUgRE5TIHNlcnZlci4gIERIQ1AgcGxheXMgYW4NCiAgICArICAgIFRoZSBEeW5hbWljIEhv c3QgQ29uZmlndXJhdGlvbiBQcm90b2NvbCBmb3IgSVB2NiAoREhDUHY2KSwgYXMgZGVzY3JpYmVk DQogICAgKyAgICsrKysNCiAgICArICAgIGluIFtSRkM4NDE1XSwgZW5hYmxlcyBESENQIHNlcnZl cnMgdG8gcGFzcyBjb25maWd1cmF0aW9uIHBhcmFtZXRlcnMsDQogICAgKyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Kw0KICAgICsgICAgc3VjaCBhcyBJUHY2IG5ldHdvcmsgYWRkcmVzc2VzIGFuZCBvdGhlciBjb25m aWd1cmF0aW9uIGluZm9ybWF0aW9uLCB0bw0KICAgICsgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKw0KICAgICsgICAg SVB2NiBub2Rlcywgc3VjaCBhcyBhIGhvc3RpbGUgcmVjdXJzaXZlIEROUyBzZXJ2ZXIuICBESENQ IHBsYXlzIGFuDQogICAgKyAgICAgICAgICAgICAgKw0KDQogICAgU2VjdGlvbiAyLjMuMywgcGFy YWdyYXBoIDMsIG5pdDoNCiAgICAtICAgIG9mLXNlcnZpY2UgYXR0YWNrIG9yIHRvIG1vdW50IG9u IHBhdGggYXR0YWNrLiAgV2hpbGUgdW5pbnRlbnRpb25hbCwgYQ0KICAgIC0gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBeDQogICAgKyAgICBvZi1zZXJ2aWNlIGF0dGFjayBvciB0 byBtb3VudCBhbiBvbi1wYXRoIGF0dGFjay4gIFdoaWxlIHVuaW50ZW50aW9uYWwsIGENCiAgICAr ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICsrKyAgXg0KDQogICAgU2VjdGlvbiAy LjMuNCwgcGFyYWdyYXBoIDIsIG5pdDoNCiAgICAtICAgIGFkZHJlc3MuICBUaGlzIGltcGxpZXMg dGhlcmUgY2FuIG9ubHkgYmUgYW4gZW5kIGhvc3QgKHRoZSBtb2JpbGUNCiAgICAtICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXg0KICAgICsgICAgYWRkcmVzcy4g IFRoaXMgaW1wbGllcyB0aGVyZSBjYW4gb25seSBiZSBvbmUgZW5kIGhvc3QgKHRoZSBtb2JpbGUN CiAgICArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXiArDQoN CiAgICBTZWN0aW9uIDIuMy40LCBwYXJhZ3JhcGggMiwgbml0Og0KICAgIC0gICAgYWRkcmVzcyBi dWlsdCBieSB0aGUgbW9iaWxlIGhvc3QuICBUaGUgR0dTTi9QR1cgYWx3YXlzIHByb3ZpZGVzIGFu DQogICAgLSAgICAgICAgICAgIF5eXl4NCiAgICArICAgIGFkZHJlc3MgZ2VuZXJhdGVkIGJ5IHRo ZSBtb2JpbGUgaG9zdC4gIFRoZSBHR1NOL1BHVyBhbHdheXMgcHJvdmlkZXMgYW4NCiAgICArICAg ICAgICAgICAgXl5eXl5eICsrDQoNCiAgICBTZWN0aW9uIDIuMy40LCBwYXJhZ3JhcGggNCwgbml0 Og0KICAgIC0gICAgbGluayBtb2RlbCwgTkRQIG9uIGl0IGFuZCB0aGUgYWRkcmVzcyBjb25maWd1 cmF0aW9uIGRldGFpbHMuICBJbiBzb21lDQogICAgLSAgICAgICAgICAgICAgICAgICAtLS0tLS0N CiAgICArICAgIGxpbmsgbW9kZWwsIE5EUCBhbmQgdGhlIGFkZHJlc3MgY29uZmlndXJhdGlvbiBk ZXRhaWxzLiAgSW4gc29tZQ0KDQogICAgU2VjdGlvbiAyLjUsIHBhcmFncmFwaCA4LCBuaXQ6DQog ICAgLSAgICBpbnRlcmZhY2Ugd2hlcmUgaXQgaXMgcmVxdWlyZWQuDQogICAgKyAgICBpbnRlcmZh Y2VzIHdoZXJlIGl0IGlzIHJlcXVpcmVkLg0KICAgICsgICAgICAgICAgICAgKw0KDQogICAgU2Vj dGlvbiAyLjUuNCwgcGFyYWdyYXBoIDIsIG5pdDoNCiAgICAtICAgIHBlcnRhaW4gdG8gZWRnZSBy b3V0ZSBmaWx0ZXJpbmcgdnMgaW50ZXJuYWwgcm91dGUgZmlsdGVyaW5nLiAgQXQgYQ0KICAgICsg ICAgcGVydGFpbiB0byBlZGdlIHJvdXRlIGZpbHRlcmluZyB2cy4gaW50ZXJuYWwgcm91dGUgZmls dGVyaW5nLiAgQXQgYQ0KICAgICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICsNCg0KICAgIFNlY3Rpb24gMi42LjEuNSwgcGFyYWdyYXBoIDIsIG5pdDoNCiAgICAtICAgIGNs aWVudHMuICBJdCBpcyBpbmRlZWQgcXVpdGUgc2ltaWxhciB0byBESENQIGZvciBJUHY0IHNvIGl0 IGNhbiBiZQ0KICAgICsgICAgY2xpZW50cy4gIEl0IGlzIGluZGVlZCBxdWl0ZSBzaW1pbGFyIHRv IERIQ1AgZm9yIElQdjQsIHNvIGl0IGNhbiBiZQ0KICAgICsgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArDQoNCiAgICBTZWN0aW9uIDIuNi4x LjUsIHBhcmFncmFwaCAzLCBuaXQ6DQogICAgLSAgICBJdCBpcyBub3Qgc28gZWFzeSBpbiB0aGUg SVB2NiBuZXR3b3JrcyBiZWNhdXNlIG5vdCBhbGwgbm9kZXMgd2lsbCB1c2UNCiAgICAtICAgICAg ICAgICAgICAgICAgICAgICAgIC0tLS0NCiAgICArICAgIEl0IGlzIG5vdCBzbyBlYXN5IGluIElQ djYgbmV0d29ya3MsIGJlY2F1c2Ugbm90IGFsbCBub2RlcyB3aWxsIHVzZQ0KICAgICsgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICsNCg0KICAgIFNlY3Rpb24gMi43LjMuMSwg cGFyYWdyYXBoIDIsIG5pdDoNCiAgICAtICAgIENhcnJpZXItR3JhZGUgTkFUIChDR04pLCBhbHNv IGNhbGxlZCBOQVQ0NDQgQ0dOIG9yIExhcmdlIFNjYWxlIE5BVA0KICAgIC0gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeXl4NCiAgICArICAgIENhcnJp ZXItR3JhZGUgTkFUIChDR04pLCBhbHNvIGNhbGxlZCBOQVQ0NDQgQ0dOLCBMYXJnZSBTY2FsZSBO QVQNCiAgICArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgXg0KDQogICAgU2VjdGlvbiA0LjMsIHBhcmFncmFwaCAzLCBuaXQ6DQogICAgLSAgICAoZS5n LiwgaGlzL2hlciBQUFAgc2Vzc2lvbiwgcGh5c2ljYWwgbGluZSwgb3IgQ1BFIE1BQyBhZGRyZXNz KS4gIFdpdGgNCiAgICAtICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgXl5eXg0KICAgICsgICAgKGUuZy4sIGhpcy9oZXIg UFBQIHNlc3Npb24sIHBoeXNpY2FsIGxpbmUsIG9yIENQRSBNQUMgYWRkcmVzcykuICBJbg0KICAg ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBeXg0KDQoNCg0KDQo= From nobody Mon May 10 01:10: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 139193A0DB2; Mon, 10 May 2021 01:09:09 -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 rN9t5vSADUl5; Mon, 10 May 2021 01:09:04 -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 DA17E3A0DAD; Mon, 10 May 2021 01:09:02 -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 8FF2427323; Mon, 10 May 2021 10:08:59 +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 6899AF062B; Mon, 10 May 2021 10:08:59 +0200 (CEST) Received: by ws26.ernw.net (Postfix, from userid 1002) id 72BC7112F5; Mon, 10 May 2021 10:08:59 +0200 (CEST) Date: Mon, 10 May 2021 10:08:59 +0200 From: Enno Rey To: Tim Chown Cc: ops-dir@ietf.org, opsec@ietf.org, iesg@ietf.org, evyncke@cisco.com, merike@doubleshotsecurity.com, kk.chittimaneni@gmail.com Message-ID: <20210510080859.GA89736@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: Mon, 10 May 2021 08:09:09 -0000 Hi Tim, thanks again for the review, for your support during the different stages of its development, and for the detailed comments. We have incorporated most of the comments that we felt were in line with the general document and were agreed upon by the authors. Some comments were not acted upon though as the current text is the result of WG consensus, and/or a proposed change would have modified the overall direction of a specific recommendation. Please allow to comment/address them in the following. On Wed, Apr 07, 2021 at 02:12:37AM -0700, Tim Chown via Datatracker wrote: > > 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. A mention of EHs was added (good point, thank you). As for NPTv6 part we decided to leave as is. > 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? We removed the part referring to multi-homed networks (and the 'exception' piece as a whole as it could indeed be a bit confusing). > 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. We simplified the section title to just 'Addressing' to reflect the general nature of the recommendations. > p.4 > In the 7934 para, RFC8981 should be mentioned as it???s a significant reason of > devices having more addresses. An explicit reference to RFC 8981 as one of the main reasons for multiple addresses was added. > p.5 > ULAs are also useful where the prefix changes, for stable internal addressing > as the global prefix changes? Typically in residential networks. >From our perspective the text already mentions this scenario. > p.5 > Section 2.1.4 is really about choices in address assignment within a network. We feel that it's mostly about the various implications of stable addresses, which is why we stayed with the current section title. > 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. RFC 7707 has a section on mitigations, which is why we point to that one. > p.6 > All mentions of 4941 should be replaced with 8981. done ;-) (This was one of cases where parallel publications obsoleted an item in our document, due to the long time of document development, as you rightfully stated) > p.7 > Can use 7721 and 8981 together. We decided to leave as is. > p.7 > Why are DHCP and DNS limped together? The DNS is only about DNSSEC, so call it > that? We split this part into two individual sections on DHCP and DNS each. > 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. The "even if the use" part was removed in the course of the rewrite/-ordering of the section. > > p.8 > The first para is very muddled. We performed a number of clarifying changes in this part of the document. We hope they address this one, too. > > 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. Good point; a respective sentence was added. > > 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. We decided not to rewrite these parts. > > p.10 > In 2.2, the intro can say these issues have parallels in IPv4. We decided not to rewrite the intro. > > p.11 > First line, say the attack can typically happen from a large address scan if > permitted into the network? That's correct. Still, as we point to RFC 6583 for an extensive discussion, we felt this addition wouldn't be needed here. > > p.11 > Bullet 1 - that contradicts the comments on predictable addressing. > Bullet 2 - how? Some clues here would be useful. We added some some examples to the second bullet. > > p.12 > ???Current??? - really? All current implementations? Delete ???current??? or replace > with ???naive??? maybe. The wording was modified in order to avoid 'current'. > > p.12 > ???Communicate directly??? - at L2? If so, why? Wording was clarified, together with an example. > > 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. Please see Eric's e-mail from April 21 why we couldn't follow that path (based on previous WG discussion). > > p.13 > ???Trivial??? cases - aren???t these common ones, like edge switches in an enterprise? The section was modified in order to provide more clarification. > > p.13 > Why ???hostile???? Delete? We deleted 'hostile' in the context of the distribution of a DNS resolver. > > p.14 > In 2.3.5 last para, what about mDNS, Bonjour? Though the DNS SD work is now > on unicast discovery. That's a tricky one as we've seen differing approaches here (mDNS/Bonjour), based on different operational needs. Still we added mentions of mDNS and LLMNR. > > 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. Some more potential log sources were added. Besides that we felt that the overall section should be left as is. > > p.28 > The text is 2.6.2.2 repeats earlier text. > Similarly text in 2.6.2.3 is repeated form before. Agreed, but these sections might be selectively read by specific audiences which is why we accepted a bit of redundancy here. > > p.29 > In 2.6.2.4 presumably also a rapid growth in ND cache size is an indicator. Good point & worthwhile suggestion; we added that one. > > p.29 > In 2.7 point to RFC 4942 A respective reference was added. > > 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? Let's hope that this document comes into play exactly when IPv6 gets deployed in a properly managed way ;-) > > 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 As there had been a lot of discussions in the WG about the whole tunneling part of the document, we considered this part as aligned with WG consensus, and hence refrained from significant changes here. This applies to most of your comments in this part (still some quick notes on individual technologies in the following). > > 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. See the above general comment (on the tunneling piece of the document) from our perspective. > > p.32 > ISATAP, in 2021? Same with 6rd. General advice should be deploy native, avoid > tunnels. I think we'd all be happy if ISATAP wasn't a thing in 2021 anymore. Alas, it seems more prevalent than one might think, e.g. see this recent talk from the PAM conference (April 2021): https://www.youtube.com/watch?v=_c061S5iZfo. We also added a reference to the full paper. > > p.33 > Same for 6to4. See comment on ISATAP > p.34 > Teredo though, is that still included in Windows and XBoX, as a MS thing? Yep, still supported/deployed with the Xbox. > > 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 Agree that Geoff's blog is excellent, but we decided not to perform changes here. 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. Agree. > > p.37 > Also RFC6092 on section 3.1? 3.1 already had a reference to RFC 6092. > > p.38 > ???Where RFC1918 address are often used??? - add ???often???, the text implies all > enterprises use v4 NAT. Done. You're right about the misleading implication of the old text. > > p.41 > Only 2 normative references? Due to nature of the document we feel that the informative ones are more important (and we actually performed some slight changes to the references, e.g. adding the ISATAP paper mentioned above). > > Nits: > All the nits have been addressed, too. I wish everyone a great week Enno -- Enno Rey Cell: +49 173 6745902 Twitter: @Enno_Insinuator From nobody Tue May 11 00:45:04 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 71A423A156D; Tue, 11 May 2021 00:45:01 -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: furry13@gmail.com, opsec-chairs@ietf.org, opsec@ietf.org, warren@kumari.net X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162071910088.5183.7405581594141809550@ietfa.amsl.com> Date: Tue, 11 May 2021 00:45:01 -0700 Archived-At: Subject: [OPSEC] opsec - Update to a 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, 11 May 2021 07:45:02 -0000 An update to a meeting session request has just been submitted by Jen Linkova, 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: Jen Linkova Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: 6man v6ops spring lsr panrg People who must be present: Ron Bonica Warren "Ace" Kumari Jen Linkova Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue May 11 06:57: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 2EDB53A18BC; Tue, 11 May 2021 06:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEcoY9NzzMhb; Tue, 11 May 2021 06:57:18 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA3B33A18C6; Tue, 11 May 2021 06:57:17 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id p12so25260759ljg.1; Tue, 11 May 2021 06:57:17 -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=7YWAHHhMTtEwMDSYILLSU4pfnMaGi4/F/GzGdSck7Jo=; b=K+ISwKEGj3hBZEg/nTT1w3FvJMdgoA7EaX9Q0E49t+NXK/x9bdGByE7Bvn9AfMkpoX ICF/PkunJinBbETOAewy+16f3t/d7zfKA/+1jY7ioPvk9w2GRckSHPrB0D5fWhm3kRUl 9SBFt108fwcH8ywLY1529zImngFTyWa0Td5bqW0Qx9+1oXl+yZg+vbmzQVqrMQI/fRfV HBvyifhvqw6sY0kwagtuJfxoyH01NUxQWC4y5w79g1RQEbh0hPqslkOYgU+Asyn7yaGE IJeyVn84TGgURIKpePotFGRSrS6rUy/PhznQOIK8IQltcmC3uc5pR5hUcBFzNZ3s3r6t bK4Q== 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=7YWAHHhMTtEwMDSYILLSU4pfnMaGi4/F/GzGdSck7Jo=; b=pN/GDladO/UhW7jmc304Jbega5ii6pCuRqJglXByPr9xWM/IpLE9krjnKOJ0+amQeT 7EMeoddqxUmbdmwSz3S/bU9R2IkPbv9WAi2fSgCvLuvbQAC2EWGCS/FXOag6jwraWvXB JhBqeqUEl6+GiFYMyjbjDEPH7Ttn9URDkfScY8/HWQl0c2AvNkLuwdUxumT8oh4c3PIl uMogrvcRfLuLTUpRefuosZI2/vuc7+aaYzUQgUS4EyTCmQz1ansVCcIchJXm0op9vMcQ 7lXf4SHdI9vWgYud5W4bWC4e3C4Q5+RSYBaCoMNjzSCPbXZRDIaSPTDo1phqNnxHSQ2j B4Aw== X-Gm-Message-State: AOAM530u/sm2qMBDZA7lzE8WCpHZavmXZwJWGwFhbevh/IrRU7DaqHyr PlOzuxE4oPWwDhJcBID5VSLuTYOMxsFSvFZW+LE= X-Google-Smtp-Source: ABdhPJwc1dB40QNQP/OKNu3NegKgSSYWEK9KKaq8iL99z+VarlwuZMT1AyZWpF5LzvqN2eWV4nB9fqHtrCFX/ZidbiE= X-Received: by 2002:a2e:581a:: with SMTP id m26mr24764475ljb.493.1620741435384; Tue, 11 May 2021 06:57:15 -0700 (PDT) MIME-Version: 1.0 References: <161779162147.18816.9995103488367885739@ietfa.amsl.com> In-Reply-To: <161779162147.18816.9995103488367885739@ietfa.amsl.com> From: KK Chittimaneni Date: Tue, 11 May 2021 06:57:04 -0700 Message-ID: To: Zaheduzzaman Sarker Cc: The IESG , draft-ietf-opsec-v6@ietf.org, opsec-chairs@ietf.org, opsec@ietf.org, Gyan Mishra Content-Type: multipart/alternative; boundary="00000000000087695005c20e458c" Archived-At: Subject: Re: [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 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2021 13:57:31 -0000 --00000000000087695005c20e458c Content-Type: text/plain; charset="UTF-8" Hello Zahed, Thank you very much for your detailed review. Together with my co-authors, we have uploaded revision -27, which should address all your comments. The diff is at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-v6-27 Regards, KK On Wed, Apr 7, 2021 at 3:33 AM Zaheduzzaman Sarker via Datatracker < noreply@ietf.org> wrote: > 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. > > > > --00000000000087695005c20e458c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Zahed,

Thank you very much for your detailed review.

Together with my co-authors, we have uploaded revision -27, which should ad= dress all your comments.

The diff is at: https://www.ietf.org/rfcdi= ff?url2=3Ddraft-ietf-opsec-v6-27

Regards,
KK

On Wed, Apr 7, 2021 at 3:33 AM Zaheduzzaman = Sarker via Datatracker <noreply@ietf= .org> wrote:
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/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ops= ec-v6/



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

I found this document very informative and I learned quite a lot by reading=
this document (I must confess I haven't=C2=A0 read the long list of=C2= =A0 referenced
documents :-)). I think the collected recommendations in one place will be = very
helpful.

Some comments -

=C2=A0 *=C2=A0 The abstract says - "The recommendations in this docume= nt are not
=C2=A0 applicable to residential user cases". However, later on in sec= tion 1.1 it
=C2=A0 says - "This covers Service Provider (SP), enterprise networks = and some
=C2=A0 knowledgeable-home-user-managed residential network." Furthermo= re in section
=C2=A0 5, it recommends configurations for residential users.=C2=A0 =C2=A0 = May be I am not
=C2=A0 getting the distinction among residential user cases, managed reside= ntial
=C2=A0 network and residential users correct but I think further clarificat= ion is
=C2=A0 needed on what is written in thee abstract and what is in the rest o= f the
=C2=A0 document.

=C2=A0 * I noted that section 2.3.4 refers to 3GPP 4G terminologies while d= escribing
=C2=A0 the case. If this section is not supposed to restricted to certain =C2=A0 generations of 3GPP technologies then I would recommend to update th= e section
=C2=A0 with 5G terminologies as well.

=C2=A0 * In section 2.6 there is an ask for the network operators to log &q= uot;of all
=C2=A0 applications using the network (including user space and kernel spac= e) when
=C2=A0 available (for example web servers)". How realistic is this? I = hardly see the
=C2=A0 web servers sharing logging files with network operators ( I would b= e happy
=C2=A0 to be corrected here ). I am also missing the discussion on -- if no= t
=C2=A0 available how much this affects the forensic research in the event o= f
=C2=A0 security incident and abnormal behavior.



--00000000000087695005c20e458c-- From nobody Tue May 11 07:30: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 91F0B3A19C6; Tue, 11 May 2021 07:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VT9CGyBHtpzK; Tue, 11 May 2021 07:30:22 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 721AC3A19C7; Tue, 11 May 2021 07:30:21 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id x20so28956710lfu.6; Tue, 11 May 2021 07:30:21 -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=C6lhI5BDNGhPYi1vjs/LIAZ7pj1bG1JyUeECF1MRwZc=; b=HDJn2atwB98k5Gok/J6LI+PYgfE3NgB+9cz9k/b/L3IGhtxwCqIjv3tSuRgrgdGvAi QCgRbmWbdNq+F0wViKoNpvQhZXCl7FBBIXJgCi/I8wRu2SG3j/JX3P6GWBXRLUork9Ww lFXSV9w35qZaNphqzq1kIswNczMRowD3FwMyGXzHmTm/zF9wyc6wgljFjsTLHKdwjHlo WlJKm8sWOKQck4opmDqJxteTqoDl69ps2yx2yfa/8TOqT8l/KwEQdzxxpHrreSJIVugX 1VsH5Lhc1wnS5v3ivdTGmhAh4cf++DM/z0fSPcvlKraDvyoEvq3+7e9sbcdvPOJ/xIlM cttg== 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=C6lhI5BDNGhPYi1vjs/LIAZ7pj1bG1JyUeECF1MRwZc=; b=lsEPIqO2qsS458G9ZfBKT9an+U5gPECUw40P+nANyuPvjoN4PIgnOyVB20veBG0ga5 RlhiEgh4yzW/La6OhoGCda96QatQatg8WKyfuniY5VmRY+aTE2Myjyvu505stIVqyX3M jv9IiyCWtbrqqAINSCiL/WAXizJGgA7C+jWE98unDLnJ49jqU0415maj+GpLmayspWOO G31Ohia/41B0eRsdkPHy0I7Pvtd0BMgssDhR7FqWAkOjCUITohCeE3j4BJEWmotX8lWI 0PgTb9JJ94sBBKM+xccfkG+f7/G47n0kPgBPd+Aai5QmzVN/B7xmkXcQ9DcpwQBho/it mwQw== X-Gm-Message-State: AOAM530lHXMVeBU4lKnyCKebgEPTm/LlyWvJ/97aQ2Kd96T8rgr4Oid5 D2eNo1Vv8SQRxmS6sMP5YLsIAHnFddHKPtKtCe0= X-Google-Smtp-Source: ABdhPJxPqEOfKM5P+CBOgukwob0fNTjP35Zt4oESt4QB16+OBIVME7k6tFnSPGagWy2ve42WaU4kMC65RLnWqqcm5Aw= X-Received: by 2002:ac2:43ce:: with SMTP id u14mr21317131lfl.439.1620743418780; Tue, 11 May 2021 07:30:18 -0700 (PDT) MIME-Version: 1.0 References: <161897107564.3338.17761721532629857647@ietfa.amsl.com> In-Reply-To: <161897107564.3338.17761721532629857647@ietfa.amsl.com> From: KK Chittimaneni Date: Tue, 11 May 2021 07:30:07 -0700 Message-ID: To: Roman Danyliw Cc: The IESG , draft-ietf-opsec-v6@ietf.org, opsec-chairs@ietf.org, opsec@ietf.org, Gyan Mishra Content-Type: multipart/alternative; boundary="000000000000bfa46205c20ebb35" Archived-At: Subject: Re: [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 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2021 14:30:27 -0000 --000000000000bfa46205c20ebb35 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Roman, Thank you very much for your detailed review. Together with my co-authors, we have uploaded revision -27, which should address most of your comments except a few listed below with our rationale: ** Section 2.1.5. Per =E2=80=9CHowever, in scenarios where anonymity is a = strong desire (protecting user privacy is more important than user attribution), privacy extension addresses should be used.=E2=80=9D, 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. [authors] We didn't change the text here as we felt that this is a given. ** Section 3.1. This list is helpful. Is text here and Section 2.5.4 needed? For example, does one need to say both =E2=80=9Cdiscard _packets_ from bogo= ns=E2=80=9D (this section) and =E2=80=9Cdiscard _routes_ from bogons=E2=80=9D (Section 2.5.4) [authors] We kept the text in both sections the rationale being that packets are dropped at the enterprise edge while routes are ignored by peering routers (not all enterprises have a DFZ routing) The diff is at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-v6-27 Regards, KK On Tue, Apr 20, 2021 at 7:11 PM Roman Danyliw via Datatracker < noreply@ietf.org> wrote: > 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 =E2=80=9CHowever, in scenarios where anonymity is = a strong > desire (protecting user privacy is more important than user attribution), > privacy extension addresses should be used.=E2=80=9D, it might be worth > acknowledging > that even if these are managed network, the end user and the operators ma= y > be > at odds on what privacy properties are important. > > ** Section 2.2.1. Per =E2=80=9CA firewall or edge device should be used = to > enforce the > recommended order and the maximum occurrences of extension headers=E2=80= =9D, does > enforcement mean dropping the packets? > > ** Section 2.3.2. Per =E2=80=9CNetwork operators should be aware that RA= -Guard and > SAVI do not work or could even be harmful in specific network > configurations=E2=80=9D, > please provide a more details, ideally through citation. > > ** Section 2.3.2, =E2=80=9CEnabling RA-Guard by default in =E2=80=A6 ente= rprise campus > networks > =E2=80=A6=E2=80=9D, what=E2=80=99s the key property of =E2=80=9Centerpris= e campus network=E2=80=9D. The > introduction > already roughly says this whole document applies to managed networks. > > ** Section 2.5.2. Reading this section, the specific recommended practic= es > weren=E2=80=99t clear. > > ** Section 2.6. It wasn=E2=80=99t clear how comprehensive this list of l= ogs 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/aud= it > 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 =E2=80=9CThe forensic use case is when the netwo= rk > operator > must locate an IPv6 address that was present in the network at a certain > time > or is currently in the network=E2=80=9D, isn=E2=80=99t 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 i= n > normal enterprise network scenario through SSO logs (if port level securi= ty > doesn=E2=80=99t exist) > > ** Section 2.6.2.2. Per =E2=80=9CThe 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=E2=80=9D. This framing is mixing th= e > 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=E2=80=99t 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 =E2=80=9CEnterprises Specific =E2= =80=A6=E2=80=9D, how is an > =E2=80=9Centerprise=E2=80=9D different than a =E2=80=9Cmanaged network=E2= =80=9D 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 =E2=80=9Cdiscard _packets_ from bo= gons=E2=80=9D > (this > section) and =E2=80=9Cdiscard _routes_ from bogons=E2=80=9D (Section 2.5.= 4) > > > > --000000000000bfa46205c20ebb35 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Roman,

T= hank you very much for your detailed review.

Together with my co-authors, we have uploaded revision -27, which should ad= dress most of your comments except a few listed below with our rationale:

** Section 2.1.5.=C2=A0 Per =E2=80=9CHowever, in sc= enarios where anonymity is a strong
desire (protecting user privacy is more important than user attribution), privacy extension addresses should be used.=E2=80=9D, it might be worth ack= nowledging
that even if these are managed network, the end user and the operators may = be
at odds on what privacy properties are important.

= [authors] We didn't change the text here as we felt that this is a give= n.

** Section 3.1.=C2=A0 This list is helpful.= =C2=A0 Is text here and Section 2.5.4 needed?
For example, does one need to say both =E2=80=9Cdiscard _packets_ from bogo= ns=E2=80=9D (this
section) and =E2=80=9Cdiscard _routes_ from bogons=E2=80=9D (Section 2.5.4)=

[authors] We kept the text in both sections the r= ationale being that packets are dropped at the enterprise edge while routes= are ignored by peering routers (not all enterprises have a DFZ routing)
KK

On Tue, Apr 20, 2021 at 7:11 PM Roman Danyli= w via Datatracker <noreply@ietf.org> wrote:
Roman Danyliw has entered the following ballot position fo= r
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/s= tatement/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-ops= ec-v6/



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

** Section 2.1.5.=C2=A0 Per =E2=80=9CHowever, in scenarios where anonymity = is a strong
desire (protecting user privacy is more important than user attribution), privacy extension addresses should be used.=E2=80=9D, it might be worth ack= nowledging
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.=C2=A0 Per =E2=80=9CA firewall or edge device should be us= ed to enforce the
recommended order and the maximum occurrences of extension headers=E2=80=9D= , does
enforcement mean dropping the packets?

** Section 2.3.2.=C2=A0 Per =E2=80=9CNetwork operators should be aware that= RA-Guard and
SAVI do not work or could even be harmful in specific network configuration= s=E2=80=9D,
please provide a more details, ideally through citation.

** Section 2.3.2, =E2=80=9CEnabling RA-Guard by default in =E2=80=A6 enterp= rise campus networks
=E2=80=A6=E2=80=9D, what=E2=80=99s the key property of =E2=80=9Centerprise = campus network=E2=80=9D.=C2=A0 The introduction
already roughly says this whole document applies to managed networks.

** Section 2.5.2.=C2=A0 Reading this section, the specific recommended prac= tices
weren=E2=80=99t clear.

** Section 2.6.=C2=A0 It wasn=E2=80=99t clear how comprehensive this list o= f logs was
intended to be.=C2=A0 A few additional thoughts include: -- DHCPv6 logs -- = firewall
ACL logs -- authentication server logs -- NEA-like policy enforcement at th= e
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.=C2=A0 The recommended fields in this section are helpfu= l, but
only in the context of the rest of the five-tuple + timing + interface + vl= an +
select layer 4 information for each flow.=C2=A0 These open IPFIX informatio= n
elements aren't mentioned.

** Section 2.6.2.1.=C2=A0 Per =E2=80=9CThe forensic use case is when the ne= twork operator
must locate an IPv6 address that was present in the network at a certain ti= me
or is currently in the network=E2=80=9D, isn=E2=80=99t this use case more p= recisely 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.=C2=A0 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 bee= n
the same one as during the time of the event of interest

-- there is discussion about identifying subscribers for an ISP but not in<= br> normal enterprise network scenario through SSO logs (if port level security=
doesn=E2=80=99t exist)

** Section 2.6.2.2.=C2=A0 Per =E2=80=9CThe first technique is to use the IP= FIX information
and extract the list of all IPv6 source addresses to find all of the IPv6 n= odes
that sent packets through the router=E2=80=9D.=C2=A0 This framing is mixing= the technique
with a particular logging format.=C2=A0 I would recommend being clear that = the
technique is question is passive inspection of network talkers.=C2=A0 There= a
several ways to get that: a properly configured IPFIX feed from a router, b= ut
also from any number of network analysis tools on a span port or a tap.

** Section 2.7.1.=C2=A0 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.=C2=A0 The intent of this section isn=E2=80=99t clear as all= of the described
practices are equally true of v4.=C2=A0 A few missing hardening practices i= nclude:

-- applying firmware, OS and application patches/upgrades to the devices in= a
timely manner.

-- using multi-factor credentials to authenticate to devices

** Section 3.=C2=A0 This section is titled =E2=80=9CEnterprises Specific = =E2=80=A6=E2=80=9D, how is an
=E2=80=9Centerprise=E2=80=9D different than a =E2=80=9Cmanaged network=E2= =80=9D called out in the applicability
statement?

** Section 3.1.=C2=A0 This list is helpful.=C2=A0 Is text here and Section = 2.5.4 needed?
For example, does one need to say both =E2=80=9Cdiscard _packets_ from bogo= ns=E2=80=9D (this
section) and =E2=80=9Cdiscard _routes_ from bogons=E2=80=9D (Section 2.5.4)=



--000000000000bfa46205c20ebb35-- From nobody Tue May 11 07:32:04 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 D7CEA3A19CF; Tue, 11 May 2021 07:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjynZkDyE31F; Tue, 11 May 2021 07:31:52 -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 E450B3A19C7; Tue, 11 May 2021 07:31:51 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id p20so1403340ljj.8; Tue, 11 May 2021 07:31:51 -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=8CsjILPcFrbws4cX8BEE/7uG6uo0b9S7efC8uwzpnCU=; b=nn0nfw6yMN/J7BEvUtXdJZRSiTQlH08hYQk8fmIPTzv32Etzl9QFDp0cTSeLtO14K0 dG9y3S2l/pO1mrV9gMx3MOP4dbQyxxI6IJeC61tLSrxlrCamGhySnhynURPsKC6Axr08 I6RT4w6baGIxAA8oa1Gfwcz6vookjSIGx5TQQxBSKrBAb5MeECAbEm3RYCKfS83Zy98z vIcW8+PrOt7jPZdXOl3d7Dc1jm0XnT+m10uHtCHoUngKSfaQ05nyVJqAxq5jIWWKtvzr vhKjXvmihwZJt9VGJ+u6j3Cm1y0ROBZo6Qa1/lCOX1WQWIU6ZNNLnGcfCqCkJ7VDra5A Yt0w== 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=8CsjILPcFrbws4cX8BEE/7uG6uo0b9S7efC8uwzpnCU=; b=R/QG/XU/NUhsyuuKV/zvUhuRKwPzy50uGKqi8RDokMAdaK+uN4t6E+tRaVJMkX7Mg6 LUv0+ZxD0pJa9YWYOlwFBjPE+pDcz4UPXGBpa/3IyU07CsjbpnPhzrQ6G/TyRdB8jCOZ Y4Hf5aR6XZgFi6GbvhwXxp/5D77LaG4tITieBM5FiyFzy2YV4Ezfmp5tEvZyck3El6VI b664xnVZd258YQ6br1ajwdKmF8Ekx+fdXgBQ2JRhHRA3QDAwJgTLO8H45Q9smp9BuYE5 HhtcyOL7+SY2gMd+2p3iQkdCigLN6EFOzFjPF23mKm3RcYFHLEPt7+zLZddGybR8d8IU p0vA== X-Gm-Message-State: AOAM532AAetuUEV8wGBZGAC5WYgGuzZZO16eAHj6AJG7up5h/QTHC26z DFeM5R9gcHovNTaL7XaMr+3tSTNCTskFyJiA37E= X-Google-Smtp-Source: ABdhPJzfAGzrnUS86oPcVA0qP5mDsxF9rFP2a5YgKOojJlsyun4Th8D2a6seW7om1JLHjbnofdYkX5EbMQBw1RiMJ2Y= X-Received: by 2002:a05:651c:210:: with SMTP id y16mr22590312ljn.279.1620743508793; Tue, 11 May 2021 07:31:48 -0700 (PDT) MIME-Version: 1.0 References: <161765687327.663.16409961435864058863@ietfa.amsl.com> <20210410183626.GC91991@ernw.de> In-Reply-To: From: KK Chittimaneni Date: Tue, 11 May 2021 07:31:37 -0700 Message-ID: To: Alvaro Retana Cc: Enno Rey , opsec@ietf.org, Gyan Mishra , draft-ietf-opsec-v6@ietf.org, The IESG , opsec-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000001d1ce705c20ec165" 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: Tue, 11 May 2021 14:31:58 -0000 --0000000000001d1ce705c20ec165 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alvaro, Thank you very much for your detailed review. Together with my co-authors, we have uploaded revision -27, which should address all your comments. The diff is at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-v6-27 Regards, KK On Mon, Apr 19, 2021 at 8:27 AM Alvaro Retana wrote: > 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= =A75) 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 *o= nly*? > > 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 th= e > > references in light of [1]. > > > > [1] > > > https://www.ietf.org/about/groups/iesg/statements/normative-informative-r= eferences/ > > > > > > > > -- > Enno Rey > > Cell: +49 173 6745902 > Twitter: @Enno_Insinuator > > --0000000000001d1ce705c20ec165 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alvaro,

Thank you very mu= ch for your detailed review.

Together with my co-authors, we have uploaded revision -27, which should ad= dress all your comments.

The diff is at: https://www.ietf.org/rfcdi= ff?url2=3Ddraft-ietf-opsec-v6-27

Regards,
KK

On Mon, Apr 19, 2021 at 8:27 AM Alvaro Retan= a <aretana.ietf@gmail.com&= gt; wrote:
=
Enno:

Hi!

I looked at -26. =C2=A0

I still find = the applicability statement confusing, the the reasons I described in 1.a/1= .b (below).=C2=A0 There is a contradiction about whether the document appli= es 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 "applicabi= lity 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 si= nce the applicability statement may influence who reads and follows the rec= ommendations.

Thanks!

Alvaro.

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

<= blockquote type=3D"cite">
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/d= iscuss-criteria.html
> 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/statements/normative-informative-references/
> =20
> =20
> =20

-- =20
Enno Rey

Cell: +49 173 6745902
Twitter: @Enno_Insinuator
--0000000000001d1ce705c20ec165-- From nobody Thu May 13 06:42: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 E0BE43A07E0; Thu, 13 May 2021 06:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=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 WF68VdMLp-I9; Thu, 13 May 2021 06:42:32 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on0616.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0d::616]) (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 AA2DC3A07D3; Thu, 13 May 2021 06:42:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LPB6OIw2cQm/FGftExSJrc6NHen+5OgPMeIOipXaPA7kt9gxM04h3rprMh8MpfLzdKnQYoTXhQQB+rposgNNaBV3yL81G5KNjKRm7E0QBYJ0qd9SpoES6o9NRJbPLVkWhrxZE/tlZ3umiiy0WJ3kC9w3rUl4rrlVCde7Pz4MRPjkND1aMt0pJfCzx25s1A5rh4/plZxwiBLbtSbMtHs9wKUv0bju5bVSL7TOhIHKT8PJyjCcFqSCE2cQz7RLC0xpJulm9+hRBlXKgQ10YJlCEk3OWf97mf6ej7a31favQH/X6i+GP6lwjJDScpqmqPLKFBMvRKUZ2wxfsO+A4uv9Rg== 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=CgJekLuHrJXLSaKpC5mq6zraueu6I//9E60GDAgibfY=; b=mjhr3Q2aP5J7Zw4ua9w7zIKg70m3LWR8O5b9YwP9FPOVTDrnFkWp/1WGdX+rVJV14kPviNJVuaW3rThRmKzgI8bL0IjB3YsznVmiA0NjWQSJpa2DQFzqaGbtj9rjRDqaGgZD3Bcim2w1HiDohmfoydvnrW9IkB+RhPoBVQLbqIDJVpx2ipHuS7fSn+/+FlVHm6/BixxJ6IrCI1SJZopHvs+dpq8lNYLap4veb1vq0ASmYMar75H+yi5+8370cCWexOrk2QY/CfgNTbAsiUde0kIF5aFhisYqbNaVC1+kXXVTzVodSkQbrdV2YpQ+Ue4LIKZyn0+ouRIdI+XfbJvrtg== 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=CgJekLuHrJXLSaKpC5mq6zraueu6I//9E60GDAgibfY=; b=Z8XtT8aOmQ35Bgw3XcAV2NCSe8USqYwYYFgyz0T+PZkZX8cVtmyr9E/cRcm/+sxeEI82tlJXtzED7LKg5bTmPiUbZf67fw9AYzoOlfUUWMEnowmc8jo6TSk7yo6YDhase3mhxcPhKqFFSlZujGvC8JX6Pmc23xjIsm8DVaneOCk= Received: from DB9PR07MB7771.eurprd07.prod.outlook.com (2603:10a6:10:2a6::15) by DB9PR07MB7993.eurprd07.prod.outlook.com (2603:10a6:10:2a4::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4150.12; Thu, 13 May 2021 13:42:20 +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.4150.012; Thu, 13 May 2021 13:42:20 +0000 From: Tim Chown To: Enno Rey CC: "ops-dir@ietf.org" , "opsec@ietf.org" , "iesg@ietf.org" , "evyncke@cisco.com" , "merike@doubleshotsecurity.com" , "kk.chittimaneni@gmail.com" Thread-Topic: [OPSEC] Opsdir last call review of draft-ietf-opsec-v6-25 Thread-Index: AQHXRXO++TSlwo6r7kSPWLS22aJi5arhcK6A Date: Thu, 13 May 2021 13:42:20 +0000 Message-ID: <5DD2F6C5-A58F-408D-9CF1-F97EC50A3D5B@jisc.ac.uk> References: <161778675730.8077.2835666586607648895@ietfa.amsl.com> <20210510080859.GA89736@ernw.de> In-Reply-To: <20210510080859.GA89736@ernw.de> 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: ernw.de; dkim=none (message not signed) header.d=none;ernw.de; dmarc=none action=none header.from=jisc.ac.uk; x-originating-ip: [2001:a88:d510:1101:f847:4af6:ba78:72f1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 582d9ee6-3fcf-4b4c-2866-08d91614ee42 x-ms-traffictypediagnostic: DB9PR07MB7993: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1850; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: MWVr/NflLyGfmNNrtNcb/8ExvlqcLqu5bt9lLXou9nJrTQZu9czSO/axV2bh+o0h7mrLzAZJVL8ZSdezUgVafMW9SC4ktKx1yuD+Aaqe+BhyzbX8h7k/ddEzBtX0SspeeIeSnKXgxxRx4tN0EvfeVVlrStVBKodF5rIIY9znxGM2N+JyAPERgTnmewsP4uW8WV02yzwc0k/WTvkiVKuNejBtQue6puc+Rq2zeWkJO6Z433yQaKDwiWct2lYk+cnXZ/f8YEe8kZo2pNH9LGZy3ZkowtoUyFnQPPuiO/bFeiXxiz74LnbgmH6v8Nry/DLL/KdoJ+v//EHbyjA8glp2cwtLYujiohvm0IWbCjeXvZnJAN4Cy9XV0bfsHdwan2AVyHn1fFi15tfrcqwgz8wCmNIB7e5rfkZpDyVT7IgVLr+K5h+8IljY3qXNBrFMXTirmGXktc7CUvbWfLHDfMWZxppSHCGAq2k7Nu38kZ4XqIDzD6vqZ+eE4gnfA2Jdd5vUN5DCT0qqbElEcGcZ0yoIHCZt0/ayJAUxJ6hdi3rTYZQ2shOwhR8GuDPTHuv9Ox+CZFcwvKfkFhJdQs0Gj4pYC52vrlqjGZ5ZWZxwDDtVujabga1LrBlDAzqU0xdfk4a4GJiT05ICSGWLOVvoiO2Ey0fjM/NGDwCFI/CCj8fKqOSA2JhvDSvO1VKev7mIOQCQ55lAZtetIhj8Nh+A0HQbGioGwDgndR461qqbVZwHTcvkDXHzi1u6NjA0jlHDu062 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)(366004)(376002)(136003)(346002)(39850400004)(396003)(786003)(316002)(122000001)(38100700002)(33656002)(6486002)(83380400001)(5660300002)(76116006)(91956017)(6512007)(66946007)(966005)(186003)(8676002)(86362001)(71200400001)(36756003)(54906003)(478600001)(8936002)(2906002)(66574015)(2616005)(66446008)(4326008)(6916009)(64756008)(66556008)(53546011)(66476007)(6506007)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?ijbrute8/IESxUYodXL0UX4/9w7QUaznpnujAYmavbPJKh/O8FtwJg2u0EFS?= =?us-ascii?Q?R4sLGXA4I22Doa3d4tBHIb4Ttvn1G8JxjeqZskM7kKz0eFxF+yZlenHRzW6A?= =?us-ascii?Q?TYehh7LVLE9MLMEkrdBeszPv0oV8KlF6dresX7+n7/rL6l/eTT/DSnQluHvc?= =?us-ascii?Q?z5jpi0B4Xc0h84XAyoiE26jczhX2isocZpokAZAfGL0utal1EfzWl7s9Qp7+?= =?us-ascii?Q?zrjFZsUyzEBGNmkKjRPLVvCo/hpzg3cUyBrJ2g8n9aQtTYLD7WTjCgvRRYXV?= =?us-ascii?Q?5iCTw/FHJXjJsV0NBXXZSKU2poIeOuvjrPmJ3wttpeo3ojxwHNOY4qKDTJNm?= =?us-ascii?Q?wyjWxxv3MBtcOk3CvR/Fak2Lc6uTUf/DS12RLTeF2vGkAAS990wP3rOieheb?= =?us-ascii?Q?KsILsC0gYoWl5QFPixYDqR9YCX2Hl4nkNCH/OwuL/h1knZ5X11JgNFhSkcvv?= =?us-ascii?Q?INNOgqpDZ0Vh0mBmjYagVC+s949H8o5iIxxaxbp2rCD5xlv6+lFWt0kVzhfw?= =?us-ascii?Q?NyoSj5YPOgQTgF3n2nCSWOm733rHs+za/zcdD1oLjp1JlR2ZquaLKu/W+ev6?= =?us-ascii?Q?V1U46wmGMc9krU8yaq3QURQsKrlQmghqjKdb1lymsaF31JF4nzo/kq3zHeoH?= =?us-ascii?Q?LxJJ/Jr2YyrQDHGhIEPm525VlwpuU1Ur9kCVZU1U3o8fVxu1C63uzjZBRmQ6?= =?us-ascii?Q?4S6gh5TgIEisWpuROKUmo4cBE9HthDEZCPERm29ywiEUmUZqMLY884NTMsAM?= =?us-ascii?Q?7sYYUsvltkI9mw1Sdy7MaTgqGMllaHqbWDseDdaT5QFV/wXIz6HknNecA/Gw?= =?us-ascii?Q?ytobHA/c/COV4JpLLq0nUXq1dnI+LEC7jQSb1/Cj7mDOtRk5HwCbWmE2ZdCq?= =?us-ascii?Q?I21bpP6YyJrnxeU9rJrv1GBOMD7u3ix53IjMD2SagaPnDEv8IQ1LkMVbpzRC?= =?us-ascii?Q?C3WO6R4U1A2pmzjDuXvOzXzp0jzwhO6420QF5n8oiau232U94wxAmQwstdDk?= =?us-ascii?Q?mK9V6KLJeju8mEu/iS+PDcHyT2I6knomnd0DUThbORjJT5d98pGyvbjpGX+i?= =?us-ascii?Q?403sTjQpulvnnbrJKNCFUW47926ml5n2tSnLtWzSZt/mO4sn3CjH1fcFW8gz?= =?us-ascii?Q?v9gTO3i+ETe+fKmvu0Kedf8UE4qkogqRLG85c3OZhpqhZSqjLlzIKYztE/s5?= =?us-ascii?Q?a2JpYseKEvh4MbUkYonQwZ0y+dK9ryGpg5fEPZ5ZHI8d7l8irmA0d9sZmLYW?= =?us-ascii?Q?wvOGgI5PiNoBj5f8yaLLVv3dHXD7GstmkYwapUPHreLM3M3nFnNqTTIwklBR?= =?us-ascii?Q?si+W9icjRW0wU9J8QwpTdDq9+ynp4mgVarY7qn3nyy0Wb1/9bAyynlpzbS2Q?= =?us-ascii?Q?PZ7ZCoRlYGWYq8PhjI3yMAnvaBfa8cBp/Nh3HusJzIyyI046Ew=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: 582d9ee6-3fcf-4b4c-2866-08d91614ee42 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2021 13:42:20.1588 (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: gKiLFi4HVeB9G+d+EntIcKbEJG8fx8zbfZ/Zll1qOTOQfTiN73AJYztXmaPeQ+GI9yBWLjuS12ZE4W7LGQa9ZA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR07MB7993 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, 13 May 2021 13:42:38 -0000 Hi Enno, Your comments and responses are all fine, thank you for explaining the rati= onales. Hopefully the new version will be approved for publication soon, = it will be very useful for the community. Best wishes, Tim > On 10 May 2021, at 09:08, Enno Rey wrote: >=20 > Hi Tim, >=20 > thanks again for the review, for your support during the different stages= of its development, and for the detailed comments. >=20 > We have incorporated most of the comments that we felt were in line with = the general document and were agreed upon by the authors. Some comments wer= e not acted upon though as the current text is the result of WG consensus, = and/or a proposed change would have modified the overall direction of a spe= cific recommendation. > Please allow to comment/address them in the following. >=20 >=20 > On Wed, Apr 07, 2021 at 02:12:37AM -0700, Tim Chown via Datatracker wrote= : >>=20 >> Specific comments: >>=20 >> 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 shoul= d be in >> a standalone section, and be neutral there. >=20 > A mention of EHs was added (good point, thank you). As for NPTv6 part we = decided to leave as is. >=20 >=20 >> 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 unma= naged >> networks? >=20 > We removed the part referring to multi-homed networks (and the 'exception= ' piece as a whole as it could indeed be a bit confusing). >=20 >=20 >> p.4 >> Again, NPTv6 is mentioned. This section is titled ???addressing archite= cture??? >> but this bit of text is about reasons for going PA, PI, or becoming an L= IR, >> which is not architecture. >=20 > We simplified the section title to just 'Addressing' to reflect the gener= al nature of the recommendations. >=20 >=20 >=20 >> p.4 >> In the 7934 para, RFC8981 should be mentioned as it???s a significant re= ason of >> devices having more addresses. >=20 > An explicit reference to RFC 8981 as one of the main reasons for multiple= addresses was added. >=20 >=20 >=20 >> p.5 >> ULAs are also useful where the prefix changes, for stable internal addre= ssing >> as the global prefix changes? Typically in residential networks. >=20 > From our perspective the text already mentions this scenario. >=20 >=20 >> p.5 >> Section 2.1.4 is really about choices in address assignment within a net= work. >=20 > We feel that it's mostly about the various implications of stable address= es, which is why we stayed with the current section title. >=20 >=20 >> p.6 >> Some of these paras should be in a section about IPv6 network reconnaiss= ance, >> how to best mitigate against scanning, and how to inventory your own net= work >> elements. >=20 >=20 > RFC 7707 has a section on mitigations, which is why we point to that one. >=20 >=20 >> p.6 >> All mentions of 4941 should be replaced with 8981. >=20 >=20 > done ;-) > (This was one of cases where parallel publications obsoleted an item in o= ur document, due to the long time of document development, as you rightfull= y stated) >=20 >=20 >> p.7 >> Can use 7721 and 8981 together. >=20 > We decided to leave as is. >=20 >=20 >> p.7 >> Why are DHCP and DNS limped together? The DNS is only about DNSSEC, so = call it >> that? >=20 > We split this part into two individual sections on DHCP and DNS each. >=20 >=20 >> p.7 >> ???Even if the use of DHCP??? - this reads badly. Rather 8504 talks abo= ut this in >> 6.5, where RFC7844 is mentioned for example. This should be in a user p= rivacy >> section (if this document had one). Section 8.4 is also useful advice. >=20 > The "even if the use" part was removed in the course of the rewrite/-orde= ring of the section. >=20 >=20 >=20 >>=20 >> p.8 >> The first para is very muddled. >=20 > We performed a number of clarifying changes in this part of the document.= We hope they address this one, too. >=20 >=20 >>=20 >> p.8 >> In 2.1.7 this can also be useful for ACL controls, if one admin / contro= l >> system sits in a prefix of its own. >=20 > Good point; a respective sentence was added. >=20 >=20 >>=20 >> 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. >=20 > We decided not to rewrite these parts. >=20 >=20 >>=20 >> p.10 >> In 2.2, the intro can say these issues have parallels in IPv4. >=20 > We decided not to rewrite the intro. >=20 >=20 >>=20 >> p.11 >> First line, say the attack can typically happen from a large address sca= n if >> permitted into the network? >=20 > That's correct. Still, as we point to RFC 6583 for an extensive discussio= n, we felt this addition wouldn't be needed here. >=20 >=20 >>=20 >> p.11 >> Bullet 1 - that contradicts the comments on predictable addressing. >> Bullet 2 - how? Some clues here would be useful. >=20 > We added some some examples to the second bullet. >=20 >=20 >>=20 >> p.12 >> ???Current??? - really? All current implementations? Delete ???current?= ?? or replace >> with ???naive??? maybe. >=20 > The wording was modified in order to avoid 'current'. >=20 >=20 >>=20 >> p.12 >> ???Communicate directly??? - at L2? If so, why? >=20 > Wording was clarified, together with an example. >=20 >=20 >>=20 >> 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. >=20 > Please see Eric's e-mail from April 21 why we couldn't follow that path (= based on previous WG discussion). >=20 >=20 >>=20 >> p.13 >> ???Trivial??? cases - aren???t these common ones, like edge switches in = an enterprise? >=20 > The section was modified in order to provide more clarification. >=20 >=20 >>=20 >> p.13 >> Why ???hostile???? Delete? >=20 > We deleted 'hostile' in the context of the distribution of a DNS resolver= . >=20 >=20 >>=20 >> p.14 >> In 2.3.5 last para, what about mDNS, Bonjour? Though the DNS SD work i= s now >> on unicast discovery. >=20 > That's a tricky one as we've seen differing approaches here (mDNS/Bonjour= ), based on different operational needs. > Still we added mentions of mDNS and LLMNR. >=20 >=20 >>=20 >> 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. >=20 > Some more potential log sources were added. Besides that we felt that the= overall section should be left as is. >=20 >=20 >=20 >>=20 >> p.28 >> The text is 2.6.2.2 repeats earlier text. >> Similarly text in 2.6.2.3 is repeated form before. >=20 > Agreed, but these sections might be selectively read by specific audience= s which is why we accepted a bit of redundancy here. >=20 >=20 >>=20 >> p.29 >> In 2.6.2.4 presumably also a rapid growth in ND cache size is an indicat= or. >=20 > Good point & worthwhile suggestion; we added that one. >=20 >=20 >=20 >=20 >>=20 >> p.29 >> In 2.7 point to RFC 4942 >=20 > A respective reference was added. >=20 >=20 >>=20 >> p.30 >> Should RFC 6092 be mentioned here? >> And that the best defence against IPv6 attacks n ???IPv4 only??? network= s is to >> deploy and manage IPv6? >=20 > Let's hope that this document comes into play exactly when IPv6 gets depl= oyed in a properly managed way ;-) >=20 >=20 >=20 >>=20 >> 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 o= n the >> first para on p.32 >=20 > =09 > As there had been a lot of discussions in the WG about the whole tunnelin= g part of the document, we considered this part as aligned with WG consensu= s, and hence refrained from significant changes here. This applies to most = of your comments in this part (still some quick notes on individual technol= ogies in the following). >=20 >=20 >=20 >>=20 >> p.31 >> Maybe say here the mitigations can also break tunnel brokers (might be d= esired, >> but users will notice???)???. Maybe tunnels to specific brokers can be a= llowed. >=20 > =09 > See the above general comment (on the tunneling piece of the document) fr= om our perspective. >=20 >=20 >=20 >>=20 >> p.32 >> ISATAP, in 2021? Same with 6rd. General advice should be deploy native= , avoid >> tunnels. >=20 > I think we'd all be happy if ISATAP wasn't a thing in 2021 anymore. Alas,= it seems more prevalent than one might think, e.g. see this recent talk fr= om the PAM conference (April 2021): > https://www.youtube.com/watch?v=3D_c061S5iZfo. We also added a reference = to the full paper. >=20 >=20 >=20 >>=20 >> p.33 >> Same for 6to4. >=20 > See comment on ISATAP >=20 >=20 >> p.34 >> Teredo though, is that still included in Windows and XBoX, as a MS thing= ? >=20 > Yep, still supported/deployed with the Xbox. >=20 >=20 >=20 >>=20 >> p.36 >> Maybe cite Geoff Huston???s blog on this - it???s very good. Maybe ther= e???s a more >> recent update though - >> https://blog.apnic.net/2016/06/09/lets-talk-ipv6-dns64-dnssec/. Host CLA= T is >> applicable here? (Hence a site should support the 64PREF RA option? RF= C8781 >=20 > Agree that Geoff's blog is excellent, but we decided not to perform chang= es here. >=20 >=20 > p.38 >> In 2.8, to be fair IPv4 is also hardened a lot of late due to the preval= ence of >> use of devices in WiFi hotspots etc. >=20 > Agree.=20 >=20 >=20 >>=20 >> p.37 >> Also RFC6092 on section 3.1? >=20 > 3.1 already had a reference to RFC 6092. >=20 >=20 >>=20 >> p.38 >> ???Where RFC1918 address are often used??? - add ???often???, the text i= mplies all >> enterprises use v4 NAT. >=20 > Done. You're right about the misleading implication of the old text. >=20 >=20 >>=20 >> p.41 >> Only 2 normative references? >=20 > Due to nature of the document we feel that the informative ones are more = important (and we actually performed some slight changes to the references,= e.g. adding the ISATAP paper mentioned above). >=20 >=20 >=20 >=20 >>=20 >> Nits: >>=20 >=20 > All the nits have been addressed, too. >=20 >=20 > I wish everyone a great week >=20 > Enno >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > --=20 > Enno Rey >=20 > Cell: +49 173 6745902 > Twitter: @Enno_Insinuator From nobody Thu May 13 08:12:57 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 0447D3A0FF5; Thu, 13 May 2021 08:12:49 -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, 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 yU7mU8zw_TrQ; Thu, 13 May 2021 08:12:44 -0700 (PDT) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 914B23A0F9D; Thu, 13 May 2021 08:12:41 -0700 (PDT) Received: by mail-pg1-x52b.google.com with SMTP id s22so21661653pgk.6; Thu, 13 May 2021 08:12:41 -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=OhP94tcMtRwS6WCU3K4rcai1D+I8tFk0HWcPo4/ubA4=; b=KRnCEgSfDA8c/CKib3i/BTpKgvUJoK9b+3UYe2ldv5kIRXGZ0I7WgIpvynxSmOfObM mjt7QxjwKs5pLF/41/hpqPqrXAHiFIvXVTE4uzCSgVr+oDVDvgF8E9mt9x548MAytXhp a5IWYtIKUDu9YQYZPX18WFp5h3lEOd3EhDYd0Q3/qaoEilYay8KqsSNlYbuhpC1KwEN8 GsbiAdPLOR6oomzWtmTFvnfGjyj+gWJUbllcEp3srj4vuNqLHwUPp/rq3Ye/gXji5tci h0b3/x6F6ehhfLI3PAwiu3KUnGDnoGwIFFKulZGL8zx2D7s13PsJqqifRVN8MlkgfCRC MvtQ== 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=OhP94tcMtRwS6WCU3K4rcai1D+I8tFk0HWcPo4/ubA4=; b=dW0ial6B2Qz9YzUo+bUhO7vYqvQi7qSnbK/cK0rzswPC1XHsFXzIVQoFUV7TJFjUhm aajZjJnF9Ju8eOOzOSU4eLWfwHY8IBBsbq7qssh+PL4pe2nCsmixqDVpICHkG1DzmSEw j6VsVtYLaxRkMQR2koLd+CNe47dr++HXAuBgod22v6uEfMN4GGPbJ7dM/2V2Tqt4QTtP zcRIljs5wujqPJmfDO0qY5g1lHRhhvzLYje4et9EiI6TeRMphgJpwixmdc8Z7LOq0Uwc xW4g9iZsPi0Yw37iBeEUY1S/t2EEGMqrfV2S8Fhlgrl985xiRFh73/POEJnBXxmEd/b2 eRoA== X-Gm-Message-State: AOAM533lO4pt6EPq+mVs5QHyQRg1i3U4E0eRMMCJWDRhJmchoX0se+Wn xzsy7y156Xu5XaiX/afEBXoEAZ839gl5cPyCWZk= X-Google-Smtp-Source: ABdhPJx9IdfRWaMkhpJCG+iZnIE/t4surlhRiLc9/L1NnCwx/lUHBuCqgSsiS7bIhxxoFijtpzVUJ/tk3sO5/PXEcfQ= X-Received: by 2002:a17:90b:88c:: with SMTP id bj12mr44476163pjb.112.1620918759237; Thu, 13 May 2021 08:12:39 -0700 (PDT) MIME-Version: 1.0 References: <0B38A56C-B339-4226-86E6-D6E89B799018@cisco.com> In-Reply-To: From: Gyan Mishra Date: Thu, 13 May 2021 11:12:28 -0400 Message-ID: To: "Eric Vyncke (evyncke)" Cc: OpSec Chairs , opsec WG Content-Type: multipart/alternative; boundary="000000000000daa91105c2378ed7" 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, 13 May 2021 15:12:56 -0000 --000000000000daa91105c2378ed7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Eric Just checking if you had a chance look my Shepherd review. Kind Regards Gyan On Thu, Apr 29, 2021 at 7:38 PM Gyan Mishra wrote: > > > 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 wel= l > 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 sam= e > 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 tha= t 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 a= bility to configure additional IPv6 addresses from the link prefix(es) with= out > 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 wher= e > 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 routin= g 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 forwarding of = IPv6 packets without an IPv6 address configured on an interface. The cavea= t here is in traceroute the interface next hop is not shown in the trace an= d so for the NOC makes troubleshooting more difficult. However it does mak= e deployments or IPv6 on routed backbone nodes much quicker as no address p= lanning is required. I actually use this method in lab environments all th= e time and > > it=E2=80=99s very handy. Also mention that on eBGP tie connections GUI o= r 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 c= aveat is LL is not reachable beyond local link and > > ping or OAM of link if required that will not work. The same operational= issue goes for a routed interfaces using LL and > > no IPv6 address are now not pingable to ensure each link is Up and reacha= ble by NMS. > > > > On P2P when using /127 it is recommended to disable DAD as the subnet rou= ter 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 = for server functions should always be stable address. Maybe worth mentionin= g 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 rand= om > 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 com= es to using random changing address used for privacy > > for broadband users versus stable address for corporate network user comm= unity 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 mentio= n > that all host have a local ND cache similar to a router ND cache as ICMPv= 6 > 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 comma= nd > 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-a= ll=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 subne= t > 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 = 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 swit= ch 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 TLV= s > 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 a= nd > doh to avoid risk of ddos attack and management plane impact which impact= s > designers from developing new use cases for hbh and doh. This impacts th= e > 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 IAC= L > 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 = 6PE and 6VPE, link-local addresses (see [RFC7404 ]) can be used and as these addresses cannot be reached from out= side 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 whic= h > 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 acce= ss > 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 stack= ed > 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 t= o > 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 a= s >> it is on its way to publication. >> >> >> >> Kind Regards >> >> >> >> >> >> *Gyan Mishra* >> >> *Network Solutions Architect * >> >> *Email gyan.s.mishra@verizon.com * >> >> *M 301 502-1347* >> >> >> > -- > > > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email gyan.s.mishra@verizon.com * > > > > *M 301 502-1347* > > -- *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* --000000000000daa91105c2378ed7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Eric=C2=A0

<= /div>
Just checking if you had a chance look my Shepherd r= eview.

Kind Regards=C2= =A0

Gyan=C2=A0

On Th= u, Apr 29, 2021 at 7:38 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:


Hi = Eric=C2=A0

Shepherd Revi= ew 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 s= ervice provider public internet and private networks are applicable=C2=A0

Introduction=C2=A0
<= div dir=3D"auto">
Maybe mention extension header= s as that has been a huge difference as well as security issue

When mentioning ARP and ND differenc= e maybe mention that now ICMPv6 now takes on the role of L2 Mac to L3 addre= ss mapping and maybe along the same line of thinking of broadcast versus mu= lticast mention 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

<= pre style=3D"font-size:1em;margin-top:0px;margin-bottom:0px;break-before:pa= ge;font-family:monospace" dir=3D"auto">In [RFC7934], it is = recommended that IPv6 network deployments provide multiple IPv6 addresses f= rom 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 net=
work provide more then one address.

New


RFC 7934 states that most general-pur= pose IPv6 networks, hosts have the ability to configure additional IPv6 add= resses 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.
<= br>
Section 2.1.1=C2=A0

<= /div>
ULAs although less likely to have overlap due to pse= udo random algorithm there is no guarantee of not having an overlap.=C2=A0 = Operators of with large internal corporate networks that are subject to mer= gers =C2=A0and acquisitions it is recommended to not use ULA.=C2=A0 ULA doe= s not guarantee uniqueness where GUA does for internal deployments.=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 re=
lated caveat related to addressing.  So as all routing protocols use LL nex=
t hop most vendors have a command similar to cisco =E2=80=9CIPv6 enable=E2=
=80=9D that allows for processing and forwarding 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 o=
n 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 th=
at on eBGP tie connections GUI or ULA as well is not required to save on ad=
dress planning and 
peering ca=
n 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 ope=
rationalissue goes for a routed interfaces using LL and 
no IPv6 address are now not pingable to ensure e=
ach 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 for server functions should always be st= able address. Maybe worth mentioning and use of static stable address for s= ervers and not SLAAC address. 

Old 

Typical deployments will have a mix of stable a=
nd 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 sta=
ble 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 use=
d for privacy=C2=A0
for broadb=
and users versus stable address for corporate network user community where =
security and traceability is of utmost importance.
<= div dir=3D"auto">
I believe what is being convey= ed related to scanning is by pinging FF02::1 it is easy to discover all hos= ts on the network.=C2=A0 Also may want to mention that all host have a loca= l ND cache similar to a router ND cache as ICMPv6 is running between the ro= uter 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 add= ress is also set as well.=C2=A0 SLAAC has to be disabled manually on router= via cisco command example =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 c= ommand example which suppress both periodic and response to unsolicited RS = as routed link has static IP. =C2=A0

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 def= ault gateway hijack as it sends an RA.=C2=A0 This can impact all hosts on t= he subnet black hole. All L2 switches Mgmt L3 interface that sits on host s= ubnets interface should 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 ho= sts placing them in =E2=80=9Chost-mode=E2=80=9D versus acting as a router a= nd now the L2 switch can pick up default route via RA from upstream router = pair.=C2=A0 With that of course any use of SLAAC and RA advertisement to ho= st requires RA guard.

2.= 2=C2=A0

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 =C2=A0the number of extended headers stacked limited by the MTU= .=C2=A0 Also the cyclical cycle by operators filtering hbh and doh to avoid= risk of ddos attack and management plane impact which impacts designers fr= om developing new use 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 which I am Co-author has some details related to NPU and fi= xed function ASIC and=C2=A0
separation of control pl= ane and data plane criticality.

Maybe add below draft as normative reference=C2=A0



<= div dir=3D"auto">
=E2=80=9CSecuring =
the routing protocol between CE and PE; in the case of 6PE and 6VPE, link-l=
ocal addresses (see [RFC7404]) can be used a=
nd as these addresses cannot be reached from outside of the link, the secur=
ity 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 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

--


Gyan Mishra

Network Solutions Architect=C2=A0

Email gyan.s.mishra@verizon.com=
<= /font>

M 301 502-1347


--
--000000000000daa91105c2378ed7-- From nobody Fri May 14 12:18:09 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 BF9A83A3D20; Fri, 14 May 2021 12:18:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.29.0 Auto-Submitted: auto-generated Precedence: bulk Cc: Gyan Mishra , The IESG , draft-ietf-opsec-v6@ietf.org, hayabusagsm@gmail.com, opsec-chairs@ietf.org, opsec@ietf.org, rfc-editor@rfc-editor.org, warren@kumari.net MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <162101988376.26048.14574373432525589983@ietfa.amsl.com> Date: Fri, 14 May 2021 12:18:03 -0700 Archived-At: Subject: [OPSEC] Document Action: 'Operational Security Considerations for IPv6 Networks' to Informational RFC (draft-ietf-opsec-v6-27.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, 14 May 2021 19:18:04 -0000 The IESG has approved the following document: - 'Operational Security Considerations for IPv6 Networks' (draft-ietf-opsec-v6-27.txt) as Informational RFC This document is the product of the Operational Security Capabilities for IP Network Infrastructure Working Group. The IESG contact persons are Warren Kumari and Robert Wilton. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ Technical Summary 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. Working Group Summary A number of members in the working group other than the authors expressed support and contributed providing positive feedback to the document and are all listed in the acknowledgement section. We have working group consensus to publish the document. Nobody is against publishing the document. Document Quality This document was originally last called in 2019. It had a vigorous discussion, and that authors have addressed ~200 comments since then. The document is now clear and easy to read. Personnel Gyan Mishra is the DS Warren Kumari is RAD! From nobody Wed May 26 06:46:29 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 959AF3A2F16; Wed, 26 May 2021 06:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, 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_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=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPfkNIKGfKV8; Wed, 26 May 2021 06:46:18 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00086.outbound.protection.outlook.com [40.107.0.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D637B3A2F11; Wed, 26 May 2021 06:46:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dJALiB05b4b5s2DiNMGywtOUvrc2/2VKrSKAkgAg0d+fJ75HpQXnyMDSGJOBMxapusLLUtj83xCWiAZmRD3/K419Jkr2lgzjsVdSnezGRR13HrQ/3GIew7kv/mWuvm9hiHTkb50vPJCFQFHRJzej9SYm8zUWLJAu5XxhRw9GQZFi9iM5k6499oocCAw9NqmYxxLtjoyN0+rqIVyMr6K+WZl1a90Zd1G1SzRwOHw7UEnFoS20VQzDJtElrz3PT01gO69Kq1KyBx2jNf+NXTG5FHs4Ng0oYhaPZt+EnAxWsiugU69a26MxykBckzwSXIytBRcYljBHOBAfiwH8rwjZ0g== 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=TLtEhXKbCUaNnuzd0guw3kmCo6zfaEdNp+Lgmtq05Vg=; b=VS+xp8YfolVc4MKWCG4xh9LH8PKiv28NtR/ahph4Vr7CfnhK/RAshoXd5YIjwzJQWXeRPruwcUCb5gQUd3afnHL7oIwgnfGdcGAESHPEKCHdINUVhqpbc2hoG9jfsFb8fuocajdyDl41M8WVckNYFGaOe0yYU9kTkKRmnAFer7quY5Euh5Bsazp2hpa4Wkpf49InNsygMCbCjS+S0cQkGyHrkzdKSTdeocQuJ+lV7njQZ65WSRMvyzcXrt9PoTf7jCmiiesyXbdCPDLpgoc21j3wbyv0LMe5+1qBc2kycOPu0GsrZkY/YlYMvb+eiMnPW4OTnqFKFW7iCnrzUwjRdw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TLtEhXKbCUaNnuzd0guw3kmCo6zfaEdNp+Lgmtq05Vg=; b=hNMKs85we27a2g93ZRrlxJnVKnuUU9zZa8ETMpZgq9ZhR2AlWNG6Y4zBHu6N5RSCDOrfyoOcP8HNpUznIXmBW3hF+jiCxmEG4X9BA326j1jcKvnmB0Z3Q/3BO6DHHSot6gETLLoFAgXpkNCXxqr7xk7UMCg/4xfwa2QoTBl2dnA= Received: from HE1PR07MB4187.eurprd07.prod.outlook.com (2603:10a6:7:98::23) by HE1PR07MB4235.eurprd07.prod.outlook.com (2603:10a6:7:95::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4150.11; Wed, 26 May 2021 13:46:09 +0000 Received: from HE1PR07MB4187.eurprd07.prod.outlook.com ([fe80::9009:1473:2b0:160d]) by HE1PR07MB4187.eurprd07.prod.outlook.com ([fe80::9009:1473:2b0:160d%7]) with mapi id 15.20.4173.021; Wed, 26 May 2021 13:46:09 +0000 From: Zaheduzzaman Sarker To: KK Chittimaneni CC: The IESG , "draft-ietf-opsec-v6@ietf.org" , "opsec-chairs@ietf.org" , "opsec@ietf.org" , Gyan Mishra Thread-Topic: Zaheduzzaman Sarker's No Objection on draft-ietf-opsec-v6-25: (with COMMENT) Thread-Index: AQHXK5mBuIMpbd9cP0a81K+ugeJMx6reg9gAgBexcQA= Date: Wed, 26 May 2021 13:46:08 +0000 Message-ID: <7855CBBF-A740-4575-AB4B-3B1FC107780E@ericsson.com> References: <161779162147.18816.9995103488367885739@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.49.21050901 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [85.238.211.27] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c12bfd24-5a9d-493b-f02d-08d9204c9e0d x-ms-traffictypediagnostic: HE1PR07MB4235: 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: wIfKAp8lUu7oZzzV+6aHQpbSrWzxxYHRAorms3LIue4V1jJuc9orYs7b+TPrOQaCgYoRQJ+jSYDTHhPdPD+2Y0Jg99jCKcV/VLyQ19WP+U8NgifRob25B4wvQRy1gKtYlT5JEHY6VuJPISGsvviAC9xAYjqg4h5DKKB1Cc5hWRQIENTQFi20ZRHb8K9MsHg3MN3+Qv33Y2WNoZJqUWkMyKC6Hx+VbRikYGPWsbeWYuHlnA1YzNhQ4EDZG3q8+0jyrZn/DYRj3IUY0BNyqgHVXmE2MWLuNqknSrRdpArYJ03GjQZ8iXj3Co+0gcikJvwN1xqD1PC7hV9YQzELMM5+BdhB2B8RwPob/3dSuH6nnqTagffBAC6HpJ+JmsCrY0VsB3ipf3VWN5KwWlEyu9PGdhWZj2h/kc88noLChcoWIkN7ULDmQmwoaZoJ6TO5KUiQ5pZGy+1SeL4VnYfFpXEepDJ1/LJbvk+POW0nWU3CyXBk+Tco0KzwAakYTWwiDxr+k2NS6GI9wSvDxl72kis4cDKagH4engr7M0T/m6FTv4tfotdz/VT2vQc7PBa6r3xjKb6x3ngeokyF9y56ysi+4EG4bde3ylv+wTvkmG7DeCtNSgx9E66TFCBbB2jTTfX4IK8kZcJMXat5guyjn7Vpv6lW4zDTyKCjTcDLKhSlvmPB+g0ZkBJ8U/WKXACqm2hl7LZFRBe5GsXyigauEBYRSaNDlIr08v5X5GOjR7+EF0yRvQ+mLzwd8RuG+VaOGVSmN2GBOwjfw6Klc7+8W4Ocjw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4187.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(376002)(366004)(39860400002)(346002)(122000001)(478600001)(76116006)(66946007)(38100700002)(4326008)(5660300002)(86362001)(6916009)(54906003)(2616005)(64756008)(66446008)(66556008)(66476007)(2906002)(966005)(6486002)(316002)(44832011)(21615005)(36756003)(71200400001)(8936002)(6506007)(8676002)(26005)(6512007)(186003)(33656002)(83380400001)(166002)(53546011)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?VUdmL3pTYXk0SGt5VDJWVG5LbWdOdjZwV1o5RzlURGl1WjlYNUlYRmRYYkdZ?= =?utf-8?B?SjlrWVExeGRMRm15MlZYdFlJbDZBNFpSRFQrWVlTQy9ydWpGNlJTc0o2MlV6?= =?utf-8?B?eUxweVJCcG80RFJveEtveGFReGl0Z2h1elpvMWtCQjJSWDhIUmpXM0tFYTgz?= =?utf-8?B?MlBmUC81MzJUeUtuYndVcy9ETytINEtmbmhvWHJTOHRTdjVKSy9tblRCcDYv?= =?utf-8?B?MGFsT3hycHB1MzI1V2gxMGVXc2tpK3FWdkhBSzA5MGhJT2NYUG5vRktVZVBi?= =?utf-8?B?RXYyR2VXN3hTNVFlMFljK2xCNm5odjMyZTVUUm4vcTYzaXBuaTRDeFNJQm9m?= =?utf-8?B?U1FpYnk4ZlBOMEZTUjR0NnIzWjZJbFRndHlCcG9SbUJYbWRwaWI0V3k3MTRj?= =?utf-8?B?amFNRGI2dEM2OG9qZzdSVFNiaXVwVWNGN2ozTkhtbFl3MDJtTVlTQVFBc3BX?= =?utf-8?B?U2srTEI0SDZxNVpRdDRmdXI3TTZqSWFUUW9wZGhBN3JmeGhHN010S0Z2SW5C?= =?utf-8?B?Z1lCTDFGMVA1VHg3ZklxZ2VHYlhTcThpSXp3QzNiQk05ZXlPTnArdmEzdXJU?= =?utf-8?B?Nm00L0Q4TmZBNjFGbXJSU2VnZ0dPTzlxaW91MVp2bVdUMTBYUkpHYUlia2Zw?= =?utf-8?B?dExCemdrMlluVElQNjd2cERVQzdxZk1IWHpiYURIamttelFOV1NaREsxQ1JU?= =?utf-8?B?ZElnc3hsSEJwTnh5UW8xRGhGZ1VPc2p5Vjl0MEVWUWI2V09DZG1rWEJYRFRX?= =?utf-8?B?cmNYQlVSbUg0STNDUDVVMk1LeDZJSTVvbzhRYkRnY294Tm5UUWRPL0o4Mkpp?= =?utf-8?B?UG1MWGtIelgzWm9pcHE1b051MmRXMG5pby92WnFtWEhmcTBtbjh5cGlYQ3VB?= =?utf-8?B?MXRHMjdaNDZFVlRLclR3cjJmcUtpQTQ1Yk5MS2tXOEsrUUJZa0hQSnB0NVFG?= =?utf-8?B?QWZwekt2SXI3RnJQQ1lQK085bVRxZWVVd3Y3SzdubXV5RFA3ejYrQm1RaGZp?= =?utf-8?B?alRRV3VtQ25yRHRMTXVWNUdFZzY0WEowcE13a3FUVm1ZVWZiMmpmVjNybkNs?= =?utf-8?B?TGVJK2ZaZk9wSkU2ZGdyK0RES2svbFM2K0FIRFprN2FXME91TGZRYUpRL0Vj?= =?utf-8?B?SzF0STNibEFBZlp2Z01BSjZyRUFkaFhhY1NYdldsNjJiYzUvdklDSEQxVURt?= =?utf-8?B?Z2hvZDVEZExMNVBkcU9xM1FXbFJmK010NVI0cU5jeFBia0FqYm05c2h6L1Vk?= =?utf-8?B?UFFFWXBUSGxUenZNbHVMUFhBSHhocnEvZ0hFbHBTc3p1c0tvZTBUSUdkVFRX?= =?utf-8?B?NjdsdEVWVnFmUVhVSG1zaW9WTG1LRUNUOTJRakNqR1pxbmxaN0lTd0xZMzY2?= =?utf-8?B?NmxCMzN2NmdDN1gxTUxta2pFY05PbjJ1RFBJMmFyNGpmWVNnUDByanhGU3NS?= =?utf-8?B?VlpBZXBDWW02ZGNHT2pMZElFOEt3Rm5jak51R2Z5Q21JbVdxdE53NytJRFc0?= =?utf-8?B?aGNidGtKUEVkSENrL1BhZFVTZlVrM2RQL0llUlB3bUJjSXRMVlNhbE9NVWZp?= =?utf-8?B?NjVnMW11NXdpbitaTGQvaVpmY3JCTThNSTVnM1p0ZTB1b3l6WjN4bmg1akt4?= =?utf-8?B?RlVRQndzODhrVkExaGdmZGEyT2ZaSGFlSFQwSTVObmpxR3MwWEt1VDZUeXQ5?= =?utf-8?B?bkpuK3BPdGpvV21nMWRpS2lZaHlkcjFmWnJFbVdCMjFLYk9XaUpSdjZpV1B2?= =?utf-8?Q?edLN57Nsag9g8DFYIjjYpdd3qEo4W+5s9OtdWpJ?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_7855CBBFA7404575AB4B3B1FC107780Eericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4187.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c12bfd24-5a9d-493b-f02d-08d9204c9e0d X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2021 13:46:08.9143 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mUlqooecYjprD4/D+pUcKvWLoYUy1iuruOIQzjOPkMFiVUMgeqMQEk/amR5qivVJBnhAM2LTfdmE6ioUtBLChSgFA9HHdVbLvgPhNbuh9kM3wpHrEW/jUNjntpG7tkl4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4235 Archived-At: Subject: Re: [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 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2021 13:46:23 -0000 --_000_7855CBBFA7404575AB4B3B1FC107780Eericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClNvcnJ5IGZvciB0aGUgbGF0ZSByZXNwb25zZSwgSSB3YXMgYXdheSBkdWUgdG8gc2lj a25lc3MuDQoNClRoYW5rcyBmb3IgYWRkcmVzc2luZyBteSBjb21tZW50cy4gSG93ZXZlciwgSSBz dGlsbCB0aGluayBpZiBzZWN0aW9uIDIuMy40IGlzIG5vdCBzcGVjaWZpYyB0byBjZXJ0YWluIGdl bmVyYXRpb24gb2YgM0dQUCBsaW5rL25ldHdvcmsgYXJjaGl0ZWN0dXJlIHRoZW4gaXQgaXMgYmV0 dGVyIHRvIGVpdGhlciB1c2UgcG9zc2libGUgZ2VuZXJpYyB0ZXJtaW5vbG9naWVzIG9yIGluY2x1 ZGUgNUcgdGVybWlub2xvZ2llcyAoYXMgaXQgaXMgb3V0IHRoZXJlKS4NCg0KQlINClphaGVkDQoN Ck9uIDIwMjEtMDUtMTEsIDE1OjU3LCAiS0sgQ2hpdHRpbWFuZW5pIiA8a2suY2hpdHRpbWFuZW5p QGdtYWlsLmNvbTxtYWlsdG86a2suY2hpdHRpbWFuZW5pQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpI ZWxsbyBaYWhlZCwNCg0KVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciBkZXRhaWxlZCByZXZp ZXcuDQoNClRvZ2V0aGVyIHdpdGggbXkgY28tYXV0aG9ycywgd2UgaGF2ZSB1cGxvYWRlZCByZXZp c2lvbiAtMjcsIHdoaWNoIHNob3VsZCBhZGRyZXNzIGFsbCB5b3VyIGNvbW1lbnRzLg0KDQpUaGUg ZGlmZiBpcyBhdDogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYt b3BzZWMtdjYtMjcNClJlZ2FyZHMsDQpLSw0KDQpPbiBXZWQsIEFwciA3LCAyMDIxIGF0IDM6MzMg QU0gWmFoZWR1enphbWFuIFNhcmtlciB2aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc8 bWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmc+PiB3cm90ZToNClphaGVkdXp6YW1hbiBTYXJrZXIgaGFz IGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQpkcmFmdC1pZXRmLW9w c2VjLXY2LTI1OiBObyBPYmplY3Rpb24NCg0KV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0 aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQplbWFpbCBhZGRyZXNzZXMg aW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcw0K aW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQoNCg0KUGxlYXNlIHJlZmVyIHRvIGh0 dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0K Zm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0 aW9ucy4NCg0KDQpUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9u cywgY2FuIGJlIGZvdW5kIGhlcmU6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLW9wc2VjLXY2Lw0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ09NTUVOVDoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCg0KSSBmb3VuZCB0aGlzIGRvY3VtZW50IHZlcnkgaW5mb3JtYXRpdmUgYW5kIEkg bGVhcm5lZCBxdWl0ZSBhIGxvdCBieSByZWFkaW5nDQp0aGlzIGRvY3VtZW50IChJIG11c3QgY29u ZmVzcyBJIGhhdmVuJ3QgIHJlYWQgdGhlIGxvbmcgbGlzdCBvZiAgcmVmZXJlbmNlZA0KZG9jdW1l bnRzIDotKSkuIEkgdGhpbmsgdGhlIGNvbGxlY3RlZCByZWNvbW1lbmRhdGlvbnMgaW4gb25lIHBs YWNlIHdpbGwgYmUgdmVyeQ0KaGVscGZ1bC4NCg0KU29tZSBjb21tZW50cyAtDQoNCiAgKiAgVGhl IGFic3RyYWN0IHNheXMgLSAiVGhlIHJlY29tbWVuZGF0aW9ucyBpbiB0aGlzIGRvY3VtZW50IGFy ZSBub3QNCiAgYXBwbGljYWJsZSB0byByZXNpZGVudGlhbCB1c2VyIGNhc2VzIi4gSG93ZXZlciwg bGF0ZXIgb24gaW4gc2VjdGlvbiAxLjEgaXQNCiAgc2F5cyAtICJUaGlzIGNvdmVycyBTZXJ2aWNl IFByb3ZpZGVyIChTUCksIGVudGVycHJpc2UgbmV0d29ya3MgYW5kIHNvbWUNCiAga25vd2xlZGdl YWJsZS1ob21lLXVzZXItbWFuYWdlZCByZXNpZGVudGlhbCBuZXR3b3JrLiIgRnVydGhlcm1vcmUg aW4gc2VjdGlvbg0KICA1LCBpdCByZWNvbW1lbmRzIGNvbmZpZ3VyYXRpb25zIGZvciByZXNpZGVu dGlhbCB1c2Vycy4gICAgTWF5IGJlIEkgYW0gbm90DQogIGdldHRpbmcgdGhlIGRpc3RpbmN0aW9u IGFtb25nIHJlc2lkZW50aWFsIHVzZXIgY2FzZXMsIG1hbmFnZWQgcmVzaWRlbnRpYWwNCiAgbmV0 d29yayBhbmQgcmVzaWRlbnRpYWwgdXNlcnMgY29ycmVjdCBidXQgSSB0aGluayBmdXJ0aGVyIGNs YXJpZmljYXRpb24gaXMNCiAgbmVlZGVkIG9uIHdoYXQgaXMgd3JpdHRlbiBpbiB0aGVlIGFic3Ry YWN0IGFuZCB3aGF0IGlzIGluIHRoZSByZXN0IG9mIHRoZQ0KICBkb2N1bWVudC4NCg0KICAqIEkg bm90ZWQgdGhhdCBzZWN0aW9uIDIuMy40IHJlZmVycyB0byAzR1BQIDRHIHRlcm1pbm9sb2dpZXMg d2hpbGUgZGVzY3JpYmluZw0KICB0aGUgY2FzZS4gSWYgdGhpcyBzZWN0aW9uIGlzIG5vdCBzdXBw b3NlZCB0byByZXN0cmljdGVkIHRvIGNlcnRhaW4NCiAgZ2VuZXJhdGlvbnMgb2YgM0dQUCB0ZWNo bm9sb2dpZXMgdGhlbiBJIHdvdWxkIHJlY29tbWVuZCB0byB1cGRhdGUgdGhlIHNlY3Rpb24NCiAg d2l0aCA1RyB0ZXJtaW5vbG9naWVzIGFzIHdlbGwuDQoNCiAgKiBJbiBzZWN0aW9uIDIuNiB0aGVy ZSBpcyBhbiBhc2sgZm9yIHRoZSBuZXR3b3JrIG9wZXJhdG9ycyB0byBsb2cgIm9mIGFsbA0KICBh cHBsaWNhdGlvbnMgdXNpbmcgdGhlIG5ldHdvcmsgKGluY2x1ZGluZyB1c2VyIHNwYWNlIGFuZCBr ZXJuZWwgc3BhY2UpIHdoZW4NCiAgYXZhaWxhYmxlIChmb3IgZXhhbXBsZSB3ZWIgc2VydmVycyki LiBIb3cgcmVhbGlzdGljIGlzIHRoaXM/IEkgaGFyZGx5IHNlZSB0aGUNCiAgd2ViIHNlcnZlcnMg c2hhcmluZyBsb2dnaW5nIGZpbGVzIHdpdGggbmV0d29yayBvcGVyYXRvcnMgKCBJIHdvdWxkIGJl IGhhcHB5DQogIHRvIGJlIGNvcnJlY3RlZCBoZXJlICkuIEkgYW0gYWxzbyBtaXNzaW5nIHRoZSBk aXNjdXNzaW9uIG9uIC0tIGlmIG5vdA0KICBhdmFpbGFibGUgaG93IG11Y2ggdGhpcyBhZmZlY3Rz IHRoZSBmb3JlbnNpYyByZXNlYXJjaCBpbiB0aGUgZXZlbnQgb2YNCiAgc2VjdXJpdHkgaW5jaWRl bnQgYW5kIGFibm9ybWFsIGJlaGF2aW9yLg0KDQoNCg== --_000_7855CBBFA7404575AB4B3B1FC107780Eericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <6FA5B1250F968643BF5AAE3D08C0176D@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4gXChCb2R5IENTXCkiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwNzBDMDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 ImVuLVNFIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHlsZT0id29yZC13cmFwOmJyZWFr LXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iY29sb3I6IzAwNzBDMDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJjb2xvcjojMDA3MEMwO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMDcwQzA7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPlNvcnJ5IGZvciB0aGUgbGF0ZSByZXNwb25zZSwgSSB3YXMgYXdheSBkdWUg dG8gc2lja25lc3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMDA3MEMwO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMDcwQzA7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPlRoYW5rcyBmb3IgYWRkcmVzc2luZyBteSBjb21tZW50cy4gSG93ZXZl ciwgSSBzdGlsbCB0aGluayBpZiBzZWN0aW9uIDIuMy40IGlzIG5vdCBzcGVjaWZpYyB0byBjZXJ0 YWluIGdlbmVyYXRpb24gb2YgM0dQUCBsaW5rL25ldHdvcmsgYXJjaGl0ZWN0dXJlIHRoZW4gaXQg aXMgYmV0dGVyIHRvDQogZWl0aGVyIHVzZSBwb3NzaWJsZSBnZW5lcmljIHRlcm1pbm9sb2dpZXMg b3IgaW5jbHVkZSA1RyB0ZXJtaW5vbG9naWVzIChhcyBpdCBpcyBvdXQgdGhlcmUpLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6IzAwNzBDMDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjojMDA3MEMwO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5CUjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6IzAwNzBDMDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+WmFo ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzAwNzBDMDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbiAyMDIxLTA1LTExLCAxNTo1NywgJnF1b3Q7S0sgQ2hp dHRpbWFuZW5pJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86a2suY2hpdHRpbWFuZW5pQGdtYWls LmNvbSI+a2suY2hpdHRpbWFuZW5pQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdp bi1yaWdodDowY207bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCkhl bGxvIFphaGVkLDxicj4NCjxicj4NClRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIgZGV0YWls ZWQgcmV2aWV3LiA8YnI+DQo8YnI+DQpUb2dldGhlciB3aXRoIG15IGNvLWF1dGhvcnMsIHdlIGhh dmUgdXBsb2FkZWQgcmV2aXNpb24gLTI3LCB3aGljaCBzaG91bGQgYWRkcmVzcyBhbGwgeW91ciBj b21tZW50cy48YnI+DQo8YnI+DQpUaGUgZGlmZiBpcyBhdDogPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtb3BzZWMtdjYtMjciIHRhcmdldD0iX2Js YW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW9wc2Vj LXY2LTI3PC9hPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5L SzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbiBX ZWQsIEFwciA3LCAyMDIxIGF0IDM6MzMgQU0gWmFoZWR1enphbWFuIFNhcmtlciB2aWEgRGF0YXRy YWNrZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpub3JlcGx5QGlldGYub3JnIj5ub3JlcGx5QGlldGYu b3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4t cmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjM2LjBwdCI+DQpaYWhl ZHV6emFtYW4gU2Fya2VyIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9u IGZvcjxicj4NCmRyYWZ0LWlldGYtb3BzZWMtdjYtMjU6IE5vIE9iamVjdGlvbjxicj4NCjxicj4N CldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5k IHJlcGx5IHRvIGFsbDxicj4NCmVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5k IENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzPGJyPg0KaW50cm9kdWN0b3J5IHBhcmFn cmFwaCwgaG93ZXZlci4pPGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIHJlZmVyIHRvIDxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRt bCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQv ZGlzY3Vzcy1jcml0ZXJpYS5odG1sPC9hPjxicj4NCmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0 IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuPGJyPg0KPGJyPg0KPGJyPg0KVGhl IGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3Vu ZCBoZXJlOjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtb3BzZWMtdjYvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vcHNlYy12Ni88L2E+PGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTxicj4NCkNPTU1FTlQ6PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCjxi cj4NCkkgZm91bmQgdGhpcyBkb2N1bWVudCB2ZXJ5IGluZm9ybWF0aXZlIGFuZCBJIGxlYXJuZWQg cXVpdGUgYSBsb3QgYnkgcmVhZGluZzxicj4NCnRoaXMgZG9jdW1lbnQgKEkgbXVzdCBjb25mZXNz IEkgaGF2ZW4ndCZuYnNwOyByZWFkIHRoZSBsb25nIGxpc3Qgb2YmbmJzcDsgcmVmZXJlbmNlZDxi cj4NCmRvY3VtZW50cyA6LSkpLiBJIHRoaW5rIHRoZSBjb2xsZWN0ZWQgcmVjb21tZW5kYXRpb25z IGluIG9uZSBwbGFjZSB3aWxsIGJlIHZlcnk8YnI+DQpoZWxwZnVsLjxicj4NCjxicj4NClNvbWUg Y29tbWVudHMgLTxicj4NCjxicj4NCiZuYnNwOyAqJm5ic3A7IFRoZSBhYnN0cmFjdCBzYXlzIC0g JnF1b3Q7VGhlIHJlY29tbWVuZGF0aW9ucyBpbiB0aGlzIGRvY3VtZW50IGFyZSBub3Q8YnI+DQom bmJzcDsgYXBwbGljYWJsZSB0byByZXNpZGVudGlhbCB1c2VyIGNhc2VzJnF1b3Q7LiBIb3dldmVy LCBsYXRlciBvbiBpbiBzZWN0aW9uIDEuMSBpdDxicj4NCiZuYnNwOyBzYXlzIC0gJnF1b3Q7VGhp cyBjb3ZlcnMgU2VydmljZSBQcm92aWRlciAoU1ApLCBlbnRlcnByaXNlIG5ldHdvcmtzIGFuZCBz b21lPGJyPg0KJm5ic3A7IGtub3dsZWRnZWFibGUtaG9tZS11c2VyLW1hbmFnZWQgcmVzaWRlbnRp YWwgbmV0d29yay4mcXVvdDsgRnVydGhlcm1vcmUgaW4gc2VjdGlvbjxicj4NCiZuYnNwOyA1LCBp dCByZWNvbW1lbmRzIGNvbmZpZ3VyYXRpb25zIGZvciByZXNpZGVudGlhbCB1c2Vycy4mbmJzcDsg Jm5ic3A7IE1heSBiZSBJIGFtIG5vdDxicj4NCiZuYnNwOyBnZXR0aW5nIHRoZSBkaXN0aW5jdGlv biBhbW9uZyByZXNpZGVudGlhbCB1c2VyIGNhc2VzLCBtYW5hZ2VkIHJlc2lkZW50aWFsPGJyPg0K Jm5ic3A7IG5ldHdvcmsgYW5kIHJlc2lkZW50aWFsIHVzZXJzIGNvcnJlY3QgYnV0IEkgdGhpbmsg ZnVydGhlciBjbGFyaWZpY2F0aW9uIGlzPGJyPg0KJm5ic3A7IG5lZWRlZCBvbiB3aGF0IGlzIHdy aXR0ZW4gaW4gdGhlZSBhYnN0cmFjdCBhbmQgd2hhdCBpcyBpbiB0aGUgcmVzdCBvZiB0aGU8YnI+ DQombmJzcDsgZG9jdW1lbnQuPGJyPg0KPGJyPg0KJm5ic3A7ICogSSBub3RlZCB0aGF0IHNlY3Rp b24gMi4zLjQgcmVmZXJzIHRvIDNHUFAgNEcgdGVybWlub2xvZ2llcyB3aGlsZSBkZXNjcmliaW5n PGJyPg0KJm5ic3A7IHRoZSBjYXNlLiBJZiB0aGlzIHNlY3Rpb24gaXMgbm90IHN1cHBvc2VkIHRv IHJlc3RyaWN0ZWQgdG8gY2VydGFpbjxicj4NCiZuYnNwOyBnZW5lcmF0aW9ucyBvZiAzR1BQIHRl Y2hub2xvZ2llcyB0aGVuIEkgd291bGQgcmVjb21tZW5kIHRvIHVwZGF0ZSB0aGUgc2VjdGlvbjxi cj4NCiZuYnNwOyB3aXRoIDVHIHRlcm1pbm9sb2dpZXMgYXMgd2VsbC48YnI+DQo8YnI+DQombmJz cDsgKiBJbiBzZWN0aW9uIDIuNiB0aGVyZSBpcyBhbiBhc2sgZm9yIHRoZSBuZXR3b3JrIG9wZXJh dG9ycyB0byBsb2cgJnF1b3Q7b2YgYWxsPGJyPg0KJm5ic3A7IGFwcGxpY2F0aW9ucyB1c2luZyB0 aGUgbmV0d29yayAoaW5jbHVkaW5nIHVzZXIgc3BhY2UgYW5kIGtlcm5lbCBzcGFjZSkgd2hlbjxi cj4NCiZuYnNwOyBhdmFpbGFibGUgKGZvciBleGFtcGxlIHdlYiBzZXJ2ZXJzKSZxdW90Oy4gSG93 IHJlYWxpc3RpYyBpcyB0aGlzPyBJIGhhcmRseSBzZWUgdGhlPGJyPg0KJm5ic3A7IHdlYiBzZXJ2 ZXJzIHNoYXJpbmcgbG9nZ2luZyBmaWxlcyB3aXRoIG5ldHdvcmsgb3BlcmF0b3JzICggSSB3b3Vs ZCBiZSBoYXBweTxicj4NCiZuYnNwOyB0byBiZSBjb3JyZWN0ZWQgaGVyZSApLiBJIGFtIGFsc28g bWlzc2luZyB0aGUgZGlzY3Vzc2lvbiBvbiAtLSBpZiBub3Q8YnI+DQombmJzcDsgYXZhaWxhYmxl IGhvdyBtdWNoIHRoaXMgYWZmZWN0cyB0aGUgZm9yZW5zaWMgcmVzZWFyY2ggaW4gdGhlIGV2ZW50 IG9mPGJyPg0KJm5ic3A7IHNlY3VyaXR5IGluY2lkZW50IGFuZCBhYm5vcm1hbCBiZWhhdmlvci48 YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7855CBBFA7404575AB4B3B1FC107780Eericssoncom_--