Re: [OPSAWG] Declaring something to be a controller in MUD

["M. Ranganathan" <[e-mail]>]

Hi Eliot,


On Mon, Jun 24, 2019 at 5:48 AM Eliot Lear <[e-mail]> wrote:

> Hi everyone,
>
> A few of us are just trying to put out an initial draft that addresses one
> gap in MUD (there are several).  In a MUD file one can say that one wants
> to access a controller in two ways: either "my-controller” meaning a
> controller that services devices of a particular MUD URL or a “controller”
> class that services devices based on a particular class name of controller.
>
> In either case, right now the administrator has to manually know and
> populate information, to say - some device 1.2.3.4 is a controller, either
> for MUD URL https://example.com/mud or a class
> http://example.com/mudclass1.  That can be laborious.  To assist, we are
> examining ways to have a controller declare itself as a candidate
> controller.  That at least provides a hint to the administrator that this
> particular device is capable of serving in a particular role.
>
> To make that declaration, the device must-
>
>    - Form the declaration;
>    - Find the MUD manager; and
>    - Send it.
>
>
> Forming the declaration is easy: we can make this a YANG grouping and then
> place it in various spots.
>
> Finding the MUD manager depends on one question:
>
>    - Was the device built to be a controller or is it a general purpose
>    device that has an app that is intended to be a controller?
>
>
> If the device was built to be a controller, we can simply cram the
> declaration into that devices own MUD file as an extension.  If the device
> is a general purpose computer, things get a bit more interesting.  In this
> case we have two choices:
>
>
>    - Either create a MUD file that points somewhere internally - this
>    doesn’t seem very plug and play.
>    - Make the declaration directly to the MUD manager.
>
>
> I’m going to focus on the latter for the moment.  It is easy enough to
> create a RESTful interface for this purpose, but it requires a mechanism to
> discovered the MUD manager, which up until now has been an internal part of
> the network infrastructure.
>
> Let me call this out plainly: letting the app itself directly call the MUD
> manager requires that the MUD manager itself become exposed to the user
> infrastructure, which is a change.
>

Regardless of whether the app directly calls the MUD manager or the Join
registrar calls the MUD manager, an interface to it would need to be
defined so that the MUD manager can be notified.

A RESTful interface should work fine. Of course the RESTful API should be
secured and based on certificates/HTTPs but that problem has been solved so
does not need to be re-defined here. Of greater concern is that it is
exposed outside the NW infrastructure. However, it does not HAVE to be
exposed -- the same interface can work in either case (i.e. the Join
registrar can use it or the controller  application can use it, with the
recommendation that it SHOULD not be exposed).

As you rightly point out, discovery protocols are dime a dozen so pick a
simple one. Can DNS (SRV record) be defined/used to locate the MUD
manager?  Perhaps it can be sent back in the DHCP response in case the
service needs to be exposed to the application (just thinking out loud).



> One possibility to address this is to incorporate the new RESTful endpoint
> into an ANIMA BRSKI join registrar, which may already be exposed.  But that
> requires that ANIMA BRSKI be in play, which it may not.
>
> My thinking is that we do this work in two stages.  First handle the easy
> case, which is the MUD file extension, and then figure out how to do the
> app version of this.
>

Sounds good.

Regards, Ranga

>
> Thoughts?
>
> Eliot
>
>

-- 
M. Ranganathan