Subject: [OPSAWG] Understanding MUD : Controller and my-controller

From: "M. Ranganathan" <[email-masked]>
Date: Wed, 11 Oct 2017 22:16:14 -0400

Hello,

I am reading through previous discussion on these topics and am still not
quite "getting it". So I request some explanation from the authors. My
understanding is as follows:

controllers : this is a place holder for things like DNS and DHCP where the
address of the server is not known a-priori.

my-controller - has me quite confused.  Here's the text from the latest
draft:

   "my-controller:  Devices associated with the MUD URL of a device that
      the administrator admits."

So my understanding on this is it allows the manufacturer to supply
access control rules which reference devices with the SAME MUD URL.

So you can, for example say how peer devices from this manufacturer
can interact. (?)

On the other hand, it is called "my-controller" so I am wondering
whether this interpretation

is the intended one.

Very confused. Would appreciate some clarification.

Regards,

Ranga.,
-- 
M. Ranganathan

---

From: Eliot Lear <[email-masked]>
Date: Thu, 12 Oct 2017 09:51:41 +0200

Hi Ranga,

On 10/12/17 4:16 AM, M. Ranganathan wrote:
> Hello,
>
> I am reading through previous discussion on these topics and am still
> not quite "getting it". So I request some explanation from the
> authors. My understanding is as follows:
>
> controllers : this is a place holder for things like DNS and DHCP
> where the address of the server is not known a-priori.
>
> my-controller - has me quite confused.  Here's the text from the
> latest draft:
>
> So you can, for example say how peer devices from this manufacturer can interact. (?)

The way I like to look at it is this:

Peer devices = "manufacturer" or "same-manufacturer", and it is the
manufacturer of the device that specifies class admittance by default. 
More intended as many-to-many.  "controller" and "my-controller" are
more focused on a one-to-many relationship where class admittance is
handled by the administrator.

Does that help?

Eliot

---

From: "M. Ranganathan" <[email-masked]>
Date: Thu, 12 Oct 2017 12:17:03 -0400

Hi Eliot,

On Thu, Oct 12, 2017 at 3:51 AM, Eliot Lear <[email-masked]> wrote:

> controllers : this is a place holder for things like DNS and DHCP where
> the address of the server is not known a-priori.
>
> More intended as many-to-many.  "controller" and "my-controller" are more
> focused on a one-to-many relationship where class admittance is handled by
> the administrator.
>
> Does that help?
>
> Eliot
>

Thanks. That sorted some confusion out but I am still wondering why, for
example, BOTH "controller" and "my-controller" need to exist in the
specification.

Regards,

Ranga

-- 
M. Ranganathan

---

From: Eliot Lear <[email-masked]>
Date: Thu, 12 Oct 2017 18:55:41 +0200

On 10/12/17 6:17 PM, M. Ranganathan wrote:
>
> Thanks. That sorted some confusion out but I am still wondering why,
> for example, BOTH "controller" and "my-controller" need to exist in
> the specification.

"my-controller" has an inferred name, if you will, of the current MUD
URL, and no other name is required.  And so administrators populate the
field for each device that hits the network.  "controller" takes a
name.  And so the idea is that if you a manufacturer have many devices
that might all use the same controller, you can specify that name, and
the administrator only needs to populate the class once.  Some
governance required, of course.

Eliot

---

From: "M. Ranganathan" <[email-masked]>
Date: Thu, 12 Oct 2017 18:48:21 -0400

Hi Eliot,

On Thu, Oct 12, 2017 at 12:55 PM, Eliot Lear <[email-masked]> wrote:

> "my-controller" has an inferred name, if you will, of the current MUD URL,
> and no other name is required.  And so administrators populate the field
> for each device that hits the network.  "controller" takes a name.  And so
> the idea is that if you a manufacturer have many devices that might all use
> the same controller, you can specify that name, and the administrator only
> needs to populate the class once.  Some governance required, of course.
>
> Eliot
>

So this is a way of supporting late binding and indirection. To verify my
understanding, here is a small example (generated by entering parameters
into mudmaker). Lets say I have a MUD file with

 "controller": "https://foo.bar.com/.well-known/mud/v1/thermometerv1"

Lets say we have a MUD file with a mud URL of

 "mud-url": "https://foo.bar.com/.well-known/mud/v1/thermometerv1"

Also, we have the following ACLs specified:

 {
              "rule-name": "ent0-todev",
              "matches": {
                "ietf-mud:mud-acl": {
                  "controller":
"https://foo.bar.com/.well-known/mud/v1/thermometerv1"
                },
                "ipv4-acl": {
                  "protocol": 6,
                  "source-port-range": {
                    "lower-port": 9000,
                    "upper-port": 9000
                  }
                },
                "tcp-acl": {
                  "ietf-mud:direction-initiated": "from-device"
                }
              },
              "actions": {
                "forwarding": "accept"
              }
            },
            {
              "rule-name": "myctl0-todev",
              "matches": {
                "ietf-mud:mud-acl": {
                  "my-controller": [
                    null
                  ]
                },
                "ipv4-acl": {
                  "protocol": 6,
                  "source-port-range": {
                    "lower-port": 800,
                    "upper-port": 800
                  }
                },
                "tcp-acl": {
                  "ietf-mud:direction-initiated": "from-device"
                }
              },
              "actions": {
                "forwarding": "accept"
              }
            }
          ]
        }

Now lets say the controller

"https://foo.bar.com/.well-known/mud/v1/thermometerv1"

Maps to a set of hosts [host1.nist.gov , host2.nist.gov]. The way in
which this mapping gets established is out of scope.

The first ACL says the IOT device can receive packets from port
host1.nist.gov:9000 and host2.nist.gov:9000.

The second rule says the IOT device can receive packets from
host1.nist.gov:800 and host1.nist.gov:800

Is that the right way to interpret this?

Thanks for your patience in explaining this to me. Perhaps you could
consider adding an example to flesh this out (?) (just a suggestion).

Regards,

Ranga

-- 
M. Ranganathan

---

From: "M. Ranganathan" <[email-masked]>
Date: Thu, 12 Oct 2017 22:10:04 -0400

Hi Eliot,

On Thu, Oct 12, 2017 at 6:48 PM, M. Ranganathan <[email-masked]> wrote:

>> field for each device that hits the network.  "controller" takes a name.
>> And so the idea is that if you a manufacturer have many devices that might
>> all use the same controller, you can specify that name, and the
>> administrator only needs to populate the class once.  Some governance
>> required, of course.
>>
>> Eliot
>>
>
>

I think I understand the purpose of the "controller" field based on your
mail here:

https://www.ietf.org/mail-archive/web/opsawg/current/msg04748.html

Here is my interpretation:

Is the following an accurate set of statements ?

A "controller" a host or set of hosts that referenced by a URN. It is a
means of referring to hosts in the MUD file that are not known a-prior by
the device manufacturer. Well known URNs are defined for well known
services such as DNS, NTP and DHCP but arbitrary URLs are allowed to refer
to classes of hosts which can be bound actual hostnames during device
deployment.  A controller referenced by a MUD url, could, for example be
used as a registration server for devices that all share the same behavior.
The utility of such a controller would be that network administrators could
track registrations of all devices that share the same MUD URL. The empty
node "my-controller" refers to the (device registration) controller
referenced by the MUD URL of the MUD file.

Please verify if I have understood things correctly.

What makes this a bit confusing is that the term "controller" is overloaded
IMHO because we also talk about MUD controllers -- which is a different
thing entirely ( or at least so I think ).

Thank you very much for your help in understanding this.

Regards,

Ranga.

-- 
M. Ranganathan