From nobody Thu Dec 17 10:24:10 2020 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9823A0E68; Thu, 17 Dec 2020 10:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OspuAUOec60a; Thu, 17 Dec 2020 10:24:04 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEEF03A1123; Thu, 17 Dec 2020 10:23:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id D8A20389AC; Thu, 17 Dec 2020 13:26:15 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ytDGNo53Qibd; Thu, 17 Dec 2020 13:26:15 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6E64A389A8; Thu, 17 Dec 2020 13:26:15 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D1F7F11B4; Thu, 17 Dec 2020 13:23:29 -0500 (EST) From: Michael Richardson To: mud@ietf.org, opsawg@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Mud] my list of MUD related documents X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2020 18:24:06 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 1) SBOM Extension for MUD draft-lear-opsawg-mud-sbom-00 Abstract Software bills of materials (SBOMs) are formal descriptions of what pieces of software are included in a product. This memo specifies a means for manufacturers to state how SBOMs may be retrieved through an extension to manufacturer usage descriptions (MUD). 2) Authorized update to MUD URLs draft-richardson-opsawg-mud-acceptable-urls-03 Abstract This document provides a way for an RFC8520 Manufacturer Usage Description (MUD) definitions to declare what are acceptable replacement MUD URLs for a device. 3) Operational Considerations for use of DNS in IoT devices draft-richardson-opsawg-mud-iot-dns-considerations-03 Abstract This document details concerns about how Internet of Things devices use IP addresses and DNS names. The issue becomes acute as network operators begin deploying RFC8520 Manufacturer Usage Description (MUD) definitions to control device access. This document explains the problem through a series of examples of what can go wrong, and then provides some advice on how a device manufacturer can best make deal with these issues. The recommendations have an impact upon device and network protocol design. 4) On loading MUD URLs from QR codes draft-richardson-opsawg-securehomegateway-mud-05 Abstract This informational document details the mechanism used by the CIRA Secure Home Gateway (SHG) to load MUD definitions for devices which have no integrated MUD (RFC8520) support. 5) Manufacturer Usage Description for quarantined access to firmware draft-richardson-shg-mud-quarantined-access-02 Abstract The Manufacturer Usage Description is a tool to describe the limited access that a single function device such as an Internet of Things device might need. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl/boiEACgkQgItw+93Q 3WWG6Af/UavM3/1T3a9Ibfp+BtSGtkXkDSP4eAMTCPIXDxNyDSwYOM13aex94+D1 45lI7kjBn6hXr/aq3MiSUj8PTmmzRpLyhE5UmELNqEqgnZyR3RYDSZJoSMb7urDn 8sSCrj6iMORbYtrv582qgzpz7nYRdHZksxW2AaRMh+jbELIa+4wJXqE5OGdYzt1v gAfW9gC9Dj3lpjpg9yskXE1K2O3uuc/jp2Azh95p9rjVIy7QTDlfymeNCDawQn1K uzqCKF5OWkTy/fU+DGT/W4Wgu4/FHLOb92RsCZfshN3ph1KP+NHO1S+IoCkzkZ+7 mhbPsaa5LtbW10ipBZ4sSd4KF+96Cw== =TiFd -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 17 10:31:28 2020 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE4B3A0E6D; Thu, 17 Dec 2020 10:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bvm9XsMhmUs4; Thu, 17 Dec 2020 10:31:25 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CAA73A0E4D; Thu, 17 Dec 2020 10:31:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 73A0C389AC; Thu, 17 Dec 2020 13:34:08 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CDjT_MAcBID6; Thu, 17 Dec 2020 13:34:08 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id F26AF389A8; Thu, 17 Dec 2020 13:34:07 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 58E6A11B4; Thu, 17 Dec 2020 13:31:22 -0500 (EST) From: Michael Richardson To: mud@ietf.org, opsawg@ietf.org In-Reply-To: <27659.1608229409@localhost> References: <27659.1608229409@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Mud] Authorized update to MUD URLs -- draft-richardson-opsawg-mud-acceptable-urls-03 X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2020 18:31:28 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Michael Richardson wrote: > 2) Authorized update to MUD URLs > draft-richardson-opsawg-mud-acceptable-urls-03 > Abstract > This document provides a way for an RFC8520 Manufacturer Usage > Description (MUD) definitions to declare what are acceptable > replacement MUD URLs for a device. This document is intended to be an Update to RFC8520. In the parlance of draft-kuehlewind-update-tag-03 this document is an Amen= ds. It normatively changes how the MUD-URL attribute is to be interpreted. The first five pages are justification, section 5 is just over a page for t= he core. I believe that we presented this document at IETF107 in the Spring. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl/bo/oACgkQgItw+93Q 3WWG2wf/XvyTlcyeL+vwt4RA5q9HmuMqwFSRkEI2JQ0j3z2qfxK1YiZowpU6d9Pc bS1jmi5pCjAFAAA9fYJmSw384MJZjE1t2HmGuhnKKyVtkHQncTsxCvB4JAL5VNE4 hbkUd9L0u3XmeKuolAtF5YdDzpJjstK9lRelS66zOVcso8VRT5omKxGPZOl7A+5T aP0ltW8bIuCDyS32qtIIAG3IngilMi/lwl8gQHe6H3eAfhbjm2xD0Z1D8vA/2Ou/ uP+i17MCsH18CwZj4ddm7tiAyseFq1l64v+Dv1jE+Bb74RdwX+dAuxTtptw2LiL6 PJ7ovIhcW1rW6KPYe7SPr9YF4JokEQ== =2tXY -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 17 10:35:19 2020 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1009C3A0E6E; Thu, 17 Dec 2020 10:35:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dV8w994UDQIY; Thu, 17 Dec 2020 10:35:16 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F5D33A0E6D; Thu, 17 Dec 2020 10:35:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id AA5C3389AC; Thu, 17 Dec 2020 13:38:00 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rhoCJCauHvAb; Thu, 17 Dec 2020 13:38:00 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 40983389A8; Thu, 17 Dec 2020 13:38:00 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9CCFF11B4; Thu, 17 Dec 2020 13:35:14 -0500 (EST) From: Michael Richardson To: mud@ietf.org, opsawg@ietf.org, iotops@ietf.org In-Reply-To: <27659.1608229409@localhost> References: <27659.1608229409@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Mud] DNS in IoT devices -- draft-richardson-opsawg-mud-iot-dns-considerations-03 X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2020 18:35:18 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Michael Richardson wrote: > 3) Operational Considerations for use of DNS in IoT devices > draft-richardson-opsawg-mud-iot-dns-considerations-03 > Abstract > This document details concerns about how Internet of Things devices > use IP addresses and DNS names. The issue becomes acute as network > operators begin deploying RFC8520 Manufacturer Usage Description > (MUD) definitions to control device access. > This document explains the problem through a series of examples of > what can go wrong, and then provides some advice on how a device > manufacturer can best make deal with these issues. The > recommendations have an impact upon device and network protocol > design. This document is a BCP, and it creates no new protocol or on-the-wire-bits. It may be an appropriate document for IOTOPS if OPSAWG does not wish to work on it. Actually, I'm more and more convinced that this is an important aspect for an IETF architectural view on IoT. The ADD WG chairs examined it, as it has policy about when (not) to use DoT/DoH/QuadX-Do53, but determined that it was not in the rather narrow ADD charter. I would like to get early review from DNSOP, and I will endeavour to get th= at early in the new year. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl/bpOIACgkQgItw+93Q 3WWfnQgAv7rRo7KUbCj0hWcT2X1Kt7PUGAQ6Z7XPlDYcEn9islWNRBevIz6YvtnT 5IWQ30CsnS2fd7Ouh6kWM93CyS7bMlZlbnYWtYUWizUhm6WcRPRiJq56lVe3XPeL L55ktrq79JCzKAn+jdgo4+mChNLJH9m+KiqG75e49H677H57FDaqkrab/KBEUvTx s5oPx0JBd4rIodim9QO+iWPLf9bYkf58pTD3oE2QZrSbJn3xsAfcSJTIdwifLLsB wr+BtEs2knEipHmvMXT2+zDNcAn5zeRWoxAUA5+We16V5VVuo/ok063HjEzB8fmq t4RfYrNrACqvAbg7+XxGBUS7+G9XGA== =OTKk -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 17 10:40:07 2020 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 698C63A0E78; Thu, 17 Dec 2020 10:40:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.878 X-Spam-Level: X-Spam-Status: No, score=-0.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0V5XUxTsfiEt; Thu, 17 Dec 2020 10:40:04 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09EFF3A0E77; Thu, 17 Dec 2020 10:40:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 45CCE389AC; Thu, 17 Dec 2020 13:42:48 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id NwBBggCDMJvp; Thu, 17 Dec 2020 13:42:47 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 405A4389A8; Thu, 17 Dec 2020 13:42:47 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 94F6111B4; Thu, 17 Dec 2020 13:40:01 -0500 (EST) From: Michael Richardson CC: mud@ietf.org, opsawg@ietf.org, iotops@ietf.org In-Reply-To: <27659.1608229409@localhost> References: <27659.1608229409@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Mud] On loading MUD URLs from QR codes - draft-richardson-opsawg-securehomegateway-mud-05 X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2020 18:40:06 -0000 --=-=-= Content-Type: text/plain Michael Richardson wrote: > 4) On loading MUD URLs from QR codes > draft-richardson-opsawg-securehomegateway-mud-05 > Abstract > This informational document details the mechanism used by the CIRA > Secure Home Gateway (SHG) to load MUD definitions for devices which > have no integrated MUD (RFC8520) support. This document is essentially complete. It does not create any on-the-wire protocol, at least no IP-wire. It described how to transmit MUD URLs over the optical-band ether[1], that is via QR code. The Return Logistics Alliance (rla.org) has a QR code format used today on many things, and a protocol for encoding and extending things. I have obtained a code point from them. While their document is open and available without marketing paywall, I have included just enough detail so that this document is probably stand-alone. Unless I hear otherwise, I intend to go to the ISE with this document. [1] - https://en.wikipedia.org/wiki/Aether_(classical_element) --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl/bpgEACgkQgItw+93Q 3WX73Af+L6upCd2pVjxJ6SRMCNZEOLO/NLsVPY9kugAqID1+GelpdRAXyWB/XjNt 6fryNakwFRhEaboQKdf5/i92ieR3i3bYpSVm3jE8bGcIKh2KHdReb/tMZWyhOAXc DjjmqjJuZ5d9fr/g1CV9+qP0/3Da0JzSBGTUELlv2mRuw/XwjBdfZBKGy9l1CbNa Y7NxJVkEjz37dgqjSsZnyfrhDCvdkgtwlXlc7wKxB+Vzpg3naDtQUhwI72kxZJv3 2PtLT42vOpQG2k2W1B5ilyORxkfdisyAmVKhwGhdilnzVLN6ADpF8hmlOzDv4Kcc tl+081S/ZI1KMvekpsiu43gkIZ83aw== =NkL8 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 17 11:23:40 2020 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7413A0E8C; Thu, 17 Dec 2020 11:23:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ans20yp5L7m; Thu, 17 Dec 2020 11:23:34 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 338403A0E60; Thu, 17 Dec 2020 11:23:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id CB1AE389AC; Thu, 17 Dec 2020 14:26:16 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id m9SbiclX722K; Thu, 17 Dec 2020 14:26:16 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 17199389A8; Thu, 17 Dec 2020 14:26:16 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5217E11B4; Thu, 17 Dec 2020 14:23:30 -0500 (EST) From: Michael Richardson to: mud@ietf.org, opsawg@ietf.org, iotops@ietf.org, suit@ietf.org In-Reply-To: <27659.1608229409@localhost> References: <27659.1608229409@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Mud] Manufacturer Usage Description for quarantined access to firmware - draft-richardson-shg-mud-quarantined-access-02 X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2020 19:23:36 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Michael Richardson wrote: > 5) Manufacturer Usage Description for quarantined access to firmware > draft-richardson-shg-mud-quarantined-access-02 [perhaps I should rename it with opsawg in the filename] > Abstract > The Manufacturer Usage Description is a tool to describe the limited > access that a single function device such as an Internet of Things > device might need. This is a small extension to RFC8520 which provides a new attribute to each ACL. It marks the ACL as being essential for firmware/software updates. In the parlance of draft-kuehlewind-update-tag-03 this document is an Exte= nds. The need for this extension became obvious during the PoC phase of the CIRA SecureHomeGateway back in 2018. We put a sample device into the deny list, kicking the device off the Internet, and and then wondered... so now what? How does it get updated? Is it landfill? There must be a better way. I believe that this work needs to be adopted by OPSAWG to be able to make p= rogress. I presented it at the spring IETF107 meeting in OPSAWG, but it is quite likely that are some Software Update people who haven't seen it. The slides are at: https://datatracker.ietf.org/meeting/interim-2020-opsawg-01/materials/s= lides-interim-2020-opsawg-01-sessa-device-quarantine-definition-for-manufac= turer-usage-descriptions-rfc8520-00 or: https://github.com/CIRALabs/shg-mud-quarantine/tree/master/presentations At present, the document isn't much more than a YANG modules with a lot of words in it! (Much like a third of the documents coming from the RTG area) The security considerations will need some work beyond "TBD": there are two= obvious concerns: 1) did a third party lie about what they essential connections are? This boils down to: how did the MUD controller establish trust in the MUD file in the first place. I have another document about that. 2) was did the manufacturer lazy and just marked everything as essential? Or, how can we be sure what's essential anyway? What kind of local policy might need to override this anyway, and does that render this all moot? In the two years since I started this document SUIT has made significant pr= ogress. One thing that the CIRA SHG team really wanted was to actually collect the firmware ourselves. That is, rather than allowing the device out to the network to get it's own firmware, we would have rather been able to discove= ry the URL of the new firmware using a standard protocol, cached it locally, a= nd then pointed the device at that copy. This would essentially have rendered the two concerns above irrelevant. SUIT has intentionally not standardized such a mechanism as being too much = of a bikeshed/rathole (I think), but I am interested if there is some interest in doing that. Perhaps in addition to this document, or maybe, instead of. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl/bsDIACgkQgItw+93Q 3WXIegf/TVZcx9NkRXRuGulQ4U4EvZcn+PgYO1erpM+XCsYsgW5E6zz//3iag70I RQ/gh2ZYdiZtHQ5p00nFdv0OQ4QjgRmadz7FdNbiI0GuOKeR05jaQ/G+k+N4phhX ODqtTO5oAs2vXCAUDRlHFItrwAOCERunclULTzsP6NXJY61VdZXexc92/Jl9y3Ev QTp1eMvp8P/yUgeoEnvyPwEhx2vwpQob6ef86n0HJ9bjU5gecqNmXDmFh4L3nKyl /0vM7+FUtXEzE/C/ofAhQr0jCqxR5wUo0buzj4HYCrU/0Mm5czEaWhk3cNyTzmam Nk9sqnhP88mKHNeAWI6fch11j1j5TA== =/qtm -----END PGP SIGNATURE----- --=-=-=--