Subject: [OPSAWG] WGLC for draft-ietf-opsawg-mud-11

From: Joe Clarke <[email-masked]>
Date: Wed, 20 Sep 2017 20:15:20 -0400

While this draft was already put through WGLC in March, there have been
a number of changes to it that should be reviewed.  This document has
had early reviews by SEC-DIR, IOT-DIR, and GEN.  The chairs are
particularly looking for a review of those items that have changed since
the -05 review (these are documented in the draft's Appendix A.

This email starts a two-week period for last call comments for
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ .

Please read this draft and provide any comments or questions to the list
on or before October 4, 2017.

Joe for the opsawg chairs

---

From: Kent Watsen <[email-masked]>
Date: Tue, 26 Sep 2017 00:57:15 +0000

Hi Elliot,

In my previous review, I had asked about how MUD intersects with my zerotouch draft, which has the device reaching out to either a well-known Internet-based or deployment-specific HTTPS resource.  But the need to reach out to these HTTPS resources should only be during the device's initial bootstrap process.  You said before something about an initial policy followed by an on-going policy, but I don't see that here.  Did I miss it?

What is the default behavior of the switch, when no MUD file is available.  Section 4 says "Anything not explicitly permitted is denied", but that section discusses the processing of a MUD file, not when there is no MUD file.  I'm assuming the goal is for the switch to deny traffic (fail close) when no MUD file can be found, but I worry that this may lead to unhappy operators as new product deployments (not having MUD support) are constantly blocked by the switches...  

Building upon the above two comments, I'm assuming that the switch could be configured to *always* allow access to some resources, even when no MUD file is found.  Is this what you had in mind?

Nits:

s1.3: "Thing" here is distracting.  Can you change to "device"? 
s1.4: replace "Our work" with something like "The solution"?
s1.5: inconsistent capitalization in manufacturer class names
s1.6: I see Thing here too.  Is this necessary?  Isn't the solution for non-IoT devices too?
s1.6: you might want to include a ref to RFC 8174, per RFC 8174.
s1.7: the text talks about NMSs and websites, but I think you mean controller and mud server, right?
s1.8: #7, how is "disconnect" defined?

<skimmed a bunch here>

regarding s3.4 and s3.7, is it possible to roll 'masa-server' into an extension?  Also, note that the brski-07 draft says nothing about this draft, so the relationship between the two is unclear.  I'd like to see references to brski removed from this draft if possible, with a preference for the brski draft to define its own "extension" is desired.

<skimmed a bunch more here>

s17: s/Watson/Watsen/    - an all too common typo in my life!  ;)

Thanks,
Kent

---

From: Eliot Lear <[email-masked]>
Date: Tue, 26 Sep 2017 08:37:35 +0200

Hi Kent,

I'll respond in two messages (I need to get more info in one case).

> In my previous review, I had asked about how MUD intersects with my zerotouch draft, which has the device reaching out to either a well-known Internet-based or deployment-specific HTTPS resource.…

I think so.  There is the notion of  “cache-validity” with the idea
being that one can change the policy from time to time.  The policy does
not itself expire, but the idea with “cache-validity” is that mud
controllers shouldn't pester the mud file server any sooner than that
period.

> What is the default behavior of the switch, when no MUD file is available.  Section 4 says "Anything not explicitly permitted is denied", but that section discusses the processing of a MUD file, no…

Fair question.  If no MUD file is available, it's a deployment decision
as to how to proceed (much as it is today).  The intent of Section 4 is
that one should assume that the end of an ACL is the JSON equivalent of
"deny any".  Should I clarify this?

> Building upon the above two comments, I'm assuming that the switch could be configured to *always* allow access to some resources, even when no MUD file is found.  Is this what you had in mind?

Yes.  I can clarify this as well.

> Nits:
I'll check each of these, but the term "Thing" is intended to be used
consistently, and changes made were in response to Robert Sparks'
review.  I'll make sure that each is as intended.
> regarding s3.4 and s3.7, is it possible to roll 'masa-server' into an extension?  Also, note that the brski-07 draft says nothing about this draft, so the relationship between the two is unclear.…

I am tempted to agree.  This is the one that may need just a day or two
to consider, perhaps with a conversation with Max and the ANIMA folk.

> s17: s/Watson/Watsen/    - an all too common typo in my life!  ;)
Deepest apologies.  I know how you feel.

Eliot

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Tue, 26 Sep 2017 18:25:25 +0000

My comments inline,

> On Sep 26, 2017, at 12:37 AM, Eliot Lear <[email-masked]> wrote:
> 
> Hi Kent,
> 

The relevant intersection would be if/how/when MUD deny’s or allows a connection to the netconf zerotouch bootstrap service as described in:
	https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-17#section-4.4 
?

I think the MUD 

I think the MUD ‘controller’ or ‘my-controller’ mechanism would be used to ensure devices of this class can access the indicated “internet-based” or “deployment-specific HTTPS resource” bootstrap-server?

Similarly for anima devices might be limited to only contacting their local BRSKI registrar via ‘my-controller'?

Assuming my interpretation is correct I don’t see any change needed in the text about this. 

> to consider, perhaps with a conversation with Max and the ANIMA folk.

I think the current text is valid and correct. I vote against any changes in this area: 

Distribution of the MASA server URL is informative to the local network infrastructure. Support for this mechanisms allows a local network infrastructure to know which MASA service to contact for this device. Allowing this within MUD provides an optimization opportunity for vendors that are anima BRSKI compatible. They can either implement the MASA extension URL, and any other urls, within their initial device identity -or- they can implement only the MUD URL extension. Space and changes to the device identity certificate are limited and difficult so an indirection through the MUD service is a valuable approach.

To make this extensible either BRSKI (et all ) needs to extend the yang models much the way it does with the voucher document or there needs to be a MUD specific extension method (iana namespace declared within MUD?) or something. I don’t see how that fits together cleanly and don’t see solving those questions as necessary at this time.

- max

---

From: Kent Watsen <[email-masked]>
Date: Tue, 26 Sep 2017 18:54:33 +0000

Hiya again,

> I think so.  There is the notion of  “cache-validity” with the idea being that one can change the policy from time to time.  The policy does not itself expire, but the idea with “cache-validity” is that mud controllers shouldn't pester the mud file server any sooner than that period.

IIUYC, you're thinking that the switch would receive updated configuration over time; an initial configuration would allow the Thing (to use the word in the draft, not my preference) to allow the bootstrapping flows and, then later, a second configuration that would reflect normal operation.  This is not (IMO) a MUD-file thing, so much as a controller-thing, as the Manufacturer would have no awareness of the operational state of the devices or be able to sequence the release of MUD files accordingly.  For this to work, I think the MUD file would need to have both states built into it, so then the controller can initially select the first state and then later, perhaps based on criteria other than a timeout, selects the second state.  Note, by "select" I mean "select and push updated config to switch based on"...

> Fair question.  If no MUD file is available, it's a deployment decision as to how to proceed (much as it is today).  The intent of Section 4 is that one should assume that the end of an ACL is the JSON equivalent of "deny any".  Should I clarify this?

Right, the ACL is default deny all, but that is the ACL within the MUD file that the controller (not the switch) processes. Looking to section 1.8, it starts off with "Thing emits URL".  In this case, it doesn't happen, the Thing doesn't implement the RFC.  In order for solutions to claim conformance, I think the switch would have to have a "mud-mode" whereby it refused pass traffic on a port unless a mud-controller gave it the config to do so.  If this is indeed the intent, I think the draft should be clear about it.

> Yes.  I can clarify this as well.

Okay, but then this seems to be at odds with the previous conclusion, which I may have gotten wrong.  To me, it seems that either the switch fails-closed (mud mode) or not (normal mode), is there room for anything else?

Okay, but I think it puts off the wrong signals and marginalizes the solution as a whole.  But, if you insist, at least be sure to define "Thing" before first use in the document (this is not the case currently) and give it a definition that clearly indicates that it applies to all network elements, not just lightbulbs, etc.

>> regarding s3.4 and s3.7, is it possible to roll 'masa-server' into an extension?  Also, note that the brski-07 draft says nothing about this draft, so the relationship between the two is unclear.  I'd like to see references to brski removed from this draft if possible, with a preference for the brski draft to define its own "extension" if desired.

> I am tempted to agree.  This is the one that may need just a day or two to consider, perhaps with a conversation with Max and the ANIMA folk.

Ack.

Thanks,
Kent

---

From: Kent Watsen <[email-masked]>
Date: Tue, 26 Sep 2017 20:17:54 +0000

Hi Max,

> The relevant intersection would be if/how/when MUD deny’s or allows a connection to the netconf zerotouch bootstrap service as described in: https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dnetconf-2Dzerotouch-2D17-23section-2D4.4&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=zRJNBxWfJ8UWKlNfBYE2-uk80qplF_03mYYTsTUK2Mc&s=Um4kALJ45VLzL4RYAZimjE0i0vsPDn8fjdbNbxpOuxE&e=  ?

Yes and no.  Yes, in that indeed the zerotouch bootstrap server may be either a well-known Internet-based resource (e.g., devices are hardcoded with its location and trust credentials) or a deployment-specific resource (e.g., devices learn about its location and trust credentials dynamically).  No, in that the zerotouch solution can also leverage DHCP, DNS, and potentially other TBD resources as well.  I'm not specifically calling out DHCP and DNS here though because the MUD draft already implicitly allows access to those two resources.  My intent was to just use zerotouch as an example here, other mechanisms (potentially not related to bootstrapping) may have similar concerns.

> I think the MUD ‘controller’ or ‘my-controller’ mechanism would be used to ensure devices of this class can access the indicated “internet-based” or “deployment-specific HTTPS resource” bootstrap-s…

Maybe? To be honest, the use of the 'controller' and 'my-controller' classes aren't very clear to me.  They're not part of the MUD file example in section 8.  Are you thinking that the Manufacturer would prepopulate 'controller' with its Internet-based resource and that deployments would populate the 'my-controller' with their deployment-specific resources?

> Similarly for anima devices might be limited to only contacting their local BRSKI registrar via ‘my-controller'?

I guess, based on the above, but this is what I'm trying to understand.

> Assuming my interpretation is correct I don’t see any change needed in the text about this. 

Well, at a minimum it would need to be more clearly explained.  Also, I think that the brski draft needs to explain how this field is intended to be used before this field's existence can be fully justified.  

As an aside, why are these fields called "[my-]controller"? - maybe something like "resource" would be more generally applicable, as not everything is a controller?

> Distribution of the MASA server URL is informative to the local network infrastructure. Support for this mechanisms allows a local network infrastructure to know which MASA service to contact for t…

I'm not disputing the value of being able to relay such information (though it's missing in the brski draft), I'm just thinking that rather than hardcode something into the base MUD file description, that the same can be done using the extension mechanism that this draft is defining instead.  Same data, just declared differently.  If there is a claim that it is too hard, then I'd recommend spending more time examining the extension mechanism now rather than after this becomes an RFC.

That said, maybe we should challenge the necessity of this field, or at least examine to what end this idea is valid.  First, just to throw it out there, why not also add a "zerotouch-server" field?  I'm guessing that this field enables lazy-binding so, rather than a device hardcoding such info, it be determined operationally.  Other resources apply too, right?  Sometimes devices need to reach out to well-known resources for e.g., anti-x signature packs.  Would the location for these resources also be map-able via a MUD file?  Note that I'm not actually advocating for any of this at the moment, just trying to understand what's intended here.

> To make this extensible either BRSKI (et all ) needs to extend the yang models much the way it does with the voucher document or there needs to be a MUD specific extension method (iana namespace de…

Yep, this is what I thought you might say.  Yes, it may not be clean, but it should be understood, right?

Separately, who generates the MUD files?  Is it the Manufacturer or someone else?  Section 12.1 doesn't say.  Section 12.2 says that the MUD controller verifies the signature to a known trust anchor, but it's unclear how these TAs became known.  Elsewhere the draft says MUD can provide a means to address some vulnerabilities in devices that no longer supported by their manufacturer, so I'm guessing that it's the latter, not the former.   Does this introduce a Security risk (degradation attack) of any sort to the brski bootstrapping process?

Thanks,
Kent

---

From: Eliot Lear <[email-masked]>
Date: Tue, 26 Sep 2017 22:57:54 +0200

Hi,

On 9/26/17 8:54 PM, Kent Watsen wrote:
> IIUYC, you're thinking that the switch would receive updated configuration over time; an initial configuration would allow the Thing (to use the word in the draft, not my preference) to allow the bootstrapping flows and, then later, a second configuration that would reflect normal operation.

Perhaps I've misunderstood your initial question, so let me try again. 
While not specifically discussed, it is possible for a device to request
a change of state if it starts to emit a different MUD-URL.  This is
possible for DHCP and LLDP but may be problematic for 802.1AR
certificates.  I do think there are some security considerations when
devices change state like this, and those are discussed in Security
Considerations.  I'm NOT recommending that devices do this.

>   This is not (IMO) a MUD-file thing, so much as a controller-thing, as the Manufacturer would have no awareness of the operational state of the devices or be able to sequence the release of MUD files accordingly.  For this to work, I think the MUD file would need to have both states built into it, so then the controller can initially select the first state and then later, perhaps based on criteria other than a timeout, selects the second state.  Note, by "select" I mean "select and push updated config to switch based on"...

See above.  I would worry about the complexity of the solution, which is
one of the reasons why I'm tending to agree with you to remove the
masa-server entry, but I'm still thinking about that one.  Also, keep
this in mind: my absolute preference is that this be done with 802.1AR
certificates so that the device itself doesn't really assert ANYTHING. 
Rather the manufacturer should do the asserting.

> Right, the ACL is default deny all, but that is the ACL within the MUD file that the controller (not the switch) processes. Looking to section 1.8, it starts off with "Thing emits URL".  In this case, it doesn't happen, the Thing doesn't implement the RFC.  In order for solutions to claim conformance,

There is no conformance claim here at all.  These are called
"descriptions" not "directives".  Deployments can do what with this
information they will.  That is stated several times in the draft.

>  I think the switch would have to have a "mud-mode" whereby it refused pass traffic on a port unless a mud-controller gave it the config to do so.  If this is indeed the intent, I think the draft should be clear about it.

It is intentionally unclear on that.  See below.
> Okay, but then this seems to be at odds with the previous conclusion, which I may have gotten wrong.  To me, it seems that either the switch fails-closed (mud mode) or not (normal mode), is there r…

How a pizza parlor deals with is will likely differ from a bank.  And a
bank will likely differ from how Juniper deals with it, which will
likely differ from how a healthcare provider deals with it.  I'm happy,
if you like to insert the following into Section 1.7 to make this
abundantly clear:

    Network administrators have the ultimate say over how their networks
    are configured.  MUD files are recommendations.  The access to
    network services assigned to a particular device either before a MUD
    file is read or after will depend on the deployment.  In some cases,
    deployments may allow open access or limit access prior to receiving
    a MUD-URL.  In some cases, deployments may completely ignore MUD
    URLs, or substitute some other behavior.

> Okay, but I think it puts off the wrong signals and marginalizes the solution as a whole.  But, if you insist, at least be sure to define "Thing" before first use in the document (this is not the c…

Emm...  it is clearly (I hope, again based on reviewer comments) defined
in the definitions section (there is a single forward reference).

From your other message:

> Separately, who generates the MUD files?  Is it the Manufacturer or someone else?  Section 12.1 doesn't say.

But Section 1 does ;-)  See bottom of page 3 top of page 4.

Finally,

> As an aside, why are these fields called "[my-]controller"?

Because controllers are a pretty well understood IoT concept.  To answer
the other question, I think it might help to state clearly that all the
abstractions are translated into appropriate IP addresses that would be
suitable for use in the ACL model.

I'll comment on BRSKI in a separate post, probably tomorrow.

Eliot

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Tue, 26 Sep 2017 23:12:31 +0000

> On Sep 26, 2017, at 2:17 PM, Kent Watsen <[email-masked]> wrote:
> 
> 
> Hi Max,
> 
> 

My thinking is that MUD allows for both NETCONF & BRSKI models via these fields. That I can’t conclusively show this by quoting the paragraphs in ‘controller’ and ‘my-controller’ sections of the MUD document re-enforces your points that more explanatory text might help. I’m curious what Eliot will say. 

> I'm not disputing the value of being able to relay such information (though it's missing in the brski draft),

There is text about the extension and how it is communicated in the current BRSKI draft. I’ve opened an issue to make it clearer (we can continue that portion of this discussion on the BRSKI github).

> I'm just thinking that rather than hardcode something into the base MUD file description, that the same can be done using the extension mechanism that this draft is defining instead.  Same data, just declared differently.  If there is a claim that it is too hard, then I'd recommend spending more time examining the extension mechanism now rather than after this becomes an RFC.
> 

I think you’re suggesting that https://tools.ietf.org/html/draft-ietf-opsawg-mud-11#section-3.4 be removed and that instead the BRSKI document leverage section https://tools.ietf.org/html/draft-ietf-opsawg-mud-11#section-3.7 to define a masa-url extension by mirroring https://tools.ietf.org/html/draft-ietf-opsawg-mud-11#appendix-C to define the extension.

In the process of following this thinking I have the following LC NOTES FOR ELIOT: 

1) This sentence of 3.7 probably needs to be adjusted to better match RFC2119 terminology. I suggest:
   "Note that NO MUD extensions may be used in a MUD file prior to
   the extensions being declared."
to
   “MUD extensions MUST NOT be used in a MUD file prior to the extensions being registered with IANA (see Extensions Registry, section 16.8.”

Although this text might instead be stating that, “MUD extensions MUST NOT be used in a MUD file unless those extensions are listed in the optional leaf-list ‘extensions’”. A discussion of the value of this leaf list might provide necessary context for this reader to disambiguate.  

2) The “Example-Extension” text of Appendix C was probably meant to indicate "ietf-mud-detext-example” as shown in the example expression lower in the section. 

Is this what you’re getting at? 
I wouldn’t have suggested this change; but I think I can confirm I see how it would work. 

> Separately, who generates the MUD files?  Is it the Manufacturer or someone else?  Section 12.1 doesn't say.  Section 12.2 says that the MUD controller verifies the signature to a known trust anchor, but it's unclear how these TAs became known.  Elsewhere the draft says MUD can provide a means to address some vulnerabilities in devices that no longer supported by their manufacturer, so I'm guessing that it's the latter, not the former.  

no comment.

> Does this introduce a Security risk (degradation attack) of any sort to the brski bootstrapping process?

No. If the manufacturer certificate doesn’t include the MASA URL and it is distributed via MUD files instead then there is no impact on the security considerations for BRSKI. In this context MUD is just another method of configuring the BRSKI registrar to know the MASA server URL. Worst case is misconfiguration which is dealt with securely. 

- max

---

From: Eliot Lear <[email-masked]>
Date: Wed, 27 Sep 2017 19:20:11 +0200

Hi Kent,

> That said, maybe we should challenge the necessity of this field, or at least examine to what end this idea is valid.  First, just to throw it out there, why not also add a "zerotouch-server" field…

As I mentioned in an earlier message, I'm inclined to want to remove
rather than add, and I think it's a reasonable suggestion to remove the
masa-server to an extension that can then be discussed in the ANIMA WG. 
It may interest you to know the reasoning for it being there in the
first place: initially there was no way in the BRSKI draft to find the
masa server, and this seemed like a simple solution.  Now that they have
solved for that separately, I do like the idea of the server being
listed in the MUD file, but as an extension, for the simple reason that
the manufacturer can keep certificates small by listing this in the MUD
file.  I invite you to do the same for a zerotouch-server.

Thanks for calling this out.

Eliot