Subject: [OPSAWG] MUD : actions { forwarding : drop } utility.

From: "M. Ranganathan" <[email-masked]>
Date: Mon, 23 Oct 2017 18:02:13 -0400

Hello,

I am wondering about the utility of the actions part of the ACE.

In the latest MUD draft, I see "Appendix B : Default MUD nodes" where it is
suggested that one could, for example, set up to drop packets to the DNS
server by setting actions

               "actions": {
                   "forwarding": "drop"
                 }

But this is only because there is a notion of default access in MUD which assume
the IOT device isallowed to access DNS and NTP by default, which now has to
be overriden by a "drop" action.

This goes aginst the basic MUD working principle that everything is
denied unless explictly
stated.

I am just voicing an opinon here :

Perhaps it would be less confusing if NTP and DNS were not given any
special treatment.
It really does not save much by way of length of the MUD file to
explicitly state rules
for them

Perhaps it is a bit late to suggest this but may I suggest removing
the idea of default
permit access to DNS and NTP. It would simplify some things.

Thanks,

Regards,

Ranga.

-- 
M. Ranganathan

---

From: Eliot Lear <[email-masked]>
Date: Tue, 24 Oct 2017 13:48:40 +0200

I want to confirm this with the WG and the chairs.  I'm okay removing
this if others are as well.  It's past WGLC and I am about to post -13. 
Objections?

On 10/24/17 12:02 AM, M. Ranganathan wrote:
> In the latest MUD draft, I see "Appendix B : Default MUD nodes" where
> it is suggested that one could, for example, set up to drop packets to
> the DNS server by setting actions
>
>
>                "actions": {
>                    "forwarding": "drop"
>                  }
>
> But this is only because there is a notion of default access in MUD
> which assume the IOT device isallowed to access DNS and NTP by
> default, which now has to be overriden by a "drop" action.
> denied unless explictly stated.
> I am just voicing an opinon here : Perhaps it would be less confusing
> if NTP and DNS were not given any special treatment. It really does
> not save much by way of length of the MUD file to explicitly state
> rules for them
> the idea of default permit access to DNS and NTP. It would simplify
> some things.
> Thanks,
> Regards,
> Ranga.
>
>
>
>
>
> -- 
> M. Ranganathan
>
>
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: Joe Clarke <[email-masked]>
Date: Tue, 24 Oct 2017 08:48:19 -0400

On 10/24/17 07:48, Eliot Lear wrote:
> I want to confirm this with the WG and the chairs.  I'm okay
> removing this if others are as well.  It's past WGLC and I am about
> to post -13. Objections?

This seems better for security and clarity with respect to other MUD
elements.  But does this break any current implementations?

Joe

>> In the latest MUD draft, I see "Appendix B : Default MUD nodes"
>> where it is suggested that one could, for example, set up to drop
>> packets to the DNS server by setting actions
>> 
>> 
>> "actions": { "forwarding": "drop" }
>> 
>> But this is only because there is a notion of default access in
>> MUD which assume the IOT device isallowed to access DNS and NTP
>> by default, which now has to be overriden by a "drop" action. 
>> This goes aginst the basic MUD working principle that everything
>> is denied unless explictly stated. I am just voicing an opinon
>> here : Perhaps it would be less confusing if NTP and DNS were not
>> given any special treatment. It really does not save much by way
>> of length of the MUD file to explicitly state rules for them 
>> Perhaps it is a bit late to suggest this but may I suggest
>> removing the idea of default permit access to DNS and NTP. It
>> would simplify some things. Thanks, Regards, Ranga.
>> 
>> 
>> 
>> 
>> 
>> -- M. Ranganathan
>> 
>> 
>> _______________________________________________ OPSAWG mailing
>> list [email-masked] 
> _______________________________________________ OPSAWG mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: Eliot Lear <[email-masked]>
Date: Tue, 24 Oct 2017 15:28:40 +0200

> elements.  But does this break any current implementations?

This is a draft.  The underlying model has changed, so this is small
potatos.

Eliot

---

From: Joe Clarke <[email-masked]>
Date: Tue, 24 Oct 2017 09:38:00 -0400

On 10/24/17 09:28, Eliot Lear wrote:
>>> removing this if others are as well.  It's past WGLC and I am
>>> about to post -13. Objections?
>> 
>> This seems better for security and clarity with respect to other
>> MUD elements.  But does this break any current implementations?
> 
> This is a draft.  The underlying model has changed, so this is
> small potatos.

I understand.  I was just trying to be pedantic as I know that people
are working on MUD quite actively.  As I said, I like the idea, and I
think it makes sense to change now versus errata down the line.

Joe

---

From: Eliot Lear <[email-masked]>
Date: Tue, 24 Oct 2017 16:15:01 +0200

Joe,

In talking with a few more people, I'm coming to conclude we should
leave things as is.  Here's the issue: MOST but probably not ALL
manufacturers will need access to DNS.  They will nearly ALL specify
that need, and they may ALL do so in different ways.  That will
translate into more management overhead for the enterprise network
administrator.  It is better to have the standard implied classes.  The
only question is whether or not to give manufacturers the means to turn
that access off.  From a device threat surface standpoint, this is
relatively small potatoes, although it's something. After all, since
MOST devices will require access to name service, most devices would
ALREADY be exposed.  From a name server perspective, they already have
to be well hardened.  A similar argument can be made for NTP.

Thus let's leave things alone.

Eliot

---

From: "M. Ranganathan" <[email-masked]>
Date: Tue, 24 Oct 2017 11:15:27 -0400

Hello Eliot, Joe,

On Tue, Oct 24, 2017 at 10:15 AM, Eliot Lear <[email-masked]> wrote:

> Joe,
>
> In talking with a few more people, I'm coming to conclude we should leave
> things as is.  Here's the issue: MOST but probably not ALL manufacturers
> will need access to DNS.  They will nearly ALL specify that need, and they
> may ALL do so in different ways.  That will translate into more management
> overhead for the enterprise network administrator.  It is better to have
> the standard implied classes.  The only question is whether or not to give
> manufacturers the means to turn that access off.  From a device threat
> surface standpoint, this is relatively small potatoes, although it's
> something. After all, since MOST devices will require access to name
> service, most devices would ALREADY be exposed.  From a name server
> perspective, they already have to be well hardened.  A similar argument can
> be made for NTP.
>

Hi Eliot,

In attempting to implement MUD I found a few things confusing:

-- There are standard implied classes with URIs "urn:ietf:params:mud:dns"
and "uri:ietf:params:mud:ntp".

-- There is default behavior associated with those classes. ( For example,
you talk to DNS on port 53, NTP on port 123.) If a MUD rule specifies
nothing (no ACEs) then these two classes exist invisibly as ALLOW rules.

-- The manufacturer can override the default behavior by specifying ACE
rules for the dns and ntp classes (e.g. by specifying ports that are
different than 53 and 123).  If I consider an implied MUD ACL list with the
two implied DNS and NTP rules in it, I need to override the rules in this
list using an ACE rule specified in the MUD file for these two services.

- The manufacturer can disable his device talking to dns and ntp services
altogether by specifying DENY rules. Why specify a default behavior and
multiple ways to override the default when the presumed reason is to save a
few lines in the ACL file.

The only convenience that the default seems to provide is a few lines in
the ACL file. For that, it sacrifices clarity.

>From an implementation perspective, it makes it messy to have to deal with
deny rules. If we are going to allow default and special classes wuch as
DNS and NTP, then may I suggest that the authors allow for no means to
override their behavior.

It is cleaner to have everything (including DNS and NTP) be handled
uniformly and in the same fashion within the otherwise unambiguous
framework of MUD.

Again, I do not mean to open any can of worms. I am just voicing an opinion
and I realize it is quite late in the game to campaign for changes.

Thank you all for reading.

Regards,

Ranga.

-- 
M. Ranganathan

---

From: Eliot Lear <[email-masked]>
Date: Tue, 24 Oct 2017 17:23:34 +0200

Hi Ranga,

Let's step through these.

On 10/24/17 5:15 PM, M. Ranganathan wrote:
> Hello Eliot, Joe,
>
>
> On Tue, Oct 24, 2017 at 10:15 AM, Eliot Lear <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Joe,
>
>     In talking with a few more people, I'm coming to conclude we
>     should leave things as is.  Here's the issue: MOST but probably
>     not ALL manufacturers will need access to DNS.  They will nearly
>     ALL specify that need, and they may ALL do so in different ways. 
>     That will translate into more management overhead for the
>     enterprise network administrator.  It is better to have the
>     standard implied classes.  The only question is whether or not to
>     give manufacturers the means to turn that access off.  From a
>     device threat surface standpoint, this is relatively small
>     potatoes, although it's something. After all, since MOST devices
>     will require access to name service, most devices would ALREADY be
>     exposed.  From a name server perspective, they already have to be
>     well hardened.  A similar argument can be made for NTP.
>
> -- There are standard implied classes with URIs
> "urn:ietf:params:mud:dns" and "uri:ietf:params:mud:ntp".
>
> -- There is default behavior associated with those classes. ( For
> example, you talk to DNS on port 53, NTP on port 123.) If a MUD rule
> specifies nothing (no ACEs) then these two classes exist invisibly as
> ALLOW rules.

Yes.  Invisible  = default.  The key point is that if we don't do this
then most vendors will end up doing their own thing, and this becomes a
management burden, and some are surely going to get them wrong, for that
matter.

>
> -- The manufacturer can override the default behavior by specifying
> ACE rules for the dns and ntp classes (e.g. by specifying ports that
> are different than 53 and 123).  If I consider an implied MUD ACL list
> with the two implied DNS and NTP rules in it, I need to override the
> rules in this list using an ACE rule specified in the MUD file for
> these two services.

Yes.

>
> - The manufacturer can disable his device talking to dns and ntp
> services altogether by specifying DENY rules. Why specify a default
> behavior and multiple ways to override the default when the presumed
> reason is to save a few lines in the ACL file.
>
That's not the sole reason.  There are multiple ways to implement these
rules, and it is best to have a single consistent way.  So for instance,
one could implement them as permitting communication to ALL devices on
UDP port 53.  One could implement them by stating that the name server
be admitted as "my-controller" on port 53.  One could create a
vendor-specific controller class such as
"https://vendor.example.com/resolvers" and permit that class on port
53.  And the challenge is that that class has to then be somehow
resolved.  Better to have it as a default to simplify simple cases for
manufacturers and the network manager.  Yes, this requires a bit of
extra code in the MUD controller, but as a design decision, we should
place the pain on ourselves.  We can argue whether or not it is okay to
override this default– perhaps we shouldn't have that capability.  But
certainly the default should be there.
>
> The only convenience that the default seems to provide is a few lines
> in the ACL file. For that, it sacrifices clarity. 
>
> From an implementation perspective, it makes it messy to have to deal
> with deny rules. If we are going to allow default and special classes
> wuch as DNS and NTP, then may I suggest that the authors allow for no
> means to override their behavior.

I would be Ok with that, and would be happy to take it as an IETF LC
comment.

> uniformly and in the same fashion within the otherwise unambiguous

But uniformity is precisely what we get with a default for common
services.  I would expect there would be more in the future to further
simplify things.  Thus the registry.

Eliot

>
> Again, I do not mean to open any can of worms. I am just voicing an
> opinion and I realize it is quite late in the game to campaign for
> changes.
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 24 Oct 2017 17:51:47 +0200

> management burden, and some are surely going to get them wrong, for that

[...]

> certainly the default should be there.

What you describe seem to be different policies. Are you saying that
these different policies are bad or a huge management problem and
hence we hard-code a default policy that is considered "good" in most
situations? If you say removing the implied default rules results in a
management burden, what is the reasoning? That having different rules
for DNS (or NTP) would make debugging things more difficult? Given the
vendors likely put creative and interesting rules into MUD files
anyway, do two more rules matter?

Would it be an option to have Appendix B an template that vendors
SHOULD use if they want to allow access to DNS or NTP? Instead, of
hardwiring it in the spec, we tell vendors that 'if you want to open
up DNS and NTP, here is the suggested way to do this'.

I am just trying to understand the reasoning for hardwiring two
special cases.

/js

PS: Is there a logic how the rule names and acl names used in appendix
    B have been constructed? Does 'ent' mean something or is it a
    short form of 'entry'? Would v4-dns-in and v4-ntp-in be more
    descriptive than ent0-todev and ent1-todev and v4-dns-out and
    v4-ntp-out be more descriptive than ent0-frdev and ent1-frdev.
    Well, this might be to some extend subjective...

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Eliot Lear <[email-masked]>
Date: Tue, 24 Oct 2017 18:43:21 +0200

Giid evening Juergen,

On 10/24/17 5:51 PM, Juergen Schoenwaelder wrote:
> management burden, what is the reasoning? 

Here is a worst case scenario, Juergen: suppose you have 600 different
types of device on your network and each manufacturer has implemented
its own class for DNS support.  That would mean that the network
administrator would essentially have to populate 600 classes.  Better to
have a single class, given its commonality.  There are very few such
common services on a network, but there are presumably one or two others
that will come to be, and thus the ability to extend this list over time.

What Ranga is concerned about is the mechanism necessary for "deny".  I
very much doubt people will actually enter the block rules, and so I see
no problem simplifying to remove the "deny" text in the draft,
particularly because the DNS and NTP servers really need to be hardened
against attack already.  And while they will assuredly be broken into
from time to time, at that point the attack surface is SOOOO wide that
these sorts of denies are unlikely to make a difference.

Make sense?

Eliot

>     Well, this might be to some extend subjective...

The names are just names, but are chosen to be illustrative.

Eliot

---

From: "M. Ranganathan" <[email-masked]>
Date: Tue, 24 Oct 2017 13:20:31 -0400

Hi Eliot,

Your comment brings up something that I believe needs some clarification:

> Better to

I have a question about the scope of the class name to host address mapping:

A class URI "resolves" to a set of host addresses.

Are classes  globally scoped across all manufacturers (and devices) for a
given MUD controller? Or are they globally scoped (i.e. there is a global
registry of class name URI to host address list mapping similar to DNS)?

Perhaps some words about scoping can be put into the spec?

Thanks,

Ranga

-- 
M. Ranganathan

---

From: Eliot Lear <[email-masked]>
Date: Tue, 24 Oct 2017 20:14:42 +0200

On 10/24/17 7:20 PM, M. Ranganathan wrote:
> Are classes  globally scoped across all manufacturers (and devices)
> for a given MUD controller? Or are they globally scoped (i.e. there is
> a global registry of class name URI to host address list mapping
> similar to DNS)?

Yes.  That is the intent.  But only URNs are registered.

> Perhaps some words about scoping can be put into the spec?

I will take that as a last call comment if nobody objects.

Eliot

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Oct 2017 18:07:12 +0200

[...]

> Make sense?

Likely but I guess I have to do more reading to understand what
'populate classes' means for the network administrator...

[. . . . ]

Done some more reading. It is still unclear to me what 'populate
classes' means. 

Some general comments (now that I read the ID):

- s/only"accept"/only "accept"/

- the definition of tree diagrams is being moved from
  [I-D.ietf-netmod-rfc6087bis] to [I-D.ietf-netmod-yang-tree-diagrams]

- I read:

   Great care should be used when invoking the controller class.  For

  I am not sure what it means to invoke a controller class. So far, I
  thought that a 'controller class' is simply a set of IP addresses
  belonging to controllers. Hm.

   The other module abstracts away IP addresses into certain classes

   Controller:  Devices that the local network administrator admits to
      the particular class.

  I guess I am confused by the usage of the word 'class'; the word
  seems to be used in different contexts with different meanings and
  hence I also confused what populate classes may mean.

- Should the titles of 7.1 and 7.2 be changed to src-dnsname and
  dst-dnsname to align with the YANG definitions? Or should the text
  in 7.1 and 7.2 not simply become part of the description of
  src-dnsname and dst-dnsname?

- Likely a wording issue:

    Four of "acl" liste entries that implement default MUD nodes is
    listed below.

  Did you mean:

    Four "acl" list entries that implement default MUD nodes are
    listed below.

Back to the thread, which rule does appendix B with the 'default MUD
nodes' really play?

(a) Are these MUD rules that are assumed by a controller to be always
    there even if they are not?

(b) Or are these a set of rules that manufacturers may include in
    their MUD files?

I assume it is (a) but I find the text not entirely clear. The first
sentence reads like these rules are automatically considered to be
there (by the controller) but the second sentence says that a
manufacturer can overwrite this if necessary. Well, the sentence are
not explicit about which entity is doing what.

   [...] This is considered the default
   behavior and the ACEs are in effect appended to whatever other "ace"
   entries that a MUD file contains.  To block DNS or NTP one repeats
   the matching statement but replaces the "forwarding" action "accept"
   with "drop".

So why is (b) not workable and (a) required?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>g