[Mud] what if MUD file is now longer available?

Michael Richardson <mcr+ietf@sandelman.ca> Sun, 12 May 2019 00:49 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 2FB27120160 for <mud@ietfa.amsl.com>; Sat, 11 May 2019 17:49:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 DTtYtJR4HAiE for <mud@ietfa.amsl.com>; Sat, 11 May 2019 17:49:47 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F234412014B for <mud@ietf.org>; Sat, 11 May 2019 17:49:42 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 2564038286; Sat, 11 May 2019 20:42:33 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 9CD2D10EE; Sat, 11 May 2019 19:51:08 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1DE911057; Sat, 11 May 2019 19:51:08 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: mud@ietf.org, mud-discuss@googlegroups.com
reply-to: mud@ietf.org
X-Attribution: mcr
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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-sha256"; protocol="application/pgp-signature"
Date: Sat, 11 May 2019 19:51:08 -0400
Message-ID: <17454.1557618668@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mud/v_ePsyp7BuG1C20UnL0XboV6VOg>
X-Mailman-Approved-At: Sat, 11 May 2019 18:17:44 -0700
Subject: [Mud] what if MUD file is now longer available?
X-BeenThere: mud@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of Manufacturer Ussage Descriptions <mud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mud>, <mailto:mud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mud/>
List-Post: <mailto:mud@ietf.org>
List-Help: <mailto:mud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mud>, <mailto:mud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 May 2019 00:49:54 -0000

{did the list transition go as intended?}

What should a MUD-manager do if a MUD file can no longer be found at the
provided URL?   Perhaps this is equivalent to the signature not verifying.

I'm thinking specifically of a case where a device is initially created by a
contractor, they dutifully create a MUD file, provide it to the customer to
host, and then.. the customer forgets... marketing reorganizes the web site,
etc.  and so the MUD file goes missing.

Section 13.2 says that the MUD-manager should cease processing at that point.
I guess at that point, the access should therefore be default-deny.
I guess the other question is what would the access be if there were no
MUD URL at all.  We'd all like to be default-deny, but I think that during
a transition period it can't be that.


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-