Re: [OPSEC] Iotdir early review of draft-ietf-opsec-v6-21
"Eric Vyncke (evyncke)" <evyncke@cisco.com> Fri, 12 February 2021 15:31 UTC
Return-Path: <evyncke@cisco.com>
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 DB59D3A172B for <opsec@ietfa.amsl.com>; Fri, 12 Feb 2021 07:31:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=OOGn2Zlg; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=l8ZubgYQ
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 XOZbbl37frD3 for <opsec@ietfa.amsl.com>; Fri, 12 Feb 2021 07:31:10 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CEEB3A1729 for <opsec@ietf.org>; Fri, 12 Feb 2021 07:31:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=53231; q=dns/txt; s=iport; t=1613143870; x=1614353470; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=NKGwZPXU4v3TLxiPFheWpJsu2QuL7ZRATNjuDaaIhqc=; b=OOGn2Zlgn9dbFwyOI5sDRWjJKtwR7OAdV9xn18Cj3RmEF/WaYYesYFpz bGtYyXhfrvTOAFY3NXh8XCQKYMglQHq5dEUUQE4uXnoi7CtSmIy/dqaM3 vgIcU1PNB+hvCg+IQQZicGa2sbssFt9kxcmXN+T5c2oBQKli1kmnm/19B I=;
X-IPAS-Result: A0BuAwCOniZgmIoNJK1iHQICCRQFBYIQgSMwIy59WhIkMQKEP4NIA44YA4ofjn2BQoERA1QLAQEBDQEBHQEKCgIEAQGETAIXgXACJTgTAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQEBAQEBAQGGCQglDYZEAQEBBAEBGAkdAQEsCwELBAIBCA4DAwECIQEGAwICAh8GCxQJCAIEDgWCcAGBflcDLgEOPaUSAooldoEygwQBAQaFGA0LghIDBoE4gnaCb1BGAQGBC4MTgicmHIFBQYERJwwQglY+ghtCAQGBKQEBEgFBFoJgNIIrgVkFCx0RLQYBPSYEAwo2EBQMAg0hCwUBNyoCFQsFARkCDQECFhoCLY90EwgREoJUQYc/gzuJD5A1OVsKgnqPaVKGJoUpAx+DMZA5j0KiZY50BIRVAgICAgQFAg4BAQaBJEghOTBwcBU7KgGCPlAXAg1VYIx2DgmDToUUhUVzDSoCBgEJAQEDCXyLFwEB
IronPort-PHdr: 9a23:RonMABAsFkndwv1EjGAEUyQJPHJ1sqjoPgMT9pssgq5PdaLm5Zn5IUjD/qw00A3HQIrG5rRPjO+F+6zjWGlV55GHvThCdZFXTBYKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGFtvxelCUqXq3vnYeHxzlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8NhKz+A7QrcIRx4BlL/U8
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,174,1610409600"; d="scan'208,217";a="665635059"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Feb 2021 15:31:08 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 11CFV87M004668 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 Feb 2021 15:31:08 GMT
Received: from xfe-rcd-002.cisco.com (173.37.227.250) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 12 Feb 2021 09:31:08 -0600
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Fri, 12 Feb 2021 09:31:08 -0600
Received: from NAM12-MW2-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.1497.2 via Frontend Transport; Fri, 12 Feb 2021 09:31:07 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=e4ESgZ4V6oI2Z/CxRB7YBgn14sD0piSPYoFkcWMcCkQWtHgu2dQ6Vu8XUrjz8rgE/rG7DVCc2IzTUtzc1xquubvOj34RrUkN5BS6+aY3sIKPG98WMRl4eAA9P1HjTfY/arrklEGLkSQbmweX2wPg5WLojJRft7oTi/eYLwD9bhn0K5NmqMa39ijHxgCokcQ1Lvoh3Jk/6PpuiPuneuMY0VsCoCygRI9Nnvult0DiL0kn3HyzTUXyD4+OqL1gJsp2uti5xBYaxl/myQgYn8I131vLD72T1CcXzfdfy7F3Zf4tMuYVMwiFofBwiF3ivhOMVjLcsZFBuFikhtBnqikKew==
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=NKGwZPXU4v3TLxiPFheWpJsu2QuL7ZRATNjuDaaIhqc=; b=h0W87fW2UUcLlYBBxHBPStBI3rIBETjEDDpto1zmoT6GHeOZYz3zZem7JH97tzZz917TN0qaq4g1Nm3KGKr/pyLr1qWl/EbhxSQh5n7aTaocpcK4z/DTJGbqrp2VaT+OFg7i0zIYWLwRqpfSRV6zDhVQrGXXm7SqapDR7z7Pz4knbKJyIZGJ8SYOCohfOBFxPBXOlB5v76tKo6totTm9kwbOcGi9VOkBXQ8CHwzgU3P2ZgCffQcYsAI1E+GshtHnjtGXxa/bKckP4s8nPiwWwkZNbSHWMP6qoTOr0uFRE9C1Xk+KZlauxtz+YB/ToVHO9c9T7i9K8fUrAZzTzgvoHQ==
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=NKGwZPXU4v3TLxiPFheWpJsu2QuL7ZRATNjuDaaIhqc=; b=l8ZubgYQSgUB3rYotUyt5oydEA0TrP81p3Pfe+Y8CnV4mI3Wi+2KYzMMMwEbIi5wndT44FGrvOHuLR6yLZyd9fnZuhx7u483+MdaejbOU9u5cCDHhv+CS8PHqpV8pHv8IWuXmmryd3wGN1pw3lS4iee5GPEBmVuQWbZpqOXCLS0=
Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB4824.namprd11.prod.outlook.com (2603:10b6:510:38::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.27; Fri, 12 Feb 2021 15:31:06 +0000
Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::7d4c:6b05:89aa:85b]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::7d4c:6b05:89aa:85b%3]) with mapi id 15.20.3846.031; Fri, 12 Feb 2021 15:31:06 +0000
From: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
To: Ted Lemon <mellon@fugue.com>
CC: Merike Kaeo <merike@doubleshotsecurity.com>, KK Chittimaneni <kk.chittimaneni@gmail.com>, Enno Rey <erey@ernw.de>, "opsec@ietf.org" <opsec@ietf.org>
Thread-Topic: [OPSEC] Iotdir early review of draft-ietf-opsec-v6-21
Thread-Index: AQHXAVQU8VxjxUWpvEaJA5sQUdn0Ag==
Date: Fri, 12 Feb 2021 15:31:05 +0000
Message-ID: <2B0A426F-9414-4FC2-99A1-DF71D495F02C@cisco.com>
References: <157394737956.25908.2003745932020934234@ietfa.amsl.com> <DA7A5C72-C893-4240-A716-B0BD37122916@doubleshotsecurity.com> <7BCD5A24-D200-48F9-8410-7F1D5BA28B28@cisco.com> <20F36D91-A80F-49F8-9820-BAB18BACB4B5@fugue.com>
In-Reply-To: <20F36D91-A80F-49F8-9820-BAB18BACB4B5@fugue.com>
Accept-Language: fr-BE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.45.21011103
authentication-results: fugue.com; dkim=none (message not signed) header.d=none;fugue.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2a02:578:8557:600:11fc:3088:6d1b:c0d4]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 42d445e5-81d1-4769-5c3d-08d8cf6b36c3
x-ms-traffictypediagnostic: PH0PR11MB4824:
x-microsoft-antispam-prvs: <PH0PR11MB4824DBAA2DB4E2B06304A522A98B9@PH0PR11MB4824.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: y6UkOGIuk7Z2NrJfnfIpEARy0VFuXDnw56oEjkrxJnhJtTLACzTpISFBkB8E+PePsSeCaNwyIk86Tg2sQaeA8o5F3ezgbsytnlppAmhSG/u3LNXcdGqJPtrHGyxoxarPLOb7lM6HVkWeVcQJcYNv2jmCcb9W/v1bpz8KlwmodwNmQ1DlS9GUe/HNGzSMTHHC9bADRDigemRfL0UmktkAz2UyZvtjWEQ3W5oBPR1mxitHl++ixZeNYDFvPEKNejYjyvVjs9IKCA3yLdd5Gqlv6K8LC8mFKJec8MMXN/aAp0hXid3SYGG2pmi5M3Zh3Tf7fMoYsLJVEMX386wd5HHBZDGasqwdCsyuef0M7SFANC/Gl5mxPCt5NQFZwQ4V3aBHDowpCRHHBVh6TO5XGWqkdKol3/Bn66oVevuEt5QJb2drAqxvvZxRX4zk+t5WgC1a+V64yEG1wRpgAce9li9jibX+zypCczHGgyDdP35u8UFALNnt8wjz95OwI1Oz2PqTu4YlSoHvOpHPhfM2tv8MnvtMDx7M1LrWAJACPOAOWQF/BDSRXAT6jO88QDA44QDwo+3ejC2FRViWr5gN1Al1HYJuGaaNj+DezBbIXnNcs9LluISIV1+ZojD04W9hNXOA/h5cPJN/AN0IUizc+k9yFg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(376002)(39860400002)(346002)(396003)(366004)(2906002)(8936002)(8676002)(66574015)(71200400001)(83380400001)(316002)(33656002)(54906003)(30864003)(5660300002)(86362001)(186003)(4326008)(6486002)(6512007)(2616005)(53546011)(6506007)(91956017)(76116006)(66446008)(64756008)(6916009)(66476007)(36756003)(66556008)(66946007)(478600001)(966005)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: /q0oL/vZLSAV/z/vLtLapD5y0jUFpvEpCqXi4UmvKTF0bZ1s8HBLbCCOxdySVbthB99TfUksfLFCj00VGh4tctfKqlxLC+di4+HVYarZRrevGIO93AxkgjEGPl5QM1O76Ezt3RKKVzEfUPicvY7A7QUOJbeAs8LQ3tt5UkZgah/XBb+hADYCUUGD2EUIapy0Ov9C1QfYlNqT+8vEXpgda/0E+yl7N4JK4/UfzIlT8dFe+/Iu3OMWKVM6P5s5HmBXlvMZPT4KwB6xoDQNml2d10W2Bi7Ezo4AsWrrOXhTp/LD1us8DPDA5nBYuQ7rhhnbYY9mwwO3dUG5MTBmjEp4w0QyufVJBxqDQIBpeDtGrEN8pF/SPmBujDLI38PrfMJpCGIfl4zshykvhuLqiO1rG2p9vyiKgizmldJw82SolEJSG7EEZtpHiWb5d6bcyF0brfhEGDgycNHjYMSZQnUHItp7f0liopNSKu+QTafmqoiN4cjGM4ScauEqbVS6luM7EKt467bkhJhHvCdFafXKooLVFsGxsaQEfyy615E0S1mCOb3av5q/agI+mXYPenQCIWc98GAljZ5poCskmgi0K532XEiRNBpaUMU6vbiK8WS30hDJs2Q8N3V17MA2tRozLaGxrF78MiQ7mKh9GNz5KkElkeL8kh2CgYFZ8NYAkHGjqf+AdT2u8ce/SzLJL4xlQ7Cm9Y3UapCK5DEDYJ0TcDl2p15peZVKgYXObRxFJNsVEaSPv13GV/pw3fh25rNjW/UGPxc5SnhE8IRSlVmudjt5NXP0cv99lDRwZDsn7tmSW6htPotRec/UXuH6mP83nDyN9eISml4oKFkyDyzZGOaGUS9+aJ8S9m+FYRW91yghqNRwcaN0ldniwX2+KZfovTCrlHX4XZLiM606kDgbeXU+XQ/2fUAw3Zd8/HBgRFPgHOKrXqSk8AwxmwoHfXhhTDYsuFJUDNySeyeHXAQDJmePLgGLNXY4FlpDUOaJnbhzgNV6vp7p8Q1a5sIn6snuSfxQNsAZaX8P8nXcB/UT6KntZPTiZrOdQLC+1xsloKg47Or1hFmBB4dz+QEO2XxPv0QlTPje48UrfACMF7YWmM1CoKS+tzKtsndW74zEhHPc5K6CcBgO5boTe/ylMD+Vt49nGuU2IaLamjPbwq5w4rgjTotikkpD1ZxxCwhiirkYXKqN7WpRILsHZm0yBU/Z7wf+8MxOyCx44t9S5VIyYOaNORjAqlrXVgAnzYBii87+Nd9ahIqxZgTzGeQE7uZEWKqZIJ/Z25J204RTAp4h4bgrNyFfOGKoEgcnTu7BrN+cORCf5tystMznkUKy+TWgzhQ3ZFSydc3GKv05v/ERtbeuQtTf+3lRq9kOgzLUkRR4dvNvoK4N4DT3WnPcykEmjX7Euj1THKa3/boEu+sa4g==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_2B0A426F94144FC299A1DF71D495F02Cciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 42d445e5-81d1-4769-5c3d-08d8cf6b36c3
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2021 15:31:05.9331 (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: F1Z9XV63vdI3lT0MjFQyo1PE9VMiBXkPSUEayC6QgILp8owFxCpSuyTPmxKwNqHSdounzBBF8of9cfoy3dW8jA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4824
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/guA6e1s8xgBspbPDRsAZbg-PL8o>
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 <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Feb 2021 15:31:14 -0000
Ted, As you guessed in your email : we, the authors, do not want to prevent multi-homing ;-) E.g., we already have several ‘do not apply in all cases’ for several mitigation techniques include the RA-guard one for obvious reason. Just to be clear, we have used your suggestion to modify the abstract and add an applicability statement in a -24 version (yet to be published). We would appreciate it if you reviewed the proposed change below. --- start of 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 associated with several types of network and proposes technical and procedural mitigation techniques. This document is only applicable to managed networks, such as enterprise building networks. The recommendations in this document are not applicable to residential user cases, even in cases where a Service Provider may be managing the home gateway. --- end of abstract --- --- start of applicability statement (sub-section of introduction) --- 1.1. Applicability Statement This document is applicable to managed networks, i.e., when the network is operated by the user organization itself. Indeed, many of the recommended mitigation techniques must be configured with the detailed knowledge of the network (which are the default router, which are the switch trunk ports, etc.). This covers Service Provider (SP), enterprise networks and some knowledgeable-home-user- managed residential network. This applicability statement especially applies to Section 2.3 and Section 2.5.4. For example, an exception to the generic recommendations of this document is when a residential or enterprise network is multi-homed. --- end of applicability statement (sub-section of introduction) --- Regards -éric From: Ted Lemon <mellon@fugue.com> Date: Tuesday, 9 February 2021 at 16:59 To: Eric Vyncke <evyncke@cisco.com> Cc: Merike Kaeo <merike@doubleshotsecurity.com>, Kiran Kumar Chittimaneni <kk.chittimaneni@gmail.com>, Enno Rey <erey@ernw.de>, "opsec@ietf.org" <opsec@ietf.org> Subject: Re: [OPSEC] Iotdir early review of draft-ietf-opsec-v6-21 Éric, to be clear, your latest changes do not successfully address my comments. For example, you talk about a managed ISP router, and say that it’s okay for such a router to do all kinds of blocking on the home network. It’s not—what does the ISP know of the home network? How is the ISP qualified to set security and reachability policy on the home network? This will cause major operational problems. Any network on which this is deployed will break stub networks, such as are used by the HomePod Mini and Google’s Nest gateway to provide reachability to Thread networks. The text that I think you added to address my concerns is this: The residential users case assumes a managed ISP CPE device. Some very specific types of networks such as the Internet of Things (IoT) and unmanaged home networks are not discussed in this document. This is not helping. The text should read this way: This document is only applicable to managed networks, such as enterprise building networks. The recommendations in this document are not applicable to residential user cases, even in cases where an ISP may be managing the home gateway. If you really want this to apply to the ISP-managed home network router, it should only be in the case where the ISP is providing a value-added service—where the home user is actually paying for a person to manage their network, not just to have an ISP-owned router that maybe gets regular firmware updates and some centrally-managed malware site blocking. If you were to address this use case (which I think is really unnecessary), this document needs to talk about what an ISP would have to do to avoid creating interop problems for IoT networks in the home. This needs to be very explicit and needs to be mentioned in the sections where you talk about RA filtering and ND filtering. Sorry to be a sticky wicket, but I am afraid I failed to fully communicate the seriousness of this problem back in 2019. Also, I don’t mean to minimize the problem you are trying to address. I’m just saying that we don’t have the technology to address it right now, and trying to address it on an effectively unmanaged network with existing technology will create serious interoperability problems. In addition to the IoT stub networks issue, following this document on a home network would also eliminate multi-homing, which I hope is not something that we are proposing to do. On Feb 9, 2021, at 8:04 AM, Eric Vyncke (evyncke) <evyncke@cisco.com<mailto:evyncke@cisco.com>> wrote: Ted, Just to confirm that the revision -23 should have all your review items addressed except the 3 cited by Merike. The section 2.3.2 has been revised extensively. Thank you again for this review -éric -----Original Message----- From: Merike Kaeo <merike@doubleshotsecurity.com<mailto:merike@doubleshotsecurity.com>> Date: Thursday, 5 December 2019 at 20:13 To: Ted Lemon <mellon@fugue.com<mailto:mellon@fugue.com>>, Eric Vyncke <evyncke@cisco.com<mailto:evyncke@cisco.com>>, Kiran Kumar Chittimaneni <kk.chittimaneni@gmail.com<mailto:kk.chittimaneni@gmail.com>>, Enno Rey <erey@ernw.de<mailto:erey@ernw.de>> Cc: <opsec@ietf.org<mailto:opsec@ietf.org>> Subject: Re: [OPSEC] Iotdir early review of draft-ietf-opsec-v6-21 Hello Ted. Very much appreciate the thorough review of the document. All 4 authors agree with most of your comments which will be incorporated in the next revision (also includes the discussion between yourself, Gyan and Suresh re DHCPv6). For the comment re section 2.3.2 and RAs, can you point us to the relevant specifications for the TBR (Threat Boarder Route) so that we can come up with a potential addition that discusses the (non-) applicability of RA for certain scenarios? For 3 comments the authors want to preserve the existing language for reasons stated below. 2.1.1 on ULA: The very first draft had some specific language on ULA use and the topic of ULAs has been a major contention area to get to working group last call. Some individuals felt for years that the discussion on ULA should be to state that they are not required and not recommended while others wanted to be more explicit on recommended language *if* ULAs are used. The current language on ULAs reflects working group rough consensus after many iterations of language. Te authors would recommend that the language not be changed at this point. 2.1.7 re /64s. The section references rfc8273 and the working group felt that re-iterating even in more detail that work, which provides the added context, was not necessary in the document itself Last comment on Isolation of Networks - While we did not discuss varying network configurations, usually more explicit details are provided in the rfcs we reference. rfc8273 referenced in Section 2.1.7 and rfc7721 referenced in section 2.1.8 are some examples. - merike --- 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. _______________________________________________ OPSEC mailing list OPSEC@ietf.org<mailto:OPSEC@ietf.org> https://www.ietf.org/mailman/listinfo/opsec
- [OPSEC] Iotdir early review of draft-ietf-opsec-v… Ted Lemon via Datatracker
- Re: [OPSEC] Iotdir early review of draft-ietf-ops… Gyan Mishra
- Re: [OPSEC] Iotdir early review of draft-ietf-ops… Ted Lemon
- Re: [OPSEC] Iotdir early review of draft-ietf-ops… Gyan Mishra
- Re: [OPSEC] [IoT-DIR] Iotdir early review of draf… Suresh Krishnan
- Re: [OPSEC] Iotdir early review of draft-ietf-ops… Ted Lemon
- Re: [OPSEC] Iotdir early review of draft-ietf-ops… Gyan Mishra
- Re: [OPSEC] Iotdir early review of draft-ietf-ops… Ted Lemon
- Re: [OPSEC] Iotdir early review of draft-ietf-ops… Merike Kaeo
- Re: [OPSEC] Iotdir early review of draft-ietf-ops… Eric Vyncke (evyncke)
- Re: [OPSEC] Iotdir early review of draft-ietf-ops… Eric Vyncke (evyncke)
- Re: [OPSEC] Iotdir early review of draft-ietf-ops… Ted Lemon
- Re: [OPSEC] Iotdir early review of draft-ietf-ops… Ted Lemon
- Re: [OPSEC] Iotdir early review of draft-ietf-ops… Eric Vyncke (evyncke)
- Re: [OPSEC] Iotdir early review of draft-ietf-ops… Ted Lemon
- Re: [OPSEC] Iotdir early review of draft-ietf-ops… Eric Vyncke (evyncke)
- Re: [OPSEC] Iotdir early review of draft-ietf-ops… Stuart Cheshire
- Re: [OPSEC] Iotdir early review of draft-ietf-ops… Gert Doering
- Re: [OPSEC] Iotdir early review of draft-ietf-ops… Ted Lemon
- Re: [OPSEC] Iotdir early review of draft-ietf-ops… Gert Doering
- Re: [OPSEC] Iotdir early review of draft-ietf-ops… Ted Lemon
- Re: [OPSEC] Iotdir early review of draft-ietf-ops… Gert Doering
- Re: [OPSEC] Iotdir early review of draft-ietf-ops… Ted Lemon