On Thu, Nov 28, 2019 at 10:05:47AM +0100, Michael Richardson wrote: > > Jaime Jiménez <[email protected]> wrote: > > here is the draft in case you wanna have a look, it's just 8 pages. > > https://jaime.win/draft-coap-mud/ > > Thank you for pointing me at it. > I'm replying to the opsawg list.
Thanks, the draft is still work in progress and I have not yet submitted it to T2TRG, which is its final intended destination. As per the feedback I have gotten so far, it seems like an interesting topic but might require a bit more "cooking". Specially the justification as to why this is needed, the motives I explain so far do not seem to be sufficiently convincing. > > > Overall a MUD is emitted as a URL using DHCP, LLDP or through 802.1X, then > > a Switch or Router will send the URI to some IoT Controlling Entity. That > > Entity will fetch the MUD file from a Server on the Internet over HTTP > > [RFC8576]. > > It might be worth adding that it can be emitted in an IDevID using BRSKI. > That uses the same certificate extension as in 802.1X. > draft-ietf-anima-constrained-voucher/draft-ietf-6tisch-dtsecurity-zerotouch > is more likely to have been used if we are getting to CoAP. Yes, that is something that should be considered. I was also discussing with others on how Neighbor Discovery (ND) would apply, as it is more common than DHCP in the very constrained space. > > There is an open question in the MUD space as to whether the MUD signature > URL is absolute or if it can be relative. This affects how the signature > file will be found when using a self-hosted MUD file as you have described. > > The signature should NOT be signed by the Thing itself, as that provides no > security against malware. So that also gets in the way of the device > providing any kind of dynamic capability by changing it's MUD. > The device *could* select from a palate of MUD files which the manufacturer > has signed. That would be very interesting. The whole security part is very raw at the moment, I have not thought in detail how that would work in practice. > > 4.1. Serialization > TBD write about SenML/CBOR MUDs. > > Are you thinking that we could serialize the YANG to CBOR instead of JSON? > I'm mostly for that, but I think that in general, since the ACLs will get > enforced by a non-constrained device, and we can host the MUD files on a > manufacturer resource, that it might be enough that it's JSON+CMS. on the > other hand... CMS. Ick. I am just assuming that the device will serialize everything in SenML/CBOR and not use YANG at all. > > Also using udf:// URLs from mathmesh would mean that the MUD file could be > found via any cachable mechanism, with the communication with the > manufacturer only if no other way is fine. This also authenticates the file, > but not quite in the same way that the signature does. Very interesitng, I am not familiar with udf:// either, I guess it does still require an IP address to be usable, right? > > > > -- > Michael Richardson <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
