From nobody Sun Nov 3 13:56:46 2019 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 DED3912001E; Sun, 3 Nov 2019 13:56:44 -0800 (PST) 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: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: opsec@ietf.org Message-ID: <157281820483.13177.8617036261217670675@ietfa.amsl.com> Date: Sun, 03 Nov 2019 13:56:44 -0800 Archived-At: Subject: [OPSEC] I-D Action: draft-ietf-opsec-v6-21.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: Sun, 03 Nov 2019 21:56:45 -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 Chittimaneni Merike Kaeo Enno Rey Filename : draft-ietf-opsec-v6-21.txt Pages : 52 Date : 2019-11-03 Abstract: Knowledge and experience on how to operate IPv4 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 in several places of a network (enterprises, service providers and residential users) and proposes technical and procedural mitigations techniques. Some very specific places of a network such as the Internet of Things are not discussed in this document. 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-21 https://datatracker.ietf.org/doc/html/draft-ietf-opsec-v6-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-v6-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 4 06:26:10 2019 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 095A8120099; Mon, 4 Nov 2019 06:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMGF4HswFdSJ; Mon, 4 Nov 2019 06:26:01 -0800 (PST) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 0732E1200F4; Mon, 4 Nov 2019 06:26:01 -0800 (PST) Received: by mail-qk1-x72d.google.com with SMTP id m16so17391286qki.11; Mon, 04 Nov 2019 06:26:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YPf72nEfhMa/1xDcHGdBMhsRw/FzA4IHzmtZ58F62xc=; b=oOPHVUzO8/CvEgTE3k7bPsblsqiGT/UBF3hTOhyG79yq4bOaAf8iCQWsqUxjsErNPf 2rqFGvfVINoDlz99qrsC7IrEr6Wbe0aS94ykHFs+NokbKp5g8hgD58OD09Ddz8Vcik61 PYBdV896hI8BscUCykvg6nOSp/GDHty53CwqR9MXKgGxIO2xdBB1G+Xsr23Yq002S8k+ GGacw975C7a/Dj5Y4qYybQIDrmI3mVOv/zH8vi1vHq/cnCcAxNTPDEdb2ZGeNjBoSNcy 79kJP8/UerPZ32eoJpt8hj5u6pkRkEfPgIVioRkvX9OzEqsCAS+oiaf9RB5KDMn+4Ibf ObHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YPf72nEfhMa/1xDcHGdBMhsRw/FzA4IHzmtZ58F62xc=; b=d84NTlqyph3iK5iRtINIdl9d+pGWB46Xv2p1MDpceX7x1V0qsCD0tkdSJjFd/d0oMw 2KPkH2DioYTxcyiHURUnVTu6VFILwWf9kqdU5sUhB3Z4HeimNTeUAh8cJ5pGrNZ/HoXj 2FqNtR8kYnczHwiUXMsK+ukOloiOxqprYj/DLoOjQV9woK/rtzZhhWI8YUCGMQBzotqs ZX/EspaAWbGp8UZzC0y+XL7idEYPimffwmY5BFG1a1enfA/+EQ2rCI7IjtbLRZwJRHyh Zk+0ZPlHmtQAeCy5hABD764cHEsykK19ECaQ7KLOfJMW+g+XABcHL+6I3oGqYPlRWBjs YeUw== X-Gm-Message-State: APjAAAUd0itdORUk3zUYXuxZ2Pct+ZwXe/z+AFszkx5ASDD2JcS4g/kM sibBhvXeyNG8/FeqR5njX8baXZJd1j8= X-Google-Smtp-Source: APXvYqyPB9JmtSfVRt9CuPaMl//7ehkv7NTJHg0pmr5J1BK6g6AlqHbLdx9GQRBdN6yM0s+4PnadCQ== X-Received: by 2002:a37:94f:: with SMTP id 76mr9589151qkj.29.1572877559499; Mon, 04 Nov 2019 06:25:59 -0800 (PST) Received: from [192.168.1.213] (pool-72-83-194-140.washdc.fios.verizon.net. [72.83.194.140]) by smtp.gmail.com with ESMTPSA id a70sm5265381qkb.86.2019.11.04.06.25.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Nov 2019 06:25:58 -0800 (PST) From: Gyan Mishra X-Google-Original-From: Gyan Mishra Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (16G102) In-Reply-To: <157281820483.13177.8617036261217670675@ietfa.amsl.com> Date: Mon, 4 Nov 2019 09:25:58 -0500 Cc: i-d-announce@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <82AA0F9C-7836-464F-8F19-69FEDB197D53@gmail.com> References: <157281820483.13177.8617036261217670675@ietfa.amsl.com> To: opsec@ietf.org, evyncke@cisco.com Archived-At: Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-21.txt 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, 04 Nov 2019 14:26:03 -0000 Hi Eric=20 Just checking what the updates are that went in v21 since this document is n= ow ready to be published just pending my Shepard writeup which I plan to fin= ish this week. =20 Thank you=20 Gyan Sent from my iPhone > On Nov 3, 2019, at 4:56 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. > This draft is a work item of the Operational Security Capabilities for IP N= etwork Infrastructure WG of the IETF. >=20 > Title : Operational Security Considerations for IPv6 Netw= orks > Authors : Eric Vyncke > Kiran Kumar Chittimaneni > Merike Kaeo > Enno Rey > Filename : draft-ietf-opsec-v6-21.txt > Pages : 52 > Date : 2019-11-03 >=20 > Abstract: > Knowledge and experience on how to operate IPv4 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. >=20 > This document analyzes the operational security issues in several > places of a network (enterprises, service providers and residential > users) and proposes technical and procedural mitigations techniques. > Some very specific places of a network such as the Internet of Things > are not discussed in this document. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-opsec-v6-21 > https://datatracker.ietf.org/doc/html/draft-ietf-opsec-v6-21 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-v6-21 >=20 >=20 > Please note that it may take a couple of minutes from the time of submissi= on > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From nobody Mon Nov 4 06:38:18 2019 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 00080120891; Mon, 4 Nov 2019 06:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=mB9vVU/J; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=gSGS78C4 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 o5WnG8Lg1qYb; Mon, 4 Nov 2019 06:38:10 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F4701208BF; Mon, 4 Nov 2019 06:38:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4780; q=dns/txt; s=iport; t=1572878290; x=1574087890; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Cu+XwpumTqNK0+0RqrQtvO5cpyL33pAm6pSSJG69mUw=; b=mB9vVU/Jvf3TEw7AiUKfxdJRFGrdaNorNwN8ZCXv0cz4sfXYGRZ/kUa/ zTLxpXy9L8Yf8Lreqc9BsMdxbdqy079XQ2Dz8EZg6dMRlmdJPj/PGyrbx 6A4x840F8aG1o9A094SSTOeLARAPR5lbWr0UQ8f8d/CBKg/TIDZCzD0Zj 0=; IronPort-PHdr: =?us-ascii?q?9a23=3AumKYehUHBPSWUsH3yk2gxzYMO2PV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSA92J8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtank3AtVEX1xo13q6KkNSXs35Yg6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AeAADwNsBd/4sNJK1mGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBEQEBAQEBAQEBAQEBgWwBAQEBAQELAYFKJCwFbFggBAsqhCm?= =?us-ascii?q?DRgOKdYJeiVaOJ4JSA1QJAQEBDAEBGAsKAgEBhEACF4N3JDcGDgIDCwEBBAE?= =?us-ascii?q?BAQIBBQRthTcMhVEBAQEBAgEBARAREQwBASwLAQ8CAQgOCgICJgICAh8GCxU?= =?us-ascii?q?QAgQBDQUUDoMAAYJGAw4gAQ6mSAKBOIhgdYEygn4BAQWBOAIOQUCCQg0Lghc?= =?us-ascii?q?JgQ4oAYUWA4Z5GIFAP4E4H4JMPoIbRwEBAgEBFoFHF4J5MoIsj36dN0EKgiS?= =?us-ascii?q?HEYoVhBAbgjxyhmiLfYNSjkKILoIRjxgCBAIEBQIOAQEFgWgjgVhwFRohKgG?= =?us-ascii?q?CQQlHERSDBoNzhRSFP3SBKI1FAQE?= X-IronPort-AV: E=Sophos;i="5.68,267,1569283200"; d="scan'208";a="372488212" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Nov 2019 14:38:09 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id xA4Ec9s9005595 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Nov 2019 14:38:09 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 4 Nov 2019 08:38:08 -0600 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 4 Nov 2019 09:38:06 -0500 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 4 Nov 2019 09:38:06 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QihRaw3ZQUzg9rwLqY17S0bzTIZ/2+ipYhPWdxQD5Xh4PygGJPRwgghlDteHECuT28Y9igDRI1a62bXoNsaiVgvcJrBHXO07hDDLnd7jBvwsdRvmC00+D76tepRjYcxlvwrn+IkHGvEHLMOUxBHr/Ta5YyuWIqlg+xt1YUVqQqljWZt7l8IG5mAqVAnYDoyROc9YwzqyfaeWhRn/VUPce3FI3Ogy1gbVOEKWUKLNv+L7nDlUR2VNQsWrgLYlYuMAQcmi5oHYUCklrhick9W/9wWP2fUj/FwhI5mmlhRwzutYnk5fpEYjYQE/tO7hD/r3e7f8IdMgM4DgsiTaRMrkFg== 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=Cu+XwpumTqNK0+0RqrQtvO5cpyL33pAm6pSSJG69mUw=; b=ZcIbNE5QwUMBHzdIUrgdhQ+NBww+8tY5vaTAVLluBH+PLgVAlRbEZ8GVi9ASiPiwGc4cbaNKUUYyDHK9kRdrjOS6Peww1g+H7NqSwYl4RdMU0AorhUOffrUj+vXooUFTlTDy2mxU4k6VLDxfPPQRUtl9KlfHem9vLNwYP7SbRTTaT3iyCppbeFCiMJvw27+jfzILzJFH+uFRosylnBXq41OPhvygC9lr5D2EqrXq9Hx1uDnf13WkCm4CI/ExuAaLBm3EbALpb3toieaTPNY1d9wcQworkS4y0Yxwh0bU/9WIJfuDEmOupv58uMhM+HileBKIFMpYMfWuIBoszlgx2Q== 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=Cu+XwpumTqNK0+0RqrQtvO5cpyL33pAm6pSSJG69mUw=; b=gSGS78C4YPcGo0P2nOVlwwjgx9QeVT6oXILZYDAVkDhqc1vSGJx0KhJliAag8zc+OxQdBMsPqF0XuDzRcKoIFmDoawei53qyAy64AB1l8OSUH0lE9D83SBQieTPcDcwuW0EVqmBmjsvcuaH2X3Z01tMMwZ1XYD4ZqQ+get123fM= Received: from CY4PR11MB1752.namprd11.prod.outlook.com (10.175.59.14) by CY4PR11MB1911.namprd11.prod.outlook.com (10.175.63.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2408.24; Mon, 4 Nov 2019 14:38:05 +0000 Received: from CY4PR11MB1752.namprd11.prod.outlook.com ([fe80::65f4:880d:4ba0:2ae]) by CY4PR11MB1752.namprd11.prod.outlook.com ([fe80::65f4:880d:4ba0:2ae%10]) with mapi id 15.20.2408.024; Mon, 4 Nov 2019 14:38:05 +0000 From: "Eric Vyncke (evyncke)" To: Gyan Mishra , "opsec@ietf.org" CC: "i-d-announce@ietf.org" Thread-Topic: [OPSEC] I-D Action: draft-ietf-opsec-v6-21.txt Thread-Index: AQHVkxvTCwtKb9Pe4UuuiLsWFfIPgqd7JXoA Date: Mon, 4 Nov 2019 14:38:04 +0000 Message-ID: <1AAA80C6-080B-492D-ABC9-645B9CEFDC99@cisco.com> References: <157281820483.13177.8617036261217670675@ietfa.amsl.com> <82AA0F9C-7836-464F-8F19-69FEDB197D53@gmail.com> In-Reply-To: <82AA0F9C-7836-464F-8F19-69FEDB197D53@gmail.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:4d9d:496f:af35:27a3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2d23e5d5-c308-4518-a043-08d761349a42 x-ms-traffictypediagnostic: CY4PR11MB1911: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0211965D06 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(366004)(39860400002)(396003)(136003)(346002)(199004)(189003)(6246003)(36756003)(256004)(91956017)(14444005)(966005)(8936002)(4326008)(81166006)(81156014)(6116002)(6506007)(25786009)(58126008)(99286004)(110136005)(2501003)(2906002)(66574012)(71190400001)(71200400001)(66476007)(64756008)(76116006)(66446008)(66946007)(66556008)(5660300002)(33656002)(6306002)(86362001)(186003)(76176011)(14454004)(7736002)(305945005)(229853002)(476003)(2616005)(486006)(316002)(8676002)(478600001)(46003)(6436002)(11346002)(446003)(6486002)(6512007)(102836004)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR11MB1911; H:CY4PR11MB1752.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: c9Wf0TH8tvQBbGAAMBRl7/MaJMQXE+eLTQZ9EsyqKpxH1NGGeLebrVXeXJqaM+q+8xBEJH0dH8eRR0+cKLoqwFirL50aTq/vrA+p7yzRYXA4TGa2aBNoPvJ4RzF0GSQLcf8I1f9Z2jvA/kO069V+GA3UObE25TiAgHp/Mhl3F43ZHCA24N3aPjPOAyWlHWr2120ndC7DOiv8C9CZsyC/TUL9dZ9WZfvG24vJ0F6w3ZxFQvCqfTqZ9y09EvjoLtXawsgdofOab/UQazWM9LJty9HVIQ0Cm9vH6ZVnvEsc38Y5OqbzuM59/tF3DfujmFHO+04Egsemfn1v8bPWGyGXUGZZhGMLk9VZDaTSHqhacUge7f4W789qU6vYZ1WUt5g7xeSYI+Wm57qqsbs3dvl4EldM+rMO6/0g+B34rYDTXDETP98U3w1QhdCnW6uvZ2lmwiDR4GLsfZ1ziOS+IM+sZ17opvwBUFPhbofEkMFwTSA= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <6B3C3E7873854C44AEB24C6FC072533A@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2d23e5d5-c308-4518-a043-08d761349a42 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2019 14:38:04.8736 (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: tU2p6mfEjeiFH1PJsCV7Nkxop03iK3+cR6sbFMaBCRfbkabtlzOhxV6v5fBVzWR5hH/7IqmwdDc81QyaqEWySA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR11MB1911 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.20, xch-rcd-010.cisco.com X-Outbound-Node: alln-core-6.cisco.com Archived-At: Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-21.txt 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, 04 Nov 2019 14:38:16 -0000 SGVsbG8gR3lhbiwNCg0KVGhhbmsgeW91IGZvciByZW1pbmRpbmcgdGhlIGF1dGhvciB0byBwb3N0 IHRoZSAnZ2lzdCcgb2YgdGhlIGNoYW5nZXMgd2l0aCB2ZXJzaW9uIC0yMS4NCg0KT3VyIE9QUyBB RCwgV2FycmVuICJBY2UiIEt1bWFyaSwgIGhhcyBraW5kbHkgcmV2aWV3ZWQgb3VyIGRvY3VtZW50 IGFuZCBoYXMgaWRlbnRpZmllZCBtb3JlIHRoYW4gNzAgYXJlYXMgd2hlcmUgdGhlIHRleHQgd2Fz IGFtYmlndW91cyBvciB1c2luZyBiYWQgRW5nbGlzaC4uLiBObyB3b25kZXIsIG5vbmUgb2YgdGhl IDQgYXV0aG9ycyBhcmUgRW5nbGlzaC1zcGVha2luZyBuYXRpdmU6IGl0IGlzIGEgbWl4IG9mIEVz dG9uaWFuIChNZXJpa2Ugd2hvIGFsc28gc3BlYWtzIEdlcm1hbiBhbmQgUnVzc2lhblsxXSksIG9u ZSBvZiB0aGUgMjIgKD8pIGxhbmd1YWdlIG9mIEluZGlhIChLSyksIEdlcm1hbiAoRW5ubyB3aG8g YWxzbyBzcGVha3MgRnJlbmNoIGFuZCBTcGFuaXNoKSBhbmQgRnJlbmNoIChteXNlbGYgYWxzbyBz cGVha2luZyBEdXRjaCkgX18gX18gSUVURiBjb21tdW5pdHkgaXMgcmVhbGx5IGRpdmVyc2UgIQ0K DQpUaGFuayB5b3UgdmVyeSBtdWNoIGluIGFkdmFuY2UgZm9yIGZpbmFsaXppbmcgdGhlIHNoZXBo ZXJkIHdyaXRlLXVwDQoNCi3DqXJpYw0KDQpbMV0gSSBjYW4gYmUgd3JvbmcgZm9yIE1lcmlrZSBC VFcgYnV0IHNoZSBpcyBxdWFkcmktbGluZ3VhbA0KDQrvu79PbiAwNC8xMS8yMDE5LCAxNToyNiwg Ikd5YW4gTWlzaHJhIiA8aGF5YWJ1c2Fnc21AZ21haWwuY29tPiB3cm90ZToNCg0KICAgIEhpIEVy aWMgDQogICAgDQogICAgSnVzdCBjaGVja2luZyB3aGF0IHRoZSB1cGRhdGVzIGFyZSB0aGF0IHdl bnQgaW4gdjIxIHNpbmNlIHRoaXMgZG9jdW1lbnQgaXMgbm93IHJlYWR5IHRvIGJlIHB1Ymxpc2hl ZCBqdXN0IHBlbmRpbmcgbXkgU2hlcGFyZCB3cml0ZXVwIHdoaWNoIEkgcGxhbiB0byBmaW5pc2gg dGhpcyB3ZWVrLiAgDQogICAgDQogICAgVGhhbmsgeW91IA0KICAgIA0KICAgIEd5YW4NCiAgICAN CiAgICBTZW50IGZyb20gbXkgaVBob25lDQogICAgDQogICAgPiBPbiBOb3YgMywgMjAxOSwgYXQg NDo1NiBQTSwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOg0KICAgID4gDQogICAgPiAN CiAgICA+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5l IEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCiAgICA+IFRoaXMgZHJhZnQgaXMgYSB3b3Jr IGl0ZW0gb2YgdGhlIE9wZXJhdGlvbmFsIFNlY3VyaXR5IENhcGFiaWxpdGllcyBmb3IgSVAgTmV0 d29yayBJbmZyYXN0cnVjdHVyZSBXRyBvZiB0aGUgSUVURi4NCiAgICA+IA0KICAgID4gICAgICAg IFRpdGxlICAgICAgICAgICA6IE9wZXJhdGlvbmFsIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIGZv ciBJUHY2IE5ldHdvcmtzDQogICAgPiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogRXJpYyBWeW5j a2UNCiAgICA+ICAgICAgICAgICAgICAgICAgICAgICAgICBLaXJhbiBLdW1hciBDaGl0dGltYW5l bmkNCiAgICA+ICAgICAgICAgICAgICAgICAgICAgICAgICBNZXJpa2UgS2Flbw0KICAgID4gICAg ICAgICAgICAgICAgICAgICAgICAgIEVubm8gUmV5DQogICAgPiAgICBGaWxlbmFtZSAgICAgICAg OiBkcmFmdC1pZXRmLW9wc2VjLXY2LTIxLnR4dA0KICAgID4gICAgUGFnZXMgICAgICAgICAgIDog NTINCiAgICA+ICAgIERhdGUgICAgICAgICAgICA6IDIwMTktMTEtMDMNCiAgICA+IA0KICAgID4g QWJzdHJhY3Q6DQogICAgPiAgIEtub3dsZWRnZSBhbmQgZXhwZXJpZW5jZSBvbiBob3cgdG8gb3Bl cmF0ZSBJUHY0IHNlY3VyZWx5IGlzDQogICAgPiAgIGF2YWlsYWJsZTogd2hldGhlciBpdCBpcyB0 aGUgSW50ZXJuZXQgb3IgYW4gZW50ZXJwcmlzZSBpbnRlcm5hbA0KICAgID4gICBuZXR3b3JrLiAg SG93ZXZlciwgSVB2NiBwcmVzZW50cyBzb21lIG5ldyBzZWN1cml0eSBjaGFsbGVuZ2VzLiAgUkZD DQogICAgPiAgIDQ5NDIgZGVzY3JpYmVzIHRoZSBzZWN1cml0eSBpc3N1ZXMgaW4gdGhlIHByb3Rv Y29sIGJ1dCBuZXR3b3JrDQogICAgPiAgIG1hbmFnZXJzIGFsc28gbmVlZCBhIG1vcmUgcHJhY3Rp Y2FsLCBvcGVyYXRpb25zLW1pbmRlZCBkb2N1bWVudCB0bw0KICAgID4gICBlbnVtZXJhdGUgYWR2 YW50YWdlcyBhbmQvb3IgZGlzYWR2YW50YWdlcyBvZiBjZXJ0YWluIGNob2ljZXMuDQogICAgPiAN CiAgICA+ICAgVGhpcyBkb2N1bWVudCBhbmFseXplcyB0aGUgb3BlcmF0aW9uYWwgc2VjdXJpdHkg aXNzdWVzIGluIHNldmVyYWwNCiAgICA+ICAgcGxhY2VzIG9mIGEgbmV0d29yayAoZW50ZXJwcmlz ZXMsIHNlcnZpY2UgcHJvdmlkZXJzIGFuZCByZXNpZGVudGlhbA0KICAgID4gICB1c2VycykgYW5k IHByb3Bvc2VzIHRlY2huaWNhbCBhbmQgcHJvY2VkdXJhbCBtaXRpZ2F0aW9ucyB0ZWNobmlxdWVz Lg0KICAgID4gICBTb21lIHZlcnkgc3BlY2lmaWMgcGxhY2VzIG9mIGEgbmV0d29yayBzdWNoIGFz IHRoZSBJbnRlcm5ldCBvZiBUaGluZ3MNCiAgICA+ICAgYXJlIG5vdCBkaXNjdXNzZWQgaW4gdGhp cyBkb2N1bWVudC4NCiAgICA+IA0KICAgID4gDQogICAgPiBUaGUgSUVURiBkYXRhdHJhY2tlciBz dGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCiAgICA+IGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb3BzZWMtdjYvDQogICAgPiANCiAgICA+IFRoZXJlIGFy ZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCiAgICA+IGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9wc2VjLXY2LTIxDQogICAgPiBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtb3BzZWMtdjYtMjENCiAgICA+ IA0KICAgID4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0 Og0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtb3Bz ZWMtdjYtMjENCiAgICA+IA0KICAgID4gDQogICAgPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQogICAg PiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRv b2xzLmlldGYub3JnLg0KICAgID4gDQogICAgPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZh aWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQogICAgPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzLw0KICAgID4gDQogICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KICAgID4gT1BTRUMgbWFpbGluZyBsaXN0DQogICAgPiBPUFNF Q0BpZXRmLm9yZw0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v cHNlYw0KICAgIA0KDQo= From nobody Fri Nov 8 23:28:06 2019 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 7AA42120851; Fri, 8 Nov 2019 23:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqeZEcd7LyVQ; Fri, 8 Nov 2019 23:28:00 -0800 (PST) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 B2C8012084C; Fri, 8 Nov 2019 23:28:00 -0800 (PST) Received: by mail-il1-x134.google.com with SMTP id z12so7214836ilp.2; Fri, 08 Nov 2019 23:28:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sIJQHeFFjCn7SqMu+mUMP/f9CPCQ2cng225o66wnQIA=; b=u3bmgWb7mxkq/B4WyR5of2oV31scmso0IIm7fZcppD7lFVK+P/Ytvf/6NjJinbzAcv pgdVb4sBpUNOwzhfZa24pqHl4k7gtGS1aVGw/rUp643NzLsqlBSYnp0jH+n/m4MRv1qJ p4pki2k/Dz/aJtUtUH2ul9nf1no+4OZ62+hbb+nrokKgPXvaZrqpUUc2cjg+6R1MBRhW qZojvR8+oXCfyTdGZlsnlI+Tgvp57YAayjCw9jy82hA6MVBQnspxENvwL8Zcb2NCZ+KZ nBizUT+TxUb7SQX/BqKEqvQ9dnLv3a/893WozHiRwEl5abjBqStLHmljC8SNIswRLD8X q8aw== 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=sIJQHeFFjCn7SqMu+mUMP/f9CPCQ2cng225o66wnQIA=; b=JnK8oLFFa7Rb50qL5DyH3HL2wI5hFfStyKWQikce9SVF2dbAVnPDtSTnwbScZVsEtm XfURQazlWpcsUIolKOQRiYlEUUAJgz5+36iAN4aXugkuTxV9PmRKay06qpBpWHr901HG ZPdlbXBxRUlOd8sJ7omAH2sAVOpOf+cgimyaCB05o6YP54HgkInEdiIeVepD6S2rBfMi ljfYHtsroB61H7nblJ2K6rYaPuRER+ter5z5r9evcseFv4VvVKzecYTylrq91fncAySu v+CmX2LZn3h1NVPq0F40thYstQYBLjnIAdtw4Xw8lqH7oqDUqW6h6Juag2/cc1ag3WM8 zN1w== X-Gm-Message-State: APjAAAVNS5ZKaJ9SpWL5RTXD1TG4ElBk6DPhdC0E2fd/vsgIMdvZo3et 6UpOfSaf9KeiWrgn800OazyetyGvlJMlU2+ojNs= X-Google-Smtp-Source: APXvYqyt3B0AyPSf0WZI3ORbUIqjFWVgtEGBq7FlNd9BclpRwmQyMNrdDwzoklHLE3TdSp/69tZgwxxC2039qLzbcSQ= X-Received: by 2002:a92:7e18:: with SMTP id z24mr17500775ilc.276.1573284479662; Fri, 08 Nov 2019 23:27:59 -0800 (PST) MIME-Version: 1.0 References: <157281820483.13177.8617036261217670675@ietfa.amsl.com> <82AA0F9C-7836-464F-8F19-69FEDB197D53@gmail.com> <1AAA80C6-080B-492D-ABC9-645B9CEFDC99@cisco.com> In-Reply-To: <1AAA80C6-080B-492D-ABC9-645B9CEFDC99@cisco.com> From: Gyan Mishra Date: Sat, 9 Nov 2019 02:27:29 -0500 Message-ID: To: "Eric Vyncke (evyncke)" Cc: "opsec@ietf.org" , "i-d-announce@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008a7f590596e4d63b" Archived-At: Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-21.txt 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, 09 Nov 2019 07:28:04 -0000 --0000000000008a7f590596e4d63b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Eric I submitted the shepherd write-up. I ran the idnits and it found the following obsolete references. We should clear that up before we publish it. I can update my comments on that once the draft is updated. Checking references for intended status: Informational -------------------------------------------------------------------------= --- -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3068 (Obsoleted by RFC 7526) -- Obsolete informational reference (is this intentional?): RFC 3627 (Obsoleted by RFC 6547) Thank you Gyan On Mon, Nov 4, 2019 at 9:38 AM Eric Vyncke (evyncke) wrote: > Hello Gyan, > > Thank you for reminding the author to post the 'gist' of the changes with > version -21. > > Our OPS AD, Warren "Ace" Kumari, has kindly reviewed our document and ha= s > identified more than 70 areas where the text was ambiguous or using bad > English... No wonder, none of the 4 authors are English-speaking native: = it > is a mix of Estonian (Merike who also speaks German and Russian[1]), one = of > the 22 (?) language of India (KK), German (Enno who also speaks French an= d > Spanish) and French (myself also speaking Dutch) __ __ IETF community is > really diverse ! > > Thank you very much in advance for finalizing the shepherd write-up > > -=C3=A9ric > > [1] I can be wrong for Merike BTW but she is quadri-lingual > > =EF=BB=BFOn 04/11/2019, 15:26, "Gyan Mishra" wrot= e: > > Hi Eric > > Just checking what the updates are that went in v21 since this > document is now ready to be published just pending my Shepard writeup whi= ch > I plan to finish this week. > > Thank you > > Gyan > > Sent from my iPhone > > > On Nov 3, 2019, at 4:56 PM, internet-drafts@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Operational Security Capabilities > for IP Network Infrastructure WG of the IETF. > > > > Title : Operational Security Considerations for > IPv6 Networks > > Authors : Eric Vyncke > > Kiran Kumar Chittimaneni > > Merike Kaeo > > Enno Rey > > Filename : draft-ietf-opsec-v6-21.txt > > Pages : 52 > > Date : 2019-11-03 > > > > Abstract: > > Knowledge and experience on how to operate IPv4 securely is > > available: whether it is the Internet or an enterprise internal > > network. However, IPv6 presents some new security challenges. R= FC > > 4942 describes the security issues in the protocol but network > > managers also need a more practical, operations-minded document t= o > > enumerate advantages and/or disadvantages of certain choices. > > > > This document analyzes the operational security issues in several > > places of a network (enterprises, service providers and residenti= al > > users) and proposes technical and procedural mitigations > techniques. > > Some very specific places of a network such as the Internet of > Things > > are not discussed in this document. > > > > > > 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-21 > > https://datatracker.ietf.org/doc/html/draft-ietf-opsec-v6-21 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-v6-21 > > > > > > 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/ > > > > _______________________________________________ > > OPSEC mailing list > > OPSEC@ietf.org > > https://www.ietf.org/mailman/listinfo/opsec > > > --=20 Gyan S. Mishra IT Network Engineering & Technology Verizon Communications Inc. (VZ) 13101 Columbia Pike FDC1 3rd Floor Silver Spring, MD 20904 United States Phone: 301 502-1347 Email: gyan.s.mishra@verizon.com www.linkedin.com/in/networking-technologies-consultant --0000000000008a7f590596e4d63b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Eric

I submitted the shepherd write-up.= =C2=A0=C2=A0

I ran the idnits and it found the fol= lowing obsolete references.=C2=A0 We should clear that up before we publish= it.=C2=A0 I can update my comments on that once the draft is updated.=C2= =A0
Checking=
 references for intended status: Informational
  -------------------------------------------------------------------------=
---

  -- Obsolete informational reference (is this intentional?): RFC 2460
     (Obsoleted by RFC 8200)

  -- Obsolete informational reference (is this intentional?): RFC 3068
     (Obsoleted by RFC 7526)

  -- Obsolete informational reference (is this intentional?): RFC 3627
     (Obsoleted by RFC 6547)

=
Thank you

Gyan

On = Mon, Nov 4, 2019 at 9:38 AM Eric Vyncke (evyncke) <evyncke@cisco.com> wrote:
Hello Gyan,

Thank you for reminding the author to post the 'gist' of the change= s with version -21.

Our OPS AD, Warren "Ace" Kumari,=C2=A0 has kindly reviewed our do= cument and has identified more than 70 areas where the text was ambiguous o= r using bad English... No wonder, none of the 4 authors are English-speakin= g native: it is a mix of Estonian (Merike who also speaks German and Russia= n[1]), one of the 22 (?) language of India (KK), German (Enno who also spea= ks French and Spanish) and French (myself also speaking Dutch) __ __ IETF c= ommunity is really diverse !

Thank you very much in advance for finalizing the shepherd write-up

-=C3=A9ric

[1] I can be wrong for Merike BTW but she is quadri-lingual

=EF=BB=BFOn 04/11/2019, 15:26, "Gyan Mishra" <hayabusagsm@gmail.com> wr= ote:

=C2=A0 =C2=A0 Hi Eric

=C2=A0 =C2=A0 Just checking what the updates are that went in v21 since thi= s document is now ready to be published just pending my Shepard writeup whi= ch I plan to finish this week.=C2=A0

=C2=A0 =C2=A0 Thank you

=C2=A0 =C2=A0 Gyan

=C2=A0 =C2=A0 Sent from my iPhone

=C2=A0 =C2=A0 > On Nov 3, 2019, at 4:56 PM, internet-drafts@ietf.org wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > A New Internet-Draft is available from the on-line Inter= net-Drafts directories.
=C2=A0 =C2=A0 > This draft is a work item of the Operational Security Ca= pabilities for IP Network Infrastructure WG of the IETF.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0: Operational Security Considerations for IPv6 Networks =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: Eric Vyncke
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Kiran Kumar Chittimaneni
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Merike Kaeo
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Enno Rey
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft= -ietf-opsec-v6-21.txt
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 52
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2019-11-03
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Abstract:
=C2=A0 =C2=A0 >=C2=A0 =C2=A0Knowledge and experience on how to operate I= Pv4 securely is
=C2=A0 =C2=A0 >=C2=A0 =C2=A0available: whether it is the Internet or an = enterprise internal
=C2=A0 =C2=A0 >=C2=A0 =C2=A0network.=C2=A0 However, IPv6 presents some n= ew security challenges.=C2=A0 RFC
=C2=A0 =C2=A0 >=C2=A0 =C2=A04942 describes the security issues in the pr= otocol but network
=C2=A0 =C2=A0 >=C2=A0 =C2=A0managers also need a more practical, operati= ons-minded document to
=C2=A0 =C2=A0 >=C2=A0 =C2=A0enumerate advantages and/or disadvantages of= certain choices.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0This document analyzes the operational secur= ity issues in several
=C2=A0 =C2=A0 >=C2=A0 =C2=A0places of a network (enterprises, service pr= oviders and residential
=C2=A0 =C2=A0 >=C2=A0 =C2=A0users) and proposes technical and procedural= mitigations techniques.
=C2=A0 =C2=A0 >=C2=A0 =C2=A0Some very specific places of a network such = as the Internet of Things
=C2=A0 =C2=A0 >=C2=A0 =C2=A0are not discussed in this document.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > The IETF datatracker status page for this draft is:
=C2=A0 =C2=A0 > https://datatracker.ietf.org= /doc/draft-ietf-opsec-v6/
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > There are also htmlized versions available at:
=C2=A0 =C2=A0 > https://tools.ietf.org/html/dra= ft-ietf-opsec-v6-21
=C2=A0 =C2=A0 > https://datatracker.i= etf.org/doc/html/draft-ietf-opsec-v6-21
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > A diff from the previous version is available at:
=C2=A0 =C2=A0 > https://www.ietf.org/rf= cdiff?url2=3Ddraft-ietf-opsec-v6-21
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Please note that it may take a couple of minutes from th= e time of submission
=C2=A0 =C2=A0 > until the htmlized version and diff are available at tools.i= etf.org.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Internet-Drafts are also available by anonymous FTP at:<= br> =C2=A0 =C2=A0 > ftp://ftp.ietf.org/internet-drafts/
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > _______________________________________________
=C2=A0 =C2=A0 > OPSEC mailing list
=C2=A0 =C2=A0 > OPSE= C@ietf.org
=C2=A0 =C2=A0 > https://www.ietf.org/mailman/listinfo/= opsec




--

Gyan S. Mishra

IT Network Engin= eering & Technology=C2=A0=

Verizon Communications=C2=A0Inc. (VZ)=

13101 Columbia Pike FDC1 3rd Floor

=

Silver Spring, MD 20904

United States<= span style=3D"color:rgb(80,0,80);background-image:initial;background-positi= on:initial;background-repeat:initial">

Phone:=C2=A0301 502-1347

Email:=C2=A0gyan.s.mishra@verizon.= com

www.linkedin.com/in/networking-technologies-co= nsultant


--0000000000008a7f590596e4d63b-- From nobody Fri Nov 8 23:57:34 2019 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 1DCE812085B for ; Fri, 8 Nov 2019 23:57:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=PO0trSJU; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=DAerssDw 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 TPoo7qhF_EVa for ; Fri, 8 Nov 2019 23:57:30 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5163912000F for ; Fri, 8 Nov 2019 23:57:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28537; q=dns/txt; s=iport; t=1573286250; x=1574495850; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6FsfoFNVCahWRuETsr6a983ewj2zI1LjYehXlXr84/4=; b=PO0trSJUUH6DuXPYJ2b4+5KnN/TaUkwj3Yt6L922u4zXs6KKlKchFwQE mahL3HP/Yb37MFsFscyitoHaA1okosuKHX59Jc5o93HaylrN7g9CTKvPt d2Slo2qt4YaEu5uFKXHAUBUkefJotNvOYevJ92Zzf1zVbdD7F+CEsJ1kK Y=; IronPort-PHdr: =?us-ascii?q?9a23=3AvxxopR23Hl6h4QiZsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKHt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQBFPqKvXpYgQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AmAABlcMZd/5NdJa1hAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAREBAQEBAQEBAQEBAYFtAQEBAQEBCwGBGy8kLAVsWCAECyq?= =?us-ascii?q?EKYNGA4prgjkliVaOKIFCgRADVAkBAQEMAQEYAQoKAgEBhEACF4N5JDcGDgI?= =?us-ascii?q?DCwEBBAEBAQIBBQRthTcMhVEBAQEBAgEBARARHQEBByULAQQJAgIBCA4DAwE?= =?us-ascii?q?CAScDAgICGQYGCxQJCAIEDgUUDoMAAYF5TQMOIAEOonsCgTiIYHWBMoJ+AQE?= =?us-ascii?q?FgTgCDkFAgkINC4IXCQWBMQGFFgOGehiBQD+BOAwTgkw+ghtHAQECAQEWgRQ?= =?us-ascii?q?BEgElEQkBDAkICYJJMoIsjSSCZ4VDmARBCoIlhxeKG4QSG4I9coZvjAWDVJA?= =?us-ascii?q?IhnSCEo8rAgQCBAUCDgEBBYE/KSNncXAVGiEqAYJBCUcRFJA2g3OFFIU/dAE?= =?us-ascii?q?wd40FgjEBAQ?= X-IronPort-AV: E=Sophos;i="5.68,283,1569283200"; d="scan'208,217";a="376201897" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Nov 2019 07:57:29 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id xA97vTeM014609 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 9 Nov 2019 07:57:29 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 9 Nov 2019 01:57:28 -0600 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 9 Nov 2019 01:57:28 -0600 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sat, 9 Nov 2019 01:57:28 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AN2QK9h5Ca40GJRh9D8VcV/xN1rOCzAsAihW0XbutyFPrsveTKJCVci5y3d/Wf0vBjJwPRtT2BRyPvWa4fr2vENiBLGXvb0rmwPcKQSexU1f/bqOcjUq+NwagKdQiQUSKUSwjX7SUKeFURofAYDC9p5k52q73dPMhAEKYQpvWNMy6XCryYHmfK7/+jl1b97kFHWGRDJjgrBzT6+XhEvJw7TnK/NNivEpsb0KSp6MMcfdNBXgNek1JVYw8NGKqMmzxG0HFzrXcO7A/AZFoR1MkVCKhjuhJQGDHcvPpE9aFHo3Bv5nzm/PgKg7X3xxrRHDJXXu+v3ZNVxcCnHhJ9SJvw== 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=6FsfoFNVCahWRuETsr6a983ewj2zI1LjYehXlXr84/4=; b=ZzcvgCQiyEjHmQy07ASe3Qst4Hsx4IWCNoFiirZEwaGPhDFgGV4d3wNyX8KXWIys2TQFcDIQqSJPJgsrBY6C+kXL6L1EFwv2sPETR4lwX51zwATaL+CbsexToiDoBctCm3q7LKiIYoMQFBicRQDDdQNHoqkh69l5tgisVURG9/kSnJRTO4L9+YuYQZbwDqK/L3rbw5l+AjihZNoUGWsLzXhAfSxDuTHeSQEnp32wnqdDaGGPYI2r2ynfLmGG7l3ZEYAh+vupfpzNTeqoYDCTHi8qHST1OHITWUMs3eRkOv6IHEVlb69rniyoa19izif6Ah42j12qdQ94OQWnxtbb1w== 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=6FsfoFNVCahWRuETsr6a983ewj2zI1LjYehXlXr84/4=; b=DAerssDwSt5rfFULza3hCpF9aG9jrtskTapzCrKp6wmLuk03ODQocD9L9C01rQf7E67nrOz17bkh7WqbqPsood+2ErhQvrqlkQPs5cmsr/Xe8VzV2phxlmpFYcmmsi9EyhJRBTd5fSQFEcCeoMKsy5M9OrC3MZ3ykh40UNo0b8Y= Received: from DM5PR11MB1753.namprd11.prod.outlook.com (10.175.88.141) by DM5PR11MB1628.namprd11.prod.outlook.com (10.172.38.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.20; Sat, 9 Nov 2019 07:57:26 +0000 Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::c1f1:d33a:2203:5a39]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::c1f1:d33a:2203:5a39%7]) with mapi id 15.20.2430.023; Sat, 9 Nov 2019 07:57:26 +0000 From: "Eric Vyncke (evyncke)" To: Gyan Mishra CC: "opsec@ietf.org" Thread-Topic: [OPSEC] I-D Action: draft-ietf-opsec-v6-21.txt Thread-Index: AQHVkxvTCwtKb9Pe4UuuiLsWFfIPgqd7JXoAgAdSl4CAABkggA== Date: Sat, 9 Nov 2019 07:57:26 +0000 Message-ID: <3BB16B9C-9065-466B-9A9A-51C5D314E126@cisco.com> References: <157281820483.13177.8617036261217670675@ietfa.amsl.com> <82AA0F9C-7836-464F-8F19-69FEDB197D53@gmail.com> <1AAA80C6-080B-492D-ABC9-645B9CEFDC99@cisco.com> In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:19c1:42a4:4110:be79] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e0d4b19c-86f3-423a-56d2-08d764ea7612 x-ms-traffictypediagnostic: DM5PR11MB1628: x-ms-exchange-purlcount: 7 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 021670B4D2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(376002)(366004)(136003)(346002)(199004)(189003)(53546011)(76176011)(81166006)(45080400002)(102836004)(486006)(76116006)(6512007)(476003)(58126008)(1411001)(236005)(81156014)(6246003)(6116002)(316002)(6506007)(4326008)(36756003)(33656002)(14454004)(46003)(229853002)(99286004)(71200400001)(186003)(6436002)(256004)(66574012)(66446008)(446003)(5660300002)(66556008)(11346002)(6486002)(86362001)(25786009)(2906002)(64756008)(8676002)(14444005)(8936002)(6916009)(6306002)(966005)(91956017)(7736002)(54896002)(606006)(2616005)(71190400001)(66946007)(66476007)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1628; H:DM5PR11MB1753.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: UT0ISF/uigNOi87PkTODLhTo8iM9CsbDoB5MBwEI3AI1loWQ7837BhLlCehc1jgihTYQyMGzxwxoz62eUUjfOrBivi/oS6CwvhlSL/AJQ80OGTwaGcQyAiJ4XZXx3AVRr1SeRdV3FM3Fv8brHGCQZDqFDG6F6YneKpz/O96QK/ZpdM5znQd+DDtUyQGvRBg+yGCkIlOwleqHFy2q0OX/lkNU9ED2ssOvadMe8kEsdiGyeOjGgTjHoyXZC/dY3VqjUkgX3qGJAsDY97XH/SLyLiC8Clgbp2Ti1jwuKf/emwcck4HhUOh1xE1OdbOBzcwiy6Oi7sb++tSjn6eOJFk3tOJFvGvd2wod8lWc3ii3aRP5BBMQ1rcOUt6ht8zrxzAedznbcNyrEHNorOAUUKhnFbTyCwsSqo+vlEJeFs55K9Pw6cnD7tjRSBg/pb5cYvySzZV1Ezfg30qdXm3G9afmLc/jd1H7Wcq3cTxfK9BPQ4w= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_3BB16B9C9065466B9A9A51C5D314E126ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e0d4b19c-86f3-423a-56d2-08d764ea7612 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2019 07:57:26.1712 (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: /IPoMOTDyZBZEI9VcoXjvsI2AO9OMVuJ13F+9RZ3F+e7b4v52wZH+ht13JrMAMiR+WfuwC6JpLYn/XR11TTTLg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1628 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-21.txt 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, 09 Nov 2019 07:57:33 -0000 --_000_3BB16B9C9065466B9A9A51C5D314E126ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R3lhbg0KDQpUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB5b3VyIHNoZXBoZXJkIHdyaXRlLXVwLCB2 ZXJ5IG11Y2ggYXBwcmVjaWF0ZWQgYnkgdGhlIGF1dGhvcnMuDQoNClRoZSBsaXN0IG9mIHRoZSDi gJhvYnNvbGV0ZWTigJkgcmVmZXJlbmNlcyBpcyBpbnRlbnRpb25hbCBpbmRlZWQgdG8gZW5zdXJl IHRoYXQgcmVhZGVycyB1bmRlcnN0YW5kIHRoYXQg4oCYb2xk4oCZIGRvY3VtZW50cyBoYXZlIGJl ZW4gcmVwbGFjZWQuIFRoZSB0ZXh0IGluIHRoZSBkb2N1bWVudCBpcyBjbGVhciBhYm91dCB0aGUg b2Jzb2xldGUgYW5kIGN1cnJlbnQgZG9jdW1lbnQuIFNvLCB3ZSBkbyBwcmVmZXIgdG8gbGVhdmUg dGhlIHJlZmVyZW5jZXMgbGlrZSB0aGV5IGFyZSBhcyB3ZSBiZWxpZXZlIHRoYXQgdGhleSBtYWtl IHRoZSBkb2N1bWVudCBtb3JlIHZhbHVhYmxlIGZvciB0aGUgcmVhZGVyLg0KDQpSZWdhcmRzDQoN Ci3DqXJpYw0KDQpGcm9tOiBHeWFuIE1pc2hyYSA8aGF5YWJ1c2Fnc21AZ21haWwuY29tPg0KRGF0 ZTogU2F0dXJkYXksIDkgTm92ZW1iZXIgMjAxOSBhdCAwODoyOA0KVG86IEVyaWMgVnluY2tlIDxl dnluY2tlQGNpc2NvLmNvbT4NCkNjOiAib3BzZWNAaWV0Zi5vcmciIDxvcHNlY0BpZXRmLm9yZz4s ICJpLWQtYW5ub3VuY2VAaWV0Zi5vcmciIDxpLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW09QU0VDXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW9wc2VjLXY2LTIxLnR4dA0KDQpF cmljDQoNCkkgc3VibWl0dGVkIHRoZSBzaGVwaGVyZCB3cml0ZS11cC4NCg0KSSByYW4gdGhlIGlk bml0cyBhbmQgaXQgZm91bmQgdGhlIGZvbGxvd2luZyBvYnNvbGV0ZSByZWZlcmVuY2VzLiAgV2Ug c2hvdWxkIGNsZWFyIHRoYXQgdXAgYmVmb3JlIHdlIHB1Ymxpc2ggaXQuICBJIGNhbiB1cGRhdGUg bXkgY29tbWVudHMgb24gdGhhdCBvbmNlIHRoZSBkcmFmdCBpcyB1cGRhdGVkLg0KDQpDaGVja2lu ZyByZWZlcmVuY2VzIGZvciBpbnRlbmRlZCBzdGF0dXM6IEluZm9ybWF0aW9uYWwNCg0KICAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQoNCg0KDQogIC0tIE9ic29sZXRlIGluZm9ybWF0aW9uYWwgcmVmZXJl bmNlIChpcyB0aGlzIGludGVudGlvbmFsPyk6IFJGQyAyNDYwDQoNCiAgICAgKE9ic29sZXRlZCBi eSBSRkMgODIwMCkNCg0KDQoNCiAgLS0gT2Jzb2xldGUgaW5mb3JtYXRpb25hbCByZWZlcmVuY2Ug KGlzIHRoaXMgaW50ZW50aW9uYWw/KTogUkZDIDMwNjgNCg0KICAgICAoT2Jzb2xldGVkIGJ5IFJG QyA3NTI2KQ0KDQoNCg0KICAtLSBPYnNvbGV0ZSBpbmZvcm1hdGlvbmFsIHJlZmVyZW5jZSAoaXMg dGhpcyBpbnRlbnRpb25hbD8pOiBSRkMgMzYyNw0KDQogICAgIChPYnNvbGV0ZWQgYnkgUkZDIDY1 NDcpDQoNCg0KDQpUaGFuayB5b3UNCg0KDQoNCkd5YW4NCg0KT24gTW9uLCBOb3YgNCwgMjAxOSBh dCA5OjM4IEFNIEVyaWMgVnluY2tlIChldnluY2tlKSA8ZXZ5bmNrZUBjaXNjby5jb208bWFpbHRv OmV2eW5ja2VAY2lzY28uY29tPj4gd3JvdGU6DQpIZWxsbyBHeWFuLA0KDQpUaGFuayB5b3UgZm9y IHJlbWluZGluZyB0aGUgYXV0aG9yIHRvIHBvc3QgdGhlICdnaXN0JyBvZiB0aGUgY2hhbmdlcyB3 aXRoIHZlcnNpb24gLTIxLg0KDQpPdXIgT1BTIEFELCBXYXJyZW4gIkFjZSIgS3VtYXJpLCAgaGFz IGtpbmRseSByZXZpZXdlZCBvdXIgZG9jdW1lbnQgYW5kIGhhcyBpZGVudGlmaWVkIG1vcmUgdGhh biA3MCBhcmVhcyB3aGVyZSB0aGUgdGV4dCB3YXMgYW1iaWd1b3VzIG9yIHVzaW5nIGJhZCBFbmds aXNoLi4uIE5vIHdvbmRlciwgbm9uZSBvZiB0aGUgNCBhdXRob3JzIGFyZSBFbmdsaXNoLXNwZWFr aW5nIG5hdGl2ZTogaXQgaXMgYSBtaXggb2YgRXN0b25pYW4gKE1lcmlrZSB3aG8gYWxzbyBzcGVh a3MgR2VybWFuIGFuZCBSdXNzaWFuWzFdKSwgb25lIG9mIHRoZSAyMiAoPykgbGFuZ3VhZ2Ugb2Yg SW5kaWEgKEtLKSwgR2VybWFuIChFbm5vIHdobyBhbHNvIHNwZWFrcyBGcmVuY2ggYW5kIFNwYW5p c2gpIGFuZCBGcmVuY2ggKG15c2VsZiBhbHNvIHNwZWFraW5nIER1dGNoKSBfXyBfXyBJRVRGIGNv bW11bml0eSBpcyByZWFsbHkgZGl2ZXJzZSAhDQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2ggaW4gYWR2 YW5jZSBmb3IgZmluYWxpemluZyB0aGUgc2hlcGhlcmQgd3JpdGUtdXANCg0KLcOpcmljDQoNClsx XSBJIGNhbiBiZSB3cm9uZyBmb3IgTWVyaWtlIEJUVyBidXQgc2hlIGlzIHF1YWRyaS1saW5ndWFs DQoNCk9uIDA0LzExLzIwMTksIDE1OjI2LCAiR3lhbiBNaXNocmEiIDxoYXlhYnVzYWdzbUBnbWFp bC5jb208bWFpbHRvOmhheWFidXNhZ3NtQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQogICAgSGkgRXJp Yw0KDQogICAgSnVzdCBjaGVja2luZyB3aGF0IHRoZSB1cGRhdGVzIGFyZSB0aGF0IHdlbnQgaW4g djIxIHNpbmNlIHRoaXMgZG9jdW1lbnQgaXMgbm93IHJlYWR5IHRvIGJlIHB1Ymxpc2hlZCBqdXN0 IHBlbmRpbmcgbXkgU2hlcGFyZCB3cml0ZXVwIHdoaWNoIEkgcGxhbiB0byBmaW5pc2ggdGhpcyB3 ZWVrLg0KDQogICAgVGhhbmsgeW91DQoNCiAgICBHeWFuDQoNCiAgICBTZW50IGZyb20gbXkgaVBo b25lDQoNCiAgICA+IE9uIE5vdiAzLCAyMDE5LCBhdCA0OjU2IFBNLCBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQogICAgPg0K ICAgID4NCiAgICA+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBv bi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCiAgICA+IFRoaXMgZHJhZnQgaXMg YSB3b3JrIGl0ZW0gb2YgdGhlIE9wZXJhdGlvbmFsIFNlY3VyaXR5IENhcGFiaWxpdGllcyBmb3Ig SVAgTmV0d29yayBJbmZyYXN0cnVjdHVyZSBXRyBvZiB0aGUgSUVURi4NCiAgICA+DQogICAgPiAg ICAgICAgVGl0bGUgICAgICAgICAgIDogT3BlcmF0aW9uYWwgU2VjdXJpdHkgQ29uc2lkZXJhdGlv bnMgZm9yIElQdjYgTmV0d29ya3MNCiAgICA+ICAgICAgICBBdXRob3JzICAgICAgICAgOiBFcmlj IFZ5bmNrZQ0KICAgID4gICAgICAgICAgICAgICAgICAgICAgICAgIEtpcmFuIEt1bWFyIENoaXR0 aW1hbmVuaQ0KICAgID4gICAgICAgICAgICAgICAgICAgICAgICAgIE1lcmlrZSBLYWVvDQogICAg PiAgICAgICAgICAgICAgICAgICAgICAgICAgRW5ubyBSZXkNCiAgICA+ICAgIEZpbGVuYW1lICAg ICAgICA6IGRyYWZ0LWlldGYtb3BzZWMtdjYtMjEudHh0DQogICAgPiAgICBQYWdlcyAgICAgICAg ICAgOiA1Mg0KICAgID4gICAgRGF0ZSAgICAgICAgICAgIDogMjAxOS0xMS0wMw0KICAgID4NCiAg ICA+IEFic3RyYWN0Og0KICAgID4gICBLbm93bGVkZ2UgYW5kIGV4cGVyaWVuY2Ugb24gaG93IHRv IG9wZXJhdGUgSVB2NCBzZWN1cmVseSBpcw0KICAgID4gICBhdmFpbGFibGU6IHdoZXRoZXIgaXQg aXMgdGhlIEludGVybmV0IG9yIGFuIGVudGVycHJpc2UgaW50ZXJuYWwNCiAgICA+ICAgbmV0d29y ay4gIEhvd2V2ZXIsIElQdjYgcHJlc2VudHMgc29tZSBuZXcgc2VjdXJpdHkgY2hhbGxlbmdlcy4g IFJGQw0KICAgID4gICA0OTQyIGRlc2NyaWJlcyB0aGUgc2VjdXJpdHkgaXNzdWVzIGluIHRoZSBw cm90b2NvbCBidXQgbmV0d29yaw0KICAgID4gICBtYW5hZ2VycyBhbHNvIG5lZWQgYSBtb3JlIHBy YWN0aWNhbCwgb3BlcmF0aW9ucy1taW5kZWQgZG9jdW1lbnQgdG8NCiAgICA+ICAgZW51bWVyYXRl IGFkdmFudGFnZXMgYW5kL29yIGRpc2FkdmFudGFnZXMgb2YgY2VydGFpbiBjaG9pY2VzLg0KICAg ID4NCiAgICA+ICAgVGhpcyBkb2N1bWVudCBhbmFseXplcyB0aGUgb3BlcmF0aW9uYWwgc2VjdXJp dHkgaXNzdWVzIGluIHNldmVyYWwNCiAgICA+ICAgcGxhY2VzIG9mIGEgbmV0d29yayAoZW50ZXJw cmlzZXMsIHNlcnZpY2UgcHJvdmlkZXJzIGFuZCByZXNpZGVudGlhbA0KICAgID4gICB1c2Vycykg YW5kIHByb3Bvc2VzIHRlY2huaWNhbCBhbmQgcHJvY2VkdXJhbCBtaXRpZ2F0aW9ucyB0ZWNobmlx dWVzLg0KICAgID4gICBTb21lIHZlcnkgc3BlY2lmaWMgcGxhY2VzIG9mIGEgbmV0d29yayBzdWNo IGFzIHRoZSBJbnRlcm5ldCBvZiBUaGluZ3MNCiAgICA+ICAgYXJlIG5vdCBkaXNjdXNzZWQgaW4g dGhpcyBkb2N1bWVudC4NCiAgICA+DQogICAgPg0KICAgID4gVGhlIElFVEYgZGF0YXRyYWNrZXIg c3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQogICAgPiBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9wc2VjLXY2Lw0KICAgID4NCiAgICA+IFRoZXJlIGFy ZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCiAgICA+IGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9wc2VjLXY2LTIxDQogICAgPiBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtb3BzZWMtdjYtMjENCiAgICA+ DQogICAgPiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6 DQogICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1vcHNl Yy12Ni0yMQ0KICAgID4NCiAgICA+DQogICAgPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQogICAgPiB1 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xz LmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQogICAgPg0KICAgID4gSW50ZXJuZXQt RHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KICAgID4gZnRw Oi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCiAgICA+DQogICAgPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gT1BTRUMgbWFpbGlu ZyBsaXN0DQogICAgPiBPUFNFQ0BpZXRmLm9yZzxtYWlsdG86T1BTRUNAaWV0Zi5vcmc+DQogICAg PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2VjDQoNCg0KDQotLQ0K R3lhbiBTLiBNaXNocmENCklUIE5ldHdvcmsgRW5naW5lZXJpbmcgJiBUZWNobm9sb2d5DQpWZXJp em9uIENvbW11bmljYXRpb25zIEluYy4gKFZaKQ0KMTMxMDEgQ29sdW1iaWEgUGlrZSBGREMxIDNy ZCBGbG9vcg0KU2lsdmVyIFNwcmluZywgTUQgMjA5MDQNClVuaXRlZCBTdGF0ZXMNClBob25lOiAz MDEgNTAyLTEzNDcNCkVtYWlsOiBneWFuLnMubWlzaHJhQHZlcml6b24uY29tPG1haWx0bzpneWFu LnMubWlzaHJhQHZlcml6b24uY29tPg0Kd3d3LmxpbmtlZGluLmNvbS9pbi9uZXR3b3JraW5nLXRl Y2hub2xvZ2llcy1jb25zdWx0YW50PGh0dHA6Ly93d3cubGlua2VkaW4uY29tL2luL25ldHdvcmtp bmctdGVjaG5vbG9naWVzLWNvbnN1bHRhbnQ+DQoNCg== --_000_3BB16B9C9065466B9A9A51C5D314E126ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <054A119019D4E541BE1A3EC4FE944EC2@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlNlZ29lIFVJIjsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQovKiBT dHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05v cm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3Jt YWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJ bWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R3lhbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGFuayB5b3UgdmVyeSBtdWNoIGZvciB5b3VyIHNoZXBoZXJkIHdyaXRlLXVwLCB2ZXJ5IG11Y2gg YXBwcmVjaWF0ZWQgYnkgdGhlIGF1dGhvcnMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBs aXN0IG9mIHRoZSDigJhvYnNvbGV0ZWTigJkgcmVmZXJlbmNlcyBpcyBpbnRlbnRpb25hbCBpbmRl ZWQgdG8gZW5zdXJlIHRoYXQgcmVhZGVycyB1bmRlcnN0YW5kIHRoYXQg4oCYb2xk4oCZIGRvY3Vt ZW50cyBoYXZlIGJlZW4gcmVwbGFjZWQuIFRoZSB0ZXh0IGluIHRoZSBkb2N1bWVudCBpcyBjbGVh ciBhYm91dCB0aGUgb2Jzb2xldGUgYW5kIGN1cnJlbnQgZG9jdW1lbnQuIFNvLCB3ZSBkbyBwcmVm ZXIgdG8gbGVhdmUNCiB0aGUgcmVmZXJlbmNlcyBsaWtlIHRoZXkgYXJlIGFzIHdlIGJlbGlldmUg dGhhdCB0aGV5IG1ha2UgdGhlIGRvY3VtZW50IG1vcmUgdmFsdWFibGUgZm9yIHRoZSByZWFkZXIu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ LcOpcmljPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+R3lhbiBNaXNocmEgJmx0O2hheWFidXNhZ3NtQGdtYWlsLmNv bSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+U2F0dXJkYXksIDkgTm92ZW1iZXIgMjAxOSBhdCAwODoy ODxicj4NCjxiPlRvOiA8L2I+RXJpYyBWeW5ja2UgJmx0O2V2eW5ja2VAY2lzY28uY29tJmd0Ozxi cj4NCjxiPkNjOiA8L2I+JnF1b3Q7b3BzZWNAaWV0Zi5vcmcmcXVvdDsgJmx0O29wc2VjQGlldGYu b3JnJmd0OywgJnF1b3Q7aS1kLWFubm91bmNlQGlldGYub3JnJnF1b3Q7ICZsdDtpLWQtYW5ub3Vu Y2VAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbT1BTRUNdIEktRCBBY3Rp b246IGRyYWZ0LWlldGYtb3BzZWMtdjYtMjEudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5FcmljIDxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SSBzdWJtaXR0ZWQgdGhlIHNoZXBoZXJkIHdyaXRlLXVw LiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij5JIHJhbiB0aGUgaWRuaXRzIGFuZCBpdCBmb3VuZCB0aGUgZm9sbG93aW5nIG9ic29s ZXRlIHJlZmVyZW5jZXMuJm5ic3A7IFdlIHNob3VsZCBjbGVhciB0aGF0IHVwIGJlZm9yZSB3ZSBw dWJsaXNoIGl0LiZuYnNwOyBJIGNhbiB1cGRhdGUgbXkgY29tbWVudHMgb24gdGhhdCBvbmNlIHRo ZSBkcmFmdCBpcyB1cGRhdGVkLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O3doaXRlLXNwYWNlOnByZS13cmFwIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPkNoZWNraW5nIHJlZmVyZW5jZXMgZm9yIGludGVuZGVkIHN0 YXR1czogSW5mb3JtYXRpb25hbDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7IC0tIE9ic29sZXRlIGluZm9ybWF0aW9uYWwgcmVmZXJl bmNlIChpcyB0aGlzIGludGVudGlvbmFsPyk6IFJGQyAyNDYwPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IChPYnNvbGV0ZWQgYnkgUkZDIDgyMDApPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ ICZuYnNwOy0tIE9ic29sZXRlIGluZm9ybWF0aW9uYWwgcmVmZXJlbmNlIChpcyB0aGlzIGludGVu dGlvbmFsPyk6IFJGQyAzMDY4PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IChPYnNvbGV0ZWQgYnkgUkZDIDc1MjYpPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7IC0tIE9ic29sZXRl IGluZm9ybWF0aW9uYWwgcmVmZXJlbmNlIChpcyB0aGlzIGludGVudGlvbmFsPyk6IFJGQyAzNjI3 PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IChPYnNv bGV0ZWQgYnkgUkZDIDY1NDcpPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQ7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQ7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+VGhhbmsgeW91PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQ7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQ7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+R3lhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij5PbiBNb24sIE5vdiA0LCAyMDE5IGF0IDk6MzggQU0gRXJpYyBWeW5ja2UgKGV2 eW5ja2UpICZsdDs8YSBocmVmPSJtYWlsdG86ZXZ5bmNrZUBjaXNjby5jb20iPmV2eW5ja2VAY2lz Y28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJn aW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjM2LjBwdCI+DQpI ZWxsbyBHeWFuLDxicj4NCjxicj4NClRoYW5rIHlvdSBmb3IgcmVtaW5kaW5nIHRoZSBhdXRob3Ig dG8gcG9zdCB0aGUgJ2dpc3QnIG9mIHRoZSBjaGFuZ2VzIHdpdGggdmVyc2lvbiAtMjEuPGJyPg0K PGJyPg0KT3VyIE9QUyBBRCwgV2FycmVuICZxdW90O0FjZSZxdW90OyBLdW1hcmksJm5ic3A7IGhh cyBraW5kbHkgcmV2aWV3ZWQgb3VyIGRvY3VtZW50IGFuZCBoYXMgaWRlbnRpZmllZCBtb3JlIHRo YW4gNzAgYXJlYXMgd2hlcmUgdGhlIHRleHQgd2FzIGFtYmlndW91cyBvciB1c2luZyBiYWQgRW5n bGlzaC4uLiBObyB3b25kZXIsIG5vbmUgb2YgdGhlIDQgYXV0aG9ycyBhcmUgRW5nbGlzaC1zcGVh a2luZyBuYXRpdmU6IGl0IGlzIGEgbWl4IG9mIEVzdG9uaWFuIChNZXJpa2Ugd2hvIGFsc28NCiBz cGVha3MgR2VybWFuIGFuZCBSdXNzaWFuWzFdKSwgb25lIG9mIHRoZSAyMiAoPykgbGFuZ3VhZ2Ug b2YgSW5kaWEgKEtLKSwgR2VybWFuIChFbm5vIHdobyBhbHNvIHNwZWFrcyBGcmVuY2ggYW5kIFNw YW5pc2gpIGFuZCBGcmVuY2ggKG15c2VsZiBhbHNvIHNwZWFraW5nIER1dGNoKSBfXyBfXyBJRVRG IGNvbW11bml0eSBpcyByZWFsbHkgZGl2ZXJzZSAhPGJyPg0KPGJyPg0KVGhhbmsgeW91IHZlcnkg bXVjaCBpbiBhZHZhbmNlIGZvciBmaW5hbGl6aW5nIHRoZSBzaGVwaGVyZCB3cml0ZS11cDxicj4N Cjxicj4NCi3DqXJpYzxicj4NCjxicj4NClsxXSBJIGNhbiBiZSB3cm9uZyBmb3IgTWVyaWtlIEJU VyBidXQgc2hlIGlzIHF1YWRyaS1saW5ndWFsPGJyPg0KPGJyPg0KT24gMDQvMTEvMjAxOSwgMTU6 MjYsICZxdW90O0d5YW4gTWlzaHJhJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aGF5YWJ1c2Fn c21AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+aGF5YWJ1c2Fnc21AZ21haWwuY29tPC9hPiZn dDsgd3JvdGU6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBIaSBFcmljIDxicj4NCjxicj4NCiZu YnNwOyAmbmJzcDsgSnVzdCBjaGVja2luZyB3aGF0IHRoZSB1cGRhdGVzIGFyZSB0aGF0IHdlbnQg aW4gdjIxIHNpbmNlIHRoaXMgZG9jdW1lbnQgaXMgbm93IHJlYWR5IHRvIGJlIHB1Ymxpc2hlZCBq dXN0IHBlbmRpbmcgbXkgU2hlcGFyZCB3cml0ZXVwIHdoaWNoIEkgcGxhbiB0byBmaW5pc2ggdGhp cyB3ZWVrLiZuYnNwOw0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBUaGFuayB5b3UgPGJyPg0K PGJyPg0KJm5ic3A7ICZuYnNwOyBHeWFuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBTZW50IGZy b20gbXkgaVBob25lPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IE9uIE5vdiAzLCAyMDE5 LCBhdCA0OjU2IFBNLCA8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+DQppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+IHdyb3RlOjxicj4N CiZuYnNwOyAmbmJzcDsgJmd0OyA8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgPGJyPg0KJm5ic3A7 ICZuYnNwOyAmZ3Q7IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBv bi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy48YnI+DQombmJzcDsgJm5ic3A7ICZn dDsgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgT3BlcmF0aW9uYWwgU2VjdXJpdHkg Q2FwYWJpbGl0aWVzIGZvciBJUCBOZXR3b3JrIEluZnJhc3RydWN0dXJlIFdHIG9mIHRoZSBJRVRG Ljxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyA8YnI+DQombmJzcDsgJm5ic3A7ICZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgVGl0bGUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOzogT3BlcmF0aW9uYWwgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgZm9yIElQdjYg TmV0d29ya3M8YnI+DQombmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgQXV0aG9ycyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IEVyaWMgVnluY2tl PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IEtpcmFuIEt1bWFyIENoaXR0aW1hbmVuaTxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBNZXJpa2UgS2Flbzxicj4NCiZuYnNwOyAmbmJzcDsg Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBFbm5vIFJleTxicj4NCiZuYnNw OyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgRmlsZW5hbWUmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgOiBkcmFmdC1pZXRmLW9wc2VjLXY2LTIxLnR4dDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0 OyZuYnNwOyAmbmJzcDsgUGFnZXMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOzogNTI8YnI+DQombmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7IERhdGUmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IDIwMTktMTEtMDM8YnI+DQombmJz cDsgJm5ic3A7ICZndDsgPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IEFic3RyYWN0Ojxicj4NCiZu YnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDtLbm93bGVkZ2UgYW5kIGV4cGVyaWVuY2Ugb24g aG93IHRvIG9wZXJhdGUgSVB2NCBzZWN1cmVseSBpczxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZu YnNwOyAmbmJzcDthdmFpbGFibGU6IHdoZXRoZXIgaXQgaXMgdGhlIEludGVybmV0IG9yIGFuIGVu dGVycHJpc2UgaW50ZXJuYWw8YnI+DQombmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7bmV0 d29yay4mbmJzcDsgSG93ZXZlciwgSVB2NiBwcmVzZW50cyBzb21lIG5ldyBzZWN1cml0eSBjaGFs bGVuZ2VzLiZuYnNwOyBSRkM8YnI+DQombmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7NDk0 MiBkZXNjcmliZXMgdGhlIHNlY3VyaXR5IGlzc3VlcyBpbiB0aGUgcHJvdG9jb2wgYnV0IG5ldHdv cms8YnI+DQombmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7bWFuYWdlcnMgYWxzbyBuZWVk IGEgbW9yZSBwcmFjdGljYWwsIG9wZXJhdGlvbnMtbWluZGVkIGRvY3VtZW50IHRvPGJyPg0KJm5i c3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwO2VudW1lcmF0ZSBhZHZhbnRhZ2VzIGFuZC9vciBk aXNhZHZhbnRhZ2VzIG9mIGNlcnRhaW4gY2hvaWNlcy48YnI+DQombmJzcDsgJm5ic3A7ICZndDsg PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgYW5hbHl6 ZXMgdGhlIG9wZXJhdGlvbmFsIHNlY3VyaXR5IGlzc3VlcyBpbiBzZXZlcmFsPGJyPg0KJm5ic3A7 ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwO3BsYWNlcyBvZiBhIG5ldHdvcmsgKGVudGVycHJpc2Vz LCBzZXJ2aWNlIHByb3ZpZGVycyBhbmQgcmVzaWRlbnRpYWw8YnI+DQombmJzcDsgJm5ic3A7ICZn dDsmbmJzcDsgJm5ic3A7dXNlcnMpIGFuZCBwcm9wb3NlcyB0ZWNobmljYWwgYW5kIHByb2NlZHVy YWwgbWl0aWdhdGlvbnMgdGVjaG5pcXVlcy48YnI+DQombmJzcDsgJm5ic3A7ICZndDsmbmJzcDsg Jm5ic3A7U29tZSB2ZXJ5IHNwZWNpZmljIHBsYWNlcyBvZiBhIG5ldHdvcmsgc3VjaCBhcyB0aGUg SW50ZXJuZXQgb2YgVGhpbmdzPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwO2Fy ZSBub3QgZGlzY3Vzc2VkIGluIHRoaXMgZG9jdW1lbnQuPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7 IDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyA8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgVGhlIElF VEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6PGJyPg0KJm5ic3A7 ICZuYnNwOyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtb3BzZWMtdjYvIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9wc2VjLXY2LzwvYT48YnI+DQombmJzcDsgJm5ic3A7 ICZndDsgPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZl cnNpb25zIGF2YWlsYWJsZSBhdDo8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgPGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb3BzZWMtdjYtMjEiIHRhcmdldD0i X2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9wc2VjLXY2 LTIxPC9hPjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtb3BzZWMtdjYtMjEiIHRhcmdldD0iX2Js YW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1v cHNlYy12Ni0yMTwvYT48YnI+DQombmJzcDsgJm5ic3A7ICZndDsgPGJyPg0KJm5ic3A7ICZuYnNw OyAmZ3Q7IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8 YnI+DQombmJzcDsgJm5ic3A7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LWlldGYtb3BzZWMtdjYtMjEiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW9wc2VjLXY2LTIxPC9hPjxi cj4NCiZuYnNwOyAmbmJzcDsgJmd0OyA8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgPGJyPg0KJm5i c3A7ICZuYnNwOyAmZ3Q7IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+DQombmJzcDsgJm5ic3A7ICZn dDsgdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCA8 YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnRvb2xzLmll dGYub3JnPC9hPi48YnI+DQombmJzcDsgJm5ic3A7ICZndDsgPGJyPg0KJm5ic3A7ICZuYnNwOyAm Z3Q7IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBh dDo8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgPGEgaHJlZj0iZnRwOi8vZnRwLmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy8iIHRhcmdldD0iX2JsYW5rIj5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzLzwvYT48YnI+DQombmJzcDsgJm5ic3A7ICZndDsgPGJyPg0KJm5ic3A7ICZuYnNw OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IE9QU0VDIG1haWxpbmcgbGlzdDxicj4NCiZuYnNwOyAmbmJz cDsgJmd0OyA8YSBocmVmPSJtYWlsdG86T1BTRUNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5P UFNFQ0BpZXRmLm9yZzwvYT48YnI+DQombmJzcDsgJm5ic3A7ICZndDsgPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNlYyIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzZWM8L2E+PGJyPg0KPGJyPg0K PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM1MDAwNTAiPkd5YW4gUy4g TWlzaHJhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzUwMDA1MCI+SVQgTmV0d29yayBF bmdpbmVlcmluZyAmYW1wOyBUZWNobm9sb2d5Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBzdHlsZT0i Y29sb3I6IzUwMDA1MCI+VmVyaXpvbiBDb21tdW5pY2F0aW9ucyZuYnNwO0luYy4gKFZaKTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4w cHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM1MDAwNTAiPjEzMTAxIENvbHVtYmlhIFBpa2UgRkRD MSAzcmQgRmxvb3I8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjojNTAwMDUwIj5TaWx2ZXIg U3ByaW5nLCBNRCAyMDkwNDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM1MDAwNTAiPlVu aXRlZCBTdGF0ZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6MzYuMHB0O2JhY2tncm91bmQtaW1hZ2U6aW5pdGlhbDtiYWNrZ3JvdW5kLXBv c2l0aW9uOmluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCI+DQo8c3BhbiBzdHlsZT0i Y29sb3I6IzUwMDA1MCI+UGhvbmU6Jm5ic3A7MzAxIDUwMi0xMzQ3PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdDtiYWNrZ3JvdW5k LWltYWdlOmluaXRpYWw7YmFja2dyb3VuZC1wb3NpdGlvbjppbml0aWFsO2JhY2tncm91bmQtcmVw ZWF0OmluaXRpYWwiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM1MDAwNTAiPkVtYWlsOiZuYnNwOzxh IGhyZWY9Im1haWx0bzpneWFuLnMubWlzaHJhQHZlcml6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxMTU1Q0MiPmd5YW4ucy5taXNocmFAdmVyaXpvbi5jb208L3Nw YW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDozNi4wcHQ7YmFja2dyb3VuZC1pbWFnZTppbml0aWFsO2JhY2tncm91bmQtcG9zaXRp b246aW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsIj4NCjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90Oztjb2xvcjpibGFjaztib3JkZXI6bm9uZSB3aW5k b3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIj48YSBocmVmPSJodHRwOi8vd3d3LmxpbmtlZGluLmNv bS9pbi9uZXR3b3JraW5nLXRlY2hub2xvZ2llcy1jb25zdWx0YW50IiB0YXJnZXQ9Il9ibGFuayI+ d3d3LmxpbmtlZGluLmNvbS9pbi9uZXR3b3JraW5nLXRlY2hub2xvZ2llcy1jb25zdWx0YW50PC9h Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_3BB16B9C9065466B9A9A51C5D314E126ciscocom_-- From nobody Sat Nov 9 08:46:50 2019 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 1C45A1200DE for ; Sat, 9 Nov 2019 08:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xnt15XNjBSOu for ; Sat, 9 Nov 2019 08:46:44 -0800 (PST) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 9A119120073 for ; Sat, 9 Nov 2019 08:46:44 -0800 (PST) Received: by mail-wr1-x433.google.com with SMTP id p2so10342148wro.2 for ; Sat, 09 Nov 2019 08:46:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=1DrPRHo7KzpI2rXKUj9mLK1439N2tHbx8oUBEY0dYqc=; b=IziryYc9RP4VNVUOZOR5N0HiQyrcB+Rxd05LqVwpax4yuHj8wzPUV0nqEcr3xQvnBF Qai8qEtOmUgR2yqxV+Md+ASh7JKT6i8znyviJIWhxlHUNE/WEikh5RKPm0vGM9NvFBHs f+f/o2J1Q4go6JiBFgEfcNDX7Ru5mGWhTjFZG+aXIeV2mZCh/6QgOWwuSiMcijnT3bRI Fa+dOUrt+x0N0rMuWPe9bSVsUyMCQFyfvQUg6GzE2KiAJuUtfbe4VbozQ/LdSfvUfkWb V8jX25q0ppHyW8QL4C/5B6KR4VzU3HVLA91USF4xEXePFMBpHgZwENfQxW4wJeth5uJf Eztw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=1DrPRHo7KzpI2rXKUj9mLK1439N2tHbx8oUBEY0dYqc=; b=CwpPhES5RzCfG5jSYBuHYnuYY2ubzt3NFiLEAczNbuTCm8JhFOuh3aSxq7a9e7PWrM XQiOmbw/ftsbcHF1OjgMKvdYWqtNF7Vbp4rtJIb9gQR4yKg52iSHCE68fJRElW0rNyYr HkhaSIEBk+6p5tOI980XVQ4uH/71UZgxY2aIVQupwrGiNaEsE4NeF/+kz7L9YUvnoQnr ZtFIt5DtpIxZy6+I019vuDcC9+slxmGK+Jj70q50L+c+6lPKMB7vWRiz4wRvuRNawjhJ rPoOrIg2Q4NUenYFWKb+j0xvRvLfyAyAB5xi94jd+ql0Qibr7p8cNwrG29CNwacGWIV/ I6Dg== X-Gm-Message-State: APjAAAVw0Va7sUSEIizmrVxODdM8fU3HmwrfxhH72MLNo7zfS5+cotN5 RPdWjaulmDzBSKAOZP8vAzg= X-Google-Smtp-Source: APXvYqzbx1boj5hsZrfIyvvWx+QXES5dKkZLumAJraPu5gXN9euh5UkvCm1qi1y36dVBY+CrUFJijQ== X-Received: by 2002:adf:9dd0:: with SMTP id q16mr13495536wre.303.1573318002871; Sat, 09 Nov 2019 08:46:42 -0800 (PST) Received: from [10.0.0.199] (c-24-5-53-184.hsd1.ca.comcast.net. [24.5.53.184]) by smtp.gmail.com with ESMTPSA id o18sm12851062wrm.11.2019.11.09.08.46.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Nov 2019 08:46:41 -0800 (PST) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_8B121791-92D4-4A0D-A2F0-FE13FA5B65D5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 9 Nov 2019 08:46:32 -0800 In-Reply-To: <3BB16B9C-9065-466B-9A9A-51C5D314E126@cisco.com> Cc: Bob Hinden , Gyan Mishra , "opsec@ietf.org" To: "Eric Vyncke (evyncke)" References: <157281820483.13177.8617036261217670675@ietfa.amsl.com> <82AA0F9C-7836-464F-8F19-69FEDB197D53@gmail.com> <1AAA80C6-080B-492D-ABC9-645B9CEFDC99@cisco.com> <3BB16B9C-9065-466B-9A9A-51C5D314E126@cisco.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-21.txt 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, 09 Nov 2019 16:46:48 -0000 --Apple-Mail=_8B121791-92D4-4A0D-A2F0-FE13FA5B65D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Eric, > On Nov 8, 2019, at 11:57 PM, Eric Vyncke (evyncke) = wrote: >=20 > Gyan >=20 > Thank you very much for your shepherd write-up, very much appreciated = by the authors. >=20 > The list of the =E2=80=98obsoleted=E2=80=99 references is intentional = indeed to ensure that readers understand that =E2=80=98old=E2=80=99 = documents have been replaced. The text in the document is clear about = the obsolete and current document. So, we do prefer to leave the = references like they are as we believe that they make the document more = valuable for the reader. I went back and reread this. The text: 2.2.2. Hop-by-Hop Options Header The hop-by-hop options header, when present in an IPv6 packet, forces all nodes in the path to inspect this header in the original IPv6 specification [RFC2460]. This enables denial of service attacks as most, if not all, routers cannot process this kind of packets in hardware but have to 'punt' this packet for software processing. Section 4.3 of the current Internet Standard for IPv6, [RFC8200], has taken this attack vector into account and made the processing of hop- by-hop options header by intermediate routers optional. I don=E2=80=99t understand why this is talking about RFC2460 at all. = Seems like it would less confusing to only describe what is in RFC8200. = Nor is =E2=80=9Cpunt=E2=80=9D correct way to describe this. Way too = colloquial. Describing RFC8200 behavior as =E2=80=9Coptional" is quite right, = RFC8200 says: ...now expected that nodes along a packet's delivery path only = examine and process the Hop-by-Hop Options header if explicitly configured to do so It=E2=80=99s not optional if configured to do so. It would be better to = use the RFC8200 words. Lastly the =E2=80=9COriginal" IPv6 Specification was RFC1883. Bob p.s. I agree about the references to RFC 3068 and RFC 3627. >=20 > Regards >=20 > -=C3=A9ric >=20 > From: Gyan Mishra > Date: Saturday, 9 November 2019 at 08:28 > To: Eric Vyncke > Cc: "opsec@ietf.org" , "i-d-announce@ietf.org" = > Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-21.txt >=20 > Eric >=20 > I submitted the shepherd write-up. >=20 > I ran the idnits and it found the following obsolete references. We = should clear that up before we publish it. I can update my comments on = that once the draft is updated. > Checking references for intended status: Informational > = --------------------------------------------------------------------------= -- >=20 > -- Obsolete informational reference (is this intentional?): RFC 2460 > (Obsoleted by RFC 8200) >=20 > -- Obsolete informational reference (is this intentional?): RFC 3068 > (Obsoleted by RFC 7526) >=20 > -- Obsolete informational reference (is this intentional?): RFC 3627 > (Obsoleted by RFC 6547) >=20 > Thank you >=20 > Gyan >=20 > On Mon, Nov 4, 2019 at 9:38 AM Eric Vyncke (evyncke) = wrote: >> Hello Gyan, >>=20 >> Thank you for reminding the author to post the 'gist' of the changes = with version -21. >>=20 >> Our OPS AD, Warren "Ace" Kumari, has kindly reviewed our document = and has identified more than 70 areas where the text was ambiguous or = using bad English... No wonder, none of the 4 authors are = English-speaking native: it is a mix of Estonian (Merike who also speaks = German and Russian[1]), one of the 22 (?) language of India (KK), German = (Enno who also speaks French and Spanish) and French (myself also = speaking Dutch) __ __ IETF community is really diverse ! >>=20 >> Thank you very much in advance for finalizing the shepherd write-up >>=20 >> -=C3=A9ric >>=20 >> [1] I can be wrong for Merike BTW but she is quadri-lingual >>=20 >> On 04/11/2019, 15:26, "Gyan Mishra" wrote: >>=20 >> Hi Eric >>=20 >> Just checking what the updates are that went in v21 since this = document is now ready to be published just pending my Shepard writeup = which I plan to finish this week. >>=20 >> Thank you >>=20 >> Gyan >>=20 >> Sent from my iPhone >>=20 >> > On Nov 3, 2019, at 4:56 PM, internet-drafts@ietf.org wrote: >> > >> > >> > A New Internet-Draft is available from the on-line = Internet-Drafts directories. >> > This draft is a work item of the Operational Security = Capabilities for IP Network Infrastructure WG of the IETF. >> > >> > Title : Operational Security Considerations = for IPv6 Networks >> > Authors : Eric Vyncke >> > Kiran Kumar Chittimaneni >> > Merike Kaeo >> > Enno Rey >> > Filename : draft-ietf-opsec-v6-21.txt >> > Pages : 52 >> > Date : 2019-11-03 >> > >> > Abstract: >> > Knowledge and experience on how to operate IPv4 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 in = several >> > places of a network (enterprises, service providers and = residential >> > users) and proposes technical and procedural mitigations = techniques. >> > Some very specific places of a network such as the Internet = of Things >> > are not discussed in this document. >> > >> > >> > 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-21 >> > https://datatracker.ietf.org/doc/html/draft-ietf-opsec-v6-21 >> > >> > A diff from the previous version is available at: >> > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-v6-21 >> > >> > >> > 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/ >> > >> > _______________________________________________ >> > OPSEC mailing list >> > OPSEC@ietf.org >> > https://www.ietf.org/mailman/listinfo/opsec >>=20 >>=20 >=20 >=20 > -- > Gyan S. Mishra > IT Network Engineering & Technology > Verizon Communications Inc. (VZ) > 13101 Columbia Pike FDC1 3rd Floor > Silver Spring, MD 20904 > United States > Phone: 301 502-1347 > Email: gyan.s.mishra@verizon.com > www.linkedin.com/in/networking-technologies-consultant >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec --Apple-Mail=_8B121791-92D4-4A0D-A2F0-FE13FA5B65D5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAl3G7WgACgkQrut0EXfn u6iNvwf+J44yIpLrjTro9ONl/ba+g2zKAQoxZC3i4PeR1EfEmJ0EblHMKWbx82/c ntooby9hHvT51gQUbRNIbltlKcUaslboG5ZmUQwdsQO90sHJ0rvxCVVxpz1bqPl9 MJRiWjKsZXo6aMqsbPYrVxHlIMwPiielJkJjwxCG04X7+sUe/k8vX9rbC6VXbO+/ zZdNS0TwP/c+5M4MrdAm5q3bSCCmagYyla3c4HjmbNMR6QvbeFBjP6gGb3+hEdE3 Kd3dl4b6QDsY5zOD3SQ+jjghYRF7X75nAC6y1DR+9v5QUOMZHABqx//NWXBy6P2N C0fhxVsvrhWb6h8vLKOZFatPT7TMiw== =urjo -----END PGP SIGNATURE----- --Apple-Mail=_8B121791-92D4-4A0D-A2F0-FE13FA5B65D5-- From nobody Sat Nov 9 11:43:09 2019 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 1FB0912001A for ; Sat, 9 Nov 2019 11:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cASWCNXROuf6 for ; Sat, 9 Nov 2019 11:43:02 -0800 (PST) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (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 1B1E1120089 for ; Sat, 9 Nov 2019 11:43:02 -0800 (PST) Received: by mail-qv1-xf2c.google.com with SMTP id s18so3507683qvr.4 for ; Sat, 09 Nov 2019 11:43:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=eOGU6fB7s1/6g8Nm9cDc9Csyd8HSgV2tffB7hn9CBZo=; b=tQXzD7AGQJluEsbNVk3j+YifhpcCRHCkGO4bCe62PnnAWiHClRa5DKpy7Ysb5j6xFY 8xICd3A+NZPWplLd0RD77YGD8s8zNFAG7zgDFiDIE9bMMMgC4nwX7o6SWJ82JBKWOOP5 R+c6PfyINpBtLvGUIW1J7kkmsMQ8DV4EI08K8Q8Km4+U7J0Q9XIsD5nkaTLpllLfbhap A43uShvUgdnfimTl07nFTqE3fwGRoR35eJShcxaxKLRhgFuLiS6CtEVwopiDRqSWereI 7uJCg682Dvy2OQ2d0BOBrWgHonzD8RzgSg/R/NbmtGdqG9cXFPF8idaF7XgFlXb+flem sQHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=eOGU6fB7s1/6g8Nm9cDc9Csyd8HSgV2tffB7hn9CBZo=; b=MRphNsRKx8QeRTm1xv+s1rZlgqBth+bSK/nzVkJwyzMiMUjBzJ1xwdgOgjCiRxXeel DvQN/BMx1c0yQneyFuoXirLCHlTWKV7eqjO41reigp2FsQnntU91U+IQbYuAKlx5zoR/ BI0qHzmT2CoS3oT7Ihdj8e5Fut2M6E2uPLRSMCeioGWjpLgqDS7+g1I6/ofTjwJ4FTgv 4QHgYqJRcPPRKSaCxLEdVPjC3xlNRwENAMI3LT+AzWcmfqkJPYEkd+Zi1lSk+YcWr5oJ 4mxojG+/as+pg6lVMPpPAkwAijdZw/xoSsGMLwTCMsYIyBaUGTqiQMjmTMGM2WVfH/Mn vZIA== X-Gm-Message-State: APjAAAW18K7yGRE3XfeElvWJuaPDlwC+1tEqL/eg+UeHNEi01lW9Uk2H 8aKWcoBg9wO5KgQIoU8DHi4siM5orKM= X-Google-Smtp-Source: APXvYqxaMpRjaTUJop769yyDGdTRY/VpOtd4bt6yHDUub2map5eXfoZbI+Hsia5Lea024MqJs+GCxQ== X-Received: by 2002:a0c:f114:: with SMTP id i20mr16131080qvl.167.1573328580225; Sat, 09 Nov 2019 11:43:00 -0800 (PST) Received: from [192.168.1.213] (pool-72-83-194-140.washdc.fios.verizon.net. [72.83.194.140]) by smtp.gmail.com with ESMTPSA id a70sm4866602qkb.86.2019.11.09.11.42.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Nov 2019 11:42:59 -0800 (PST) From: Gyan Mishra X-Google-Original-From: Gyan Mishra Content-Type: multipart/alternative; boundary=Apple-Mail-BFF9F50D-7C99-4C6E-898C-AF329BFE27B1 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (16G102) In-Reply-To: <3BB16B9C-9065-466B-9A9A-51C5D314E126@cisco.com> Date: Sat, 9 Nov 2019 14:42:59 -0500 Cc: "opsec@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <77012E7A-9DD9-4C60-8D89-D697325CB7F4@gmail.com> References: <157281820483.13177.8617036261217670675@ietfa.amsl.com> <82AA0F9C-7836-464F-8F19-69FEDB197D53@gmail.com> <1AAA80C6-080B-492D-ABC9-645B9CEFDC99@cisco.com> <3BB16B9C-9065-466B-9A9A-51C5D314E126@cisco.com> To: "Eric Vyncke (evyncke)" Archived-At: Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-21.txt 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, 09 Nov 2019 19:43:07 -0000 --Apple-Mail-BFF9F50D-7C99-4C6E-898C-AF329BFE27B1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Most welcome Eric! I will update the write-up based on what you stated on the intended obsolete= d references. Gyan Sent from my iPhone > On Nov 9, 2019, at 2:57 AM, Eric Vyncke (evyncke) wrot= e: >=20 > Gyan > =20 > Thank you very much for your shepherd write-up, very much appreciated by t= he authors. > =20 > The list of the =E2=80=98obsoleted=E2=80=99 references is intentional inde= ed to ensure that readers understand that =E2=80=98old=E2=80=99 documents ha= ve been replaced. The text in the document is clear about the obsolete and c= urrent document. So, we do prefer to leave the references like they are as w= e believe that they make the document more valuable for the reader. > =20 > Regards > =20 > -=C3=A9ric > =20 > From: Gyan Mishra > Date: Saturday, 9 November 2019 at 08:28 > To: Eric Vyncke > Cc: "opsec@ietf.org" , "i-d-announce@ietf.org" > Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-21.txt > =20 > Eric > =20 > I submitted the shepherd write-up. =20 > =20 > I ran the idnits and it found the following obsolete references. We shoul= d clear that up before we publish it. I can update my comments on that once= the draft is updated.=20 > Checking references for intended status: Informational > ------------------------------------------------------------------------= ---- > =20 > -- Obsolete informational reference (is this intentional?): RFC 2460 > (Obsoleted by RFC 8200) > =20 > -- Obsolete informational reference (is this intentional?): RFC 3068 > (Obsoleted by RFC 7526) > =20 > -- Obsolete informational reference (is this intentional?): RFC 3627 > (Obsoleted by RFC 6547) > =20 > Thank you > =20 > Gyan > =20 > On Mon, Nov 4, 2019 at 9:38 AM Eric Vyncke (evyncke) w= rote: > Hello Gyan, >=20 > Thank you for reminding the author to post the 'gist' of the changes with v= ersion -21. >=20 > Our OPS AD, Warren "Ace" Kumari, has kindly reviewed our document and has= identified more than 70 areas where the text was ambiguous or using bad Eng= lish... No wonder, none of the 4 authors are English-speaking native: it is a= mix of Estonian (Merike who also speaks German and Russian[1]), one of the 2= 2 (?) language of India (KK), German (Enno who also speaks French and Spanis= h) and French (myself also speaking Dutch) __ __ IETF community is really di= verse ! >=20 > Thank you very much in advance for finalizing the shepherd write-up >=20 > -=C3=A9ric >=20 > [1] I can be wrong for Merike BTW but she is quadri-lingual >=20 > On 04/11/2019, 15:26, "Gyan Mishra" wrote: >=20 > Hi Eric=20 >=20 > Just checking what the updates are that went in v21 since this documen= t is now ready to be published just pending my Shepard writeup which I plan t= o finish this week. =20 >=20 > Thank you=20 >=20 > Gyan >=20 > Sent from my iPhone >=20 > > On Nov 3, 2019, at 4:56 PM, internet-drafts@ietf.org wrote: > >=20 > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts d= irectories. > > This draft is a work item of the Operational Security Capabilities f= or IP Network Infrastructure WG of the IETF. > >=20 > > Title : Operational Security Considerations for IPv= 6 Networks > > Authors : Eric Vyncke > > Kiran Kumar Chittimaneni > > Merike Kaeo > > Enno Rey > > Filename : draft-ietf-opsec-v6-21.txt > > Pages : 52 > > Date : 2019-11-03 > >=20 > > Abstract: > > Knowledge and experience on how to operate IPv4 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. > >=20 > > This document analyzes the operational security issues in several > > places of a network (enterprises, service providers and residentia= l > > users) and proposes technical and procedural mitigations technique= s. > > Some very specific places of a network such as the Internet of Thi= ngs > > are not discussed in this document. > >=20 > >=20 > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ > >=20 > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-opsec-v6-21 > > https://datatracker.ietf.org/doc/html/draft-ietf-opsec-v6-21 > >=20 > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-v6-21 > >=20 > >=20 > > Please note that it may take a couple of minutes from the time of su= bmission > > until the htmlized version and diff are available at tools.ietf.org.= > >=20 > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > >=20 > > _______________________________________________ > > OPSEC mailing list > > OPSEC@ietf.org > > https://www.ietf.org/mailman/listinfo/opsec >=20 >=20 >=20 > =20 > -- > Gyan S. Mishra > IT Network Engineering & Technology=20 > Verizon Communications Inc. (VZ) > 13101 Columbia Pike FDC1 3rd Floor > Silver Spring, MD 20904 > United States > Phone: 301 502-1347 > Email: gyan.s.mishra@verizon.com > www.linkedin.com/in/networking-technologies-consultant > =20 --Apple-Mail-BFF9F50D-7C99-4C6E-898C-AF329BFE27B1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Most welcome Eric!

I wil= l update the write-up based on what you stated on the intended obsoleted ref= erences.

Gyan

Sent from my iPhone

On Nov 9, 20= 19, at 2:57 AM, Eric Vyncke (evyncke) <evyncke@cisco.com> wrote:

<= div dir=3D"ltr">

Gyan

 

Thank you very much for your shepherd write-up, very m= uch appreciated by the authors.

 

The list of the =E2=80=98obsoleted=E2=80=99 reference= s is intentional indeed to ensure that readers understand that =E2=80=98old=E2= =80=99 documents have been replaced. The text in the document is clear about= the obsolete and current document. So, we do prefer to leave the references like they are as we believe that they make the document more= valuable for the reader.

 

Regards

 

-=C3=A9ric

 

From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Saturday, 9 November 2019 at 08:28
To: Eric Vyncke <evyncke@cisc= o.com>
Cc: "opsec@ietf.org" <opsec@ietf.org>, "i-d-announce@ietf.org" <i-d-announce@ietf.org>
Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-21.txt

 

Eric

 

I submitted the shepherd= write-up.  

 

I ran the idnits and it f= ound the following obsolete references.  We should clear that up before= we publish it.  I can update my comments on that once the draft is upd= ated. 

Checking references for intended status: Informational
  -------=
---------------------------------------------------------------------
 
  -- Obso=
lete informational reference (is this intentional?): RFC 2460
  &n=
bsp;  (Obsoleted by RFC 8200)
 
  -- Obso=
lete informational reference (is this intentional?): RFC 3068
  &n=
bsp;  (Obsoleted by RFC 7526)
 
  -- Obso=
lete informational reference (is this intentional?): RFC 3627
  &n=
bsp;  (Obsoleted by RFC 6547)
 
Thank you
 
Gyan

 

On Mon, Nov 4, 2019 at 9= :38 AM Eric Vyncke (evyncke) <evynck= e@cisco.com> wrote:

Hello Gyan,

Thank you for reminding the author to post the 'gist' of the changes with ve= rsion -21.

Our OPS AD, Warren "Ace" Kumari,  has kindly reviewed our document and h= as identified more than 70 areas where the text was ambiguous or using bad E= nglish... No wonder, none of the 4 authors are English-speaking native: it i= s a mix of Estonian (Merike who also speaks German and Russian[1]), one of the 22 (?) language of India (KK), Ge= rman (Enno who also speaks French and Spanish) and French (myself also speak= ing Dutch) __ __ IETF community is really diverse !

Thank you very much in advance for finalizing the shepherd write-up

-=C3=A9ric

[1] I can be wrong for Merike BTW but she is quadri-lingual

On 04/11/2019, 15:26, "Gyan Mishra" <hayabusagsm@gmail.com> wrote:

    Hi Eric

    Just checking what the updates are that went in v21 since this= document is now ready to be published just pending my Shepard writeup which= I plan to finish this week. 

    Thank you

    Gyan

    Sent from my iPhone

    > On Nov 3, 2019, at 4:56 PM, internet-drafts@ietf.org wrote:
    >
    >
    > A New Internet-Draft is available from the on-line Intern= et-Drafts directories.
    > This draft is a work item of the Operational Security Cap= abilities for IP Network Infrastructure WG of the IETF.
    >
    >        Title      &nbs= p;    : Operational Security Considerations for IPv6 Networks
    >        Authors      &n= bsp;  : Eric Vyncke
    >                &n= bsp;         Kiran Kumar Chittimaneni
    >                &n= bsp;         Merike Kaeo
    >                &n= bsp;         Enno Rey
    >    Filename        : draft-= ietf-opsec-v6-21.txt
    >    Pages          &nbs= p;: 52
    >    Date           = ; : 2019-11-03
    >
    > Abstract:
    >   Knowledge and experience on how to operate IP= v4 securely is
    >   available: whether it is the Internet or an e= nterprise internal
    >   network.  However, IPv6 presents some ne= w security challenges.  RFC
    >   4942 describes the security issues in the pro= tocol but network
    >   managers also need a more practical, operatio= ns-minded document to
    >   enumerate advantages and/or disadvantages of c= ertain choices.
    >
    >   This document analyzes the operational securi= ty issues in several
    >   places of a network (enterprises, service pro= viders and residential
    >   users) and proposes technical and procedural m= itigations techniques.
    >   Some very specific places of a network such a= s the Internet of Things
    >   are not discussed in this document.
    >
    >
    > 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-21
    > https://datatracker.ietf.org/doc/html/draft-ietf-opsec-v6-21
    >
    > A diff from the previous version is available at:
    > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-v6-21
    >
    >
    > 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/
    >
    > _______________________________________________
    > OPSEC mailing list
    > OPSEC= @ietf.org
    > https://www.ietf.org/mailman/listinfo/opsec


 

--

Gyan S. Mishra

IT Network Engineering & Technology <= /span>

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor=

Silver Spring, MD 20904

United States

Phone: 301 502-1347

=

Email: gyan.s.mishra@ver= izon.com

www.linkedin.com/in/networking-tec= hnologies-consultant

 

= --Apple-Mail-BFF9F50D-7C99-4C6E-898C-AF329BFE27B1-- From nobody Sat Nov 9 12:10:05 2019 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 5B5241200B7 for ; Sat, 9 Nov 2019 12:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lymq5UYGmG38 for ; Sat, 9 Nov 2019 12:10:00 -0800 (PST) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 8151712001A for ; Sat, 9 Nov 2019 12:10:00 -0800 (PST) Received: by mail-qt1-x82f.google.com with SMTP id 30so10890657qtz.12 for ; Sat, 09 Nov 2019 12:10:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=t4FmN4SwtXjy+E5OGOZi/5TNyX0QkFAMRQXj8z99ZaE=; b=njxbPhszY+gEfvDHewXFwMxYiN8Tn9/9r8yTfkI3lTuFEbTAqLBudXzZNq609SFoXy hyLdKCB+7RACLJrfOzew8ql3a/+vd5dQdZXbZZedODBnyGSijhP6yRuczM4aRfUxFqM9 UyrDsL4n7liRqeIZineQulIQoGihM89uNQp+SHG7/9ICbv/fO3dKNG5px3kaY44EOiVq I3rVppBCaAV+omNmBjUweMRX4UdSVDVpF8G1DAfpADJuHYO+OEWc8N2HkyWNmwJS3Mz1 mAFF3NcCktHmnASpthkFWykS3rhKgIV90L2fkNRQfwR23+UWcfKmn6ZqcGGCN+fWOZB2 e/cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=t4FmN4SwtXjy+E5OGOZi/5TNyX0QkFAMRQXj8z99ZaE=; b=ognG2IARurUwOVxrCcBa5xAKfmsrvoPSzjqWPnSsSFo1y9isj50D1ppM7TxfTt8aBs qKalc0f7tRbmDu9rJ/SyOXm+iwaHk1lD2/2pm58Zh1wpYSFazxKPcrDWhNNW/V/6dVYo YHt0Tyg7IfWYRA672GR0d3dpDVSZcnN6LPPljHoHztbk90PxUwfohsHoKgAwp85EqlfL SZBi8ZPpq76tgbhfoEGHg4X5nWRXmylQlEWQM3KNF4MY7xSTGQI2nKGjw5D4bXDi730Z 85lPPlV8a7HEPg2e4D0HOUio/xYxlQd6zVfltAH2OrTyGHj1X8vAeLuZQAPuvRhBWnEW 3gRQ== X-Gm-Message-State: APjAAAVjwcHpEAtok4QwKRju0stzRcTHMGHu8mwWgS/C/+Y5gEsmozKN 08tWND2FqeKqGr8Ne2bG82vQzaaA2D4= X-Google-Smtp-Source: APXvYqzTYcPPIKJUb68v4LGsmyTS6PzSXARQDX51nMptSXHViH+AxkN6Rz30AsnylyTNyU8MWvQvZg== X-Received: by 2002:ac8:18af:: with SMTP id s44mr18086428qtj.1.1573330198767; Sat, 09 Nov 2019 12:09:58 -0800 (PST) Received: from [192.168.1.213] (pool-72-83-194-140.washdc.fios.verizon.net. [72.83.194.140]) by smtp.gmail.com with ESMTPSA id f5sm4573237qkl.85.2019.11.09.12.09.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Nov 2019 12:09:57 -0800 (PST) From: Gyan Mishra X-Google-Original-From: Gyan Mishra Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (16G102) In-Reply-To: Date: Sat, 9 Nov 2019 15:09:57 -0500 Cc: "Eric Vyncke (evyncke)" , "opsec@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <157281820483.13177.8617036261217670675@ietfa.amsl.com> <82AA0F9C-7836-464F-8F19-69FEDB197D53@gmail.com> <1AAA80C6-080B-492D-ABC9-645B9CEFDC99@cisco.com> <3BB16B9C-9065-466B-9A9A-51C5D314E126@cisco.com> To: Bob Hinden Archived-At: Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-21.txt 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, 09 Nov 2019 20:10:03 -0000 > On Nov 9, 2019, at 11:46 AM, Bob Hinden wrote: >=20 > Eric, >=20 >> On Nov 8, 2019, at 11:57 PM, Eric Vyncke (evyncke) wr= ote: >>=20 >> Gyan >>=20 >> Thank you very much for your shepherd write-up, very much appreciated by t= he authors. >>=20 >> The list of the =E2=80=98obsoleted=E2=80=99 references is intentional ind= eed to ensure that readers understand that =E2=80=98old=E2=80=99 documents h= ave been replaced. The text in the document is clear about the obsolete and c= urrent document. So, we do prefer to leave the references like they are as w= e believe that they make the document more valuable for the reader. >=20 > I went back and reread this. The text: >=20 > 2.2.2. Hop-by-Hop Options Header >=20 > The hop-by-hop options header, when present in an IPv6 packet, forces > all nodes in the path to inspect this header in the original IPv6 > specification [RFC2460]. This enables denial of service attacks as > most, if not all, routers cannot process this kind of packets in > hardware but have to 'punt' this packet for software processing. > Section 4.3 of the current Internet Standard for IPv6, [RFC8200], has > taken this attack vector into account and made the processing of hop- > by-hop options header by intermediate routers optional. >=20 > I don=E2=80=99t understand why this is talking about RFC2460 at all. Seem= s like it would less confusing to only describe what is in RFC8200. Nor is =E2= =80=9Cpunt=E2=80=9D correct way to describe this. Way too colloquial. >=20 > Describing RFC8200 behavior as =E2=80=9Coptional" is quite right, RFC8200 s= ays: >=20 > ...now expected that nodes along a packet's delivery path only examine a= nd process the > Hop-by-Hop Options header if explicitly configured to do so >=20 > It=E2=80=99s not optional if configured to do so. It would be better to u= se the RFC8200 words. >=20 > Lastly the =E2=80=9COriginal" IPv6 Specification was RFC1883. >=20 > Bob >=20 > p.s. I agree about the references to RFC 3068 and RFC 3627. >=20 > [Gyan] I agree with Bob about RFC 8200 as it=E2=80=99s a major update to t= he original IPv6 specification written in 1998 by Bob as well. The other tw= o are minor and agree to the historical deprecated informational references.= The term =E2=80=9Cpunt to cpu=E2=80=9D is commonly used by router vendors wh= en switching from the slow software switched path which hits the RP CPU vers= us the hardware switched fast path which remains on the line card NP process= or. >=20 >=20 >=20 >=20 >=20 >>=20 >> Regards >>=20 >> -=C3=A9ric >>=20 >> From: Gyan Mishra >> Date: Saturday, 9 November 2019 at 08:28 >> To: Eric Vyncke >> Cc: "opsec@ietf.org" , "i-d-announce@ietf.org" >> Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-21.txt >>=20 >> Eric >>=20 >> I submitted the shepherd write-up. >>=20 >> I ran the idnits and it found the following obsolete references. We shou= ld clear that up before we publish it. I can update my comments on that onc= e the draft is updated. >> Checking references for intended status: Informational >> ------------------------------------------------------------------------= ---- >>=20 >> -- Obsolete informational reference (is this intentional?): RFC 2460 >> (Obsoleted by RFC 8200) >>=20 >> -- Obsolete informational reference (is this intentional?): RFC 3068 >> (Obsoleted by RFC 7526) >>=20 >> -- Obsolete informational reference (is this intentional?): RFC 3627 >> (Obsoleted by RFC 6547) >>=20 >> Thank you >>=20 >> Gyan >>=20 >>> On Mon, Nov 4, 2019 at 9:38 AM Eric Vyncke (evyncke) = wrote: >>> Hello Gyan, >>>=20 >>> Thank you for reminding the author to post the 'gist' of the changes wit= h version -21. >>>=20 >>> Our OPS AD, Warren "Ace" Kumari, has kindly reviewed our document and h= as identified more than 70 areas where the text was ambiguous or using bad E= nglish... No wonder, none of the 4 authors are English-speaking native: it i= s a mix of Estonian (Merike who also speaks German and Russian[1]), one of t= he 22 (?) language of India (KK), German (Enno who also speaks French and Sp= anish) and French (myself also speaking Dutch) __ __ IETF community is reall= y diverse ! >>>=20 >>> Thank you very much in advance for finalizing the shepherd write-up >>>=20 >>> -=C3=A9ric >>>=20 >>> [1] I can be wrong for Merike BTW but she is quadri-lingual >>>=20 >>> On 04/11/2019, 15:26, "Gyan Mishra" wrote: >>>=20 >>> Hi Eric >>>=20 >>> Just checking what the updates are that went in v21 since this docume= nt is now ready to be published just pending my Shepard writeup which I plan= to finish this week. >>>=20 >>> Thank you >>>=20 >>> Gyan >>>=20 >>> Sent from my iPhone >>>=20 >>>> On Nov 3, 2019, at 4:56 PM, internet-drafts@ietf.org wrote: >>>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. >>>> This draft is a work item of the Operational Security Capabilities for I= P Network Infrastructure WG of the IETF. >>>>=20 >>>> Title : Operational Security Considerations for IPv6 Ne= tworks >>>> Authors : Eric Vyncke >>>> Kiran Kumar Chittimaneni >>>> Merike Kaeo >>>> Enno Rey >>>> Filename : draft-ietf-opsec-v6-21.txt >>>> Pages : 52 >>>> Date : 2019-11-03 >>>>=20 >>>> Abstract: >>>> Knowledge and experience on how to operate IPv4 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. >>>>=20 >>>> This document analyzes the operational security issues in several >>>> places of a network (enterprises, service providers and residential >>>> users) and proposes technical and procedural mitigations techniques. >>>> Some very specific places of a network such as the Internet of Things >>>> are not discussed in this document. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ >>>>=20 >>>> There are also htmlized versions available at: >>>> https://tools.ietf.org/html/draft-ietf-opsec-v6-21 >>>> https://datatracker.ietf.org/doc/html/draft-ietf-opsec-v6-21 >>>>=20 >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-v6-21 >>>>=20 >>>>=20 >>>> Please note that it may take a couple of minutes from the time of submi= ssion >>>> until the htmlized version and diff are available at tools.ietf.org. >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> _______________________________________________ >>>> OPSEC mailing list >>>> OPSEC@ietf.org >>>> https://www.ietf.org/mailman/listinfo/opsec >>>=20 >>>=20 >>=20 >>=20 >> -- >> Gyan S. Mishra >> IT Network Engineering & Technology >> Verizon Communications Inc. (VZ) >> 13101 Columbia Pike FDC1 3rd Floor >> Silver Spring, MD 20904 >> United States >> Phone: 301 502-1347 >> Email: gyan.s.mishra@verizon.com >> www.linkedin.com/in/networking-technologies-consultant >>=20 >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec >=20 From nobody Sat Nov 9 12:54:15 2019 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 9F964120048 for ; Sat, 9 Nov 2019 12:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Fa2JilLZwPw for ; Sat, 9 Nov 2019 12:54:09 -0800 (PST) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 323CF120020 for ; Sat, 9 Nov 2019 12:54:09 -0800 (PST) Received: by mail-wm1-x336.google.com with SMTP id a17so9143154wmb.0 for ; Sat, 09 Nov 2019 12:54:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Xkyy2O+9ktc3GXquWI0xmNoDoymrxHg/8c+s53IKawU=; b=aah5PdQWWwANAxWCtz8ncFY0TzB/MEjyNx2DS8RcTcai3h/TE3aUq6HoCnlv1N1CdW 4Z682obdADdJYnGqyBoV0RSGIAdHdtFqt2lWrfENTGn2wFfwwOcQFM6MTn4ktvcZ8qtb Zq4tLRKiOVzV0ZBDSt1fjn58YFhfefuqmwCEp6C0lXzmHdl2ISwe/iFUIW+KW5S/aZvs C1WlL+ARCDMmx/IDVuZoMp9POEk3n6F+4Lg0761R21IFsC0blBdybJMfYtfQeU13Cw+v zBSM9OsuO5FApHGlAcM/JJfhgXWZUJae0PpUMrKLkfU4SLI4e9PTKGQc9Puxids2yObh PGxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Xkyy2O+9ktc3GXquWI0xmNoDoymrxHg/8c+s53IKawU=; b=NfQ8ib7CMKpz+4G6mK1veaZCgoQkNMzr6kvMnSlxvUQXzFZeGZMpOQu+Z2YiqyhsUH SArlCm0favrE8E3NA9/ZPWEEfo9ZV111sFa1HQruNNkOlWuO3M/+EmIF8pfeQdamFJqX TdFLO0TXHhdps/9Tgf6DhvFPILRuYdJg40EPrnPq5spPOHjYqrter09cTHxPY4jm4fm1 U8ED2DE5KM8GywYDLt9Lw6cecxELETnjHcNxnFl7E+aO2FvNAG0DL/iTI1EVCMXGLxDO Tmts0BYmrObn51v3Bz4GooBQuIRCf0KSgJvvW82sRyfh9LENm1UXFaWNU+Bpo11I4MNi TLzQ== X-Gm-Message-State: APjAAAWXYowf4MduY5ktcJvwfUx778bArytFBq/+fgr1xsy+2TFzoN/Y m0+Wwp2LjMWUcRtJhF1k+r0= X-Google-Smtp-Source: APXvYqxF//xQxX50IrrAarQ4etkfua2VzJmM02EeRGfFuqvYmrLNjEf0aQwZnCXvTfBDLpXLXz/d/w== X-Received: by 2002:a7b:c408:: with SMTP id k8mr14856117wmi.67.1573332847383; Sat, 09 Nov 2019 12:54:07 -0800 (PST) Received: from ?IPv6:2601:647:5a00:ef0b:5c31:9c68:be8f:6bac? ([2601:647:5a00:ef0b:5c31:9c68:be8f:6bac]) by smtp.gmail.com with ESMTPSA id t133sm15992215wmb.1.2019.11.09.12.54.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Nov 2019 12:54:06 -0800 (PST) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_F98B8A53-B602-4F56-8EA0-8782CF111639"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 9 Nov 2019 12:54:01 -0800 In-Reply-To: Cc: Bob Hinden , "Eric Vyncke (evyncke)" , "opsec@ietf.org" To: Gyan Mishra References: <157281820483.13177.8617036261217670675@ietfa.amsl.com> <82AA0F9C-7836-464F-8F19-69FEDB197D53@gmail.com> <1AAA80C6-080B-492D-ABC9-645B9CEFDC99@cisco.com> <3BB16B9C-9065-466B-9A9A-51C5D314E126@cisco.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-21.txt 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, 09 Nov 2019 20:54:13 -0000 --Apple-Mail=_F98B8A53-B602-4F56-8EA0-8782CF111639 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Gyan, > On Nov 9, 2019, at 12:09 PM, Gyan Mishra = wrote: >=20 >=20 >=20 >=20 >> On Nov 9, 2019, at 11:46 AM, Bob Hinden wrote: >>=20 >> Eric, >>=20 >>> On Nov 8, 2019, at 11:57 PM, Eric Vyncke (evyncke) = wrote: >>>=20 >>> Gyan >>>=20 >>> Thank you very much for your shepherd write-up, very much = appreciated by the authors. >>>=20 >>> The list of the =E2=80=98obsoleted=E2=80=99 references is = intentional indeed to ensure that readers understand that =E2=80=98old=E2=80= =99 documents have been replaced. The text in the document is clear = about the obsolete and current document. So, we do prefer to leave the = references like they are as we believe that they make the document more = valuable for the reader. >>=20 >> I went back and reread this. The text: >>=20 >> 2.2.2. Hop-by-Hop Options Header >>=20 >> The hop-by-hop options header, when present in an IPv6 packet, = forces >> all nodes in the path to inspect this header in the original IPv6 >> specification [RFC2460]. This enables denial of service attacks as >> most, if not all, routers cannot process this kind of packets in >> hardware but have to 'punt' this packet for software processing. >> Section 4.3 of the current Internet Standard for IPv6, [RFC8200], = has >> taken this attack vector into account and made the processing of = hop- >> by-hop options header by intermediate routers optional. >>=20 >> I don=E2=80=99t understand why this is talking about RFC2460 at all. = Seems like it would less confusing to only describe what is in RFC8200. = Nor is =E2=80=9Cpunt=E2=80=9D correct way to describe this. Way too = colloquial. >>=20 >> Describing RFC8200 behavior as =E2=80=9Coptional" is quite right, = RFC8200 says: >>=20 >> ...now expected that nodes along a packet's delivery path only = examine and process the >> Hop-by-Hop Options header if explicitly configured to do so >>=20 >> It=E2=80=99s not optional if configured to do so. It would be better = to use the RFC8200 words. >>=20 >> Lastly the =E2=80=9COriginal" IPv6 Specification was RFC1883. >>=20 >> Bob >>=20 >> p.s. I agree about the references to RFC 3068 and RFC 3627. >>=20 >> [Gyan] I agree with Bob about RFC 8200 as it=E2=80=99s a major update = to the original IPv6 specification written in 1998 by Bob as well. The = other two are minor and agree to the historical deprecated informational = references. >=20 > The term =E2=80=9Cpunt to cpu=E2=80=9D is commonly used by router = vendors when switching from the slow software switched path which hits = the RP CPU versus the hardware switched fast path which remains on the = line card NP processor. I understand what it means, but as I said its colloquial and may not be = clear to some readers. Not appropriate for a document like this, IMHO. Bob >>=20 >>=20 >>=20 >>=20 >>=20 >>>=20 >>> Regards >>>=20 >>> -=C3=A9ric >>>=20 >>> From: Gyan Mishra >>> Date: Saturday, 9 November 2019 at 08:28 >>> To: Eric Vyncke >>> Cc: "opsec@ietf.org" , "i-d-announce@ietf.org" = >>> Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-21.txt >>>=20 >>> Eric >>>=20 >>> I submitted the shepherd write-up. >>>=20 >>> I ran the idnits and it found the following obsolete references. We = should clear that up before we publish it. I can update my comments on = that once the draft is updated. >>> Checking references for intended status: Informational >>> = --------------------------------------------------------------------------= -- >>>=20 >>> -- Obsolete informational reference (is this intentional?): RFC 2460 >>> (Obsoleted by RFC 8200) >>>=20 >>> -- Obsolete informational reference (is this intentional?): RFC 3068 >>> (Obsoleted by RFC 7526) >>>=20 >>> -- Obsolete informational reference (is this intentional?): RFC 3627 >>> (Obsoleted by RFC 6547) >>>=20 >>> Thank you >>>=20 >>> Gyan >>>=20 >>>> On Mon, Nov 4, 2019 at 9:38 AM Eric Vyncke (evyncke) = wrote: >>>> Hello Gyan, >>>>=20 >>>> Thank you for reminding the author to post the 'gist' of the = changes with version -21. >>>>=20 >>>> Our OPS AD, Warren "Ace" Kumari, has kindly reviewed our document = and has identified more than 70 areas where the text was ambiguous or = using bad English... No wonder, none of the 4 authors are = English-speaking native: it is a mix of Estonian (Merike who also speaks = German and Russian[1]), one of the 22 (?) language of India (KK), German = (Enno who also speaks French and Spanish) and French (myself also = speaking Dutch) __ __ IETF community is really diverse ! >>>>=20 >>>> Thank you very much in advance for finalizing the shepherd write-up >>>>=20 >>>> -=C3=A9ric >>>>=20 >>>> [1] I can be wrong for Merike BTW but she is quadri-lingual >>>>=20 >>>> On 04/11/2019, 15:26, "Gyan Mishra" wrote: >>>>=20 >>>> Hi Eric >>>>=20 >>>> Just checking what the updates are that went in v21 since this = document is now ready to be published just pending my Shepard writeup = which I plan to finish this week. >>>>=20 >>>> Thank you >>>>=20 >>>> Gyan >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>>> On Nov 3, 2019, at 4:56 PM, internet-drafts@ietf.org wrote: >>>>>=20 >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Title : Operational Security Considerations for = IPv6 Networks >>>>> Authors : Eric Vyncke >>>>> Kiran Kumar Chittimaneni >>>>> Merike Kaeo >>>>> Enno Rey >>>>> Filename : draft-ietf-opsec-v6-21.txt >>>>> Pages : 52 >>>>> Date : 2019-11-03 >>>>>=20 >>>>> Abstract: >>>>> Knowledge and experience on how to operate IPv4 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. >>>>>=20 >>>>> This document analyzes the operational security issues in several >>>>> places of a network (enterprises, service providers and = residential >>>>> users) and proposes technical and procedural mitigations = techniques. >>>>> Some very specific places of a network such as the Internet of = Things >>>>> are not discussed in this document. >>>>>=20 >>>>>=20 >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ >>>>>=20 >>>>> There are also htmlized versions available at: >>>>> https://tools.ietf.org/html/draft-ietf-opsec-v6-21 >>>>> https://datatracker.ietf.org/doc/html/draft-ietf-opsec-v6-21 >>>>>=20 >>>>> A diff from the previous version is available at: >>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-v6-21 >>>>>=20 >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>=20 >>>>> _______________________________________________ >>>>> OPSEC mailing list >>>>> OPSEC@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/opsec >>>>=20 >>>>=20 >>>=20 >>>=20 >>> -- >>> Gyan S. Mishra >>> IT Network Engineering & Technology >>> Verizon Communications Inc. (VZ) >>> 13101 Columbia Pike FDC1 3rd Floor >>> Silver Spring, MD 20904 >>> United States >>> Phone: 301 502-1347 >>> Email: gyan.s.mishra@verizon.com >>> www.linkedin.com/in/networking-technologies-consultant >>>=20 >>> _______________________________________________ >>> OPSEC mailing list >>> OPSEC@ietf.org >>> https://www.ietf.org/mailman/listinfo/opsec >>=20 --Apple-Mail=_F98B8A53-B602-4F56-8EA0-8782CF111639 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAl3HJ2kACgkQrut0EXfn u6hIxgf8CTqBrk7t5y3dg6q1mpsp+8Eou1QXGt4NeC1JJB/qNdeuw9I8fWnoeliH XcFIlEpW+q0am3LaZnFTONbkTmOq62A6ZLOchBf+WqsgG9m2iRiAqA4qjmwJt+cC qTTKlFVjSV+echfzcV17iypBdL1lHxaQtXFCZxMbHY9guHN43EWmzzJclrW0tCXE 6sAaCG+3z5CPPbZJ37xAsJ9jMD3sChMdzXccAcpTQHjrUq5gs1ktm4JVQO225oTG pCmtBnHBxEPU8NKPgaPkekb1i8lU/Ru2bOJacp53Lrbewpbmhhr6TIg5ZrWdcxMP jKhN3DWgqbW99w+MBs+Rj+eeVtXn8w== =agvO -----END PGP SIGNATURE----- --Apple-Mail=_F98B8A53-B602-4F56-8EA0-8782CF111639-- From nobody Sat Nov 9 13:08:23 2019 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 BC8281200D6 for ; Sat, 9 Nov 2019 13:08:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBOhMPe9uC-J for ; Sat, 9 Nov 2019 13:08:18 -0800 (PST) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 B2ED712008D for ; Sat, 9 Nov 2019 13:08:17 -0800 (PST) Received: by mail-qk1-x732.google.com with SMTP id z16so8116553qkg.7 for ; Sat, 09 Nov 2019 13:08:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hEqSGT7UCZT2deuDSE/gzae6DHmJ4Zrcan8ibXJzBCg=; b=qFAtxF0/VFb03+9KjohmB2U1YE/7uv/C/wY/QrbfWykkiv60r2ra0K99WzbE+cUrTH bo0f1+YLeU6gzUirL+jncNBQccCv9YEN/fj7VoPvuDMpbb6Cby2Av0m0P6TGkPqsxjA2 jgiScsDLvWpZRUoQKsPGcFke2HYrIk9RCILY22QV5dT8FcRySHRMv9nyN9l2EA6jTZ+U pETLPTF0vtWTHlibwztKDkiWnXGonlAgbQslW9ejQhyzij53IP/RZTWnVsB98rDvB652 vFTHogB5z5Prny4Gf2p21A29G09fVjbLeGHNp84YV6DSk+mHfAX1sbEPZCeKw2q8NSoj eEJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hEqSGT7UCZT2deuDSE/gzae6DHmJ4Zrcan8ibXJzBCg=; b=o7NnU2xNMvV0Kg+VvuG1mA1Vp5xWLR0A3hfUlIcGKCTB9xqXpTtuLsNFzufAk4eYSv J5wzVomhJqfXoNw8o/CIe1CF5Q+TBT6qGWT60zfJoS3wn4KOg6g0mkH93ZmzYDYYxLiw k+j95jMQsm8ZsgD7fafgsB5GW4kwPR5KMOM7Rxgf+uBvfqfJ1DABbrNCfPHSNllkbHY0 tAXrP0ahE/8MkuLslfnh9GyZuRg+3HTmiJX/ArIpTXFaBIhJMmW/3rcB92qtALmRHxaN tYs4n8HvET0ukHDq9QChu1pkCu2ceXMpTXRRK664ykqSTsGFqMZgXRtIsDK9SP1EZa9k oNWw== X-Gm-Message-State: APjAAAXBYeOanq/b8CF6jdSGvhnP8y8Qbah+uDWF7yAa47EzEeU0dZIC 1omFt/WvdT2rWPqOWEFlOmlH03SvQzw= X-Google-Smtp-Source: APXvYqyP4iwSiDjuVSvt3IXo8/1F5gR1SlYHkFAwYrk54PUkL7rotf879s5S3UrB5SpY6EHU1TelLg== X-Received: by 2002:a37:5942:: with SMTP id n63mr3573509qkb.432.1573333695807; Sat, 09 Nov 2019 13:08:15 -0800 (PST) Received: from [192.168.1.213] (pool-72-83-194-140.washdc.fios.verizon.net. [72.83.194.140]) by smtp.gmail.com with ESMTPSA id h3sm7162824qte.62.2019.11.09.13.08.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Nov 2019 13:08:13 -0800 (PST) From: Gyan Mishra X-Google-Original-From: Gyan Mishra Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (16G102) In-Reply-To: Date: Sat, 9 Nov 2019 16:08:13 -0500 Cc: "Eric Vyncke (evyncke)" , "opsec@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <157281820483.13177.8617036261217670675@ietfa.amsl.com> <82AA0F9C-7836-464F-8F19-69FEDB197D53@gmail.com> <1AAA80C6-080B-492D-ABC9-645B9CEFDC99@cisco.com> <3BB16B9C-9065-466B-9A9A-51C5D314E126@cisco.com> To: Bob Hinden Archived-At: Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-21.txt 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, 09 Nov 2019 21:08:22 -0000 > On Nov 9, 2019, at 3:54 PM, Bob Hinden wrote: >=20 > Gyan, >=20 >> On Nov 9, 2019, at 12:09 PM, Gyan Mishra wrote: >>=20 >>=20 >>=20 >>=20 >>> On Nov 9, 2019, at 11:46 AM, Bob Hinden wrote: >>>=20 >>> Eric, >>>=20 >>>> On Nov 8, 2019, at 11:57 PM, Eric Vyncke (evyncke) w= rote: >>>>=20 >>>> Gyan >>>>=20 >>>> Thank you very much for your shepherd write-up, very much appreciated b= y the authors. >>>>=20 >>>> The list of the =E2=80=98obsoleted=E2=80=99 references is intentional i= ndeed to ensure that readers understand that =E2=80=98old=E2=80=99 documents= have been replaced. The text in the document is clear about the obsolete an= d current document. So, we do prefer to leave the references like they are a= s we believe that they make the document more valuable for the reader. >>>=20 >>> I went back and reread this. The text: >>>=20 >>> 2.2.2. Hop-by-Hop Options Header >>>=20 >>> The hop-by-hop options header, when present in an IPv6 packet, forces >>> all nodes in the path to inspect this header in the original IPv6 >>> specification [RFC2460]. This enables denial of service attacks as >>> most, if not all, routers cannot process this kind of packets in >>> hardware but have to 'punt' this packet for software processing. >>> Section 4.3 of the current Internet Standard for IPv6, [RFC8200], has >>> taken this attack vector into account and made the processing of hop- >>> by-hop options header by intermediate routers optional. >>>=20 >>> I don=E2=80=99t understand why this is talking about RFC2460 at all. Se= ems like it would less confusing to only describe what is in RFC8200. Nor i= s =E2=80=9Cpunt=E2=80=9D correct way to describe this. Way too colloquial.= >>>=20 >>> Describing RFC8200 behavior as =E2=80=9Coptional" is quite right, RFC820= 0 says: >>>=20 >>> ...now expected that nodes along a packet's delivery path only examine a= nd process the >>> Hop-by-Hop Options header if explicitly configured to do so >>>=20 >>> It=E2=80=99s not optional if configured to do so. It would be better to= use the RFC8200 words. >>>=20 >>> Lastly the =E2=80=9COriginal" IPv6 Specification was RFC1883. >>>=20 >>> Bob >>>=20 >>> p.s. I agree about the references to RFC 3068 and RFC 3627. >>>=20 >>> [Gyan] I agree with Bob about RFC 8200 as it=E2=80=99s a major update to= the original IPv6 specification written in 1998 by Bob as well. The other t= wo are minor and agree to the historical deprecated informational references= . >>=20 >> The term =E2=80=9Cpunt to cpu=E2=80=9D is commonly used by router vendors= when switching from the slow software switched path which hits the RP CPU v= ersus the hardware switched fast path which remains on the line card NP proc= essor. >=20 > I understand what it means, but as I said its colloquial and may not be cl= ear to some readers. Not appropriate for a document like this, IMHO. >=20 > Bob >=20 Understood. How about =E2=80=9Cforward=E2=80=9D or =E2=80=9Credirect=E2=80=9D= . >=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>>=20 >>>> Regards >>>>=20 >>>> -=C3=A9ric >>>>=20 >>>> From: Gyan Mishra >>>> Date: Saturday, 9 November 2019 at 08:28 >>>> To: Eric Vyncke >>>> Cc: "opsec@ietf.org" , "i-d-announce@ietf.org" >>>> Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-21.txt >>>>=20 >>>> Eric >>>>=20 >>>> I submitted the shepherd write-up. >>>>=20 >>>> I ran the idnits and it found the following obsolete references. We sh= ould clear that up before we publish it. I can update my comments on that o= nce the draft is updated. >>>> Checking references for intended status: Informational >>>> -----------------------------------------------------------------------= ----- >>>>=20 >>>> -- Obsolete informational reference (is this intentional?): RFC 2460 >>>> (Obsoleted by RFC 8200) >>>>=20 >>>> -- Obsolete informational reference (is this intentional?): RFC 3068 >>>> (Obsoleted by RFC 7526) >>>>=20 >>>> -- Obsolete informational reference (is this intentional?): RFC 3627 >>>> (Obsoleted by RFC 6547) >>>>=20 >>>> Thank you >>>>=20 >>>> Gyan >>>>=20 >>>>> On Mon, Nov 4, 2019 at 9:38 AM Eric Vyncke (evyncke) wrote: >>>>> Hello Gyan, >>>>>=20 >>>>> Thank you for reminding the author to post the 'gist' of the changes w= ith version -21. >>>>>=20 >>>>> Our OPS AD, Warren "Ace" Kumari, has kindly reviewed our document and= has identified more than 70 areas where the text was ambiguous or using bad= English... No wonder, none of the 4 authors are English-speaking native: it= is a mix of Estonian (Merike who also speaks German and Russian[1]), one of= the 22 (?) language of India (KK), German (Enno who also speaks French and S= panish) and French (myself also speaking Dutch) __ __ IETF community is real= ly diverse ! >>>>>=20 >>>>> Thank you very much in advance for finalizing the shepherd write-up >>>>>=20 >>>>> -=C3=A9ric >>>>>=20 >>>>> [1] I can be wrong for Merike BTW but she is quadri-lingual >>>>>=20 >>>>> On 04/11/2019, 15:26, "Gyan Mishra" wrote: >>>>>=20 >>>>> Hi Eric >>>>>=20 >>>>> Just checking what the updates are that went in v21 since this docume= nt is now ready to be published just pending my Shepard writeup which I plan= to finish this week. >>>>>=20 >>>>> Thank you >>>>>=20 >>>>> Gyan >>>>>=20 >>>>> Sent from my iPhone >>>>>=20 >>>>>> On Nov 3, 2019, at 4:56 PM, internet-drafts@ietf.org wrote: >>>>>>=20 >>>>>>=20 >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts di= rectories. >>>>>> This draft is a work item of the Operational Security Capabilities fo= r IP Network Infrastructure WG of the IETF. >>>>>>=20 >>>>>> Title : Operational Security Considerations for IPv6 Ne= tworks >>>>>> Authors : Eric Vyncke >>>>>> Kiran Kumar Chittimaneni >>>>>> Merike Kaeo >>>>>> Enno Rey >>>>>> Filename : draft-ietf-opsec-v6-21.txt >>>>>> Pages : 52 >>>>>> Date : 2019-11-03 >>>>>>=20 >>>>>> Abstract: >>>>>> Knowledge and experience on how to operate IPv4 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. >>>>>>=20 >>>>>> This document analyzes the operational security issues in several >>>>>> places of a network (enterprises, service providers and residential >>>>>> users) and proposes technical and procedural mitigations techniques. >>>>>> Some very specific places of a network such as the Internet of Things= >>>>>> are not discussed in this document. >>>>>>=20 >>>>>>=20 >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ >>>>>>=20 >>>>>> There are also htmlized versions available at: >>>>>> https://tools.ietf.org/html/draft-ietf-opsec-v6-21 >>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-opsec-v6-21 >>>>>>=20 >>>>>> A diff from the previous version is available at: >>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-v6-21 >>>>>>=20 >>>>>>=20 >>>>>> Please note that it may take a couple of minutes from the time of sub= mission >>>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>>>=20 >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OPSEC mailing list >>>>>> OPSEC@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/opsec >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> Gyan S. Mishra >>>> IT Network Engineering & Technology >>>> Verizon Communications Inc. (VZ) >>>> 13101 Columbia Pike FDC1 3rd Floor >>>> Silver Spring, MD 20904 >>>> United States >>>> Phone: 301 502-1347 >>>> Email: gyan.s.mishra@verizon.com >>>> www.linkedin.com/in/networking-technologies-consultant >>>>=20 >>>> _______________________________________________ >>>> OPSEC mailing list >>>> OPSEC@ietf.org >>>> https://www.ietf.org/mailman/listinfo/opsec >>>=20 >=20 From nobody Sat Nov 9 13:34:58 2019 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 EAF9B1200EF for ; Sat, 9 Nov 2019 13:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwISUIXyhbaO for ; Sat, 9 Nov 2019 13:34:53 -0800 (PST) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CB321200E3 for ; Sat, 9 Nov 2019 13:34:53 -0800 (PST) Received: by mail-wr1-x431.google.com with SMTP id z10so5417280wrs.12 for ; Sat, 09 Nov 2019 13:34:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ucoDdXU1cgYlKghK7oe6gK8Vlmxv3bLrxWgW5ZV3C0w=; b=hSCkChuXeFuL4gQj41AfCwOa6W4TbRmIB7f/CaX+TFxm8jjyh6mUo/LpMUe1TMmwtQ p+W1NvGpzjS1mFXYVK9hDpEdDzJxJXyxqk5ZQUWKzbXxFxzfEj0amvPo5u5IEdPqNuOP oDVU0tuKlw/vuED/QQwhvh4ghz8yaEqx9aQsT9eN5HHJ3zd5yFVBp1LgmDF0GMb3t7Sv 0C5+brHF66vN86E0L02J/Z+9q/QOZcLFhoZmSolRQCfz1zQ6YLO76JY5RBS19Agm05Rt GU3TgUfEKzgrktrKuvCj0Y0Yi5yK8RWun5nJ2k3oxDsJ5FM02juzK3d4b2rD/lmMCcYd KmOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ucoDdXU1cgYlKghK7oe6gK8Vlmxv3bLrxWgW5ZV3C0w=; b=UrFQ7530c5kmFOWZwWZZOAa1m8XPtJ9XvjVZoAYbqfwrY6j/tvGxW9bV/C5l8ZbvrD 0KRPwMsJhh13OnetcoFB+dTHZ6PToviebQLHLfxDbdP5GzvQX/Lkx8oK/1KILaz4yczi liIOD5a6ltUyLMke3YwX59+DaT4uWsqFHpmv1KTzi+g/9q8UEZQSydFgi+SydOsBduM9 GezzV1/XM+2AAgcvS3w7CqA77ONtfb6h5hd8DTf8GJMXoelDqSUndsyDV/w1l6Munnqu KMhNKJqTaLhVq96EmLAuNId0oH82kMOpdE7Mri63GX81XVqI7yUwAuoLnBn2/tgyOr9k HvMw== X-Gm-Message-State: APjAAAUVBLyLlAR6gV45AumrM5W1JTyDSczwHsYhTfUdtCtPWicfg64r cZ8wDNffpSHf6gQdDjm+c8I= X-Google-Smtp-Source: APXvYqzwUJY56wxZCrf3+aoRD6rCsRHeS3CEMqlHbVAcXkUzRVZ3PhJGYNBfg3ykaLXbuozcukOPXA== X-Received: by 2002:a5d:6a43:: with SMTP id t3mr13877454wrw.268.1573335291836; Sat, 09 Nov 2019 13:34:51 -0800 (PST) Received: from ?IPv6:2601:647:5a00:ef0b:5c31:9c68:be8f:6bac? ([2601:647:5a00:ef0b:5c31:9c68:be8f:6bac]) by smtp.gmail.com with ESMTPSA id v128sm17475845wmb.14.2019.11.09.13.34.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Nov 2019 13:34:50 -0800 (PST) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_1E72827D-1798-41C3-A15C-E507AB2A6527"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 9 Nov 2019 13:34:45 -0800 In-Reply-To: Cc: Bob Hinden , "Eric Vyncke (evyncke)" , "opsec@ietf.org" To: Gyan Mishra References: <157281820483.13177.8617036261217670675@ietfa.amsl.com> <82AA0F9C-7836-464F-8F19-69FEDB197D53@gmail.com> <1AAA80C6-080B-492D-ABC9-645B9CEFDC99@cisco.com> <3BB16B9C-9065-466B-9A9A-51C5D314E126@cisco.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-21.txt 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, 09 Nov 2019 21:34:57 -0000 --Apple-Mail=_1E72827D-1798-41C3-A15C-E507AB2A6527 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Gyan, > On Nov 9, 2019, at 1:08 PM, Gyan Mishra wrote: >=20 >=20 >=20 >> On Nov 9, 2019, at 3:54 PM, Bob Hinden wrote: >>=20 >> Gyan, >>=20 >>> On Nov 9, 2019, at 12:09 PM, Gyan Mishra = wrote: >>>=20 >>>=20 >>>=20 >>>=20 >>>> On Nov 9, 2019, at 11:46 AM, Bob Hinden = wrote: >>>>=20 >>>> Eric, >>>>=20 >>>>> On Nov 8, 2019, at 11:57 PM, Eric Vyncke (evyncke) = wrote: >>>>>=20 >>>>> Gyan >>>>>=20 >>>>> Thank you very much for your shepherd write-up, very much = appreciated by the authors. >>>>>=20 >>>>> The list of the =E2=80=98obsoleted=E2=80=99 references is = intentional indeed to ensure that readers understand that =E2=80=98old=E2=80= =99 documents have been replaced. The text in the document is clear = about the obsolete and current document. So, we do prefer to leave the = references like they are as we believe that they make the document more = valuable for the reader. >>>>=20 >>>> I went back and reread this. The text: >>>>=20 >>>> 2.2.2. Hop-by-Hop Options Header >>>>=20 >>>> The hop-by-hop options header, when present in an IPv6 packet, = forces >>>> all nodes in the path to inspect this header in the original IPv6 >>>> specification [RFC2460]. This enables denial of service attacks as >>>> most, if not all, routers cannot process this kind of packets in >>>> hardware but have to 'punt' this packet for software processing. >>>> Section 4.3 of the current Internet Standard for IPv6, [RFC8200], = has >>>> taken this attack vector into account and made the processing of = hop- >>>> by-hop options header by intermediate routers optional. >>>>=20 >>>> I don=E2=80=99t understand why this is talking about RFC2460 at = all. Seems like it would less confusing to only describe what is in = RFC8200. Nor is =E2=80=9Cpunt=E2=80=9D correct way to describe this. = Way too colloquial. >>>>=20 >>>> Describing RFC8200 behavior as =E2=80=9Coptional" is quite right, = RFC8200 says: >>>>=20 >>>> ...now expected that nodes along a packet's delivery path only = examine and process the >>>> Hop-by-Hop Options header if explicitly configured to do so >>>>=20 >>>> It=E2=80=99s not optional if configured to do so. It would be = better to use the RFC8200 words. >>>>=20 >>>> Lastly the =E2=80=9COriginal" IPv6 Specification was RFC1883. >>>>=20 >>>> Bob >>>>=20 >>>> p.s. I agree about the references to RFC 3068 and RFC 3627. >>>>=20 >>>> [Gyan] I agree with Bob about RFC 8200 as it=E2=80=99s a major = update to the original IPv6 specification written in 1998 by Bob as = well. The other two are minor and agree to the historical deprecated = informational references. >>>=20 >>> The term =E2=80=9Cpunt to cpu=E2=80=9D is commonly used by router = vendors when switching from the slow software switched path which hits = the RP CPU versus the hardware switched fast path which remains on the = line card NP processor. >>=20 >> I understand what it means, but as I said its colloquial and may not = be clear to some readers. Not appropriate for a document like this, = IMHO. >>=20 >> Bob >>=20 > Understood. How about =E2=80=9Cforward=E2=80=9D or =E2=80=9Credirect=E2=80= =9D. That=E2=80=99s better. Thanks, Bob >=20 >>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> Regards >>>>>=20 >>>>> -=C3=A9ric >>>>>=20 >>>>> From: Gyan Mishra >>>>> Date: Saturday, 9 November 2019 at 08:28 >>>>> To: Eric Vyncke >>>>> Cc: "opsec@ietf.org" , "i-d-announce@ietf.org" = >>>>> Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-21.txt >>>>>=20 >>>>> Eric >>>>>=20 >>>>> I submitted the shepherd write-up. >>>>>=20 >>>>> I ran the idnits and it found the following obsolete references. = We should clear that up before we publish it. I can update my comments = on that once the draft is updated. >>>>> Checking references for intended status: Informational >>>>> = --------------------------------------------------------------------------= -- >>>>>=20 >>>>> -- Obsolete informational reference (is this intentional?): RFC = 2460 >>>>> (Obsoleted by RFC 8200) >>>>>=20 >>>>> -- Obsolete informational reference (is this intentional?): RFC = 3068 >>>>> (Obsoleted by RFC 7526) >>>>>=20 >>>>> -- Obsolete informational reference (is this intentional?): RFC = 3627 >>>>> (Obsoleted by RFC 6547) >>>>>=20 >>>>> Thank you >>>>>=20 >>>>> Gyan >>>>>=20 >>>>>> On Mon, Nov 4, 2019 at 9:38 AM Eric Vyncke (evyncke) = wrote: >>>>>> Hello Gyan, >>>>>>=20 >>>>>> Thank you for reminding the author to post the 'gist' of the = changes with version -21. >>>>>>=20 >>>>>> Our OPS AD, Warren "Ace" Kumari, has kindly reviewed our = document and has identified more than 70 areas where the text was = ambiguous or using bad English... No wonder, none of the 4 authors are = English-speaking native: it is a mix of Estonian (Merike who also speaks = German and Russian[1]), one of the 22 (?) language of India (KK), German = (Enno who also speaks French and Spanish) and French (myself also = speaking Dutch) __ __ IETF community is really diverse ! >>>>>>=20 >>>>>> Thank you very much in advance for finalizing the shepherd = write-up >>>>>>=20 >>>>>> -=C3=A9ric >>>>>>=20 >>>>>> [1] I can be wrong for Merike BTW but she is quadri-lingual >>>>>>=20 >>>>>> On 04/11/2019, 15:26, "Gyan Mishra" = wrote: >>>>>>=20 >>>>>> Hi Eric >>>>>>=20 >>>>>> Just checking what the updates are that went in v21 since this = document is now ready to be published just pending my Shepard writeup = which I plan to finish this week. >>>>>>=20 >>>>>> Thank you >>>>>>=20 >>>>>> Gyan >>>>>>=20 >>>>>> Sent from my iPhone >>>>>>=20 >>>>>>> On Nov 3, 2019, at 4:56 PM, internet-drafts@ietf.org wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> Title : Operational Security Considerations for = IPv6 Networks >>>>>>> Authors : Eric Vyncke >>>>>>> Kiran Kumar Chittimaneni >>>>>>> Merike Kaeo >>>>>>> Enno Rey >>>>>>> Filename : draft-ietf-opsec-v6-21.txt >>>>>>> Pages : 52 >>>>>>> Date : 2019-11-03 >>>>>>>=20 >>>>>>> Abstract: >>>>>>> Knowledge and experience on how to operate IPv4 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. >>>>>>>=20 >>>>>>> This document analyzes the operational security issues in = several >>>>>>> places of a network (enterprises, service providers and = residential >>>>>>> users) and proposes technical and procedural mitigations = techniques. >>>>>>> Some very specific places of a network such as the Internet of = Things >>>>>>> are not discussed in this document. >>>>>>>=20 >>>>>>>=20 >>>>>>> The IETF datatracker status page for this draft is: >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ >>>>>>>=20 >>>>>>> There are also htmlized versions available at: >>>>>>> https://tools.ietf.org/html/draft-ietf-opsec-v6-21 >>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-opsec-v6-21 >>>>>>>=20 >>>>>>> A diff from the previous version is available at: >>>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-v6-21 >>>>>>>=20 >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OPSEC mailing list >>>>>>> OPSEC@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/opsec >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- >>>>> Gyan S. Mishra >>>>> IT Network Engineering & Technology >>>>> Verizon Communications Inc. (VZ) >>>>> 13101 Columbia Pike FDC1 3rd Floor >>>>> Silver Spring, MD 20904 >>>>> United States >>>>> Phone: 301 502-1347 >>>>> Email: gyan.s.mishra@verizon.com >>>>> www.linkedin.com/in/networking-technologies-consultant >>>>>=20 >>>>> _______________________________________________ >>>>> OPSEC mailing list >>>>> OPSEC@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/opsec >>>>=20 >>=20 --Apple-Mail=_1E72827D-1798-41C3-A15C-E507AB2A6527 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAl3HMPUACgkQrut0EXfn u6im1QgAvDwTdYCh6FG/IqFydkB8JGqkqlXSqyouY2OFzXFKWMEe0F8IxEua8257 yXshZAqMmKsPydxIygAznPYYe0beHK7qBIDbj5JfLuP2m5grysIofs1Bd6cPU3fG 8TOuu+2mqZXe1+06Wdm3waThVLHlEUo6LLVsDbzKQXUL4lNu8vPXwsZnlHB4UpN+ kU13D3tZ3ii3D/8EbYCeFtGub+gOuCQnTahijLWMhXHJvw/yPDv++Z0QvcPSfhZP YOYvtnford65ygrUMmzK0aqSQYrt/RE8PPC1c1ORp6rtTrMB4zU83uhw9s3EPogU Yd8ZVAKp44Ym+sApPgvBOqVe8MBoPA== =EzvR -----END PGP SIGNATURE----- --Apple-Mail=_1E72827D-1798-41C3-A15C-E507AB2A6527-- From nobody Sat Nov 9 13:49:35 2019 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 2C5681200FF for ; Sat, 9 Nov 2019 13:49:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3Ig4ZZfAOiV for ; Sat, 9 Nov 2019 13:49:31 -0800 (PST) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9053212001E for ; Sat, 9 Nov 2019 13:49:31 -0800 (PST) Received: from [192.168.10.145] (dhcp217197164246.blix.com [217.197.164.246]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id A9CE04E11B11; Sat, 9 Nov 2019 21:49:29 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Ole Troan Mime-Version: 1.0 (1.0) Date: Sat, 9 Nov 2019 22:49:26 +0100 Message-Id: <21EF15E3-51F0-405A-86D1-C68567DBEFFF@employees.org> References: Cc: Gyan Mishra , "opsec@ietf.org" In-Reply-To: To: Bob Hinden X-Mailer: iPhone Mail (17C5032d) Archived-At: Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-21.txt 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, 09 Nov 2019 21:49:34 -0000 > On 9 Nov 2019, at 22:35, Bob Hinden wrote: > >>>>> The hop-by-hop options header, when present in an IPv6 packet, forces >>>>> all nodes in the path to inspect this header in the original IPv6 >>>>> specification [RFC2460]. This enables denial of service attacks as >>>>> most, if not all, routers cannot process this kind of packets in >>>>> hardware but have to 'punt' this packet for software processing. I believe this statement is far out of date. I would recommend getting recent data on this or delete it. Cheers Ole From nobody Sat Nov 9 18:16:09 2019 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 56E9F1200EF for ; Sat, 9 Nov 2019 18:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYtzrwTRbA7S for ; Sat, 9 Nov 2019 18:16:04 -0800 (PST) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 3862D12001E for ; Sat, 9 Nov 2019 18:16:04 -0800 (PST) Received: by mail-qk1-x735.google.com with SMTP id 205so8462781qkk.1 for ; Sat, 09 Nov 2019 18:16:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WP2M1SxPB6172GJN2ORlP2OjttxnldN94RMNmlXGuwg=; b=cTqmSzm8unCUIurWNW+IqlTysEVXspov//3w+O1k91UtJGxCWXHQJSVot6RdfUxAwD RiNCDdsnqMaolPGVIrkbCcKce+ZCjYRBgUexCrp68K/35l8fQR0f3LoH3IoRVSIWQVw7 UDm5JKDACMfkALwZwv03HWgGYhFe3m/6hYrQFnw2404/LDibYTg6p9QRQT2Zwi9U7OjD enbBo0NtwJ3Ty1fm8U+MKFJKIETAtVIeep5SYvos0toWH7F9Ewb5lF6OqLn+te6j+8s2 nDlCmP+S3W6OARuodvoV24ZqhnHnjZ2BX9o8SAOaoB6oGl3ZYfPnmAI0gMeIVZT80/fO e52Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WP2M1SxPB6172GJN2ORlP2OjttxnldN94RMNmlXGuwg=; b=k3gsKxuxdv2ZaVc7lFjXYR3hhVDxHREuTHma6mr1AbNtdSXfcn7eyD251EE96THk1x nbe51KPAThv32Dc3lgQNmIldGTQHJZmw9+ZTm0SK39MMfDidVSxgqRmgPj0V+M5pBlz5 FfBr7ifR+JxdbVKq8M1zPjKo0BCNVa+FXs0GtzrqT1nwjuHYTZ+zxEzJ9llgQZSwIoNe cFO4ncNXBuIRLhwMW8funiIc5c/youFZVmSqPPnz8vTsifZKxx18q/pmdFDZbclpqgLg NY9qfrJwITdCUl4/3NoiewPYIWJZXGjree7pyL5CHJjDIs/4IyU5MMr3rkFOUnbMz5G0 FmuA== X-Gm-Message-State: APjAAAWo0UhZIl7jPiWUB8QNWHX3oGVzp/k0TiKqummFbV/IXRo8iSJV du5g09Avco4KRwHxj5Bf4w0aJhnW X-Google-Smtp-Source: APXvYqwqKodM4MMf6kwMWAiDGsK83mYcZJzcUPMkoL7/Zu/3GRIxZDFDUjQpBKAHNdEjYcz2xLEPbg== X-Received: by 2002:ae9:e114:: with SMTP id g20mr4033745qkm.13.1573352161812; Sat, 09 Nov 2019 18:16:01 -0800 (PST) Received: from ?IPv6:2600:1003:b02c:8e21:bd93:abc:b878:80c4? ([2600:1003:b02c:8e21:bd93:abc:b878:80c4]) by smtp.gmail.com with ESMTPSA id h37sm5532974qth.78.2019.11.09.18.15.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Nov 2019 18:16:00 -0800 (PST) From: Gyan Mishra X-Google-Original-From: Gyan Mishra Content-Type: multipart/alternative; boundary=Apple-Mail-BB8D9D87-B363-4513-A6A9-898E9790DD2E Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (16G102) In-Reply-To: <21EF15E3-51F0-405A-86D1-C68567DBEFFF@employees.org> Date: Sat, 9 Nov 2019 21:15:59 -0500 Cc: Bob Hinden , "opsec@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: <21EF15E3-51F0-405A-86D1-C68567DBEFFF@employees.org> To: Ole Troan Archived-At: Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-21.txt 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: Sun, 10 Nov 2019 02:16:08 -0000 --Apple-Mail-BB8D9D87-B363-4513-A6A9-898E9790DD2E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Nov 9, 2019, at 4:49 PM, Ole Troan wrote: >=20 >=20 >=20 >> On 9 Nov 2019, at 22:35, Bob Hinden wrote: >>=20 >>>>>> The hop-by-hop options header, when present in an IPv6 packet, forces= >>>>>> all nodes in the path to inspect this header in the original IPv6 >>>>>> specification [RFC2460]. This enables denial of service attacks as >>>>>> most, if not all, routers cannot process this kind of packets in >>>>>> hardware but have to 'punt' this packet for software processing. >=20 > I believe this statement is far out of date.=20 > I would recommend getting recent data on this or delete it.=20 >=20 > Cheers=20 > Ole This draft expired late 2016 so only few years old on this subject. https://tools.ietf.org/html/draft-ietf-6man-hbh-header-handling-03 So I think the main issue with hbh is that even on the latest modern high e= nd routers that process everything in hardware in the forwarding plane that h= bh processing had to be sent to the control plane because some hbh options a= re used in the forwarding plane like jumbo frames, while others are to be co= nsumed by the control plane such as router alert. Older routers forwarded a= ll hbh from the forwarding plane to the control plane which now newer router= s don=E2=80=99t do so but you still have hbh options that have to be consume= d by the control plane. Excerpt from the draft above. Many modern routers maintain a strict separation between forwarding plane ha= rdware and control plane hardware. In these routers, forwarding plane bandwi= dth is plentiful, while control plane bandwidth is constrained. In order to p= rotect scarce control plane resources, these routers enforce policies the re= strict access from the from the forwarding plane to the control plane. Effec= tive policies address packets containing the HBH Options Extension header, b= ecause HBH control options require access from the forwarding plane to the c= ontrol plane. Many network operators perceive HBH Options to be a breach of t= he separation between the forwarding and control planes [I-D.ietf-v6ops-ipv6= -ehs-in-real-world]. Therefore, some network operators discard all packets c= ontaining the HBH Options Extension Header, while others forward the packets= but ignore the HBH Options. Still other operators severely rate-limit pa= ckets containing the HBH Options Extension Header. In addition, some (notabl= y older) implementations send all packets containing a HBH header to the con= trol plane even if they contain only pad options, resulting in an effect DoS= on the router and inconsistent drops among those packets due to rate limiti= ng or other factors. [RFC7045] legitimizes the current state of affairs, sev= erely limiting the utility of HBH options. In the words of RFC 7045: "The IP= v6 Hop-by-Hop Options header SHOULD be processed by intermediate forwarding n= odes as described in RFC2460. However, it is to be expected that high-perfor= mance routers will either ignore it or assign packets containing it to a slo= w processing path. Designers planning to use a Hop-by-Hop option need t= o be aware of this likely behaviour." https://tools.ietf.org/html/rfc7045 2.2. Hop-by-Hop Options The IPv6 Hop-by-Hop Options header SHOULD be process= ed by intermediate forwarding nodes as described in [RFC2460]. However, it i= s to be expected that high-performance routers will either ignore it or assi= gn packets containing it to a slow processing path. Designers planning to us= e a hop-by-hop option need to be aware of this likely behaviour. As a remind= er, in RFC 2460, it is stated that the Hop-by-Hop Options header, if present= , must be first. We should reference these two documents in this draft which I have to check.= --Apple-Mail-BB8D9D87-B363-4513-A6A9-898E9790DD2E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable




On Nov 9, 2= 019, at 4:49 PM, Ole Troan <otroa= n@employees.org> wrote:



On 9 Nov 2019, at 22:35, Bob Hinden <bob.hinden@gmail.com> wrote:

The hop-by-hop options header, when present in an= IPv6 packet, forces
all nodes in the path to inspect this header in the original IPv6=
specification [RFC2460]= .  This enables denial of service attacks as
<= blockquote type=3D"cite">
most, if not all, routers cannot process th= is kind of packets in
<= span>hardware but have to 'punt' this packet for software processing.=
<= /span>
I believe this statement is far out of date.
I would recommend getting recent data on this or delete it.

Cheers
Ole

This draft expired late 2016 so only few years old on this s= ubject.

https://tools.ietf.org/html/draft-ietf-6man-hb= h-header-handling-03

So I think the main issue wi= th hbh is that even on  the latest modern high end routers that process= everything in hardware in the forwarding plane that hbh processing had to b= e sent to the control plane because some hbh options are used in the forward= ing plane like jumbo frames, while others are to be consumed by the control p= lane such as router alert.  Older routers forwarded all hbh from the fo= rwarding plane to the control plane which now newer routers don=E2=80=99t do= so but you still have hbh options that have to be consumed by the control p= lane.

Excerpt from the draft above.

<= /div>
Many modern r=
outers maintain a strict separation between forwarding
   plane hardware and control plane hardware.  In these routers,
   forwarding plane bandwidth is plentiful, while control plane
   bandwidth is constrained.  In order to protect scarce control plane
   resources, these routers enforce policies the restrict access from
   the from the forwarding plane to the control plane.  Effective
   policies address packets containing the HBH Options Extension header,
   because HBH control options require access from the forwarding plane
   to the control plane.

   Many network operators perceive HBH Options to be a breach of the
   separation between the forwarding and control planes
   [I-D.ietf-v6ops-ipv6-ehs-in-real-world].  Therefore, some network
   operators discard all packets containing the HBH Options Extension
   Header, while others forward the packets but ignore the HBH Options.
   Still other operators severely rate-limit packets containing the HBH
   Options Extension Header.  In addition, some (notably older)
   implementations send all packets containing a HBH header to the
   control plane even if they contain only pad options, resulting in an
   effect DoS on the router and inconsistent drops among those packets
   due to rate limiting or other factors.

   [RFC7045] legitimizes the c=
urrent state of affairs, severely limiting
   the utility of HBH options.  In the words of RFC 7045:

      "The IPv6 Hop-by-Hop Options header SHOULD be processed by
      intermediate forwarding nodes as described in RFC2460.  However,
      it is to be expected that high-performance routers will either
      ignore it or assign packets containing it to a slow processing
      path.  Designers planning to use a Hop-by-Hop option need to be
      aware of this likely behaviour."


=

2.2.  Hop-by-Hop Options


   The IPv6 Hop-by-Hop Options header SHOULD be processed by
   intermediate forwarding nodes as described in [RFC2460].  However, it
   is to be expected that high-performance routers will either ignore it
   or assign packets containing it to a slow processing path.  Designers
   planning to use a hop-by-hop option need to be aware of this likely
   behaviour.

   As a reminder, in RFC 246=
0, it is stated that the Hop-by-Hop Options
   header, if present, must be first.

We should reference these two documents=
 in this draft which I have to check.

<=
/pre>
= --Apple-Mail-BB8D9D87-B363-4513-A6A9-898E9790DD2E-- From nobody Sun Nov 10 08:38:25 2019 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 DAF591201B7 for ; Sun, 10 Nov 2019 08:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSuWqLHgB6Rj for ; Sun, 10 Nov 2019 08:38:21 -0800 (PST) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 2D702120170 for ; Sun, 10 Nov 2019 08:38:21 -0800 (PST) Received: by mail-qt1-x833.google.com with SMTP id y39so13029101qty.0 for ; Sun, 10 Nov 2019 08:38:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=klzw8g3ITE5R1Z9ikjTCDbndpQkaxdApseO4sBAcLgw=; b=nBNAt0g7EqVJ9+q4GNtMys/pdYMPmkL9YETZG/+VpTTADioCO0VRsWran7Pf93x2DJ 5oVStrZzZ3ELLAEzbnu9ExRGmsK47boAHcfs51Wmjp92HeRgwrToyQxfXEP6iOuSVGIE LrrdtVFYZA19ONFbLHTlswcRrNUZpdtqYizpKRcC7/QsrUgF79x3JGW43TgPN1LLzW+b kmTCpOjFimXDSADXuXapJUQbknoiTC7f1w9q7d8O9xuEsklwWvWPhKYfnlv0wxlzdVyN quv3u3nBL8ukgqGlrMZQLCcVKUdytUFgbUptsc9ejVtZTQfHlSHarwNeBXZenoFiP+lH PsRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=klzw8g3ITE5R1Z9ikjTCDbndpQkaxdApseO4sBAcLgw=; b=hlLPsKj+fbW9qT+MgFrDEjAg2p6aJlUPE8EJjSdbOTWyzO5yvrOKuZuv6iai1BNmgy ZaObjNGzSlDYZ8N7zaz98SjN+GZUYws8NTOZtaTVwwbbkag8+UjMS5n1kdWxMNK+uYur DDmw0xAJJ9M0jujTkmylDqWfztwF8q5dUgsXXdVGfZ1itMOxOpTVmXvoGl0SFV3/kdtc GUhgmNj1+NZQrW4VbE6t7CP/a7EStNSmlqlxjA2UpyQMZS92fVjiEL2LkcuSWF+VYzAz YnlG/TxnS5k/9283PizERfhyDiJ/YU142isai42C62X6waj96FRE3NRcgD3EhErAr2FN 0x6Q== X-Gm-Message-State: APjAAAXU9QKO2lV+RmmyGedFgk5CUJ/97heqmEb2EAkswFVRQcU8GPVJ MhGXJAHq0g6h9sBnAWi0SBI= X-Google-Smtp-Source: APXvYqzSuzHmr7ELtbahzH8uAHly7amXTJb9CQgWylCAkiGcEKBbCh8ESplIyOr9FrJyjhUZJ+2kIA== X-Received: by 2002:ac8:6a13:: with SMTP id t19mr21716183qtr.56.1573403899999; Sun, 10 Nov 2019 08:38:19 -0800 (PST) Received: from [192.168.1.213] (pool-72-83-194-140.washdc.fios.verizon.net. [72.83.194.140]) by smtp.gmail.com with ESMTPSA id v54sm6679883qtc.77.2019.11.10.08.38.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Nov 2019 08:38:15 -0800 (PST) From: Gyan Mishra X-Google-Original-From: Gyan Mishra Content-Type: multipart/alternative; boundary=Apple-Mail-3D73C990-F55B-4475-B90C-AF9C19B56B39 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (16G102) In-Reply-To: Date: Sun, 10 Nov 2019 11:38:14 -0500 Cc: Ole Troan , Bob Hinden , "opsec@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: <21EF15E3-51F0-405A-86D1-C68567DBEFFF@employees.org> To: Gyan Mishra Archived-At: Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-21.txt 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: Sun, 10 Nov 2019 16:38:25 -0000 --Apple-Mail-3D73C990-F55B-4475-B90C-AF9C19B56B39 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Nov 9, 2019, at 9:15 PM, Gyan Mishra wrote: >=20 >=20 >=20 >=20 >=20 >> On Nov 9, 2019, at 4:49 PM, Ole Troan wrote: >>=20 >>=20 >>=20 >>> On 9 Nov 2019, at 22:35, Bob Hinden wrote: >>>=20 >>>>>>> The hop-by-hop options header, when present in an IPv6 packet, force= s >>>>>>> all nodes in the path to inspect this header in the original IPv6 >>>>>>> specification [RFC2460]. This enables denial of service attacks as >>>>>>> most, if not all, routers cannot process this kind of packets in >>>>>>> hardware but have to 'punt' this packet for software processing. >>=20 >> I believe this statement is far out of date.=20 >> I would recommend getting recent data on this or delete it.=20 >>=20 >> Cheers=20 >> Ole >=20 > This draft expired late 2016 so only few years old on this subject. >=20 > https://tools.ietf.org/html/draft-ietf-6man-hbh-header-handling-03 >=20 > So I think the main issue with hbh is that even on the latest modern high= end routers that process everything in hardware in the forwarding plane tha= t hbh processing had to be sent to the control plane because some hbh option= s are used in the forwarding plane like jumbo frames, while others are to be= consumed by the control plane such as router alert. Older routers forwarde= d all hbh from the forwarding plane to the control plane which now newer rou= ters don=E2=80=99t do so but you still have hbh options that have to be cons= umed by the control plane. >=20 > Excerpt from the draft above. >=20 > Many modern routers maintain a strict separation between forwarding plane h= ardware and control plane hardware. In these routers, forwarding plane bandw= idth is plentiful, while control plane bandwidth is constrained. In order to= protect scarce control plane resources, these routers enforce policies the r= estrict access from the from the forwarding plane to the control plane. E= ffective policies address packets containing the HBH Options Extension heade= r, because HBH control options require access from the forwarding plane to t= he control plane. Many network operators perceive HBH Options to be a breach= of the separation between the forwarding and control planes [I-D.ietf-v6ops= -ipv6-ehs-in-real-world]. Therefore, some network operators discard all pack= ets containing the HBH Options Extension Header, while others forward the pa= ckets but ignore the HBH Options. Still other operators severely rate-limit p= ackets containing the HBH Options Extension Header. In addition, some (notab= ly older) implementations send all packets containing a HBH header to the co= ntrol plane even if they contain only pad options, resulting in an effect Do= S on the router and inconsistent drops among those packets due to rate limit= ing or other factors. [RFC7045] legitimizes the current state of affairs, se= verely limiting the utility of HBH options. In the words of RFC 7045: "The I= Pv6 Hop-by-Hop Options header SHOULD be processed by intermediate forwarding= nodes as described in RFC2460. However, it is to be expected that high-perf= ormance routers will either ignore it or assign packets containing it to a s= low processing path. Designers planning to use a Hop-by-Hop option need to b= e aware of this likely behaviour." >=20 > https://tools.ietf.org/html/rfc7045 >=20 > 2.2. Hop-by-Hop Options The IPv6 Hop-by-Hop Options header SHOULD be proce= ssed by intermediate forwarding nodes as described in [RFC2460]. However, it= is to be expected that high-performance routers will either ignore it or as= sign packets containing it to a slow processing path. Designers planning to u= se a hop-by-hop option need to be aware of this likely behaviour. As a remin= der, in RFC 2460, it is stated that the Hop-by-Hop Options header, if presen= t, must be first. >=20 > We should reference these two documents in this draft which I have to chec= k. Ole Thanks for the comments. I think the hbh section is most pertinent to this I= -D. I will work with the authors to update with current data. Gyan >=20 --Apple-Mail-3D73C990-F55B-4475-B90C-AF9C19B56B39 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Nov 9, 2019, at= 9:15 PM, Gyan Mishra <hayabusag= sm@gmail.com> wrote:





On Nov 9, 2019, at 4:49 PM, Ole Troan &l= t;otroan@employees.org> wrote= :


<= span>
On 9 Nov 2019, at 22:35, Bob= Hinden <bob.hinden@gmail.com= > wrote:
T= he hop-by-hop options header, when present in an IPv6 packet, forces<= br>
all nodes in the path to= inspect this header in the original IPv6
specification [RFC2460].  This enables denial o= f service attacks as
most, if not all, routers cannot process this kind of packets in<= br>
hardware but have to 'pu= nt' this packet for software processing.

I believe thi= s statement is far out of date.
I would recommend getting r= ecent data on this or delete it.

Cheers
Ole

This draft ex= pired late 2016 so only few years old on this subject.

https://tools.ietf.org/html/draft-ietf-6man-hbh-header-handling-03
<= div>
So I think the main issue with hbh is that even on  = the latest modern high end routers that process everything in hardware in th= e forwarding plane that hbh processing had to be sent to the control plane b= ecause some hbh options are used in the forwarding plane like jumbo frames, w= hile others are to be consumed by the control plane such as router alert. &n= bsp;Older routers forwarded all hbh from the forwarding plane to the control= plane which now newer routers don=E2=80=99t do so but you still have hbh op= tions that have to be consumed by the control plane.

Excerpt from the draft above.

Many modern routers maintain a strict sep=
aration between forwarding
   plane hardware and control plane hardware.  In these routers,
   forwarding plane bandwidth is plentiful, while control plane
   bandwidth is constrained.  In order to protect scarce control plane
   resources, these routers enforce policies the restrict access from
   the from the forwarding plane to the control plane.  Effective
   policies address packets containing the HBH Options Extension header,
   because HBH control options require access from the forwarding plane
   to the control plane.

   Many network operators perceive HBH Options to be a breach of the
   separation between the forwarding and control planes
   [I-D.ietf-v6ops-ipv6-ehs-in-real-world].  Therefore, some network
   operators discard all packets containing the HBH Options Extension
   Header, while others forward the packets but ignore the HBH Options.
   Still other operators severely rate-limit packets containing the HBH
   Options Extension Header.  In addition, some (notably older)
   implementations send all packets containing a HBH header to the
   control plane even if they contain only pad options, resulting in an
   effect DoS on the router and inconsistent drops among those packets
   due to rate limiting or other factors.

   [RFC7045] legitimizes the c=
urrent state of affairs, severely limiting
   the utility of HBH options.  In the words of RFC 7045:

      "The IPv6 Hop-by-Hop Options header SHOULD be processed by
      intermediate forwarding nodes as described in RFC2460.  However,
      it is to be expected that high-performance routers will either
      ignore it or assign packets containing it to a slow processing
      path.  Designers planning to use a Hop-by-Hop option need to be
      aware of this likely behaviour."


=

2.2.  Hop-by-Hop Options


   The IPv6 Hop-by-Hop Options header SHOULD be processed by
   intermediate forwarding nodes as described in [RFC2460].  However, it
   is to be expected that high-performance routers will either ignore it
   or assign packets containing it to a slow processing path.  Designers
   planning to use a hop-by-hop option need to be aware of this likely
   behaviour.

   As a reminder, in RFC 246=
0, it is stated that the Hop-by-Hop Options
   header, if present, must be first.

We should reference these two documents=
 in this draft which I have to check.
<= /blockquote>

Ole

Thanks for the comments.  I thin= k the hbh section is most pertinent to this I-D.  I will work with the a= uthors to update with current data.

Gyan

=
= --Apple-Mail-3D73C990-F55B-4475-B90C-AF9C19B56B39-- From nobody Mon Nov 11 07:42:16 2019 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 46EBF1208A8; Mon, 11 Nov 2019 07:42:08 -0800 (PST) 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: 6.110.0 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: hayabusagsm@gmail.com, warren@kumari.net, draft-ietf-opsec-v6@ietf.org, opsec@ietf.org, opsec-chairs@ietf.org, Gyan Mishra Content-Transfer-Encoding: 7bit Reply-To: last-call@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <157348692828.7549.5693363954495959926.idtracker@ietfa.amsl.com> Date: Mon, 11 Nov 2019 07:42:08 -0800 Archived-At: Subject: [OPSEC] Last Call: (Operational Security Considerations for IPv6 Networks) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 15:42:08 -0000 The IESG has received a request from the Operational Security Capabilities for IP Network Infrastructure WG (opsec) to consider the following document: - 'Operational Security Considerations for IPv6 Networks' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2019-12-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Knowledge and experience on how to operate IPv4 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 in several places of a network (enterprises, service providers and residential users) and proposes technical and procedural mitigations techniques. Some very specific places of a network such as the Internet of Things are not discussed in this document. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Nov 12 03:03:22 2019 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 CFAE512080C for ; Tue, 12 Nov 2019 03:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=DE/koaAR; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=rlVNCYt5 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 jQAvuKeVZqrh for ; Tue, 12 Nov 2019 03:03:18 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A2BC120826 for ; Tue, 12 Nov 2019 03:03:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11488; q=dns/txt; s=iport; t=1573556598; x=1574766198; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=oNXuHDzAorMCJqvQu0QBrx4SZ3/9jOO/ojZ7Y+1p4+g=; b=DE/koaARF7C0BORWqSUnax8FbK4VIjobyPiUvzemSK8gFugLs+q5Xwqx 4GT6KpP1hohFUicXL7QjFksDM+e7FOO/NGo80D1TpD4KincDjPN6HqUMu A+TDNZNVXjMPLM998mvGCHGAapCpQx7ZBjJUfhh76XeOAU9/jG++4SQQN Q=; IronPort-PHdr: =?us-ascii?q?9a23=3Acnu8MRzSYKUuoMLXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhSN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZuIF1z9J/3nRyc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AeAACJkMpd/5FdJa1iAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAREBAQEBAQEBAQEBAYFtAQEBAQEBCwGBSiQsBWxYIAQLKoQ?= =?us-ascii?q?pg0YDimyCXolYjiiBQoEQA1QJAQEBDAEBGAsKAgEBgUyCdAIXg38kNwYOAgM?= =?us-ascii?q?LAQEEAQEBAgEFBG2FNwyFUQEBAQECAQEBEBERDAEBByULAQ0CAgEIEQMBAgE?= =?us-ascii?q?CAhEVAgICGQYGCxUICAIEDgUUDoMAAYJGAw4gAQ6kBAKBOIhgdYEygn4BAQW?= =?us-ascii?q?BOAIOQUCCQQ0LghcJBYEJKAGFFgOEMYJJGIFAP4ERJx+CTD6CG0cBAQIBARa?= =?us-ascii?q?BAhIBEgEfFwoeCIJJMoIsjSWCZ51HQQqCJYcXihuEEhQHgj1yhm+MB4NUkAi?= =?us-ascii?q?GdYISjy4CBAIEBQIOAQEFgWgjZ3FwFRohKgGCQQlHERSQNoNzhRSFP3QBMHe?= =?us-ascii?q?NV4IxAQE?= X-IronPort-AV: E=Sophos;i="5.68,296,1569283200"; d="scan'208";a="370945973" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Nov 2019 11:03:16 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id xACB3GSG012903 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Nov 2019 11:03:16 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 12 Nov 2019 05:03:16 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 12 Nov 2019 06:03:15 -0500 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 12 Nov 2019 06:03:15 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Kpk6cfjAnV48K7b0WDi2fjUgMCl3WWa1z/zz+U3mTZagPwm/27JnxwxvMerdROgKarf4Zik9dOet6FrDbIFHbHN3kVxUGD6yu7U2t8g5Z08DGtTOhQSp7YV5G62GpQUkMMP2IxJ3PIHcI4bw/JbdYxQuYzZqY9789a/eY8qzF7C2hoySSB/WytVGUEDsJUYoBwbLoQbesVENAXWGGvLZYVUOpczxdteSvTT9lnHZSBEOvk1D2vZ9lUKnVF0gJP4zjtevdSZSENgm0QBE4I/4XuhMyOoQhS38DPNVstBRa+q+cS+6vmJXFLXw05cMyCQais1FmSM46F4eOEN1HKKsOg== 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=oNXuHDzAorMCJqvQu0QBrx4SZ3/9jOO/ojZ7Y+1p4+g=; b=dJqEksW23TW6wvXAJkZOtbpNOkc6mv1w/4MLkyEn11NyFBohKBb7jtrDIG3xZSagZHFP9bTSj/wArkJPyk3yid53tHYiKnTae1CUt9fVG4gcbg/HWES8yef6WCgctMv1CQaLWGQYn/RchnNPdF2+GPzM2Fe6QcUReXyXu/U0hK4LHL7dV532uscakU1EBonoh6DFY2zAKUbTe6gy2bJB9LWX/k286ihbStfMgWIuxk/nD9aoxl39KjMs2D6KF74d790uGGF3oQgRxUYtVocQ6OcVbEgQkrxcmfmFCE1O++ZB57bDyFuriqZLj660VRhkArKYNbnuKcTbAS4QnoxHmA== 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=oNXuHDzAorMCJqvQu0QBrx4SZ3/9jOO/ojZ7Y+1p4+g=; b=rlVNCYt54+BrmhbPqbu3OmVVhMCfA5eM3T4JO+YGr+fsfLrujqkE6WBi2BqSFoNJIGWdSN0KxuH1BJGgGf87VODqoE9OC5iVe1RldBuibt+QhYgAupZw/6H1b04PgGnMgBXSqUaj+xTx0kIECteOLXfaU9jagTb3jG/lnIrUUIc= Received: from DM5PR11MB1753.namprd11.prod.outlook.com (10.175.88.141) by DM5PR11MB1929.namprd11.prod.outlook.com (10.175.87.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.22; Tue, 12 Nov 2019 11:03:14 +0000 Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::c1f1:d33a:2203:5a39]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::c1f1:d33a:2203:5a39%7]) with mapi id 15.20.2430.027; Tue, 12 Nov 2019 11:03:14 +0000 From: "Eric Vyncke (evyncke)" To: Bob Hinden CC: Gyan Mishra , "opsec@ietf.org" Thread-Topic: [OPSEC] I-D Action: draft-ietf-opsec-v6-21.txt Thread-Index: AQHVkxvTCwtKb9Pe4UuuiLsWFfIPgqd7JXoAgAdSl4CAABkggIAAgxIAgARn1oA= Date: Tue, 12 Nov 2019 11:03:13 +0000 Message-ID: References: <157281820483.13177.8617036261217670675@ietfa.amsl.com> <82AA0F9C-7836-464F-8F19-69FEDB197D53@gmail.com> <1AAA80C6-080B-492D-ABC9-645B9CEFDC99@cisco.com> <3BB16B9C-9065-466B-9A9A-51C5D314E126@cisco.com> In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:7095:3572:4497:7847] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8b3f3c60-b631-41eb-6abd-08d7675fe9f7 x-ms-traffictypediagnostic: DM5PR11MB1929: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 021975AE46 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(366004)(346002)(136003)(39860400002)(396003)(199004)(189003)(86362001)(45080400002)(6306002)(6512007)(478600001)(58126008)(54906003)(316002)(5660300002)(6246003)(15974865002)(6486002)(14454004)(229853002)(11346002)(6916009)(446003)(2616005)(6436002)(25786009)(476003)(46003)(966005)(14444005)(6506007)(8936002)(99286004)(2906002)(256004)(66574012)(4326008)(102836004)(33656002)(66946007)(66556008)(66476007)(64756008)(6116002)(53546011)(66446008)(81166006)(81156014)(8676002)(186003)(7736002)(486006)(71190400001)(71200400001)(36756003)(76116006)(91956017)(305945005)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1929; H:DM5PR11MB1753.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Qg3a5Nq/HNveJuKFFbURg0UVjaxt1Ae5zLqQNAm4MEtYnfS/BrZP6X7NL8BtkZfH2G56alXIeKEV77V0RwV9ceFX92DdyWG/FQLnmXyBRLAYy1LgE7HgUyMhlizKsgUpJSFGsfyZQG2wRD3qY82OfMDiDBkpQ3qe8NqZ7ayeI2bvaEoLVmyZKzJRKHCLEFCcEMKHbioXYftLAo8MTrj+/jEFykEA6u7nV5eRK94JXI50b0CL/CeU1Ee4GXuDoQiAXke+gAItbMTRhxVowxFRBQmRgDLeh+F7TUFOTW/4X1skZwlEmLdOcjxope1B15xOptn4um/7NpLqm1+5oLRLVF8+LyNsiEMmafIIOfQN5T27SPo28i5gVtmaC6C3LnozWwFGB2/CNH3+IECMModRyJzjN1sICcyJmq8YqE9p7n/YB+lSGkPzGEzAJfhYuSm2 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <03BA717B355A704D8CAFAA9CA182578C@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8b3f3c60-b631-41eb-6abd-08d7675fe9f7 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2019 11:03:13.8995 (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: JqLufz7fE7pVKRxgs3NLcZNifYVk3mz/lnEW9n8zW3vNqJQXYi/q+21kwZggvt2iHVF9RSkwe1zhLlwJ2aFWsg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1929 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-21.txt 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, 12 Nov 2019 11:03:21 -0000 Qm9iDQoNClRoYW5rIHlvdSBmb3IgcmVhZGluZyBvdXIgZG9jdW1lbnQuDQoNCkkgd2lsbCBrZWVw IHRoZSByZWZlcmVuY2UgdG8gUkZDIDI0NjAgc2ltcGx5IGJlY2F1c2UgdGhlIHZhc3QgbWFqb3Jp dHksIElNSE8sIG9mIGRlcGxveWVkIGRldmljZXMgc3RpbGwgZm9sbG93IHRoaXMgUkZDIGFuZCBu b3QgODIwMC4gKEJUVywgd2Ugd2lsbCBmaXggdGhlICJvcmlnaW5hbCIgcGFydCkuIA0KDQoncHVu dCcgaXMgaW5kZWVkIGEgQ2lzY28tbGFuZ3VhZ2UsIHNvLCBsZXQncyBhbHNvIGNoYW5nZSBpdC4N Cg0KRmluYWxseSwgd2Ugd2lsbCBleHRlbmQvY2xhcmlmeSB0aGUgJ29wdGlvbmFsJyBwYXJ0IG9m IEhiQiBpbiBSRkMgODIwMCB0aGF0IHdhcyBvdmVyc2ltcGxpZmljYXRpb24uDQoNCj0+IGFsbCB0 aGUgYWJvdmUgd2lsbCBiZSB1cGRhdGVkIHdoZW4gdGhlIElFVEYtd2lkZSBMYXN0Q2FsbCBpcyBv dmVyLg0KDQpSZWdhcmRzDQoNCi3DqXJpYw0KDQrvu79PbiAwOS8xMS8yMDE5LCAxNzo0NywgIkJv YiBIaW5kZW4iIDxib2IuaGluZGVuQGdtYWlsLmNvbT4gd3JvdGU6DQoNCiAgICBFcmljLA0KICAg IA0KICAgID4gT24gTm92IDgsIDIwMTksIGF0IDExOjU3IFBNLCBFcmljIFZ5bmNrZSAoZXZ5bmNr ZSkgPGV2eW5ja2VAY2lzY28uY29tPiB3cm90ZToNCiAgICA+IA0KICAgID4gR3lhbg0KICAgID4g DQogICAgPiBUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB5b3VyIHNoZXBoZXJkIHdyaXRlLXVwLCB2 ZXJ5IG11Y2ggYXBwcmVjaWF0ZWQgYnkgdGhlIGF1dGhvcnMuDQogICAgPiANCiAgICA+IFRoZSBs aXN0IG9mIHRoZSDigJhvYnNvbGV0ZWTigJkgcmVmZXJlbmNlcyBpcyBpbnRlbnRpb25hbCBpbmRl ZWQgdG8gZW5zdXJlIHRoYXQgcmVhZGVycyB1bmRlcnN0YW5kIHRoYXQg4oCYb2xk4oCZIGRvY3Vt ZW50cyBoYXZlIGJlZW4gcmVwbGFjZWQuIFRoZSB0ZXh0IGluIHRoZSBkb2N1bWVudCBpcyBjbGVh ciBhYm91dCB0aGUgb2Jzb2xldGUgYW5kIGN1cnJlbnQgZG9jdW1lbnQuIFNvLCB3ZSBkbyBwcmVm ZXIgdG8gbGVhdmUgdGhlIHJlZmVyZW5jZXMgbGlrZSB0aGV5IGFyZSBhcyB3ZSBiZWxpZXZlIHRo YXQgdGhleSBtYWtlIHRoZSBkb2N1bWVudCBtb3JlIHZhbHVhYmxlIGZvciB0aGUgcmVhZGVyLg0K ICAgIA0KICAgIEkgd2VudCBiYWNrIGFuZCByZXJlYWQgdGhpcy4gIFRoZSB0ZXh0Og0KICAgIA0K ICAgICAgIDIuMi4yLiAgSG9wLWJ5LUhvcCBPcHRpb25zIEhlYWRlcg0KICAgIA0KICAgICAgIFRo ZSBob3AtYnktaG9wIG9wdGlvbnMgaGVhZGVyLCB3aGVuIHByZXNlbnQgaW4gYW4gSVB2NiBwYWNr ZXQsIGZvcmNlcw0KICAgICAgIGFsbCBub2RlcyBpbiB0aGUgcGF0aCB0byBpbnNwZWN0IHRoaXMg aGVhZGVyIGluIHRoZSBvcmlnaW5hbCBJUHY2DQogICAgICAgc3BlY2lmaWNhdGlvbiBbUkZDMjQ2 MF0uICBUaGlzIGVuYWJsZXMgZGVuaWFsIG9mIHNlcnZpY2UgYXR0YWNrcyBhcw0KICAgICAgIG1v c3QsIGlmIG5vdCBhbGwsIHJvdXRlcnMgY2Fubm90IHByb2Nlc3MgdGhpcyBraW5kIG9mIHBhY2tl dHMgaW4NCiAgICAgICBoYXJkd2FyZSBidXQgaGF2ZSB0byAncHVudCcgdGhpcyBwYWNrZXQgZm9y IHNvZnR3YXJlIHByb2Nlc3NpbmcuDQogICAgICAgU2VjdGlvbiA0LjMgb2YgdGhlIGN1cnJlbnQg SW50ZXJuZXQgU3RhbmRhcmQgZm9yIElQdjYsIFtSRkM4MjAwXSwgaGFzDQogICAgICAgdGFrZW4g dGhpcyBhdHRhY2sgdmVjdG9yIGludG8gYWNjb3VudCBhbmQgbWFkZSB0aGUgcHJvY2Vzc2luZyBv ZiBob3AtDQogICAgICAgYnktaG9wIG9wdGlvbnMgaGVhZGVyIGJ5IGludGVybWVkaWF0ZSByb3V0 ZXJzIG9wdGlvbmFsLg0KICAgIA0KICAgIEkgZG9u4oCZdCB1bmRlcnN0YW5kIHdoeSB0aGlzIGlz IHRhbGtpbmcgYWJvdXQgUkZDMjQ2MCBhdCBhbGwuICBTZWVtcyBsaWtlIGl0IHdvdWxkIGxlc3Mg Y29uZnVzaW5nIHRvIG9ubHkgZGVzY3JpYmUgd2hhdCBpcyBpbiBSRkM4MjAwLiAgTm9yIGlzIOKA nHB1bnTigJ0gY29ycmVjdCB3YXkgdG8gZGVzY3JpYmUgdGhpcy4gICBXYXkgdG9vIGNvbGxvcXVp YWwuDQogICAgDQogICAgRGVzY3JpYmluZyBSRkM4MjAwIGJlaGF2aW9yIGFzIOKAnG9wdGlvbmFs IiBpcyBxdWl0ZSByaWdodCwgUkZDODIwMCBzYXlzOg0KICAgIA0KICAgICAgIC4uLm5vdyBleHBl Y3RlZCB0aGF0IG5vZGVzIGFsb25nIGEgcGFja2V0J3MgZGVsaXZlcnkgcGF0aCBvbmx5IGV4YW1p bmUgYW5kIHByb2Nlc3MgdGhlDQogICAgICAgICAgSG9wLWJ5LUhvcCBPcHRpb25zIGhlYWRlciBp ZiBleHBsaWNpdGx5IGNvbmZpZ3VyZWQgdG8gZG8gc28NCiAgICANCiAgICBJdOKAmXMgbm90IG9w dGlvbmFsIGlmIGNvbmZpZ3VyZWQgdG8gZG8gc28uICBJdCB3b3VsZCBiZSBiZXR0ZXIgdG8gdXNl IHRoZSBSRkM4MjAwIHdvcmRzLg0KICAgIA0KICAgIExhc3RseSB0aGUg4oCcT3JpZ2luYWwiIElQ djYgU3BlY2lmaWNhdGlvbiB3YXMgUkZDMTg4My4NCiAgICANCiAgICBCb2INCiAgICANCiAgICBw LnMuIEkgYWdyZWUgYWJvdXQgdGhlIHJlZmVyZW5jZXMgdG8gUkZDIDMwNjggYW5kIFJGQyAzNjI3 Lg0KICAgIA0KICAgIA0KICAgIA0KICAgIA0KICAgIA0KICAgIA0KICAgIA0KICAgID4gDQogICAg PiBSZWdhcmRzDQogICAgPiANCiAgICA+IC3DqXJpYw0KICAgID4gDQogICAgPiBGcm9tOiBHeWFu IE1pc2hyYSA8aGF5YWJ1c2Fnc21AZ21haWwuY29tPg0KICAgID4gRGF0ZTogU2F0dXJkYXksIDkg Tm92ZW1iZXIgMjAxOSBhdCAwODoyOA0KICAgID4gVG86IEVyaWMgVnluY2tlIDxldnluY2tlQGNp c2NvLmNvbT4NCiAgICA+IENjOiAib3BzZWNAaWV0Zi5vcmciIDxvcHNlY0BpZXRmLm9yZz4sICJp LWQtYW5ub3VuY2VAaWV0Zi5vcmciIDxpLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQogICAgPiBTdWJq ZWN0OiBSZTogW09QU0VDXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW9wc2VjLXY2LTIxLnR4dA0K ICAgID4gDQogICAgPiBFcmljDQogICAgPiANCiAgICA+IEkgc3VibWl0dGVkIHRoZSBzaGVwaGVy ZCB3cml0ZS11cC4NCiAgICA+IA0KICAgID4gSSByYW4gdGhlIGlkbml0cyBhbmQgaXQgZm91bmQg dGhlIGZvbGxvd2luZyBvYnNvbGV0ZSByZWZlcmVuY2VzLiAgV2Ugc2hvdWxkIGNsZWFyIHRoYXQg dXAgYmVmb3JlIHdlIHB1Ymxpc2ggaXQuICBJIGNhbiB1cGRhdGUgbXkgY29tbWVudHMgb24gdGhh dCBvbmNlIHRoZSBkcmFmdCBpcyB1cGRhdGVkLg0KICAgID4gQ2hlY2tpbmcgcmVmZXJlbmNlcyBm b3IgaW50ZW5kZWQgc3RhdHVzOiBJbmZvcm1hdGlvbmFsDQogICAgPiAgIC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCiAgICA+IA0KICAgID4gICAtLSBPYnNvbGV0ZSBpbmZvcm1hdGlvbmFsIHJlZmVyZW5j ZSAoaXMgdGhpcyBpbnRlbnRpb25hbD8pOiBSRkMgMjQ2MA0KICAgID4gICAgICAoT2Jzb2xldGVk IGJ5IFJGQyA4MjAwKQ0KICAgID4gDQogICAgPiAgIC0tIE9ic29sZXRlIGluZm9ybWF0aW9uYWwg cmVmZXJlbmNlIChpcyB0aGlzIGludGVudGlvbmFsPyk6IFJGQyAzMDY4DQogICAgPiAgICAgIChP YnNvbGV0ZWQgYnkgUkZDIDc1MjYpDQogICAgPiANCiAgICA+ICAgLS0gT2Jzb2xldGUgaW5mb3Jt YXRpb25hbCByZWZlcmVuY2UgKGlzIHRoaXMgaW50ZW50aW9uYWw/KTogUkZDIDM2MjcNCiAgICA+ ICAgICAgKE9ic29sZXRlZCBieSBSRkMgNjU0NykNCiAgICA+IA0KICAgID4gVGhhbmsgeW91DQog ICAgPiANCiAgICA+IEd5YW4NCiAgICA+IA0KICAgID4gT24gTW9uLCBOb3YgNCwgMjAxOSBhdCA5 OjM4IEFNIEVyaWMgVnluY2tlIChldnluY2tlKSA8ZXZ5bmNrZUBjaXNjby5jb20+IHdyb3RlOg0K ICAgID4+IEhlbGxvIEd5YW4sDQogICAgPj4gDQogICAgPj4gVGhhbmsgeW91IGZvciByZW1pbmRp bmcgdGhlIGF1dGhvciB0byBwb3N0IHRoZSAnZ2lzdCcgb2YgdGhlIGNoYW5nZXMgd2l0aCB2ZXJz aW9uIC0yMS4NCiAgICA+PiANCiAgICA+PiBPdXIgT1BTIEFELCBXYXJyZW4gIkFjZSIgS3VtYXJp LCAgaGFzIGtpbmRseSByZXZpZXdlZCBvdXIgZG9jdW1lbnQgYW5kIGhhcyBpZGVudGlmaWVkIG1v cmUgdGhhbiA3MCBhcmVhcyB3aGVyZSB0aGUgdGV4dCB3YXMgYW1iaWd1b3VzIG9yIHVzaW5nIGJh ZCBFbmdsaXNoLi4uIE5vIHdvbmRlciwgbm9uZSBvZiB0aGUgNCBhdXRob3JzIGFyZSBFbmdsaXNo LXNwZWFraW5nIG5hdGl2ZTogaXQgaXMgYSBtaXggb2YgRXN0b25pYW4gKE1lcmlrZSB3aG8gYWxz byBzcGVha3MgR2VybWFuIGFuZCBSdXNzaWFuWzFdKSwgb25lIG9mIHRoZSAyMiAoPykgbGFuZ3Vh Z2Ugb2YgSW5kaWEgKEtLKSwgR2VybWFuIChFbm5vIHdobyBhbHNvIHNwZWFrcyBGcmVuY2ggYW5k IFNwYW5pc2gpIGFuZCBGcmVuY2ggKG15c2VsZiBhbHNvIHNwZWFraW5nIER1dGNoKSBfXyBfXyBJ RVRGIGNvbW11bml0eSBpcyByZWFsbHkgZGl2ZXJzZSAhDQogICAgPj4gDQogICAgPj4gVGhhbmsg eW91IHZlcnkgbXVjaCBpbiBhZHZhbmNlIGZvciBmaW5hbGl6aW5nIHRoZSBzaGVwaGVyZCB3cml0 ZS11cA0KICAgID4+IA0KICAgID4+IC3DqXJpYw0KICAgID4+IA0KICAgID4+IFsxXSBJIGNhbiBi ZSB3cm9uZyBmb3IgTWVyaWtlIEJUVyBidXQgc2hlIGlzIHF1YWRyaS1saW5ndWFsDQogICAgPj4g DQogICAgPj4gT24gMDQvMTEvMjAxOSwgMTU6MjYsICJHeWFuIE1pc2hyYSIgPGhheWFidXNhZ3Nt QGdtYWlsLmNvbT4gd3JvdGU6DQogICAgPj4gDQogICAgPj4gICAgIEhpIEVyaWMNCiAgICA+PiAN CiAgICA+PiAgICAgSnVzdCBjaGVja2luZyB3aGF0IHRoZSB1cGRhdGVzIGFyZSB0aGF0IHdlbnQg aW4gdjIxIHNpbmNlIHRoaXMgZG9jdW1lbnQgaXMgbm93IHJlYWR5IHRvIGJlIHB1Ymxpc2hlZCBq dXN0IHBlbmRpbmcgbXkgU2hlcGFyZCB3cml0ZXVwIHdoaWNoIEkgcGxhbiB0byBmaW5pc2ggdGhp cyB3ZWVrLg0KICAgID4+IA0KICAgID4+ICAgICBUaGFuayB5b3UNCiAgICA+PiANCiAgICA+PiAg ICAgR3lhbg0KICAgID4+IA0KICAgID4+ICAgICBTZW50IGZyb20gbXkgaVBob25lDQogICAgPj4g DQogICAgPj4gICAgID4gT24gTm92IDMsIDIwMTksIGF0IDQ6NTYgUE0sIGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZyB3cm90ZToNCiAgICA+PiAgICAgPg0KICAgID4+ICAgICA+DQogICAgPj4gICAg ID4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50 ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KICAgID4+ICAgICA+IFRoaXMgZHJhZnQgaXMgYSB3 b3JrIGl0ZW0gb2YgdGhlIE9wZXJhdGlvbmFsIFNlY3VyaXR5IENhcGFiaWxpdGllcyBmb3IgSVAg TmV0d29yayBJbmZyYXN0cnVjdHVyZSBXRyBvZiB0aGUgSUVURi4NCiAgICA+PiAgICAgPg0KICAg ID4+ICAgICA+ICAgICAgICBUaXRsZSAgICAgICAgICAgOiBPcGVyYXRpb25hbCBTZWN1cml0eSBD b25zaWRlcmF0aW9ucyBmb3IgSVB2NiBOZXR3b3Jrcw0KICAgID4+ICAgICA+ICAgICAgICBBdXRo b3JzICAgICAgICAgOiBFcmljIFZ5bmNrZQ0KICAgID4+ICAgICA+ICAgICAgICAgICAgICAgICAg ICAgICAgICBLaXJhbiBLdW1hciBDaGl0dGltYW5lbmkNCiAgICA+PiAgICAgPiAgICAgICAgICAg ICAgICAgICAgICAgICAgTWVyaWtlIEthZW8NCiAgICA+PiAgICAgPiAgICAgICAgICAgICAgICAg ICAgICAgICAgRW5ubyBSZXkNCiAgICA+PiAgICAgPiAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFm dC1pZXRmLW9wc2VjLXY2LTIxLnR4dA0KICAgID4+ICAgICA+ICAgIFBhZ2VzICAgICAgICAgICA6 IDUyDQogICAgPj4gICAgID4gICAgRGF0ZSAgICAgICAgICAgIDogMjAxOS0xMS0wMw0KICAgID4+ ICAgICA+DQogICAgPj4gICAgID4gQWJzdHJhY3Q6DQogICAgPj4gICAgID4gICBLbm93bGVkZ2Ug YW5kIGV4cGVyaWVuY2Ugb24gaG93IHRvIG9wZXJhdGUgSVB2NCBzZWN1cmVseSBpcw0KICAgID4+ ICAgICA+ICAgYXZhaWxhYmxlOiB3aGV0aGVyIGl0IGlzIHRoZSBJbnRlcm5ldCBvciBhbiBlbnRl cnByaXNlIGludGVybmFsDQogICAgPj4gICAgID4gICBuZXR3b3JrLiAgSG93ZXZlciwgSVB2NiBw cmVzZW50cyBzb21lIG5ldyBzZWN1cml0eSBjaGFsbGVuZ2VzLiAgUkZDDQogICAgPj4gICAgID4g ICA0OTQyIGRlc2NyaWJlcyB0aGUgc2VjdXJpdHkgaXNzdWVzIGluIHRoZSBwcm90b2NvbCBidXQg bmV0d29yaw0KICAgID4+ICAgICA+ICAgbWFuYWdlcnMgYWxzbyBuZWVkIGEgbW9yZSBwcmFjdGlj YWwsIG9wZXJhdGlvbnMtbWluZGVkIGRvY3VtZW50IHRvDQogICAgPj4gICAgID4gICBlbnVtZXJh dGUgYWR2YW50YWdlcyBhbmQvb3IgZGlzYWR2YW50YWdlcyBvZiBjZXJ0YWluIGNob2ljZXMuDQog ICAgPj4gICAgID4NCiAgICA+PiAgICAgPiAgIFRoaXMgZG9jdW1lbnQgYW5hbHl6ZXMgdGhlIG9w ZXJhdGlvbmFsIHNlY3VyaXR5IGlzc3VlcyBpbiBzZXZlcmFsDQogICAgPj4gICAgID4gICBwbGFj ZXMgb2YgYSBuZXR3b3JrIChlbnRlcnByaXNlcywgc2VydmljZSBwcm92aWRlcnMgYW5kIHJlc2lk ZW50aWFsDQogICAgPj4gICAgID4gICB1c2VycykgYW5kIHByb3Bvc2VzIHRlY2huaWNhbCBhbmQg cHJvY2VkdXJhbCBtaXRpZ2F0aW9ucyB0ZWNobmlxdWVzLg0KICAgID4+ICAgICA+ICAgU29tZSB2 ZXJ5IHNwZWNpZmljIHBsYWNlcyBvZiBhIG5ldHdvcmsgc3VjaCBhcyB0aGUgSW50ZXJuZXQgb2Yg VGhpbmdzDQogICAgPj4gICAgID4gICBhcmUgbm90IGRpc2N1c3NlZCBpbiB0aGlzIGRvY3VtZW50 Lg0KICAgID4+ICAgICA+DQogICAgPj4gICAgID4NCiAgICA+PiAgICAgPiBUaGUgSUVURiBkYXRh dHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCiAgICA+PiAgICAgPiBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9wc2VjLXY2Lw0KICAgID4+ ICAgICA+DQogICAgPj4gICAgID4gVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZh aWxhYmxlIGF0Og0KICAgID4+ICAgICA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLW9wc2VjLXY2LTIxDQogICAgPj4gICAgID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLW9wc2VjLXY2LTIxDQogICAgPj4gICAgID4NCiAgICA+ PiAgICAgPiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6 DQogICAgPj4gICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWll dGYtb3BzZWMtdjYtMjENCiAgICA+PiAgICAgPg0KICAgID4+ICAgICA+DQogICAgPj4gICAgID4g UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2Ygc3VibWlzc2lvbg0KICAgID4+ICAgICA+IHVudGlsIHRoZSBodG1saXplZCB2ZXJz aW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQogICAgPj4gICAg ID4NCiAgICA+PiAgICAgPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFu b255bW91cyBGVFAgYXQ6DQogICAgPj4gICAgID4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy8NCiAgICA+PiAgICAgPg0KICAgID4+ICAgICA+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPj4gICAgID4gT1BTRUMgbWFpbGluZyBs aXN0DQogICAgPj4gICAgID4gT1BTRUNAaWV0Zi5vcmcNCiAgICA+PiAgICAgPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2VjDQogICAgPj4gDQogICAgPj4gDQogICAg PiANCiAgICA+IA0KICAgID4gLS0NCiAgICA+IEd5YW4gUy4gTWlzaHJhDQogICAgPiBJVCBOZXR3 b3JrIEVuZ2luZWVyaW5nICYgVGVjaG5vbG9neQ0KICAgID4gVmVyaXpvbiBDb21tdW5pY2F0aW9u cyBJbmMuIChWWikNCiAgICA+IDEzMTAxIENvbHVtYmlhIFBpa2UgRkRDMSAzcmQgRmxvb3INCiAg ICA+IFNpbHZlciBTcHJpbmcsIE1EIDIwOTA0DQogICAgPiBVbml0ZWQgU3RhdGVzDQogICAgPiBQ aG9uZTogMzAxIDUwMi0xMzQ3DQogICAgPiBFbWFpbDogZ3lhbi5zLm1pc2hyYUB2ZXJpem9uLmNv bQ0KICAgID4gd3d3LmxpbmtlZGluLmNvbS9pbi9uZXR3b3JraW5nLXRlY2hub2xvZ2llcy1jb25z dWx0YW50DQogICAgPiANCiAgICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQogICAgPiBPUFNFQyBtYWlsaW5nIGxpc3QNCiAgICA+IE9QU0VDQGlldGYu b3JnDQogICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2VjDQog ICAgDQogICAgDQoNCg== From nobody Sat Nov 16 15:36:26 2019 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 948B312080D; Sat, 16 Nov 2019 15:36:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ted Lemon via Datatracker To: Cc: opsec@ietf.org, draft-ietf-opsec-v6.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.110.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Ted Lemon Message-ID: <157394737956.25908.2003745932020934234@ietfa.amsl.com> Date: Sat, 16 Nov 2019 15:36:19 -0800 Archived-At: Subject: [OPSEC] Iotdir early review of draft-ietf-opsec-v6-21 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: Sat, 16 Nov 2019 23:36:20 -0000 Reviewer: Ted Lemon Review result: On the Right Track This is a review of draft-ietf-opsec-v6 from the IoT Directorate perspective. I am a volunteer on the IoT, and do not speak authoritatively for the IoT Directorate as a whole. My impression of this document is that it's useful, but could use some work. Some of my comments below are coming strictly from an IoT perspective; others are more general. --- The document doesn't talk about its intended audience. It appears to be the case based on my reading of it that the intended audience is enterprise operators and similar. This should be stated clearly and explicitly. Some of the advice in this document would be actively harmful if deployed on an unmanaged network (e.g. in a home). That doesn't mean that the document is bad—just that it needs to be scoped appropriately. I would suggest adding a brief statement of applicability in the abstract and a more detailed explanation in the introduction. It is important that this statement make clear that the advice in this document must not be followed by implementers of home routers and similar devices. E.g., this advice would utterly break a Thread (IPv6 over 802.15.4 mesh) Border Router. It's also not clear that this document lives up to its abstract. The abstract says: This document analyzes the operational security issues in several places of a network (enterprises, service providers and residential users) and proposes technical and procedural mitigations techniques. And yet if you look for example at section 2.1.1, there is no actual analysis of the use of ULAs, nor is any advice on their use provided. Section 2.1.4 doesn't mention using DHCP to provide hosts with obfuscated address that, since known to the operator, can be added to filter lists as appropriate, while still making probing mathematically challenging to an outside attacker. Section 2.1.6 incorrectly implies that DHCPv4 binds IP addresses to link-layer addresses. This is not true. I don't know that it really matters, but since it's not true, you should fix it. DHCPv4 uses a "client identifier," which is quite similar to a DUID. If no client identifier is offered, then the link-layer address is used, but this is not required, and the behavior described for DUIDs in this document is also applicable to client identifiers. 2.1.7 seems to be continuing a thought that was started in 2.1.4. It would be worth stating that explicitly, and comparing and contrasting these approaches. Although the abstract explicitly excludes applicability to IoT networks, the advice in this document will necessarily be taken as applicable in situations where IoT networks are leaf networks or even infrastructure that is present alongside the networks that _are_ covered by this document. This has some specific impacts that aren't talked about here and should be. For instance, Manufacturer Usage Descriptions (MUD) are not mentioned, and should be. MUD is applicable to infrastructure devices and really any special-purpose device; e.g., MUD would be highly appropriate for use in hospital environments where many devices are connected to the network that absolutely must have their accessibility controlled; MUD is a good candidate for doing this. The omission of this approach from section 2,1 is a major gap, since the issues discussed in section 2.1 directly impact the feasibility of using MUD (since MUD specifies firewall behavior for devices, and devices are necessarily identified by source address). The conclusion I'm drawing having gotten to the end of section 2.1, in addition to what I've said above, is that some of the issues introduced in subsections of section 2.1, like filterability of host addresses, really belong in the initial section 2.1 introduction, so that the subsections of 2.1 can refer back and give the reader a coherent picture, rather than requiring the reader to synthesize this as they read through the subsections. Section 2.3.2 talks about the threat of a MITM attack through the use of forged RAs, but doesn't actually describe how prevalent such on-link attacks are (this would be an on-link attack) nor does it talk about how such an on-link attack would be more effective than an attack the attacker could do without this capability. Without a threat model, this is somewhat hypothetical. Section 2.3.2 goes on to talk at length about how to make RA Guard work, without talking about when it is useful, what attacks it prevents, and what problems it causes when deployed incorrectly. We have actually run into serious problems working on the Thread Border Router specification because of uncertainty about whether RA Guard may be present on a network to which the TBR is attached. If it is, then the easiest way for the TBR to advertise reachability is gone, and we have to resort to bypasses such as ND Proxy, reverse NAT64, NAT66, or tunnels, just in order to ensure reachability of the leaf network. I think it's actively harmful to recommend the use of RA guard without talking about the problems it causes and how to mitigate them. This section should explicitly say that RA guard should never be enabled by default: it should be the case that the operator enables it explicitly, and that in cases where there is no operator with the authority to set routing policy for a link, RA guard should not be used on that link. SAVI is another extremely useful technology that can't really be deployed automatically without creating similar problems. To be clear, my goal here is not to say that the document shouldn't recommend RA guard or SAVI, but rather that it should be very clear about when to deploy it and when not to. In section 2.3.5, what is a "generic operating system?" I don't know what this term means. Can you use a term with a clearer meaning? One thing I didn't see discussed in section 2 that I think belongs there is the concept of isolation of networks. Networks that provide connectivity to general-purpose devices like phones and comouters may need to provide flexibility of addressing for privacy reasons. Infrastructure devices, particularly those for which MUD is applicable, may need to be on networks where filtering is present and addressing is tightly controlled. There's no discussion fo this kind of separation in the document, and I think it's a serious gap. From nobody Sun Nov 17 22:50:25 2019 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 4428B1200B3; Sun, 17 Nov 2019 22:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60uakoZ6I14x; Sun, 17 Nov 2019 22:50:19 -0800 (PST) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 AD01E12089E; Sun, 17 Nov 2019 22:50:19 -0800 (PST) Received: by mail-qk1-x72d.google.com with SMTP id i3so1519187qkk.9; Sun, 17 Nov 2019 22:50:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PylIzbLJMJWRKcfMHNpZyp1lkcnWfoeNAEjMjmUKpm0=; b=o9USI0nvfpgj5slNOEomBmL9+5HM0Oicmsr+lPXWl05WF2FRSzSHD90axrdcD9MRXu ZkEu0KxMQsaKy+/7j+mb2pfGeiNfgZtngdE75ztgJ/RxwY1jtdKG2hub0SZSYIbpXoOS AzomPeQV2ODWB8cj1f/qvJ/3V/vxMf3T4MrR0ewKh8FfO76Nd7mi3cxLPxgXKYx78y3I bTlo1tSKzTJYwFYj8P9B0qLEnwL0NCdc/+Bxuuj3dwIRiayPzS/gAybAH1/FSX0p+d/U AYj8Fy7jlZYCBBZYbUDQEYKB30YGiLa84NXCmwX/wY23VbsooJ68X/pB7jwR5m4o8j0Y aaQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PylIzbLJMJWRKcfMHNpZyp1lkcnWfoeNAEjMjmUKpm0=; b=nBlzvujL65YnfQ37DSgODj7DBL2EZgeFyhqnEbuegxPAcQ8ptZX+zR78FyXZAnu649 id2W2JhbvGZH6IvsIxVwNPUzrELS9jVDBUx03933//m7gvWPlTo1B1+g4il4vMgGcJxn f2xIm6f292cae0icD1GKJBr/bFyGPI6s4CZQSmWWUSaonlNtW74RaYgBr+FKUts2Ethm wEX9qw2OXxqyNTEysFgLlrsAfhwnOrqlfuUTT4DROWlV2GXYb6TZtvp3vcPK2TqM3c75 +GlDLrpIIOdbXAmU6pVGz/46qtcfP/cQnZiIDIDOIMkaQe2uFlhXW+RD6zjQuW4D5GtG zwqQ== X-Gm-Message-State: APjAAAVgfksrvLC+8Onnl0wAaEePanSZRi22EMLS7mjHFHtnZeLLj2AR hERAozbwP+dwIjaDFTlYFMEwEKBHh38= X-Google-Smtp-Source: APXvYqwAnuc8f6p5XlfRgL3QaxAWwBN0dcxBbsqd9vZau+XoVprRFcTcdMjZA5TajqsFElwRsXThsw== X-Received: by 2002:a05:620a:120c:: with SMTP id u12mr22207964qkj.441.1574059818095; Sun, 17 Nov 2019 22:50:18 -0800 (PST) Received: from [192.168.1.213] (pool-72-83-194-140.washdc.fios.verizon.net. [72.83.194.140]) by smtp.gmail.com with ESMTPSA id a7sm8056422qka.136.2019.11.17.22.50.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Nov 2019 22:50:16 -0800 (PST) From: Gyan Mishra X-Google-Original-From: Gyan Mishra Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (16G102) In-Reply-To: <157394737956.25908.2003745932020934234@ietfa.amsl.com> Date: Mon, 18 Nov 2019 01:50:15 -0500 Cc: Iot-dir@ietf.org, opsec@ietf.org, draft-ietf-opsec-v6.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <157394737956.25908.2003745932020934234@ietfa.amsl.com> To: Ted Lemon Archived-At: Subject: Re: [OPSEC] Iotdir early review of draft-ietf-opsec-v6-21 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, 18 Nov 2019 06:50:22 -0000 Ted Thank you for the comments. In the abstract it does mention the audience but needs to be clearer as I ag= ree to your point that this document is geared for a managed network and not= for unmanaged or home network. ULA mentioned in section 2.1 mentions use case described in RFC 4864 but sho= uld mention section 3.2 of that document. I think we could add some verbiag= e that ULA is used for local scope communications only. Also maybe a case of= SHIM6 multi homing or where 6to6 nat - nat64 is used where ULA is inside l= ocal Nat to outside global address use case. Maybe also mention default addr= ess selection RFC 6724 where a host is configured with both ULA and Global a= nd how ULA is used for internal local communications and how the global addr= ess is used for external internet communications. 2.1.4 static does mention obfuscation of static address but 2.1.6 does not s= ince DHCPv6 ISC or other DHCPV6 server implementations the pool address pick= ed let=E2=80=99s say within the scope is randomly picked each time the serve= r doles ourt an IPv6 lease by default and not picked sequentially by the ser= ver which is why obfuscation is not mentioned. We could mention that is ho= w the DHCPv6 sever picks the address so that is not confused. We don=E2=80=99= t mention split scope is required for redundancy which should be mentioned a= nd how that works in comparison to IPv4 where state sharing is done between a= ctive and backup server where with DHCPV6 no active leases state sharing. W= e will get that added as well. Also a caveat with DHCPv6 that when the prim= ary server goes down and the lease has to be renewed rebind time that the IP= v6 address has to change at which time any active session will have to reset= . I have actually deployed this with BT Diamond which used ISC and to get a= round this issue we ended up setting a long 7 day lease time with larger blo= ck size for the scope being a /112 versus our initial /116 scope. Also good= to mention that since the 128 bits is managed to use smaller scope size for= split scope then 2 /65 since their is not any privacy extension which state= ful that for security it=E2=80=99s better to have a smaller DHCPv6 scope for= managed address. In section 2.1.6 the DUID has the mac embedded in the add= ress embedded in the DUID as the 48 LSB bits. Can you provide the use case w= here the DUID does not have embedded mac. I agree that 2.1.7 needs to some= extra verbiage as to the use case of when and why addressing would be done a= s /64 per host and refer back to 2.1.4 static addressing use case. Thank you=20 Gyan Sent from my iPhone > On Nov 16, 2019, at 6:36 PM, Ted Lemon via Datatracker w= rote: >=20 > Reviewer: Ted Lemon > Review result: On the Right Track >=20 > This is a review of draft-ietf-opsec-v6 from the IoT Directorate perspecti= ve. =20 > I am a volunteer on the IoT, and do not speak authoritatively for the IoT > Directorate as a whole. My impression of this document is that it's usefu= l, > but could use some work. Some of my comments below are coming strictly f= rom > an IoT perspective; others are more general. >=20 > --- >=20 > The document doesn't talk about its intended audience. It appears to be t= he > case based on my reading of it that the intended audience is enterprise > operators and similar. This should be stated clearly and explicitly. Som= e of > the advice in this document would be actively harmful if deployed on an > unmanaged network (e.g. in a home). That doesn't mean that the document i= s > bad=E2=80=94just that it needs to be scoped appropriately. I would sugge= st adding a > brief statement of applicability in the abstract and a more detailed > explanation in the introduction. It is important that this statement make= > clear that the advice in this document must not be followed by implementer= s of > home routers and similar devices. E.g., this advice would utterly break a= > Thread (IPv6 over 802.15.4 mesh) Border Router. >=20 > It's also not clear that this document lives up to its abstract. The abs= tract > says: >=20 > This document analyzes the operational security issues in several > places of a network (enterprises, service providers and residential > users) and proposes technical and procedural mitigations techniques. >=20 > And yet if you look for example at section 2.1.1, there is no actual analy= sis > of the use of ULAs, nor is any advice on their use provided. >=20 > Section 2.1.4 doesn't mention using DHCP to provide hosts with obfuscated > address that, since known to the operator, can be added to filter lists as= > appropriate, while still making probing mathematically challenging to an > outside attacker. >=20 > Section 2.1.6 incorrectly implies that DHCPv4 binds IP addresses to link-l= ayer > addresses. This is not true. I don't know that it really matters, but si= nce > it's not true, you should fix it. DHCPv4 uses a "client identifier," whic= h is > quite similar to a DUID. If no client identifier is offered, then the > link-layer address is used, but this is not required, and the behavior > described for DUIDs in this document is also applicable to client identifi= ers. >=20 > 2.1.7 seems to be continuing a thought that was started in 2.1.4. It woul= d be > worth stating that explicitly, and comparing and contrasting these approac= hes. >=20 > Although the abstract explicitly excludes applicability to IoT networks, t= he > advice in this document will necessarily be taken as applicable in situati= ons > where IoT networks are leaf networks or even infrastructure that is presen= t > alongside the networks that _are_ covered by this document. This has some= > specific impacts that aren't talked about here and should be. For instan= ce, > Manufacturer Usage Descriptions (MUD) are not mentioned, and should be. M= UD > is applicable to infrastructure devices and really any special-purpose dev= ice; > e.g., MUD would be highly appropriate for use in hospital environments whe= re > many devices are connected to the network that absolutely must have their > accessibility controlled; MUD is a good candidate for doing this. The > omission of this approach from section 2,1 is a major gap, since the issue= s > discussed in section 2.1 directly impact the feasibility of using MUD (sin= ce > MUD specifies firewall behavior for devices, and devices are necessarily > identified by source address). >=20 > The conclusion I'm drawing having gotten to the end of section 2.1, in add= ition > to what I've said above, is that some of the issues introduced in subsecti= ons > of section 2.1, like filterability of host addresses, really belong in the= > initial section 2.1 introduction, so that the subsections of 2.1 can refer= back > and give the reader a coherent picture, rather than requiring the reader t= o > synthesize this as they read through the subsections. >=20 > Section 2.3.2 talks about the threat of a MITM attack through the use of f= orged > RAs, but doesn't actually describe how prevalent such on-link attacks are (= this > would be an on-link attack) nor does it talk about how such an on-link att= ack > would be more effective than an attack the attacker could do without this > capability. Without a threat model, this is somewhat hypothetical. >=20 > Section 2.3.2 goes on to talk at length about how to make RA Guard work, > without talking about when it is useful, what attacks it prevents, and wha= t > problems it causes when deployed incorrectly. We have actually run into > serious problems working on the Thread Border Router specification because= of > uncertainty about whether RA Guard may be present on a network to which th= e TBR > is attached. If it is, then the easiest way for the TBR to advertise > reachability is gone, and we have to resort to bypasses such as ND Proxy, > reverse NAT64, NAT66, or tunnels, just in order to ensure reachability of t= he > leaf network. >=20 > I think it's actively harmful to recommend the use of RA guard without tal= king > about the problems it causes and how to mitigate them. This section shoul= d > explicitly say that RA guard should never be enabled by default: it should= be > the case that the operator enables it explicitly, and that in cases where t= here > is no operator with the authority to set routing policy for a link, RA gua= rd > should not be used on that link. >=20 > SAVI is another extremely useful technology that can't really be deployed > automatically without creating similar problems. To be clear, my goal her= e is > not to say that the document shouldn't recommend RA guard or SAVI, but rat= her > that it should be very clear about when to deploy it and when not to. >=20 > In section 2.3.5, what is a "generic operating system?" I don't know wha= t > this term means. Can you use a term with a clearer meaning? >=20 > One thing I didn't see discussed in section 2 that I think belongs there i= s the > concept of isolation of networks. Networks that provide connectivity to > general-purpose devices like phones and comouters may need to provide > flexibility of addressing for privacy reasons. Infrastructure devices, > particularly those for which MUD is applicable, may need to be on networks= > where filtering is present and addressing is tightly controlled. There's n= o > discussion fo this kind of separation in the document, and I think it's a > serious gap. >=20 >=20 From nobody Mon Nov 18 23:31:02 2019 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 CA2CE120089 for ; Mon, 18 Nov 2019 23:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwXxA947ZOro for ; Mon, 18 Nov 2019 23:30:58 -0800 (PST) Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) (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 40A1B120878 for ; Mon, 18 Nov 2019 23:30:58 -0800 (PST) Received: by mail-qk1-x741.google.com with SMTP id z23so16914925qkj.10 for ; Mon, 18 Nov 2019 23:30:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gJG+7oBQCzlah4n/lzJCJn6BneYcIy2Lo0ly54mtpNs=; b=QBBFj7bjC3VKMTiSgLZ40oa/yLspQL4N7eU0oeknYbbqMh7ow9a6d3zThQbKHV0EhQ 9IHRKD9iY4DZ+ewGmYGzRWve/2gCPOhlQgL6c/xc93WZk6OCF1OIp/XegM5XcdOZMDDw r/gSgK+YWawLtNIi2ubsbUhWdEmEJwlEUFvcImNdnps+Nf74nIPueZT522OK/pUA4PZA Jx8Ymq0YPlNqTvcIzy7Y/a3IOP2QoExogigrsEQa1jVWLQnfFyZMnmhnYCME2VIsdHz2 4LogGpjHM5C9UkHP1ysdE3SayN2SKa46TOgbNoq6JNxEie+ucUXr270288nYKgMmYnFp I1BA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gJG+7oBQCzlah4n/lzJCJn6BneYcIy2Lo0ly54mtpNs=; b=jiqev3JLkB/ywZRDqnLynvTuqABLkj8WrNerJoEfU3wgLcaIAXx9kB27AdptSexYMe t2F45Le7j0Z6nUMrFmhcBj0z74ihLGWs4jEhwZdtWqbOc7HGr7ofp8YCmRvMn/5utDE7 hKKprtR69m5f0bzs85lzJoBMmwo2CyoluTOA5+4eqy+zXExbE7kdzRHMb53U2TFFO2di aB/P9Qfhhk6HeMboEwBj8zgcoxGcxQMyBJWN5NDTRvvkJwInHKlM8YE0GdhsqakR6FBB RbzzCY0JgM1esJN1Yv4LV58k357kdtjfksy8+b7JerOyXsjMTMmg2U39iF4oJExGjPXg r2BA== X-Gm-Message-State: APjAAAUy4ElU4YSSp+quFsR1zrKcEKiORV0jTrEQ6LTzgCtWnwGd35s8 hswgJ9i5WrvqvkE70W+PFDci8g== X-Google-Smtp-Source: APXvYqz6rOVGZwlLaeF/9tO5/A1GtrLSqcARqMoGvK6oXgLpjSrLVB96/tkfpM181M/TFlwpcJ500Q== X-Received: by 2002:ae9:f217:: with SMTP id m23mr27977006qkg.151.1574148657130; Mon, 18 Nov 2019 23:30:57 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:6101:8b1:d9fd:1e9a? ([2601:18b:300:36ee:6101:8b1:d9fd:1e9a]) by smtp.gmail.com with ESMTPSA id k129sm9891907qke.128.2019.11.18.23.30.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Nov 2019 23:30:56 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.1\)) From: Ted Lemon In-Reply-To: Date: Tue, 19 Nov 2019 02:30:54 -0500 Cc: Iot-dir@ietf.org, opsec@ietf.org, draft-ietf-opsec-v6.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <157394737956.25908.2003745932020934234@ietfa.amsl.com> To: Gyan Mishra X-Mailer: Apple Mail (2.3608.40.2.2.1) Archived-At: Subject: Re: [OPSEC] Iotdir early review of draft-ietf-opsec-v6-21 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, 19 Nov 2019 07:31:01 -0000 On Nov 18, 2019, at 1:50 AM, Gyan Mishra wrote: > ULA mentioned in section 2.1 mentions use case described in RFC 4864 = but should mention section 3.2 of that document. I think we could add = some verbiage that ULA is used for local scope communications only. Also = maybe a case of SHIM6 multi homing or where 6to6 nat - nat64 is used = where ULA is inside local Nat to outside global address use case. Maybe = also mention default address selection RFC 6724 where a host is = configured with both ULA and Global and how ULA is used for internal = local communications and how the global address is used for external = internet communications. I don=E2=80=99t think you should mention anything that=E2=80=99s not = ready to deploy. SHIM6 is a neat idea that nobody has deployed, as far = as I know, and it=E2=80=99s not clear that it can be deployed. I may be = wrong about that=E2=80=94that=E2=80=99s just my impression=E2=80=94but = the point is that if you=E2=80=99re going to suggest something, it = should be readily actionable. > 2.1.4 static does mention obfuscation of static address but 2.1.6 does = not since DHCPv6 ISC or other DHCPV6 server implementations the pool = address picked let=E2=80=99s say within the scope is randomly picked = each time the server doles ourt an IPv6 lease by default and not picked = sequentially by the server which is why obfuscation is not mentioned. = We could mention that is how the DHCPv6 sever picks the address so that = is not confused. We don=E2=80=99t mention split scope is required for = redundancy which should be mentioned and how that works in comparison to = IPv4 where state sharing is done between active and backup server where = with DHCPV6 no active leases state sharing. We will get that added as = well. Also a caveat with DHCPv6 that when the primary server goes down = and the lease has to be renewed rebind time that the IPv6 address has to = change at which time any active session will have to reset. I have = actually deployed this with BT Diamond which used ISC and to get around = this issue we ended up setting a long 7 day lease time with larger block = size for the scope being a /112 versus our initial /116 scope. Also = good to mention that since the 128 bits is managed to use smaller scope = size for split scope then 2 /65 since their is not any privacy extension = which stateful that for security it=E2=80=99s better to have a smaller = DHCPv6 scope for managed address. In section 2.1.6 the DUID has the mac = embedded in the address embedded in the DUID as the 48 LSB bits. Can = you provide the use case where the DUID does not have embedded mac. I = agree that 2.1.7 needs to some extra verbiage as to the use case of = when and why addressing would be done as /64 per host and refer back to = 2.1.4 static addressing use case. Why do you need a split scope? If the prefix is managed, just give out = random addresses. Use a good random number generator. Use failover to = keep the servers in sync. DUID is opaque. We recommended generating it using the MAC address = because we hadn=E2=80=99t thought about privacy. RFC7824 makes it = clear that this is a problem. Any DHCP implementation on a device where = privacy is a likely issue should already be randomizing the DUID. = DUID-LLT with a random MAC address should be safe to use and unique. It = can be regenerated as frequently as the client decides. But this isn=E2=80=99t really your problem. You=E2=80=99re talking = about network operational security, not about host operational security. = =46rom the network perspective, you should just assume that this = problem either is solved, or will be solved, because the network = operator=E2=80=99s behavior is the same in either case. In fact, given = that we are talking about firewalls and filtering here, the fact that = any client already can just fabricate a DUID means that you have to = account for that when talking about the policy implications of this. From nobody Tue Nov 19 17:12:10 2019 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 5ADBC1208E2; Tue, 19 Nov 2019 17:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVNqdQV7Nd1x; Tue, 19 Nov 2019 17:12:05 -0800 (PST) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 75333120116; Tue, 19 Nov 2019 17:12:05 -0800 (PST) Received: by mail-qk1-x736.google.com with SMTP id z16so19813874qkg.7; Tue, 19 Nov 2019 17:12:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lPBSy53ka5MPVoWneWjl2VArd8+BUyJXs8O9iz5T/DA=; b=J4lCWRMYQSiVO2u+9chb09CC2khOobbYn6paSGHb8w3ZPOLrxe/kAnTKk1J0BnbMzt nyPbnkdfsbq0TTZ7VjiMFjnna5VzEM0DBL6jt92zv3A12nRhjaAuzQaNIOLTGigLnYoe pGFIaiWETjEJGKitq6XlGjfkIF8crEWQq6CVDjOjAxBssEDoMsq0UtqViiNbSrKMVt+r 8hhdSYYEmnbmmI5Yq14J8Hwa/i3sZAMIfJG9pgXiX/CGtC1aeJKGBQZ4e3Dy1Ew6AzL8 3oVGkw4UTNxcBdQ/pH7gwWEoSye7Fdf2J35215PHQin4pXjpxWszuCv4vsXaFrMXUNy4 u/RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lPBSy53ka5MPVoWneWjl2VArd8+BUyJXs8O9iz5T/DA=; b=d3pO6E5Mm8HDtbMRa8UBwzprjwjW5VD/4tV6ju9MeHUG2iPHf+dIY915h/2PmnAxKC W8r8HmHxPkRWmsER7o8aR2uOeTdbTLODRw8UWqdxvE39+NHOlkL9yjgX6lhrLnm//Mq5 Jt+lf8mPtpbkAAOZ/KLJD2GMeFbIL2hCcsmLbOQXjvG2d3zpabZ/ZsDnETRI23vE81FV PFxKXE6blZWfoUCc3jlyOkz1x33whUKEwgOr722m9n5UFhGl+W0i7akxhUS4YcRIu4GY 56pu9PRCHcIJVLSxO+1QXKysj4YajWDT61LKDi7RaW9Q5AcvFAkjw7smLNrXdhBHfHIk BjUA== X-Gm-Message-State: APjAAAUYzeL7u6ldoWBUnrMoaox2V49q4r/hZjAVmZG4bi34VJFQ3X0+ C5k/I7jf4RaeIM6vpiJf1HcqobkC X-Google-Smtp-Source: APXvYqxaIeb3z6HNAeAGutOhCm197rDvzO6kPn+2pIgZdnG7vWimqrJLXefHLZfMd4dGRB25bWUN3A== X-Received: by 2002:a05:620a:911:: with SMTP id v17mr190916qkv.88.1574212323887; Tue, 19 Nov 2019 17:12:03 -0800 (PST) Received: from ?IPv6:2600:1003:b110:b21f:a8af:6a7b:f98:340b? ([2600:1003:b110:b21f:a8af:6a7b:f98:340b]) by smtp.gmail.com with ESMTPSA id l132sm11203232qke.38.2019.11.19.17.12.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Nov 2019 17:12:03 -0800 (PST) From: Gyan Mishra X-Google-Original-From: Gyan Mishra Content-Type: multipart/alternative; boundary=Apple-Mail-33B08C89-5147-4FFA-AFE6-641B3517196C Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (16G102) In-Reply-To: Date: Tue, 19 Nov 2019 20:12:01 -0500 Cc: Iot-dir@ietf.org, opsec@ietf.org, draft-ietf-opsec-v6.all@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <95B1A8FE-A74F-47C3-AC91-66A10B727D32@gmail.com> References: <157394737956.25908.2003745932020934234@ietfa.amsl.com> To: Ted Lemon Archived-At: Subject: Re: [OPSEC] Iotdir early review of draft-ietf-opsec-v6-21 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, 20 Nov 2019 01:12:08 -0000 --Apple-Mail-33B08C89-5147-4FFA-AFE6-641B3517196C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable >> On Nov 19, 2019, at 2:30 AM, Ted Lemon wrote: >>=20 >> On Nov 18, 2019, at 1:50 AM, Gyan Mishra wrote: >> ULA mentioned in section 2.1 mentions use case described in RFC 4864 but s= hould mention section 3.2 of that document. I think we could add some verbi= age that ULA is used for local scope communications only. Also maybe a case o= f SHIM6 multi homing or where 6to6 nat - nat64 is used where ULA is inside l= ocal Nat to outside global address use case. Maybe also mention default addr= ess selection RFC 6724 where a host is configured with both ULA and Global a= nd how ULA is used for internal local communications and how the global addr= ess is used for external internet communications. >=20 > I don=E2=80=99t think you should mention anything that=E2=80=99s not ready= to deploy. SHIM6 is a neat idea that nobody has deployed, as far as I know= , and it=E2=80=99s not clear that it can be deployed. I may be wrong about t= hat=E2=80=94that=E2=80=99s just my impression=E2=80=94but the point is that i= f you=E2=80=99re going to suggest something, it should be readily actionable= . Agreed. >=20 >> 2.1.4 static does mention obfuscation of static address but 2.1.6 does no= t since DHCPv6 ISC or other DHCPV6 server implementations the pool address p= icked let=E2=80=99s say within the scope is randomly picked each time the se= rver doles ourt an IPv6 lease by default and not picked sequentially by the s= erver which is why obfuscation is not mentioned. We could mention that is h= ow the DHCPv6 sever picks the address so that is not confused. We don=E2=80= =99t mention split scope is required for redundancy which should be mentione= d and how that works in comparison to IPv4 where state sharing is done betwe= en active and backup server where with DHCPV6 no active leases state sharing= . We will get that added as well. Also a caveat with DHCPv6 that when the p= rimary server goes down and the lease has to be renewed rebind time that the= IPv6 address has to change at which time any active session will have to re= set. I have actually deployed this with BT Diamond which used ISC and to ge= t around this issue we ended up setting a long 7 day lease time with larger b= lock size for the scope being a /112 versus our initial /116 scope. Also go= od to mention that since the 128 bits is managed to use smaller scope size f= or split scope then 2 /65 since their is not any privacy extension which sta= teful that for security it=E2=80=99s better to have a smaller DHCPv6 scope f= or managed address. In section 2.1.6 the DUID has the mac embedded in the a= ddress embedded in the DUID as the 48 LSB bits. Can you provide the use cas= e where the DUID does not have embedded mac. I agree that 2.1.7 needs to s= ome extra verbiage as to the use case of when and why addressing would be do= ne as /64 per host and refer back to 2.1.4 static addressing use case. >=20 > Why do you need a split scope? If the prefix is managed, just give out ra= ndom addresses. Use a good random number generator. Use failover to keep t= he servers in sync. See RFC 6853. https://tools.ietf.org/html/rfc6853#section-6.1 With DHCPV6 all servers are active and that is why there is not any state sh= aring since the pool has to be different and there a a preference option as t= o which server is preferred. This does go deeper into host configuration wh= ich is out of scope for this document so will leave out. >=20 > DUID is opaque. We recommended generating it using the MAC address becaus= e we hadn=E2=80=99t thought about privacy. RFC7824 makes it clear that thi= s is a problem. Any DHCP implementation on a device where privacy is a like= ly issue should already be randomizing the DUID. DUID-LLT with a random MAC= address should be safe to use and unique. It can be regenerated as frequen= tly as the client decides. >=20 DUID-LLT which is most commonly used still uses an embedded Mac but now alon= g with time source to generate the DUID versus DUID-LL. > But this isn=E2=80=99t really your problem. You=E2=80=99re talking about n= etwork operational security, not about host operational security. =46rom t= he network perspective, you should just assume that this problem either is s= olved, or will be solved, because the network operator=E2=80=99s behavior is= the same in either case. In fact, given that we are talking about firewall= s and filtering here, the fact that any client already can just fabricate a D= UID means that you have to account for that when talking about the policy im= plications of this. >=20 Agreed. I think staying on point with network operational security which is t= he goal of this draft and not drift into the weeds on host security. That i= n itself could be a separate host operational security draft.= --Apple-Mail-33B08C89-5147-4FFA-AFE6-641B3517196C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Nov 19, 2019, at 2:30 AM, Ted Lemon &l= t;mellon@fugue.com> wrote:
On Nov 18, 2019, at 1= :50 AM, Gyan Mishra <hayabusagsm= @gmail.com> wrote:
ULA ment= ioned in section 2.1 mentions use case described in RFC 4864 but should ment= ion section 3.2 of that document.  I think we could add some verbiage t= hat ULA is used for local scope communications only. Also maybe a case of SH= IM6 multi homing or where 6to6  nat - nat64 is used where ULA is inside= local Nat to outside global address use case. Maybe also mention default ad= dress selection RFC 6724 where a host is configured with both ULA and Global= and how ULA is used for internal local communications and how the global ad= dress is used for external internet communications.
<= span>
I don=E2=80=99t think you should mention anything that= =E2=80=99s not ready to deploy.  SHIM6 is a neat idea that nobody has d= eployed, as far as I know, and it=E2=80=99s not clear that it can be deploye= d.  I may be wrong about that=E2=80=94that=E2=80=99s just my impression= =E2=80=94but the point is that if you=E2=80=99re going to suggest something,= it should be readily actionable.

Agreed.

2.1.4 static does mention obfuscation of static= address but 2.1.6 does not since DHCPv6 ISC or other DHCPV6 server implemen= tations the pool address picked let=E2=80=99s say within the scope is random= ly picked each time the server doles ourt an IPv6 lease by default and not p= icked sequentially by the server which is why obfuscation is not mentioned. &= nbsp; We could mention that is how the DHCPv6 sever picks the address s= o that is not confused.  We don=E2=80=99t mention split scope is requir= ed for redundancy which should be mentioned and how that works in comparison= to IPv4 where state sharing is done between active and backup server where w= ith DHCPV6 no active leases state sharing.  We will get that added as w= ell.  Also a caveat with DHCPv6 that when the primary server goes down a= nd the lease has to be renewed rebind time that the IPv6 address has to chan= ge at which time any active session will have to reset.  I have actuall= y deployed this with BT Diamond which used ISC and to get around this issue w= e ended up setting a long 7 day lease time with larger block size for the sc= ope being a /112 versus our initial /116 scope.  Also good to mention t= hat since the 128 bits is managed to use smaller scope size for split scope t= hen 2 /65 since their is not any privacy extension which stateful that for s= ecurity it=E2=80=99s better to have a smaller DHCPv6 scope for managed addre= ss.  In section 2.1.6 the DUID has the mac embedded in the address embe= dded in the DUID as the 48 LSB bits.  Can you provide the use case wher= e the DUID does not have embedded mac.  I agree  that 2.1.7 needs t= o some extra verbiage as to the use case of when and why addressing would be= done as /64 per host and refer back to 2.1.4 static addressing use case.

Why do you need a split scope? &= nbsp;If the prefix is managed, just give out random addresses.   U= se a good random number generator.  Use failover to keep the servers in= sync.

See RFC 6853.=

With DHCPV6 all servers are active a= nd that is why there is not any state sharing since the pool has to be diffe= rent and there a a preference option as to which server is preferred.  = This does go deeper into host configuration which is out of scope for this d= ocument so will leave out.
<= div dir=3D"ltr">
DUID is opaque.  We recommended g= enerating it using the MAC address because we hadn=E2=80=99t thought about p= rivacy.   RFC7824 makes it clear that this is a problem.  Any= DHCP implementation on a device where privacy is a likely issue should alre= ady be randomizing the DUID.  DUID-LLT with a random MAC address should= be safe to use and unique.  It can be regenerated as frequently as the= client decides.

DUID-LLT whic= h is most commonly used still uses an embedded Mac but now along with time s= ource to generate the DUID versus DUID-LL.

But this isn=E2=80=99t really your= problem.  You=E2=80=99re talking about network operational security, n= ot about host operational security.   =46rom the network perspecti= ve, you should just assume that this problem either is solved, or will be so= lved, because the network operator=E2=80=99s behavior is the same in either c= ase.  In fact, given that we are talking about firewalls and filtering h= ere, the fact that any client already can just fabricate a DUID means that y= ou have to account for that when talking about the policy implications of th= is.

Agreed. I think staying on= point with network operational security which is the goal of this draft and= not drift into the weeds on host security.  That in itself could be a s= eparate host operational security draft.
= --Apple-Mail-33B08C89-5147-4FFA-AFE6-641B3517196C-- From nobody Tue Nov 19 22:06:31 2019 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 4D4BF1202DD; Tue, 19 Nov 2019 22:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OJnRAXXBp1H; Tue, 19 Nov 2019 22:06:28 -0800 (PST) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 9BA14120274; Tue, 19 Nov 2019 22:06:28 -0800 (PST) Received: by mail-pl1-x634.google.com with SMTP id q18so9606978pls.5; Tue, 19 Nov 2019 22:06:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=sqry/mGqDkAikAu+9TAJnraoldZPnOEaBmds6Hy1jeA=; b=qD4qPRko1tH3RNR3wRzS8nJ/UOBuJCgNvJaN73ecyeknSyJSs0lXdvqgK2YOct4hre 45dIV+lUfJPd4w8Rs5dTaJLMtcHeyaiWc7LLnQfDdsVkHg38XMAfWS4gVJLhCE6m7I9i wYwLnrif6pkt5Sa81WKTgbbSHqY3sjdmjjgOZkiYVBv4FjnI/nteTbsZzmN+bk+MqKHg P5h68Rk7o6qnrpNHd9N3QKP/uEXb4HOhTElJderzJULwl1YaQkzfl123O6Jm3OCGVs3T z4g7rPn8WCNUrAdhchp7bdHKrV1k6t1pU8dFTKibMZ3fj0AGmLk1V/PO58LWG72sKwgs VeWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=sqry/mGqDkAikAu+9TAJnraoldZPnOEaBmds6Hy1jeA=; b=Gn8SBV/ymvXOukJWcmqYfcgBxdBq/J8Tdb+wSisvPfV/32hMWl8af+5ss7Hwotx5yH ZZUBUG/vmZmZ+qpddI0WKy7JTTsu40OoCfWQaT/GzbvGN+oeuc1uEHRkwkEks/jUTNB5 i3SlIfafmrvymiS+SL18bkWPPcPW7yPueYvf6Flgm/+vZsJlCzsoYquyDSRjknKQZcmw dCqTfcqZu4BDq8ZZAMwwee/UP8gVguMaQfwdSikfuPlYixdoG66dRn8tmANl7xBUXnOU DqyKQumd4D7+zFKQyEJZg2km578cX6HVYSBiPse6HVmYpsVpoMqEZFm7Qp3QXHCyj3ne ZoRg== X-Gm-Message-State: APjAAAXc6rB4UgsdZc3ACIhM0Mj7M2lx1vgUpCM3leqCDv8WNIlTciOg CbZfivqxiEFvfLlkGiGTC78= X-Google-Smtp-Source: APXvYqwBSACIDZh/oPT1W8tN/AWxqHszsY5O/XRQZ8pxGMy0fRczW7I10/rf6Fae6js59bocJW3JDQ== X-Received: by 2002:a17:90a:24b:: with SMTP id t11mr1902366pje.77.1574229988094; Tue, 19 Nov 2019 22:06:28 -0800 (PST) Received: from dhcp-8974.meeting.ietf.org (dhcp-8974.meeting.ietf.org. [31.133.137.116]) by smtp.gmail.com with ESMTPSA id 16sm28848768pfc.21.2019.11.19.22.06.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Nov 2019 22:06:27 -0800 (PST) From: Suresh Krishnan Message-Id: <5277F10F-A455-48A1-B81E-1C6840CBD90A@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8EF99687-DA7D-4ADC-9B8D-46C2F7A856D4" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 20 Nov 2019 14:06:24 +0800 In-Reply-To: <95B1A8FE-A74F-47C3-AC91-66A10B727D32@gmail.com> Cc: Ted Lemon , opsec@ietf.org, Iot-dir@ietf.org, draft-ietf-opsec-v6.all@ietf.org To: Gyan Mishra References: <157394737956.25908.2003745932020934234@ietfa.amsl.com> <95B1A8FE-A74F-47C3-AC91-66A10B727D32@gmail.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OPSEC] [IoT-DIR] Iotdir early review of draft-ietf-opsec-v6-21 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, 20 Nov 2019 06:06:30 -0000 --Apple-Mail=_8EF99687-DA7D-4ADC-9B8D-46C2F7A856D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Gyan/Ted, > On Nov 20, 2019, at 9:12 AM, Gyan Mishra = wrote: >=20 >=20 >=20 > On Nov 19, 2019, at 2:30 AM, Ted Lemon > wrote: >=20 >> On Nov 18, 2019, at 1:50 AM, Gyan Mishra > wrote: >>> ULA mentioned in section 2.1 mentions use case described in RFC 4864 = but should mention section 3.2 of that document. I think we could add = some verbiage that ULA is used for local scope communications only. Also = maybe a case of SHIM6 multi homing or where 6to6 nat - nat64 is used = where ULA is inside local Nat to outside global address use case. Maybe = also mention default address selection RFC 6724 where a host is = configured with both ULA and Global and how ULA is used for internal = local communications and how the global address is used for external = internet communications. >>=20 >> I don=E2=80=99t think you should mention anything that=E2=80=99s not = ready to deploy. SHIM6 is a neat idea that nobody has deployed, as far = as I know, and it=E2=80=99s not clear that it can be deployed. I may be = wrong about that=E2=80=94that=E2=80=99s just my impression=E2=80=94but = the point is that if you=E2=80=99re going to suggest something, it = should be readily actionable. >=20 > Agreed. >>=20 >>> 2.1.4 static does mention obfuscation of static address but 2.1.6 = does not since DHCPv6 ISC or other DHCPV6 server implementations the = pool address picked let=E2=80=99s say within the scope is randomly = picked each time the server doles ourt an IPv6 lease by default and not = picked sequentially by the server which is why obfuscation is not = mentioned. We could mention that is how the DHCPv6 sever picks the = address so that is not confused. We don=E2=80=99t mention split scope = is required for redundancy which should be mentioned and how that works = in comparison to IPv4 where state sharing is done between active and = backup server where with DHCPV6 no active leases state sharing. We will = get that added as well. Also a caveat with DHCPv6 that when the primary = server goes down and the lease has to be renewed rebind time that the = IPv6 address has to change at which time any active session will have to = reset. I have actually deployed this with BT Diamond which used ISC and = to get around this issue we ended up setting a long 7 day lease time = with larger block size for the scope being a /112 versus our initial = /116 scope. Also good to mention that since the 128 bits is managed to = use smaller scope size for split scope then 2 /65 since their is not any = privacy extension which stateful that for security it=E2=80=99s better = to have a smaller DHCPv6 scope for managed address. In section 2.1.6 = the DUID has the mac embedded in the address embedded in the DUID as the = 48 LSB bits. Can you provide the use case where the DUID does not have = embedded mac. I agree that 2.1.7 needs to some extra verbiage as to = the use case of when and why addressing would be done as /64 per host = and refer back to 2.1.4 static addressing use case. >>=20 >> Why do you need a split scope? If the prefix is managed, just give = out random addresses. Use a good random number generator. Use = failover to keep the servers in sync. >=20 > See RFC 6853. >=20 > https://tools.ietf.org/html/rfc6853#section-6.1 = >=20 > With DHCPV6 all servers are active and that is why there is not any = state sharing since the pool has to be different and there a a = preference option as to which server is preferred. This does go deeper = into host configuration which is out of scope for this document so will = leave out. >>=20 >> DUID is opaque. We recommended generating it using the MAC address = because we hadn=E2=80=99t thought about privacy. RFC7824 makes it = clear that this is a problem. Any DHCP implementation on a device where = privacy is a likely issue should already be randomizing the DUID. = DUID-LLT with a random MAC address should be safe to use and unique. It = can be regenerated as frequently as the client decides. >>=20 > DUID-LLT which is most commonly used still uses an embedded Mac but = now along with time source to generate the DUID versus DUID-LL. There are specific recommendations for this (generation of DUIDs) in = Section 4.3 of RFC7844, essentially describing randomizing contents (and = usage of =E2=80=9Cold=E2=80=9D random timestamps for DUID-LLT).=20 Regards Suresh --Apple-Mail=_8EF99687-DA7D-4ADC-9B8D-46C2F7A856D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Gyan/Ted,

On Nov 20, 2019, at 9:12 AM, Gyan Mishra = <hayabusagsm@gmail.com> wrote:



On Nov 19, 2019, at 2:30 AM, Ted Lemon <mellon@fugue.com> = wrote:

On Nov 18, 2019, = at 1:50 AM, Gyan Mishra <hayabusagsm@gmail.com> wrote:
ULA = mentioned in section 2.1 mentions use case described in RFC 4864 but = should mention section 3.2 of that document.  I think we could add = some verbiage that ULA is used for local scope communications only. Also = maybe a case of SHIM6 multi homing or where 6to6  nat - nat64 is = used where ULA is inside local Nat to outside global address use case. = Maybe also mention default address selection RFC 6724 where a host is = configured with both ULA and Global and how ULA is used for internal = local communications and how the global address is used for external = internet communications.

I don=E2=80=99t think = you should mention anything that=E2=80=99s not ready to deploy. =  SHIM6 is a neat idea that nobody has deployed, as far as I know, = and it=E2=80=99s not clear that it can be deployed.  I may be wrong = about that=E2=80=94that=E2=80=99s just my impression=E2=80=94but the = point is that if you=E2=80=99re going to suggest something, it should be = readily actionable.

Agreed.

2.1.4 static does mention obfuscation of = static address but 2.1.6 does not since DHCPv6 ISC or other DHCPV6 = server implementations the pool address picked let=E2=80=99s say within = the scope is randomly picked each time the server doles ourt an IPv6 = lease by default and not picked sequentially by the server which is why = obfuscation is not mentioned.   We could mention that is how = the DHCPv6 sever picks the address so that is not confused.  We = don=E2=80=99t mention split scope is required for redundancy which = should be mentioned and how that works in comparison to IPv4 where state = sharing is done between active and backup server where with DHCPV6 no = active leases state sharing.  We will get that added as well. =  Also a caveat with DHCPv6 that when the primary server goes down = and the lease has to be renewed rebind time that the IPv6 address has to = change at which time any active session will have to reset.  I have = actually deployed this with BT Diamond which used ISC and to get around = this issue we ended up setting a long 7 day lease time with larger block = size for the scope being a /112 versus our initial /116 scope. =  Also good to mention that since the 128 bits is managed to use = smaller scope size for split scope then 2 /65 since their is not any = privacy extension which stateful that for security it=E2=80=99s better = to have a smaller DHCPv6 scope for managed address.  In section = 2.1.6 the DUID has the mac embedded in the address embedded in the DUID = as the 48 LSB bits.  Can you provide the use case where the DUID = does not have embedded mac.  I agree  that 2.1.7 needs to some = extra verbiage as to the use case of when and why addressing would be = done as /64 per host and refer back to 2.1.4 static addressing use = case.

Why do you need a split scope?  If the = prefix is managed, just give out random addresses.   Use a = good random number generator.  Use failover to keep the servers in = sync.

See RFC 6853.

https://tools.ietf.org/html/rfc6853#section-6.1

With DHCPV6 all servers are active = and that is why there is not any state sharing since the pool has to be = different and there a a preference option as to which server is = preferred.  This does go deeper into host configuration which is = out of scope for this document so will leave out.

DUID = is opaque.  We recommended generating it using the MAC address = because we hadn=E2=80=99t thought about privacy.   RFC7824 = makes it clear that this is a problem.  Any DHCP implementation on = a device where privacy is a likely issue should already be randomizing = the DUID.  DUID-LLT with a random MAC address should be safe to use = and unique.  It can be regenerated as frequently as the client = decides.

DUID-LLT which is most commonly used still = uses an embedded Mac but now along with time source to generate the DUID = versus DUID-LL.

There = are specific recommendations for this (generation of DUIDs) in Section = 4.3 of RFC7844, essentially describing randomizing contents (and usage = of =E2=80=9Cold=E2=80=9D random timestamps for = DUID-LLT). 

Regards
Suresh

= --Apple-Mail=_8EF99687-DA7D-4ADC-9B8D-46C2F7A856D4-- From nobody Wed Nov 20 01:53:31 2019 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 DABAB1208C6 for ; Wed, 20 Nov 2019 01:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iUSwLE_o8Yw for ; Wed, 20 Nov 2019 01:53:23 -0800 (PST) Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) (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 3FD8C1208BF for ; Wed, 20 Nov 2019 01:53:23 -0800 (PST) Received: by mail-qv1-xf2e.google.com with SMTP id y18so9443102qve.2 for ; Wed, 20 Nov 2019 01:53:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=kYMpL/vAKGF702siHhy5KZYBnCY0MHvE1/qtMMR7AKQ=; b=OCidimxGpGBVvaHkPnqhsEUCtgT97WGCSe7UoTJveAaIuaal8wGXnC7N/UDsqSnRe4 XpO2NpotKir5fdLb3CjS8WuU4oUtYlFN+fEmhXd/uwsoSsGRjHXl3uM6oDEELKTh4zrH SDAFoLIe/sjlCMWjnZo/h1K8xd3t8KN6L91IdYvLU95kiZYS5ze980k5Zx3SaBELtRaG nqhJbrTuI3DnDl5DHLHM6lbxFjdLMe4/n/tK5CGWDUQqOJqY5R5g4aVHhJOvFhDhJDsY CGL2roFzTqwVGLQxhRmmXhEBcepn816zlUnZjEE/Bd3OmF/yzj1UZ7zF3qnCbQVyV7OR dOvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=kYMpL/vAKGF702siHhy5KZYBnCY0MHvE1/qtMMR7AKQ=; b=FFwVsF+3frvAn7TH4x6+cFH9hAZrc+/Vb8s+jXlMOwwftrJ2m/c9MkoJeOGDJbsZ+n tnfsgVY+vblsEWrCV409J0OFAedYAT/n0TXvXJIufIi+mEUmD3SWk345XAi7/7J1XHAK cSCjI03xvH8tSO6/tUT7XbZazxPm9aF4b9FYOUPL1iaLcKBwrSkzBwiHnY3DSAaqXs1v xhf5k8ZVQ2W0B/iNIFLplIyjjJ2UhWCqLwIASLJavyxUczwSNmuQkRziWAFi0UlIhCOF q4DpS1bLtEohTaTbxohxZ46/TBk33dvGpkMIeUpIZDPloKlmQKZxcNH93HUpfhYG2ahn CUpA== X-Gm-Message-State: APjAAAUA0JRUl34QWNox3eo7lPmW1LuRhwn4hO4j2foA55Y/sDJ8TjmS bMQlbaowUomlcdpN7WsVSxMWfA== X-Google-Smtp-Source: APXvYqxQ+7/01zx9fQp/bDVZERzIv2+CntDhi8eismEinfQvC3x+OhqL+Kf/HVphC6tHQvRDBWOAJg== X-Received: by 2002:a0c:edcc:: with SMTP id i12mr1675270qvr.20.1574243602277; Wed, 20 Nov 2019 01:53:22 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:9125:6a16:b164:3b45? ([2601:18b:300:36ee:9125:6a16:b164:3b45]) by smtp.gmail.com with ESMTPSA id a4sm11333310qkk.113.2019.11.20.01.53.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 Nov 2019 01:53:21 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-18A46DEE-E882-4A09-87A4-EF2677BBC289 Content-Transfer-Encoding: 7bit From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Wed, 20 Nov 2019 04:53:20 -0500 Message-Id: References: <95B1A8FE-A74F-47C3-AC91-66A10B727D32@gmail.com> Cc: iot-dir@ietf.org, opsec@ietf.org, draft-ietf-opsec-v6.all@ietf.org In-Reply-To: <95B1A8FE-A74F-47C3-AC91-66A10B727D32@gmail.com> To: Gyan Mishra X-Mailer: iPad Mail (17E177) Archived-At: Subject: Re: [OPSEC] Iotdir early review of draft-ietf-opsec-v6-21 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, 20 Nov 2019 09:53:27 -0000 --Apple-Mail-18A46DEE-E882-4A09-87A4-EF2677BBC289 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Nov 19, 2019, at 8:12 PM, Gyan Mishra wrote: >=20 > See RFC 6853. >=20 > https://tools.ietf.org/html/rfc6853#section-6.1 >=20 > With DHCPV6 all servers are active and that is why there is not any state s= haring since the pool has to be different and there a a preference option as= to which server is preferred. This does go deeper into host configuration w= hich is out of scope for this document so will leave out. Right. What I=E2=80=99m suggesting is that you explicitly recommend using D= HCPv6 servers that support RFC 8156 rather than the less effective solution p= roposed in RFC 6853. This recommendation will not be actionable for all net= work operators, but it should work well in enterprise settings. --Apple-Mail-18A46DEE-E882-4A09-87A4-EF2677BBC289 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Nov 19, 2019, at 8:12 PM, Gyan Mishra &l= t;hayabusagsm@gmail.com> wrote:
See RFC 6853.

With D= HCPV6 all servers are active and that is why there is not any state sharing s= ince the pool has to be different and there a a preference option as to whic= h server is preferred.  This does go deeper into host configuration whi= ch is out of scope for this document so will leave out.

Right.  What I=E2=80=99m suggesting is that you explicitly= recommend using DHCPv6 servers that support RFC 8156 rather than the less e= ffective solution proposed in RFC 6853.  This recommendation will not b= e actionable for all network operators, but it should work well in enterpris= e settings.

= --Apple-Mail-18A46DEE-E882-4A09-87A4-EF2677BBC289-- From nobody Sat Nov 23 23:12:12 2019 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 F05BA1200B4; Sat, 23 Nov 2019 23:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 0n95ztoBp7SR; Sat, 23 Nov 2019 23:12:08 -0800 (PST) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 5AC9C120025; Sat, 23 Nov 2019 23:12:08 -0800 (PST) Received: by mail-io1-xd2f.google.com with SMTP id u24so10927541iob.5; Sat, 23 Nov 2019 23:12:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p4V+A0hdiF5KxObRiMXYlMd1nBAkTXFsUHAS2E7Mvb8=; b=EKIgf5x2vtkmtgrI46xoxjmXxSle0O1pMrIDnmQc0q5uo7GvPRyIsMLfrR9zoKI9U+ iImxoqhhHhrkQAVDIo9QegRldUm/oV3GT+KVZqADxZ5jRU4saLHAJF84Wk6BfoHLJw4p /SvuN9YNHBZiuo/bDAlLMhBIv/WFgEqB37tvLzGD9fwEsVOEhaP5b0j1Ebl4NYF35aOy EANI88cD2Kd8WOAil9nUyH8hK1F8DruhOpJj7uYPQ4qf8pZjMGMVRz5KM2qG2KIk4E+f YjV0Y5QTLEGbXLGFdXjnZ/CzCuPHqa47bzMRy/gImDoxADVoljUv4L+iqb0OPoB6adsR ZNZQ== 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=p4V+A0hdiF5KxObRiMXYlMd1nBAkTXFsUHAS2E7Mvb8=; b=jFJXyZNhlGP6hvSpDxYUT4ceGzuSTpbT3h2wA78lyBs6WhleobM23/V5s0rCmmhtSD /EcvBGxq3DtJ+EDrvHWzXlArzUrIrJXdv+Xu95cAgsA7e1rtuFD6Vk5qXVQaWy0OlAoA qiI3cacI31HZbpwBt/5kTAPRPCKqhVvhwaLa7M0VBOCsI71qj4hOg9zuVRHK2sec/2nn 9fu9CyOCe1P0AAplPkPk2uSYshedKgIA/dwI84s12VlUN8TP5YuTkbpYl7n5bVXQ0J7C oVx+MS+3hDWX8WWGAuI9p/i0f6ILzfVIkpiIGJ7j3ODYCc5Mp8Hf89/YF8VQZUThE2or IrZQ== X-Gm-Message-State: APjAAAVa4ef2+/hRgFkBBaL70l3NeVfm/2dLTK0eo5nC9nfy8PUsuh8F drn8Jtx20R6WKWPPd0XnIItq8AXPUIxzrKqC05I1aF7Y X-Google-Smtp-Source: APXvYqya3ZbeZywk1SYifAiWheqCdgRWSvED0PQtAzuULqg8mnrQakspsr3tlaaWUaDjA5RFYoocBm1tNZv5yiZZ1oM= X-Received: by 2002:a02:13c2:: with SMTP id 185mr14404373jaz.0.1574579527302; Sat, 23 Nov 2019 23:12:07 -0800 (PST) MIME-Version: 1.0 References: <95B1A8FE-A74F-47C3-AC91-66A10B727D32@gmail.com> In-Reply-To: From: Gyan Mishra Date: Sun, 24 Nov 2019 02:11:56 -0500 Message-ID: To: Ted Lemon Cc: draft-ietf-opsec-v6.all@ietf.org, iot-dir@ietf.org, opsec@ietf.org Content-Type: multipart/alternative; boundary="0000000000006545a70598125d46" Archived-At: Subject: Re: [OPSEC] Iotdir early review of draft-ietf-opsec-v6-21 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: Sun, 24 Nov 2019 07:12:11 -0000 --0000000000006545a70598125d46 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Agreed. We will update the draft to reflect. This is exactly what I have been looking for in an enterprise setting and I see it=E2=80=99s authored by ISC. Thank you for enlightening me. Gyan On Wed, Nov 20, 2019 at 4:53 AM Ted Lemon wrote: > On Nov 19, 2019, at 8:12 PM, Gyan Mishra wrote: > > See RFC 6853. > > https://tools.ietf.org/html/rfc6853#section-6.1 > > With DHCPV6 all servers are active and that is why there is not any state > sharing since the pool has to be different and there a a preference optio= n > as to which server is preferred. This does go deeper into host > configuration which is out of scope for this document so will leave out. > > > Right. What I=E2=80=99m suggesting is that you explicitly recommend usin= g DHCPv6 > servers that support RFC 8156 rather than the less effective solution > proposed in RFC 6853. This recommendation will not be actionable for all > network operators, but it should work well in enterprise settings. > > -- Gyan S. Mishra IT Network Engineering & Technology Verizon Communications Inc. (VZ) 13101 Columbia Pike FDC1 3rd Floor Silver Spring, MD 20904 United States Phone: 301 502-1347 Email: gyan.s.mishra@verizon.com www.linkedin.com/in/networking-technologies-consultant --0000000000006545a70598125d46 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agreed. We will update the draft to reflect.

This is exactly what I ha= ve been looking for in an enterprise setting and I see it=E2=80=99s authore= d by ISC.

Thank you for = enlightening me.

Gyan

On Wed, Nov 20, 2019 at 4:53 AM Ted Lemon <mellon@fugue.com> wrote:
On Nov 19, 2019, at 8:12 PM, Gyan Mishra <hayabusagsm@gmail.com<= /a>> wrote:
S= ee RFC 6853.

Wit= h DHCPV6 all servers are active and that is why there is not any state shar= ing since the pool has to be different and there a a preference option as t= o which server is preferred.=C2=A0 This does go deeper into host configurat= ion which is out of scope for this document so will leave out.
<= /blockquote>
Right.=C2=A0 What I=E2=80=99m suggesting is that you e= xplicitly recommend using DHCPv6 servers that support RFC 8156 rather than = the less effective solution proposed in RFC 6853.=C2=A0 This recommendation= will not be actionable for all network operators, but it should work well = in enterprise settings.

= --

Gyan S. Mishra<= span>

IT Network Engineering & Technology=C2=A0=

Verizon Communications=C2=A0Inc. (VZ)=

13101 Columbia Pike FDC1 3rd Floor

=

Silver Spring, MD 20904

United States<= span style=3D"color:rgb(80,0,80);background-image:initial;background-positi= on:initial;background-repeat:initial">

Phone:=C2=A0301 502-1347

Email:=C2=A0gyan.s.mishra@verizon.= com

www.linkedin.com/in/networking-technologies-co= nsultant


--0000000000006545a70598125d46-- From nobody Sun Nov 24 03:40:38 2019 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 E6466120128 for ; Sun, 24 Nov 2019 03:40:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-gXFfp4c2Ox for ; Sun, 24 Nov 2019 03:40:33 -0800 (PST) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 7696F120127 for ; Sun, 24 Nov 2019 03:40:33 -0800 (PST) Received: by mail-qk1-x72f.google.com with SMTP id h15so10210847qka.13 for ; Sun, 24 Nov 2019 03:40:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=/5AY778a+WqWQ2TmsWAExxUkE+t0zomGHFriiH09uMQ=; b=feRpXmlfMGroaZjQvYS1ASfMD/5AEnNh0yd5QJKqFKM5AurXURqyeLa86j7HUGp2Mk IgSz9xT31Im7IJSSCsQqjT4z+h8T27zJ/1EsNP+e6hzg564NoEEWeL/iCc2ewfX/2Vpw TRaxElY18bJdaQyVUgMMQw3mPtcVDlSP0W09jXeV4Y9DcDq2QOFv2sBE6VfsXWhPuHfF jkSBrdpWfac1u5ws4riOUb0zy1FnRuBHmaCrFYbA68py0kYLW/V2J8YtLHK0yfSf2K9c dfVBBIqi1PuDoy6LPQTwEtQNMIItiVV9jCvVyr2KPqDg2Tiyn0/0BH6w/12r4OGu96Bf 3FWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=/5AY778a+WqWQ2TmsWAExxUkE+t0zomGHFriiH09uMQ=; b=G1C/ggiglca8E5ROlbIlbZqjH6DRFwefnMBBNgKV7T60HdNFwSgvZA+9bU1dMiK8TU 4ZHStyhwV/QleO8GwekIb4LLZL1eXYjExKt+u6hHOSHgsSaswyR+WBXg0VGgOb4Cw1O1 9NMeW4IiVcXRLNV54xEMHhOP/tGbj5m/QsGIdeIxqK2VtlHaLRTauruMB1q2b/vYWD4z j5K43aWonxLNxmYMx9h4DzLDOpxxPCbFTu5AdBBfnKn6LyjzFsKdCuTzm69wHDhZf/sq VJevkN0Z5OuOI7t1cHYpW0p9RZVJmiUbAa4HWKTj0PJrMGrowpJvjRnkO6hnGHJFUnRl 8XxQ== X-Gm-Message-State: APjAAAWxapZA4dUB9TkKxc6cnsC5M6CvHzwFHrQs5Ta+L9oOZHT56YEj 7pLUYy4XXw4Pm3a7hVerfWsyWA== X-Google-Smtp-Source: APXvYqztbRVboCgz7gXKKRpjj1gWFixq6hfuwCjUYOy5iFAxN6O0+mDCpvxYLMdf+IL/Aq8bJ8I1CA== X-Received: by 2002:a05:620a:1505:: with SMTP id i5mr12227773qkk.64.1574595631243; Sun, 24 Nov 2019 03:40:31 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:f8d0:944f:1039:9d4c? ([2601:18b:300:36ee:f8d0:944f:1039:9d4c]) by smtp.gmail.com with ESMTPSA id d6sm1717194qkb.103.2019.11.24.03.40.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 24 Nov 2019 03:40:30 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Sun, 24 Nov 2019 06:40:29 -0500 Message-Id: <771DF135-9C27-4B2D-ABBA-A6CAD44BEB03@fugue.com> References: Cc: draft-ietf-opsec-v6.all@ietf.org, iot-dir@ietf.org, opsec@ietf.org In-Reply-To: To: Gyan Mishra X-Mailer: iPhone Mail (17E180a) Archived-At: Subject: Re: [OPSEC] Iotdir early review of draft-ietf-opsec-v6-21 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: Sun, 24 Nov 2019 11:40:36 -0000 On Nov 24, 2019, at 02:12, Gyan Mishra wrote: > This is exactly what I have been looking for in an enterprise setting and I= see it=E2=80=99s authored by ISC. The bulk of the work was done by Kim Kinnear when he was working at American= Internet, and finished after Cisco acquired them. It=E2=80=99s an excellent= piece of work. I=E2=80=99ve implemented an earlier version of the spec (I n= o longer so DHCP work).=20=