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

["Max Pritikin (pritikin)" <[e-mail]>]

> On Sep 26, 2017, at 2:17 PM, Kent Watsen <[e-mail]> wrote:
> 
> 
> 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-server?
> 
> 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?

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 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.
> 
> 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.
> 
> 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 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.
> 
> Yep, this is what I thought you might say.  Yes, it may not be clean, but it should be understood, right?

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

> 
> 
> Thanks,
> Kent
> 
>