Subject: [OPSAWG] MUD : Default ACLs for DHCP . Time and DNS.

From: "M. Ranganathan" <[email-masked]>
Date: Tue, 3 Oct 2017 12:40:41 -0400

MUD suggests that devices should always have access to DHCP and DNS.
However, I don't know how to communicate this information to the MUD
controller so that appropriate ACLs can be installed when a device comes
up. A logical place to put this would be in the request sent out by the
DHCP server to the MUD controller when it gets the OPTIONS 161 from the
device. Would this be the way this is envisioned to work?

Would it be worthwhile documenting this interaction (in followup work).

Thanks.

-- 
M. Ranganathan

---

From: Steven Rich <[email-masked]>
Date: Tue, 3 Oct 2017 12:52:10 -0400

> On Oct 3, 2017, at 12:40 , M. Ranganathan <[email-masked]> wrote:
> 
> MUD suggests that devices should always have access to DHCP and DNS. However, I don't know how to communicate this information to the MUD controller so that appropriate ACLs can be installed when a device comes up. A logical place to put this would be in the request sent out by the DHCP server to the MUD controller when it gets the OPTIONS 161 from the device. Would this be the way this is envisioned to work?
> 

I and Thorsten are trying to capture some of these notions in

  https://tools.ietf.org/html/draft-srich-opsawg-mud-net-lifecycle-01 <https://tools.ietf.org/html/draft-srich-opsawg-mud-net-lifecycle-01>

although your particular case isn’t covered explicitly (I’ll add that).  Do you mind reading section 3.3 “Network Device Configuration” there and seeing if the wording is helpful?  The draft is not complete, and as always, feedback is appreciated.

Thanks,
sjr

> 
> Thanks.
> 
> --
> M. Ranganathan
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: Eliot Lear <[email-masked]>
Date: Tue, 3 Oct 2017 20:31:19 +0200

Hi Ranga,

On 10/3/17 6:40 PM, M. Ranganathan wrote:
> controller so that appropriate ACLs can be installed when a device
> comes up. A logical place to put this would be in the request sent out
> by the DHCP server to the MUD controller when it gets the OPTIONS 161
> from the device. Would this be the way this is envisioned to work? 

This is covered in the document in Section 4, with NTP and DNS being
given access by default, and it is covered as well in Appendix B.  The
intent is that your MUD controller should be aware of the DNS and NTP
servers, perhaps through configuration.  Thus when constructing an
access-list, appropriate permits should be generated without reference
within the MUD file.  Does this need more clarity?

Eliot

---

From: "M. Ranganathan" <[email-masked]>
Date: Tue, 3 Oct 2017 15:42:58 -0400

Eliot,

The MUD draft says:

    Local DNS and NTP are, by default, permitted to and from the Thing.

Looking at the example in Appendix B I see :

       "controller": "urn:ietf:params:mud:dns"

Which implies this string has to map to the ip address where DNS is hosted.
I am wondering where/how that mapping takes place. For example, if a DHCP
server were to communicate with the MUD controller, it could make this
information available to the MUD controller but how?

Perhaps an example of how to do this would help implementers.

Also in appendix B is the syntax of the ACL for the example correct ?

Thanks,

Ranga.

-- 
M. Ranganathan

---

From: "M. Ranganathan" <[email-masked]>
Date: Wed, 4 Oct 2017 11:58:21 -0400

Hello,

Architecturally, there are four functional blocks:

MUD file server : Serves MUD files. This is an optional component. MUD
files could be directly bundled with the device itself if is-supported flag
is False

MUD Controller: Transmits the mud file and auxiliary information (such as
the local address of the default network services) to the MUD policy
server. Manages the cache (retrieves policy files from the MUD file server
periodically and supplies them to the MUD policy server). For example, this
functionality may be implemented in an enhanced DHCP server or as a cloud
resident caching service.

MUD policy server: Resolves MUD ACLs and installs them on switch (e.g. as a
set of Flow rules). The MUD policy server could be a NETCONF or SDN
controller managing multiple switches.

ACL / SDN capable switch.

If my terminology is wrong, please correct.

Looking through section 3 (comments in line)

    The MUD Policy Server may support caching retrieved MUD files.  If
   it does, then the operator may choose to enable, tune, test, and
   monitor this functionality as well.  Details about caching MUD
   files as well as each task above will be covered later in this
   document.

Does the MUD policy server need to do this? If "is-supported" is True
then the MUD Controller may do cache management as well (?).

   The goal of MUD is to enable the near-automatic management of
   device segmentation for the class of devices which have MUD
   support.

That is, we want to automatically map devices with different
sensitivities to different network segments. That is not necessarily
the only goal. One could

limit the behavior of specific devices without introducing the notion
of network segments.

   1. Able to "see" a MUD URI

   2. Able to retrieve a MUD file

3. Able to map a specific device (for example via a MAC id) to a MUD
file that has been retrieved from the cloud.

Does section 3.4 (Testing) belong in section 3?

Cache management could be important because a manufacturer could
update the MUD file. So at least when a device boots, if is-supported
is True then

a new copy of the file should be retrieved.

Good work on the draft!

Regards,

Ranga.  (Affiliation: NIST / Advanced Networking Technologies Division)

On Tue, Oct 3, 2017 at 12:52 PM, Steven Rich <[email-masked]> wrote:

>   https://tools.ietf.org/html/draft-srich-opsawg-mud-net-lifecycle-01
>
> although your particular case isn’t covered explicitly (I’ll add that).
> Do you mind reading section 3.3 “Network Device Configuration” there and
> seeing if the wording is helpful?  The draft is not complete, and as
> always, feedback is appreciated.
>
> Thanks,
> sjr
>
>
> Thanks.
>
> --
> M. Ranganathan

-- 
M. Ranganathan

---

From: Eliot Lear <[email-masked]>
Date: Sat, 7 Oct 2017 17:31:23 +0200

Hi Ranga,

I apologize- I thought I had answered this note.  I'm going to top post
because the theme of your note is pretty consistent: it essentially
asks, what happens if we want to decompose the MUD controller into two? 
I don't see anything particularly wrong with the idea, but that's not
where we are today.  There may be many ways one wishes to decompose a
MUD controller, that being one of them.  I think that's fine follow-on
work as well.  We're leaving plenty of meat on the bone.

Eliot

On 10/4/17 5:58 PM, M. Ranganathan wrote:
> files could be directly bundled with the device itself if is-supported
> flag is False
>
> MUD Controller: Transmits the mud file and auxiliary information (such
> as the local address of the default network services) to the MUD
> policy server. Manages the cache (retrieves policy files from the MUD
> file server periodically and supplies them to the MUD policy server).
> For example, this functionality may be implemented in an enhanced DHCP
> server or as a cloud resident caching service.
>
> MUD policy server: Resolves MUD ACLs and installs them on switch (e.g.
> as a set of Flow rules). The MUD policy server could be a NETCONF or
> SDN controller managing multiple switches.
>
> Does the MUD policy server need to do this? If "is-supported" is True then the MUD Controller may do cache management as well (?). 
> That is, we want to automatically map devices with different sensitivities to different network segments. That is not necessarily the only goal. One could 
> limit the behavior of specific devices without introducing the notion of network segments.
> 3. Able to map a specific device (for example via a MAC id) to a MUD file that has been retrieved from the cloud.
>
> Cache management could be important because a manufacturer could update the MUD file. So at least when a device boots, if is-supported is True then 
> On Tue, Oct 3, 2017 at 12:52 PM, Steven Rich <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>>     On Oct 3, 2017, at 12:40 , M. Ranganathan <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>     MUD suggests that devices should always have access to DHCP and
>>     DNS. However, I don't know how to communicate this information to
>>     the MUD controller so that appropriate ACLs can be installed when
>>     a device comes up. A logical place to put this would be in the
>>     request sent out by the DHCP server to the MUD controller when it
>>     gets the OPTIONS 161 from the device. Would this be the way this
>>     is envisioned to work? 
>>
>     <https://tools.ietf.org/html/draft-srich-opsawg-mud-net-lifecycle-01>
>
>     although your particular case isn’t covered explicitly (I’ll add
>     that).  Do you mind reading section 3.3 “Network Device
>     Configuration” there and seeing if the wording is helpful?  The
>     draft is not complete, and as always, feedback is appreciated.
>
>     Thanks,
>     sjr
>
>>
>>     Thanks.
>>
>>     -- 
>>     M. Ranganathan
>>     [email-masked] <mailto:[email-masked]>
>>     <https://www.ietf.org/mailman/listinfo/opsawg>
>
>
>
>
> -- 
> M. Ranganathan
>
>