[OPSAWG] changes to draft-richardson-opsawg-mud-iot-dns-considerations-03.txt

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 24 September 2020 15:20 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2C7023A0E06; Thu, 24 Sep 2020 08:20:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id jrgb69EOAwJO; Thu, 24 Sep 2020 08:20:26 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9282D3A0DE8; Thu, 24 Sep 2020 08:20:25 -0700 (PDT)
Received: from localhost (localhost []) by tuna.sandelman.ca (Postfix) with ESMTP id ED2D1389B4; Thu, 24 Sep 2020 10:58:59 -0400 (EDT)
Received: from tuna.sandelman.ca ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id rKTydgd3-trE; Thu, 24 Sep 2020 10:58:56 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id ECE6438994; Thu, 24 Sep 2020 10:58:55 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 857014DB; Thu, 24 Sep 2020 11:20:19 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: opsawg@ietf.org, mud@ietf.org
In-Reply-To: <160082461431.2339.6222888407127336620@ietfa.amsl.com>
References: <160082461431.2339.6222888407127336620@ietfa.amsl.com>
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<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Thu, 24 Sep 2020 11:20:19 -0400
Message-ID: <15779.1600960819@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/izjStDFEntJlJSEFDGC0GF4J0Zc>
Subject: [OPSAWG] changes to draft-richardson-opsawg-mud-iot-dns-considerations-03.txt
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Sep 2020 15:20:28 -0000

Another thread is
        active at: https://mailarchive.ietf.org/arch/msg/opsawg/04UY5rDs_ojh97_edY-a4xBPZT4

I meant to wait to post this email until there had been some discussion about
the acceptable-urls document.

From 2018 onwards I have been working with CIRALabs on an IoT security system
for home gateways.  This first two revisions of the effort were very much MUD
focused, and this document was written to capture my experiences with DNS
lookups vs MUD names in MUD files.

This document was presented at the IETF107 virtual interim meeting in April.
The slides are at: https://www.ietf.org/proceedings/interim-2020-opsawg-01/slides/slides-interim-2020-opsawg-01-sessa-operational-considerations-for-use-of-dns-in-iot-devices-wslide-numbers-00

As a big part of the advice is to use the local resolver, whether via Do53,
DoT or DoH, it was suggested that this advice might be better given by the
Adaptive DNS Discovery (ADD).

Perhaps that made more sense when it was the Applications Doing DNS BOF though.
A number of discussions about this document over the summer with the ADD
chairs revealed that the document does not belong in the ADD WG.

The -03 version contains mostly minor editorial changes.
I've decided that, even as a BCP, that it seems to still be using BCP14 language,
and so should include the boilerplate.

I would like the OPSAWG to consider adopting this MUD related document.
It changes no bits on the wire changes to MUD or semantic changes (like my
other document), rather this is guidance to IoT manufacturers.

Name:		draft-richardson-opsawg-mud-iot-dns-considerations
Revision:	03
Title:		Operational Considerations for use of DNS in IoT devices
Document date:	2020-09-22
Group:		Individual Submission
Pages:		13
URL:            https://www.ietf.org/id/draft-richardson-opsawg-mud-iot-dns-considerations-03.txt
Status:         https://datatracker.ietf.org/doc/draft-richardson-opsawg-mud-iot-dns-considerations/
Html:           https://www.ietf.org/id/draft-richardson-opsawg-mud-iot-dns-considerations-03.html
Htmlized:       https://tools.ietf.org/html/draft-richardson-opsawg-mud-iot-dns-considerations-03
Diff:           https://www.ietf.org/rfcdiff?url2=draft-richardson-opsawg-mud-iot-dns-considerations-03

   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

   {RFC-EDITOR, please remove.  Markdown and issue tracker for this
   document is at https://github.com/mcr/iot-mud-dns-considerations.git

Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide