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

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 03 June 2019 18:27 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 211C1120120 for <mud@ietfa.amsl.com>; Mon, 3 Jun 2019 11:27:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 uA_9Qm12F9LC for <mud@ietfa.amsl.com>; Mon, 3 Jun 2019 11:27:03 -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 E62F4120161 for <mud@ietf.org>; Mon, 3 Jun 2019 11:27:02 -0700 (PDT)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id E58793808A; Mon, 3 Jun 2019 14:25:49 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 1925F16A5; Mon, 3 Jun 2019 14:27:01 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 16B30E69; Mon, 3 Jun 2019 14:27:01 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Eliot Lear <lear@cisco.com>
cc: mud@ietf.org
In-Reply-To: <C0D6CB77-DB28-4425-B5AD-8BEA70DC4813@cisco.com>
References: <17454.1557618668@localhost> <DF4FB039-6373-4980-9E26-C66D454D11A0@cisco.com> <5960.1558214710@localhost> <C0D6CB77-DB28-4425-B5AD-8BEA70DC4813@cisco.com>
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: Mon, 03 Jun 2019 14:27:01 -0400
Message-ID: <12945.1559586421@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mud/aD9y8J2nXViJtYtRJ8jUgsuZQdE>
Subject: Re: [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: Mon, 03 Jun 2019 18:27:05 -0000

Eliot Lear <lear@cisco.com> wrote:
    >> Eliot Lear <lear@cisco.com> wrote:
    >>>> 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.
    >>
    >>
    >>> If you ever had a valid MUD file you should keep using it.  This
    >>> follows the principle of least astonishment.  Otherwise, a temporary
    >>> outage might cause policy flaps.  An alternative might be to invoke an
    >>> exception flow that says, “yo! No more MUD file”.
    >>
    >> Yes, I'm asking: what if the MUD-manager never got a valid MUD file.
    >> It did exist at some point, but then marketing moved it when they redid the
    >> web site, or the company just went under.

    > I think this ties to the draft we discussed putting together in Prague.
    > That is- a search path of sorts.

Yes.  We agreed that it was more than a local decision because there is the
issue of how the signatures will work.  Both where the signature is to be
found, and how the MUD file can be amended with new signatures.

(I know very little about WebDAV's PATCH method.  I see that in rfc4918 there
is PROPPATCH, and it seems to apply to XML content.  I was thinking that
maybe we could borrow from that specifications to describe modifications, and
sign those)

    >>> A few things to think about with this use case.  We really don’t have
    >>> contact information in the MUD file.  While one might think that an
    >>> oversight, honestly I get a little nervous about sticking email
    >>> addresses in various places that can be harvested for SPAM.
    >>
    >> The contact info does not have to be an email address.
    >>
    >> It could point to quite a number of other things.
    >> There are some identities out there like 1id.com, Dun&Bradstreet numbers, RIR
    >> handles,  URLs, …
    >>

    > True- in YANG terms this would be a CHOICE.  Let’s not go crazy with the # of choices, tho.

Fair enough.  Isn't URI probably enough?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


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