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

From: Eliot Lear <[email-masked]>
Date: Mon, 1 Jul 2019 10:48:55 +0200

> On 1 Jul 2019, at 10:23, Qin Wu <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 发件人: Eliot Lear [mailto:[email-masked] <mailto:[email-masked]>]
> 发送时间: 2019年7月1日 15:52
> 收件人: Qin Wu <[email-masked] <mailto:[email-masked]>>
> 抄送: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> 主题: Re: [OPSAWG] Declaring something to be a controller in MUD
> 
> 
> 
> 
> On 1 Jul 2019, at 09:20, Qin Wu <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 发件人: OPSAWG [mailto:[email-masked] <mailto:[email-masked]>] 代表 Eliot Lear
> 发送时间: 2019年6月24日 17:48
> 收件人: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> 主题: [OPSAWG] Declaring something to be a controller in MUD
> 
> 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 <https://example.com/mud> or a class http://example.com/mudclass1 <http://example.com/mudclass1>.  That can be laborious.  To assist, we are examining ways to have a controller declare itself as a candidate controller.
> 
> [Qin]: Since MUD in RFC8520 has already specify DNS extension and DHCP extension, why not configure MUD manager with controller’s declaration? So the RESTFUL interface can be defined between NMS and controller, if my understanding is correct.
> I believe this is network initiated solution, you might have client initiated solution, but probably more complicated than network initiated solution.
> 
> Can you say a few more words?  I’m not sure I’m quite following you.
> [Qin]: What I am suggesting is NMS preconfigures the MUD manager with controller’s declaration information, during DHCP process or DNS process, the controller’s declaration can be returned
> To the router or switch between the thing and MUD manager or return to the thing, the router or the thing can access controller through controller delclartion.
> 
> If the MUD manager also needs to be advertised to the thing, DHCP Discovery or DNS process can be leveraged. In this case, NMS needs to preconfigure DHCP server with MUD manager information.

I apologize, but I’m not quite following.  Let’s step through what I’m trying to solve, and then let’s step through your flow.

Device sends a MUD URL X that points to a MUD file that says to permit ip access to my-controller.

Now- how do we determine who “my-controller” for MUD URL X is?

Ways to do that:
Ask the administrator (pre-configuration)
Provide the administrator hints
Controller says who it can control (by MUD URLs, etc) or
Device says which controllers (by MUD URL) are good candidates
Other

If it’s the controller, then we can do a RESTful interface.  If it’s the device, we already have a communication path.  Nothing stops us from doing both.

So now insert your approach.  What steps would you take?

Eliot

> 
> Eliot
> 
> 
>  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.
> 
> 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.
> 
> Thoughts?
> 
> Eliot
>

---

From: Qin Wu <[email-masked]>
Date: Mon, 1 Jul 2019 08:23:03 +0000

发件人: Eliot Lear [mailto:[email-masked]]
发送时间: 2019年7月1日 15:52
收件人: Qin Wu <[email-masked]>
抄送: [email-masked]; [email-masked]
主题: Re: [OPSAWG] Declaring something to be a controller in MUD

On 1 Jul 2019, at 09:20, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:

发件人: OPSAWG [mailto:[email-masked]] 代表 Eliot Lear
发送时间: 2019年6月24日 17:48
收件人: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题: [OPSAWG] Declaring something to be a controller in MUD

Hi everyone,

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.

Eliot

  *   Form the declaration;
  *   Find the MUD manager; and
  *   Send it.

  *   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?

  *   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.

Thoughts?

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Mon, 1 Jul 2019 12:25:56 +0200

Qin and others:

Just to get the ball rolling, I’ve posted today draft-lear-opsawg-mud-controller-candidates-00.

I think this should help the discussion.

Eliot

> On 1 Jul 2019, at 10:23, Qin Wu <[email-masked]> wrote:
>

---

From: "M. Ranganathan" <[email-masked]>
Date: Mon, 1 Jul 2019 14:51:06 -0400

On Mon, Jul 1, 2019 at 6:26 AM Eliot Lear <[email-masked]> wrote:

> Qin and others:
>
> Just to get the ball rolling, I’ve posted today
> draft-lear-opsawg-mud-controller-candidates-00.
>

Hello Eliot,

In a similar vein to the question Qin is asking, I have a question (we
could discuss during the upcoming IETF side meeting if you don't have time
to respond now).

What is the essential difference between a device declaring itself to be a
"controller" for another class and the situation where the device (being
controlled) just uses the "model" abstraction in an ACE?

If a device with mud URL  https://toothbrush.nist.local/super1 is a
controller for device coffemaker.nist.local, then simply declare an ACE in
the coffeemaker MUD file, with a Model abstraction naming
toothbursh.nist.local :

       {
              "name": "man0-todev",
              "matches": {
                "ietf-mud:mud": {
              "model": "https://toothbrush.nist.local/super1"
                },
                "ipv4": {
                  "protocol": 17
                },
                "udp": {
                  "source-port": {
                    "operator": "eq",
                    "port": 8008
                  }
                }
              }

(similarly in the "frdev")

What is the difference (in behavior) between this and the new mechanism
proposed in the draft?

Thanks, Ranga

> *发件人:* Eliot Lear [mailto:[email-masked] <[email-masked]>]
> *发送时间:* 2019年7月1日 15:52
> *收件人:* Qin Wu <[email-masked]>
> *抄送:* [email-masked]; [email-masked]
> *主题:* Re: [OPSAWG] Declaring something to be a controller in MUD
>
>
>
>
> On 1 Jul 2019, at 09:20, Qin Wu <[email-masked]> wrote:
>
> *发件人:* OPSAWG [mailto:[email-masked] <[email-masked]>]
> *代表 *Eliot Lear
> *发送时间:* 2019年6月24日 17:48
> *收件人:* [email-masked]; [email-masked]
> *主题:* [OPSAWG] Declaring something to be a controller in MUD
>
> 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.
>
> [Qin]: Since MUD in RFC8520 has already specify DNS extension and DHCP
> extension, why not configure MUD manager with controller’s declaration? So
> the RESTFUL interface can be defined between NMS and controller, if my
> understanding is correct.
> I believe this is network initiated solution, you might have client
> initiated solution, but probably more complicated than network initiated
> solution.
>
>
> [Qin]: What I am suggesting is NMS preconfigures the MUD manager with
> controller’s declaration information, during DHCP process or DNS process,
> the controller’s declaration can be returned
> To the router or switch between the thing and MUD manager or return to the
> thing, the router or the thing can access controller through controller
> delclartion.
>
> If the MUD manager also needs to be advertised to the thing, DHCP
> Discovery or DNS process can be leveraged. In this case, NMS needs to
> preconfigure DHCP server with MUD manager information.
>
> Eliot
>
>
>  That at least provides a hint to the administrator that this particular
> device is capable of serving in a particular role.
>
>    - Form the declaration;
>    - Find the MUD manager; and
>    - Send it.
>
>
>    - 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.
>
> 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.
>
> Thoughts?
>
> Eliot
>
>
>
>
> --
> Mud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mud
>

-- 
M. Ranganathan

---

From: Eliot Lear <[email-masked]>
Date: Tue, 2 Jul 2019 08:07:22 +0200

Hi Ranga,

> On 1 Jul 2019, at 20:51, M. Ranganathan <[email-masked]> wrote:
> 
> What is the essential difference between a device declaring itself to be a "controller" for another class and the situation where the device (being controlled) just uses the "model" abstraction in an ACE?

You could indeed do this with “model”,

---

From: Eliot Lear <[email-masked]>
Date: Tue, 2 Jul 2019 08:10:53 +0200

Hi Ranga,

Sorry for the pre-mature send.

> What is the essential difference between a device declaring itself to be a "controller" for another class and the situation where the device (being controlled) just uses the "model" abstraction in…

You could indeed do this with “model”.  The reason I hadn’t thought of that was because in my mind, same-manufacturer and model were for NxN communications, and that it might be a hint to the NMS to use appropriate scale mechanisms.  But that’s not actually in the text.

I think, by the way, that there’s another reason to think about doing this from the controller side: if the standards are open like we like them to be, a device may not know who should be the controller for a particular device or class.

Eliot

---

From: "M. Ranganathan" <[email-masked]>
Date: Tue, 2 Jul 2019 13:21:56 -0400

Hello Eliot,

On Tue, Jul 2, 2019 at 2:10 AM Eliot Lear <[email-masked]> wrote:

> You could indeed do this with “model”.  The reason I hadn’t thought of
> that was because in my mind, same-manufacturer and model were for NxN
> communications, and that it might be a hint to the NMS to use appropriate
> scale mechanisms.  But that’s not actually in the text.
>
> I think, by the way, that there’s another reason to think about doing this
> from the controller side: if the standards are open like we like them to
> be, a device may not know who should be the controller for a particular
> device or class.
>
>
Yes I agree with your reasoning - especially the second part. I think some
wording providing justification for this in the draft would be good  (maybe
even as an addendum to the MUD specification).

Looking forward to further discussion on how applications can become
controllers.

Regards, Ranga

-- 
M. Ranganathan