[Mud] different modes for MUD files
Michael Richardson <mcr+ietf@sandelman.ca> Wed, 10 July 2019 01:01 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 B2D031200C4 for <mud@ietfa.amsl.com>; Tue, 9 Jul 2019 18:01:09 -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 l1fU37KUt2Hk for <mud@ietfa.amsl.com>; Tue, 9 Jul 2019 18:01:07 -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 8BCDE1200F6 for <mud@ietf.org>; Tue, 9 Jul 2019 18:01:07 -0700 (PDT)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id DFB173808A; Tue, 9 Jul 2019 20:59:02 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 989D95BE; Tue, 9 Jul 2019 21:01:05 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "M. Ranganathan" <mranga@gmail.com>, "mud@ietf.org" <mud@ietf.org>
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: Tue, 09 Jul 2019 21:01:05 -0400
Message-ID: <20928.1562720465@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mud/48DrgrBv0krx0MxqPpz-57fKEYE>
Subject: [Mud] different modes for MUD files
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: Wed, 10 Jul 2019 01:01:10 -0000
{starting a new thread with a new subject line}
M. Ranganathan <mranga@gmail.com> wrote:
> The current draft https://datatracker.ietf.org/doc/draft-ietf-capport-api/
> Assumes that the "quarantined device" can access a subset of the ACE's
> allowed to the "unquarantined" device.
> However, I can think of a scenario where this does not have to be the case.
> I'd propose to generalize this.
> i.e. There are two sets of ACL's - one for normal operation and one for
> quarantined access. (i.e. quarantine access is not necessarily a subset of
> regular access).
I can agree with the idea.
> Use case:
> Under normal circumstances, the device does not need SSH access (port 22 is
> not open). However, if the device is misbehaving some external agent (or
> human maybe) logs in and investigates the issue. The fix could involve
> copying new firmware.
> Does this make sense?
Yes, but I'd like to term this the "debug" or "diagnostic" access.
I suggest that this is easily done by switching MUD files in/out.
Rather than try to create profiles within A mud file, I suggest multiple mud
files.
What we should do is to create references to alternate profiles that could be used.
> Another thing that is missing currently is how to "clear" the quarantine
> state at the enforcement point. This would need an API defintion of we want
> to make that portable.
Yes, that does require an API. The SHG project has developed one, but the
document is stale. It can't be the device that invokes the API, it must be
be the operator.
--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
- [Mud] different modes for MUD files Michael Richardson