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? > 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), 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? 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 _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
