Hi Henk,
On 8/30/17 6:50 PM, Henk Birkholz wrote:
> Hello Eliot,
>
> thank you for your fast feedback! I still have some comments and
> questions for another round, though. I hope that is okay - please see
> comments in-line.
Soon, please.
>
>> Ok, but a cautionary note: this draft intentionally focuses NOT on
>> giving the Thing guidance but on giving the *network* guidance. That
>> isn't to say that Things couldn't derive guidance from extensions to the
>> model (we'll talk about that below), but at the moment, the pain point
>> is protecting them.
>
> This has to be clearly stated in the abstract and the introduction, I
> think. From my point of view, filter rules that are disabler and
> enabler of communication are a very specific subset of imperative
> network guidance, which are a distinct subset of the the usage
> descriptions a manufacturer would want to provide for a thing.
>
Taken together with Robert's comments, I'm proposing the following changes:
The abstract:
OLD:
> This memo specifies a component-based architecture for manufacturer
> usage descriptions (MUD). This includes 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.
NEW:
> 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.
> Maybe an example on how to include a trivial non-ACL-focussed
> extension into the module via an (exemplary/bogus) augment would
> clarify how to include "other" content in a MUD file. A corresponding
> example of a JSON instance (MUD file) that then includes content
> defined by the augment would also be beneficial, I think.
>
> Would that be okay?
>
Ok, with the understanding that it is illustrative. Someone who shall
remain nameless for just the moment talked about an indicator as to
whether DETNET is used. I've done that, complete with serialization for
the new draft. Ironically for brevity purposes, I will not include it
here ;-)
>>
>> On the second point, one reason for referencing information is so that
>> the underlying information can change as needed without the need to
>> change the URL itself. While it may be possible in some instances to
>> update the URL, this will not always be the case. Consider that the
>> URL may be inside a signed certificate that is burned into the device.
>> This having been said, we leave open the possibility that the MUD
>> controller may wish to modify the URI through "extras". See below for
>> more details.
>
> Please also consider that the URI can be composed. Most of its parts
> (segments, etc.) are probably represented redundantly in a DevID or
> can be inferred from context (MUD controller, domain, etc.). For
> example, you could get the content of most of the segments out of the
> attributes that are already stored in the DevID and just include the
> "missing additional parts" in a specific "mud-attribute". This is
> possible, because there is a precise rule how to compose the MUD URI
> canonically. Next to "arcance content" and unnecessary verbose
> encoding, redundancy inside Identity Documents is a problem the
> constrained-node network world is struggling with.
>
> Also, this "burning in" is only effecting content of URI path segments
> that are to be defined by the manufacturer. If there would be a
> canonical tree of paths coming after the
>
>> "/.well-known/mud/" mud-rev "/" model
>
> e.g. a set of paths segments/branches, such as
>
>> "/" acl|rim|composition
>
> then there would be no problem to provide semantic separate MUD files,
> because it would be the canonical URI where to find them -
> circumventing the "burned into the device" issue. You only need to
> find the "burned in" values to compose your canonical MUD URI. A task
> presumably conducted by the MUD controller. Would that be correct?
>
Right. We discussed this in the working group, and substantial issues
developed, mostly around versioning. On the whole we must be very
cautious in these circumstances around composibility, especially when it
introduces either linkage or complexity. This, to be sure, is a tradeoff.
{{json readability discussion elided}}
>
>>>
>>> In the scope of the extensibility feature highlighted, is it intended
>>> that every MUD file must contain content that relates to the structure
>>> of a YANG module (or are there other data models for data at rest
>>> planned for)?
>>
>> If the extension augments the YANG module then, well, yes ;-) On the
>> other hand, if the extension is a reference to something else, then the
>> rules are up to that "something else". Let's take an example. Suppose
>> there is an extension that points to some form of WoT/schema.org-based
>> description. That description could be in the form of a URN, that a
>> network might use to populate a CoAP resource directory, that other
>> Things could then retrieve. The rules for the form of all of that would
>> be well outside the scope of MUD, which would be a good thing, because I
>> just referenced a bunch of stuff that you know a lot more about than I
>> do ;-) All the encoding rules and semantics are left to you to define.
>> At that point, a network management system would have to obey your
>> semantics if the device wants want to play.
>>
>> If you like the above text, we could add something like it.
>
> Yes please. I actually thought that this was out-of-scope at the moment.
>
As it happens, we have something of a good example of how that might be
done, already in the draft. It's the masa-server node. There we don't
attempt to define all the semantics of BRSKI, but instead simply
reference the work. One could easily do that again as an extension.
Therefore, I propose the following text:
OLD:
> This optional leaf-list names MUD extensions that are used in the MUD
> file.
> Note that NO MUD extensions may be used in a MUD file prior to the
> extensions
> being declared. Implementations MUST ignore any elements in this file
> that
> they do not understand.
NEW:
> This optional leaf-list names MUD extensions that are used in the MUD
> file.
> Note that NO MUD extensions may be used in a MUD file prior to the
> extensions
> being declared. Implementations MUST ignore any node in this file that
> they do not understand. The extensions list MUST appear prior to
> extension use.
>
> Note that extensions can either extend the MUD file as described in
> the previous paragraph, or they might reference other work. A good
> example of how this might be done is the masa-server URI that is
> defined in the base model. We say nothing about the semantics of that
> work here, but rather leave that to the underlying specification found in
> {{I-D.anima-bootstrapping-keyinfra}}.
{{snip}}
>>> "extras" is intended for use by the MUD controller to provide
>>> additional information such as posture about the Thing to the MUD file
>>> server. This field MUST not be configured on the Thing itself by a
>>> manufacturer - that is what "modelinfo" is for. It is left as future
>>> work to define the full semantics of this field.
>
> Could you please provide an example of "posture about the Thing" that
> could be requested as an option from the MUD file server by the MUD
> controller? I am still not really sure what to make of it. If this is
> future work in the scope of this draft, we can just revisit this at a
> later point.
Sure. Think about NEA values as parameters (RFC 5209) as an example.
>
>>
>>>
>>> ### Signing MUD files
>>>
>>> The given openssl example basically allows for every kind of
>>> certificate- or key-type. Is that intentional? While most individuals
>>> will be able to inflate "mancertfile" or "mankey" to manufacturer
>>> certificate and manufacturer key, respectively, I strongly recommend
>>> to provide more guidance here - especially in regard to command
>>> parameters and appropriate hash and cipher algorithms with a low
>>> footprint. Providing examples here will be beneficial (maybe ECDSA &
>>> EDDSA).
>>
>> Keep in mind that the signature is intended to be consumed by a MUD
>> controller. This having been said, I'll examine this and see if we can
>> add guidance.
>
> In general, the MUD controller might benefit from canonical guidance
> what signature to expect and how to verify it. Because, as it seems to
> be at the moment, the manufacturer decides on this, right? Could
> getting this information be one of the uses of the extra query?
I'm not particularly comfortable with that for a few reasons, the first
of which is that this seems like a possible downgrade attack, should the
device specify weak algorithm choices, and the second is that CMS is
already self-contained. Again, let's ponder your original point a bit.
Eliot
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
