Subject: [OPSAWG] MUD: certain enterprise service functions and descriptions & defaults

From: Eliot Lear <[email-masked]>
Date: Wed, 21 Sep 2016 08:15:19 +0200

Hi everyone again,

This one is more interesting.

Right now, if you want to allow DNS and NTP and similar services, you
have to entirely allow them.  You can't specify which servers to allow. 
But we are this close to being able to do just that.  There is a
controller class function already available, although there is no
standard naming for that class.  What I propose to do is create a
registry for certain standard classes that devices can be registered
into.  In this way, authorized DNS servers (for example) could be
registered by the enterprise administrator into urn:mud:nameserver, or
for NTP being urn:mud:ntp.

This allows us to solve another problem as well.  We can also specify
defaults.  My suggestion is that both of those classes (nameserver and
ntp) be included as "permit" defaults.  In the context of an access
list, that would mean that they would be *appended*, meaning that it
would be possible for the manufacturer to add an explicit "deny" in
front of them to negate either or both.  These proposals require no
explicit model changes, but I would specify in the document the precise
JSON that the default would mean.  The benefit of doing this is to keep
the files more succinct and readable.

Comments?

Eliot

---

From: Thorsten Dahm <[email-masked]>
Date: Mon, 26 Sep 2016 14:47:50 +0100

Hi Eliot,

> for NTP being urn:mud:ntp.
+1 to this idea. DNS & NTP are essential services, but as admin /
manufacturer you must be able to specify a list of trusted sources for DNS
and time.

Should we look at RFC6106 for devices that support IPv6?

cheers,
Thorsten

---

From: Eliot Lear <[email-masked]>
Date: Mon, 26 Sep 2016 15:53:32 +0200

On 9/26/16 3:47 PM, Thorsten Dahm wrote:
> Hi Eliot,
>
> On 21 September 2016 at 07:15, Eliot Lear <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> manufacturer you must be able to specify a list of trusted sources for
> DNS and time.
>

Yes, I think so.  An I think we need the appropriate rule set though to
stick in the appendix.

Eliot