Subject: [Mud] different modes for MUD files

From: Michael Richardson <[email-masked]>
Date: Tue, 09 Jul 2019 21:01:05 -0400

{starting a new thread with a new subject line}

M. Ranganathan <[email-masked]> 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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-