Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt

From: [email-masked]
Date: Wed, 24 Jan 2018 00:29:40 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Operations and Management Area Working Group WG of the IETF.

        Title           : Manufacturer Usage Description Specification
        Authors         : Eliot Lear
                          Ralph Droms
                          Dan Romascanu
	Filename        : draft-ietf-opsawg-mud-14.txt
	Pages           : 56
	Date            : 2018-01-24

Abstract:
   This memo specifies a component-based architecture for manufacturer
   usage descriptions (MUD).  The goal of MUD is to provide a means for
   Things to signal to the network what sort of access and network
   functionality they require to properly function.  The initial focus
   is on access control.  Later work can delve into other aspects.

   This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, an
   LLDP TLV, a URL suffix specification, an X.509 certificate extension
   and a means to sign and verify the descriptions.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-opsawg-mud-14
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-14

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Eliot Lear <[email-masked]>
Date: Wed, 24 Jan 2018 09:34:10 +0100

This update primarily focuses on two elements that were agreed during WGLC:

  * The update to the ACL model.  That update has taken longer than I
    would have liked, but it is now at least close to finished.  Note:
    the MUD model does not yet match the published ACL model, but it
    does match the agreed changes that will be produced in the next ACL
    draft.
  * Mark Nottingham had commented that it is not appropriate to have
    versioning information in the MUD-URL itself, but that it should be
    in the model.  We agreed on this change, as well as some wording
    around how HTTP is handled.

Based on these changes, I would like to move this document forward to
IETF LC.

Eliot

On 24.01.18 09:29, [email-masked] wrote:
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: <[email-masked]>
Date: Wed, 24 Jan 2018 09:52:12 +0000

Hi Eliot,

Some quick comments:

* Please note that "acl-type" should be “type” and "rule-name" should be changed to “name”. This can be easily fixed in the examples.

* This sentence should be carefully updated as well: “With the exceptions of "name", "acl-type", "rule-name", and TCP and”.

* I guess the examples should be checked to align with the new ACL structure. For example,

 - “ipv6-acl” entries should be updated to “ipv6”.

 - add “l3” entry before “ipv4” and “ipv6”.

* It would useful to add a justification why it is not recommended to support 'reject' action.

* Unless I’m mistaken, the mud use case does not require the support of interfaces as an attachment point. It may be useful to add something among those lines:

   Given that MUD does not deal with interfaces, the
   support of the "ietf-interfaces" module [RFC7223<https://tools.ietf.org/html/rfc7223>] is not
   required. Specifically, the support of interface-related
   features and branches (e.g., interface-attachment and interface-stats)
   of the ACL YANG module is not required.

Cheers,

Med

De : OPSAWG [mailto:[email-masked]] De la part de Eliot Lear
Envoyé : mercredi 24 janvier 2018 09:34
Cc : Mahesh Jethanandani; [email-masked]; Mark Nottingham
Objet : Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt

  *   The update to the ACL model.  That update has taken longer than I would have liked, but it is now at least close to finished.  Note: the MUD model does not yet match the published ACL model, but it does match the agreed changes that will be produced in the next ACL draft.
  *   Mark Nottingham had commented that it is not appropriate to have versioning information in the MUD-URL itself, but that it should be in the model.  We agreed on this change, as well as some wording around how HTTP is handled.

Based on these changes, I would like to move this document forward to IETF LC.

Eliot

On 24.01.18 09:29, [email-masked]<mailto:[email-masked]> wrote:

        Authors         : Eliot Lear

                          Ralph Droms

                          Dan Romascanu

 Pages           : 56

 Date            : 2018-01-24

Abstract:

OPSAWG mailing list

[email-masked]<mailto:[email-masked]>

---

From: Eliot Lear <[email-masked]>
Date: Wed, 24 Jan 2018 11:05:13 +0100

Hi Med,

On 24.01.18 10:52, [email-masked] wrote:
>
> Hi Eliot,
>
>  
>
> Some quick comments:
> * Please note that "acl-type" should be “type” and "rule-name" should
> be changed to “name”. This can be easily fixed in the examples.

My understanding from draft-ietf-netmod-acl-model-14 is that acl-type
remains acl-type.  acl-name became name.  But you're right- rule-name
became name as well.  I will adjust the text accordingly.

> * This sentence should be carefully updated as well: “With the
> exceptions of "name", "acl-type", "rule-name", and TCP and”.

Which is the text I adjusted ;-)

> - add “l3” entry before “ipv4” and “ipv6”.

I think this is done in the normative text but you're right- it needs to
be corrected in the examples.

> * It would useful to add a justification why it is not recommended to

Ok, I'll add some text.

> * Unless I’m mistaken, the mud use case does not require the support
> of interfaces as an attachment point. It may be useful to add
> something among those lines:  
>
>  
>
>    support of the "ietf-interfaces" module [RFC7223
> <https://tools.ietf.org/html/rfc7223>] is not
>

ok.

In addition, I have received the following requests for data elements to
be added to the core model:

  * Manufacturer-Name
  * Device-Type
  * Model-Number
  * Software-version

Unless I hear objections, I am disposed to add these as non-mandatory
leaf-nodes as strings underneath the top-level MUD object.

Eliot
>
>  
> Cheers,
> Med
>
>  
>
> *De :*OPSAWG [mailto:[email-masked]] *De la part de* Eliot Lear
> *Envoyé :* mercredi 24 janvier 2018 09:34
> *Cc :* Mahesh Jethanandani; [email-masked]; Mark Nottingham
> *Objet :* Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt
>
>  
>
>     does match the agreed changes that will be produced in the next
>     ACL draft.
>     versioning information in the MUD-URL itself, but that it should
>     be in the model.  We agreed on this change, as well as some
>     wording around how HTTP is handled.
>
>     [email-masked] <mailto:[email-masked]>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 24 Jan 2018 11:14:06 +0100

> be added to the core model:

Will these definitions be aligned with definitions in 'ietf-hardware'
defined in draft-ietf-netmod-entity-08.txt (which is in the state IESG
Evaluation)?

/js

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

---

From: Eliot Lear <[email-masked]>
Date: Wed, 24 Jan 2018 12:00:57 +0100

Yes, this makes sense.

Eliot

---

From: Joe Clarke <[email-masked]>
Date: Wed, 24 Jan 2018 06:20:25 -0500

On 1/24/18 05:05, Eliot Lear wrote:
> In addition, I have received the following requests for data
> elements to be added to the core model:
> 
> * Manufacturer-Name * Device-Type * Model-Number *
> Software-version
> 
> 
> Unless I hear objections, I am disposed to add these as
> non-mandatory leaf-nodes as strings underneath the top-level MUD
> object.

Is there a reason why they wouldn't be mandatory?  Seems like these
data would be readily available and having them would make a number of
use case cases possible.

Joe

---

From: Eliot Lear <[email-masked]>
Date: Wed, 24 Jan 2018 12:24:32 +0100

> data would be readily available and having them would make a number of

Yes, there is.  If the MUD-URL is "burned in" via 802.1AR and the
software can be updated, then one oughtn't provide software information
for the simple reason that it would be most likely wrong.  Hardware
info?  Sure.  Software when using DHCP or LLDP?  Sure.  But otherwise no.

Eliot

---

From: <[email-masked]>
Date: Wed, 24 Jan 2018 11:54:29 +0000

Re-,

Thank you Eliot for the prompt follow-up.

Please see some comments inline.

Cheers,
Med

De : Eliot Lear [mailto:[email-masked]]
Envoyé : mercredi 24 janvier 2018 11:05
À : BOUCADAIR Mohamed IMT/OLN
Cc : Mahesh Jethanandani; [email-masked]; Mark Nottingham; Saswat Praharaj (saspraha)
Objet : Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt

Hi Med,

On 24.01.18 10:52, [email-masked]<mailto:[email-masked]> wrote:
Hi Eliot,

Some quick comments:

My understanding from draft-ietf-netmod-acl-model-14 is that acl-type remains acl-type.  acl-name became name.  But you're right- rule-name became name as well.  I will adjust the text accordingly.
[Med] I guess you meant -15. I confirm that acl-type is to be changed too. Below an excerpt of the acl tree structure:

     +--rw access-lists
        +--rw acl* [name]
        |  +--rw name    string
        |  +--rw type?   acl-type

Which is the text I adjusted ;-)
[Med] Yes. I was referring to the examples.

I think this is done in the normative text but you're right- it needs to be corrected in the examples.

Ok, I'll add some text.

[Med] Thank you. BTW, wouldn’t you need a rate-limit action to “protect” against exhausting Thing resources?

If so, feel free to grab from the following:

==

   augment "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces" +
           "/ietf-acl:ace/ietf-acl:actions" {
     description
       "Augments ACL module with a rate-limit action.";
     leaf rate-limit {

       when "derived-from-or-self(/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/" +
            "ietf-acl:ace/ietf-acl:actions/ietf-acl:forwarding, 'ietf-acl:accept')";
       type decimal64 {
         fraction-digits 2;
       }
      description
        "rate-limit traffic. This action is valid only when accept action is used.";
      }
   }
==

ok.

In addition, I have received the following requests for data elements to be added to the core model:

  *   Manufacturer-Name
  *   Device-Type
  *   Model-Number
  *   Software-version

Unless I hear objections, I am disposed to add these as non-mandatory leaf-nodes as strings underneath the top-level MUD object.

Eliot

Cheers,

Med

De : OPSAWG [mailto:[email-masked]] De la part de Eliot Lear
Envoyé : mercredi 24 janvier 2018 09:34
Cc : Mahesh Jethanandani; [email-masked]<mailto:[email-masked]>; Mark Nottingham
Objet : Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt

Eliot

        Authors         : Eliot Lear

                          Ralph Droms

                          Dan Romascanu

 Pages           : 56

 Date            : 2018-01-24

Abstract:

OPSAWG mailing list

---

From: Eliot Lear <[email-masked]>
Date: Wed, 24 Jan 2018 13:15:58 +0100

Hi Med,

Please see below:

On 24.01.18 12:54, [email-masked] wrote:

> [Med] I guess you meant -15. I confirm that acl-type is to be changed
> too. Below an excerpt of the acl tree structure:
>
>  
>
>      +--rw access-lists
>
>         +--rw acl* [name]
>
>         |  +--rw name    string
>
>         |  +--rw type?   acl-type
>
>  
>

You're right.  I stand corrected.  And I spotted the error in the
example.  Will correct.
> [Med] Thank you. BTW, wouldn’t you need a rate-limit action to
> “protect” against exhausting Thing resources?
>

I don't think that's appropriate at this point.  For one thing, it goes
well beyond what many implementations can actually do.  For another, it
may be asking a bit much of the manufacturers to predict this sort of
behavior, and it will be easy to get wrong.  I would suggest this be
handled later as we get some additional operational experience.

Eliot

---

From: <[email-masked]>
Date: Wed, 24 Jan 2018 12:36:02 +0000

Fair enough. Thank you.

Cheers,
Med

Envoyé : mercredi 24 janvier 2018 13:16

Hi Med,

Please see below:

On 24.01.18 12:54, [email-masked]<mailto:[email-masked]> wrote:

     +--rw access-lists
        +--rw acl* [name]
        |  +--rw name    string
        |  +--rw type?   acl-type

You're right.  I stand corrected.  And I spotted the error in the example.  Will correct.

Ok, I'll add some text.

I don't think that's appropriate at this point.  For one thing, it goes well beyond what many implementations can actually do.  For another, it may be asking a bit much of the manufacturers to predict this sort of behavior, and it will be easy to get wrong.  I would suggest this be handled later as we get some additional operational experience.

Eliot

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 24 Jan 2018 10:25:18 -0800

> On Jan 24, 2018, at 12:34 AM, Eliot Lear <[email-masked]> wrote:
> 
> The update to the ACL model.  That update has taken longer than I would have liked, but it is now at least close to finished.  Note: the MUD model does not yet match the published ACL model, but it does match the agreed changes that will be produced in the next ACL draft.
Does it?

Looking at the MUD example in Section 8 of the draft, I see that port/range is hanging off of ipv6 IP header. Per your comment, we moved the port under the ‘tcp’ header in the ACL model.

Also, the container "access-list-entries" had been renamed to “aces” in an earlier version of the draft. Med has pointed out some other discrepancies, but in general, I would scrub the entire example one more time.

Cheers.

p.s. The updated ACL model tree looks like this now:

module: ietf-access-control-list
    +--rw access-lists
       +--rw acl* [name]
       |  +--rw name    string
       |  +--rw type?   acl-type
       |  +--rw aces
       |     +--rw ace* [name]
       |        +--rw name          string
       |        +--rw matches
       |        |  +--rw (l2)?
       |        |  |  +--:(eth)
       |        |  |     +--rw eth {match-on-eth}?
       |        |  |        +--rw destination-mac-address?
       |        |  |        |       yang:mac-address
       |        |  |        +--rw destination-mac-address-mask?
       |        |  |        |       yang:mac-address
       |        |  |        +--rw source-mac-address?
       |        |  |        |       yang:mac-address
       |        |  |        +--rw source-mac-address-mask?
       |        |  |        |       yang:mac-address
       |        |  |        +--rw ethertype?
       |        |  |                eth:ethertype
       |        |  +--rw (l3)?
       |        |  |  +--:(ipv4)
       |        |  |  |  +--rw ipv4 {match-on-ipv4}?
       |        |  |  |     +--rw dscp?                       inet:dscp
       |        |  |  |     +--rw ecn?                        uint8
       |        |  |  |     +--rw length?                     uint16
       |        |  |  |     +--rw ttl?                        uint8
       |        |  |  |     +--rw protocol?                   uint8
       |        |  |  |     +--rw ihl?                        uint8
       |        |  |  |     +--rw flags?                      bits
       |        |  |  |     +--rw offset?                     uint16
       |        |  |  |     +--rw identification?             uint16
       |        |  |  |     +--rw (destination-network)?
       |        |  |  |     |  +--:(destination-ipv4-network)
       |        |  |  |     |     +--rw destination-ipv4-network?
       |        |  |  |     |             inet:ipv4-prefix
       |        |  |  |     +--rw (source-network)?
       |        |  |  |        +--:(source-ipv4-network)
       |        |  |  |           +--rw source-ipv4-network?
       |        |  |  |                   inet:ipv4-prefix
       |        |  |  +--:(ipv6)
       |        |  |     +--rw ipv6 {match-on-ipv6}?
       |        |  |        +--rw dscp?                       inet:dscp
       |        |  |        +--rw ecn?                        uint8
       |        |  |        +--rw length?                     uint16
       |        |  |        +--rw ttl?                        uint8
       |        |  |        +--rw protocol?                   uint8
       |        |  |        +--rw (destination-network)?
       |        |  |        |  +--:(destination-ipv6-network)
       |        |  |        |     +--rw destination-ipv6-network?
       |        |  |        |             inet:ipv6-prefix
       |        |  |        +--rw (source-network)?
       |        |  |        |  +--:(source-ipv6-network)
       |        |  |        |     +--rw source-ipv6-network?
       |        |  |        |             inet:ipv6-prefix
       |        |  |        +--rw flow-label?
       |        |  |                inet:ipv6-flow-label
       |        |  +--rw (l4)?
       |        |  |  +--:(tcp)
       |        |  |  |  +--rw tcp {match-on-tcp}?
       |        |  |  |     +--rw sequence-number?
       |        |  |  |     |       uint32
       |        |  |  |     +--rw acknowledgement-number?
       |        |  |  |     |       uint32
       |        |  |  |     +--rw data-offset?
       |        |  |  |     |       uint8
       |        |  |  |     +--rw reserved?
       |        |  |  |     |       uint8
       |        |  |  |     +--rw flags?
       |        |  |  |     |       bits
       |        |  |  |     +--rw window-size?
       |        |  |  |     |       uint16
       |        |  |  |     +--rw urgent-pointer?
       |        |  |  |     |       uint16
       |        |  |  |     +--rw options?
       |        |  |  |     |       uint32
       |        |  |  |     +--rw (source-port)?
       |        |  |  |     |  +--:(source-port-range-or-operator)
       |        |  |  |     |     +--rw source-port-range-or-operator
       |        |  |  |     |        +--rw (port-range-or-operator)?
       |        |  |  |     |           +--:(range)
       |        |  |  |     |           |  +--rw lower-port
       |        |  |  |     |           |  |       inet:port-number
       |        |  |  |     |           |  +--rw upper-port
       |        |  |  |     |           |          inet:port-number
       |        |  |  |     |           +--:(operator)
       |        |  |  |     |              +--rw operator?     operator
       |        |  |  |     |              +--rw port
       |        |  |  |     |                      inet:port-number
       |        |  |  |     +--rw (destination-port)?
       |        |  |  |        +--:(destination-port-range-or-operator)
       |        |  |  |           +--rw destination-port-range-or-opera
tor
       |        |  |  |              +--rw (port-range-or-operator)?
       |        |  |  |                 +--:(range)
       |        |  |  |                 |  +--rw lower-port
       |        |  |  |                 |  |       inet:port-number
       |        |  |  |                 |  +--rw upper-port
       |        |  |  |                 |          inet:port-number
       |        |  |  |                 +--:(operator)
       |        |  |  |                    +--rw operator?     operator
       |        |  |  |                    +--rw port
       |        |  |  |                            inet:port-number
       |        |  |  +--:(udp)
       |        |  |  |  +--rw udp {match-on-udp}?
       |        |  |  |     +--rw length?
       |        |  |  |     |       uint16
       |        |  |  |     +--rw (source-port)?
       |        |  |  |     |  +--:(source-port-range-or-operator)
       |        |  |  |     |     +--rw source-port-range-or-operator
       |        |  |  |     |        +--rw (port-range-or-operator)?
       |        |  |  |     |           +--:(range)
       |        |  |  |     |           |  +--rw lower-port
       |        |  |  |     |           |  |       inet:port-number
       |        |  |  |     |           |  +--rw upper-port
       |        |  |  |     |           |          inet:port-number
       |        |  |  |     |           +--:(operator)
       |        |  |  |     |              +--rw operator?     operator
       |        |  |  |     |              +--rw port
       |        |  |  |     |                      inet:port-number
       |        |  |  |     +--rw (destination-port)?
       |        |  |  |        +--:(destination-port-range-or-operator)
       |        |  |  |           +--rw destination-port-range-or-opera
tor
       |        |  |  |              +--rw (port-range-or-operator)?
       |        |  |  |                 +--:(range)
       |        |  |  |                 |  +--rw lower-port
       |        |  |  |                 |  |       inet:port-number
       |        |  |  |                 |  +--rw upper-port
       |        |  |  |                 |          inet:port-number
       |        |  |  |                 +--:(operator)
       |        |  |  |                    +--rw operator?     operator
       |        |  |  |                    +--rw port
       |        |  |  |                            inet:port-number
       |        |  |  +--:(icmp)
       |        |  |     +--rw icmp {match-on-icmp}?
       |        |  |        +--rw type?             uint8
       |        |  |        +--rw code?             uint8
       |        |  |        +--rw rest-of-header?   uint32
       |        |  +--rw egress-interface?    if:interface-ref
       |        |  +--rw ingress-interface?   if:interface-ref
       |        +--rw actions
       |        |  +--rw forwarding    identityref
       |        |  +--rw logging?      identityref
       |        +--ro statistics {acl-aggregate-stats}?
       |           +--ro matched-packets?   yang:counter64
       |           +--ro matched-octets?    yang:counter64
       +--rw attachment-points
          +--rw interface* [interface-id] {interface-attachment}?
             +--rw interface-id    if:interface-ref
             +--rw ingress
             |  +--rw acl-sets
             |     +--rw acl-set* [name]
             |        +--rw name
             |        |       -> ../../../../../../acl/name
             |        +--ro ace-statistics* [name] {interface-stats}?
             |           +--ro name               leafref
             |           +--ro matched-packets?   yang:counter64
             |           +--ro matched-octets?    yang:counter64
             +--rw egress
                +--rw acl-sets
                   +--rw acl-set* [name]
                      +--rw name
                      |       -> ../../../../../../acl/name
                      +--ro ace-statistics* [name] {interface-stats}?
                         +--ro name               leafref
                         +--ro matched-packets?   yang:counter64
                         +--ro matched-octets?    yang:counter64
> Mark Nottingham had commented that it is not appropriate to have versioning information in the MUD-URL itself, but that it should be in the model.  We agreed on this change, as well as some wording around how HTTP is handled.
> On 24.01.18 09:29, [email-masked] <mailto:[email-masked]> wrote:
>> https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ <https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/>
>> 
>> https://tools.ietf.org/html/draft-ietf-opsawg-mud-14 <https://tools.ietf.org/html/draft-ietf-opsawg-mud-14>
>> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-14 <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-14>
>> 
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-14 <https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-14>
>> 
>> 
>> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
>> 
>> https://www.ietf.org/mailman/listinfo/opsawg <https://www.ietf.org/mailman/listinfo/opsawg>
>> 
> 

Mahesh Jethanandani
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Wed, 24 Jan 2018 19:27:19 +0100

On 24.01.18 19:25, Mahesh Jethanandani wrote:
>
>
>> On Jan 24, 2018, at 12:34 AM, Eliot Lear <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>     would have liked, but it is now at least close to finished. 
>>     Note: the MUD model does not yet match the published ACL model,
>>     but it does match the agreed changes that will be produced in the
>>     next ACL draft.
>>
> Does it?
>
> Looking at the MUD example in Section 8 of the draft, I see that
> port/range is hanging off of ipv6 IP header. Per your comment, we
> moved the port under the ‘tcp’ header in the ACL model.

Yeah, the example was blown.  Fixed in next release ;-)  Same with
protocol.  It ended up in l4 when it should be l3.

>
> Also, the container "access-list-entries" had been renamed to “aces”
> in an earlier version of the draft. Med has pointed out some other
> discrepancies, but in general, I would scrub the entire example one
> more time.
>
> Cheers.
>
>>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org>.
>>>
> [email-masked] <mailto:[email-masked]>
>

---

From: Joe Clarke <[email-masked]>
Date: Fri, 26 Jan 2018 05:05:05 -0500

On 1/24/18 06:24, Eliot Lear wrote:
>> Is there a reason why they wouldn't be mandatory?  Seems like
>> these data would be readily available and having them would make
>> a number of use case cases possible.
> 
> software can be updated, then one oughtn't provide software
> information for the simple reason that it would be most likely
> wrong.  Hardware info?  Sure.  Software when using DHCP or LLDP?
> Sure.  But otherwise no.

Fair, but why not mandatory then for device-type, model-number, and
manuf-name?

Joe

---

From: Eliot Lear <[email-masked]>
Date: Fri, 26 Jan 2018 11:59:03 +0100

> Fair, but why not mandatory then for device-type, model-number, and

I think the argument should be the other way around.  Why should they be
mandatory?  Making things mandatory makes them more fragile.  To me
there really has to be value in adding that fragility.

Also, I've been persuaded to drop device-type because nobody can easily
define such a thing, and it requires serious consideration elsewhere
(like in t2trg).

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Fri, 26 Jan 2018 23:12:08 +0100

Hi Saswat,

On 26.01.18 20:17, Saswat Praharaj (saspraha) wrote:
> Hi Eliot, > > Adding device information (manufacture/device-type etc.) in MUD
file provides visibility in network, in addition to policy. > If
visibility is not that important for MUD, we could have it as optional
parameters. > > IMHO, it’s important because MUD will not be the only
policy for the device and if admin has to apply other policies, he/she
needs to know what the device is. > Device manufacturer is the most
reliable source to provide information about the device. > > Based on
your comment > > > Yes, there is. If the MUD-URL is "burned in" via
802.1AR and the > > software can be updated, then one oughtn't provide
software > > information for the simple reason that it would be most
likely > > wrong. Hardware info? Sure. Software when using DHCP or LLDP?
> > Sure. But otherwise no. > > For this, it’s important that we have
version number in the MUD URL – Either as v1, v2 or <software version>
itself. > Device description and access policy may change when software
is upgraded. A newly released device with a different software version
may have different access pattern compared to older version of the device.
That's not quite what the version did, and hardcoding the MUD-URL is the
fundamental issue.  Remember, it's a GOOD thing to hardcode that URL
into a cert because then it is the manufacturer making the assertion and
not the device itself.  But there are some attendant drawbacks, which is
why we have the other mechanisms.

Eliot

---

From: "Saswat Praharaj (saspraha)" <[email-masked]>
Date: Fri, 26 Jan 2018 19:17:39 +0000

Hi Eliot,

Adding device information (manufacture/device-type etc.) in MUD file provides visibility in network, in addition to policy.
If visibility is not that important for MUD, we could have it as optional parameters. 

IMHO, it’s important because MUD will not be the only policy for the device and if admin has to apply other policies, he/she needs to know what the device is.
Device manufacturer is the most reliable source to provide information about the device.

Based on your comment 

    > wrong.  Hardware info?  Sure.  Software when using DHCP or LLDP?

For this, it’s important that we have version number in the MUD URL – Either as v1, v2 or <software version> itself. 
Device description and access policy may change when software is upgraded. A newly released device with a different software version may have different access pattern compared to older version of the device.

MUD file is a static file and in a static file serving web-server like apache (or even an object store like AWS S3) it is most likely to be stored in the disk (on in object store) as path  <</.well-known/mud/model>> .
MUD file would be read directly from the disk path when the file is served to the requester.

It’s going to be very difficult to host multiple policy files for the same model unless we have a way to distinguish them in the URL itself. 
If we have software version in the URL, we not need to have it in the file. 
Two different software version (therefore different URLs) could point to the same MUD file, if there is a need for that. 
This mapping can be done fairly easily inside a webserver. 

Thanks,
Saswat

On 1/26/18, 2:05 AM, "Joe Clarke (jclarke)" <[email-masked]> wrote:

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    
    Joe
    -----BEGIN PGP SIGNATURE-----
    
    iF0EARECAB0WIQTMiWQHc8wChijkr7lvaI+K/hTPhwUCWmr9TwAKCRBvaI+K/hTP
    h4UhAJ9C7cFxWuDxndYipyAFnunsWUrllQCfRhK/8Gnk4t7YMM26hCsxUCt3rVY=
    =eEtq
    -----END PGP SIGNATURE-----

---

From: "Marco Davids (SIDN)" <[email-masked]>
Date: Wed, 31 Jan 2018 10:07:05 +0100

> Adding device information (manufacture/device-type etc.) in MUD file provides visibility in network, in addition to policy.

Also, besides ACL's, I believe it would also make sense to convey 
bandwidth limitation information via MUD's (my Zigbee hub does not need 
the full available bandwidth, especially not when it is compromised) and 
maybe even time constraints (only allow it to interact with the internet 
during office hours, or something like that).

I see several use cases for these features.

--
Marco

---

From: Eliot Lear <[email-masked]>
Date: Wed, 31 Jan 2018 12:09:01 +0100

Hi Marco,

I think this is an example opportunity for an extension.  Let's put that
together separately.  happy to work with you on it.

Eliot

On 31.01.18 10:07, Marco Davids (SIDN) wrote:
>> Adding device information (manufacture/device-type etc.) in MUD file
>> provides visibility in network, in addition to policy.
>
> bandwidth limitation information via MUD's (my Zigbee hub does not
> need the full available bandwidth, especially not when it is
> compromised) and maybe even time constraints (only allow it to
> interact with the internet during office hours, or something like that).
>