Subject: [Mud] Controller and MyController secure registration

From: "M. Ranganathan" <[email-masked]>
Date: Fri, 7 Jun 2019 13:17:17 -0400

Controller and my-controller mechanisms are defined to allow the device to
talk to classes of devices which register themselves as controllers.

The MUD specification leaves out the mechanism on how Controller and
my-controller will be defined other than to say that this is an
administrator concern.

While several mechanisms are possible for secure registration (identity
based perhaps), should we pick one for interoperability purposes. eg. if a
manufacturer ships a controller for his devices, how will that controller
know how to register itself with the mud manager?

Ranga

-- 
M. Ranganathan

---

From: Eliot Lear <[email-masked]>
Date: Fri, 7 Jun 2019 19:27:54 +0200

Hi Ranga,

Right now for those abstractions it’s manual.  But I do think it’s good to look at standardizing how controllers can register with the MUD manager, for ease of selection.  We’ve looked at this a bit at Cisco.  That leads to a discovery discussion (how to find the MUD manager) or whether to create a new certificate attribute, or what.

This would be a good discussion for MUD side meeting.

Eliot

> On 7 Jun 2019, at 19:17, M. Ranganathan <[email-masked]> wrote:
> 
> Controller and my-controller mechanisms are defined to allow the device to talk to classes of devices which register themselves as controllers.
> 
> The MUD specification leaves out the mechanism on how Controller and my-controller will be defined other than to say that this is an administrator concern.
> 
> While several mechanisms are possible for secure registration (identity based perhaps), should we pick one for interoperability purposes. eg. if a manufacturer ships a controller for his devices, how will that controller know how to register itself with the mud manager?
> 
> Ranga
> 
> --
> M. Ranganathan
> 
> --
> Mud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mud

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Jun 2019 15:56:09 -0400

First, I didn't really pay a lot of attention to the controller portion of
the specification.

Eliot Lear <[email-masked]> wrote:
    > Right now for those abstractions it’s manual.  But I do think it’s good
    > to look at standardizing how controllers can register with the MUD
    > manager, for ease of selection.  We’ve looked at this a bit at Cisco.
    > That leads to a discovery discussion (how to find the MUD manager) or
    > whether to create a new certificate attribute, or what.

I think that when the controller communicates it's MUD URL to the
mud-manager, the MUD file should declare it to be a controller.
I would like to further consider specifying something in or around BRSKI
about this as well. (Could be an IDevID extension, could be an BRSKI-EST API
extension)

Clearly the device needs to be clear about what kind of controller it talks
to, and I don't know how this works right now.  There could also be a
multitude of controllers (a lighting controller for each floor for instance)
From the same vendor.   Do controllers get to talk to controllers?

    > This would be a good discussion for MUD side meeting.

I agree.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-