Re: [OPSAWG] Last Call Review of draft-ietf-opsawg-mud-acceptable-urls-10

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 01 March 2024 00:46 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1BAC14F619; Thu, 29 Feb 2024 16:46:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUj-OJggmEaN; Thu, 29 Feb 2024 16:46:55 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84B04C14F60A; Thu, 29 Feb 2024 16:46:55 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 4A7353898E; Thu, 29 Feb 2024 19:46:54 -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 uM_4Xn_Jlf8a; Thu, 29 Feb 2024 19:46:53 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 119A93898D; Thu, 29 Feb 2024 19:46:53 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandelman.ca; s=mail; t=1709254013; bh=+vYTMinVQ84YSK4Ku+4ays9npils9P/E4cZeM+X+zA8=; h=From:To:Subject:In-Reply-To:References:Date:From; b=ZZzUz8tWhbUOFg4MTcTkT0+kM8gMnA4Kb9IfSHZpzQBYPefDapc3H4gL0MDx5QEpe XzM8ZzfPERrWX5taR4JC7gS5KdHDGdFzE0WoFCFX2adAMApVlax24bs+juDjCcqBW3 2AG9+8eYhgOltduBDGmN4xFFi+OOZ3pK1WrruPB8YZ5Y8LoK4ie8fIN6Ik3ywrzoTZ AzYj9GXaIcsW06mFYb+rgpdjvlsXAojaW+QdiEC8Ddyea3tHQhv8AKKeU1e6wI2zPD 32MgzNjn6/vx1Gqy49QDY7er2QwiAfGsD7gguvgOy3zSl1GAlhpfAL4meS0pV/YFdc zInN8QOP3SUzw==
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0A13F873; Thu, 29 Feb 2024 19:46:53 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Christian Huitema <huitema@huitema.net>, Eliot Lear <lear@lear.ch>, "sec-ads@ietf.org" <sec-ads@ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>, draft-ietf-opsawg-mud-acceptable-urls@ietf.org
In-Reply-To: <cc555621-e17e-44b1-97e2-6802d263fa8c@huitema.net>
References: <8a2c556a-905b-46f9-926c-03f09ed98f32@lear.ch> <66588cac-0f33-4924-920f-6b4dbd5c2964@huitema.net> <51cc9f21-748b-4527-9809-f51c11cd9144@lear.ch> <cc555621-e17e-44b1-97e2-6802d263fa8c@huitema.net>
X-Mailer: MH-E 8.6+git; nmh 1.8+dev; GNU Emacs 28.2
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, 29 Feb 2024 19:46:53 -0500
Message-ID: <8673.1709254013@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/UsArljnZocTFkwXZhAiXCCCxQ9A>
Subject: Re: [OPSAWG] Last Call Review of draft-ietf-opsawg-mud-acceptable-urls-10
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 01 Mar 2024 00:46:59 -0000

Christian Huitema <huitema@huitema.net> wrote:
    > I am not entirely convinced. This looks like keeping logs, keeping them
    > online, and accessing them in real-time. That can be challenging in
    > many environments. I would prefer that the draft be updated to present

Why would this be a challenge?
The MUD manager is unlikely to be a non-constrained device.
(even if it's in a home router, which I've done running code for, a few
megabytes of URL history shouldn't be a problem)

In an enterprise environment, where the could be tens of thousands of IoT
devices, the MUD manager is probably going to be in the NOC, integrated with
some SDN controller that is in charge of deploying all the resulting firewall
rules.

    > the "play old URL back" issue, and then that this log-based rule be
    > proposed as one of the possible solutions. If I was implementing this,
    > I would probably prefer some kind of real-time mitigation.

What do you have in mind?
The MUD-URL is open to pretty much any scheme:// you can imagine.
Are you thinking about something on that side of things?
While we can invent new mechanisms on the southbound ("DHCP", "LLDP") side of
things to transmit the URL, they would require new infrastructure.

Other people (NQuiring Minds, via the NIST NCCoE IoT onboarding effort)
having been looking at continual assurance systems that would assess the
health of devices.  Such a system would be collecting a set of signed
Evidence (RFC9334 sense) from the devices on a regular basis, and a
manufacturer signed MUD-URL could be provided then.

Also, draft-ietf-suit-mud also provides a stronger connection, however, since
it's in the SUIT Manifest (downward flowing, towards IoT device), rather than
in the SUIT Report (upward flowing, from IoT device to SUIT status tracker),
it has somewhat less connection to what's actually running on the device.
It does, however, provide a palette of URLs that are valid.

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