Eliot Lear <[email protected]> wrote: >>> In either case, right now the administrator has to manually know and >>> populate information, to say - some device 1.2.3.4 is a controller, >>> either for MUD URL https://example.com/mud <https://example.com/mud> or >>> a class http://example.com/mudclass1 <http://example.com/mudclass1>. >>> That can be laborious. To assist, we are examining ways to have a >>> controller declare itself as a candidate controller. That at least >>> provides a hint to the administrator that this particular device is >>> capable of serving in a particular role. >> >> I think that anything that requires administrator activity to be a fail for >> residential use. It's too complex.
> There will ALWAYS be a need for an administrator in the enterprise
> case. But maybe with the options above we can ease the consumer burden
> over time. In the consumer case, you might want an app for initial
> device admission control anyway, no? Can we not rely on that
> interaction as an approval step in this instance?
I think we'd all like to have a generic app (with an RFC standard API) that
can onboard any device and can do admission control for any controller.
I think this is what you are saying as well.
>>> One possibility to address this is to incorporate the new RESTful
>>> endpoint into an ANIMA BRSKI join registrar, which may already be
>>> exposed. But that requires that ANIMA BRSKI be in play, which it may
>>> not.
>> It is, however, a really good idea for the case where it is in play.
>>
>>> My thinking is that we do this work in two stages. First handle the
>>> easy case, which is the MUD file extension, and then figure out how to
>>> do the app version of this.
>>
>>> Thoughts?
>>
>> yes.
>>
> Was that “yes” to the two stage approach?
"Yes" :-)
Eliot Lear <[email protected]> wrote:
>> 1) insist that to user the my-controller connections that the two devices
>> have to be signed by the "same" entity. ["same" could mean literal the
>> same key, the same certificate Issuer/DN, or something more complex]
>>
>> 2) we could have devices declare in an MUD extension the
>> DN/certificate/entity which must sign their controller device.
>>
>> 3) (2) above, but with some level of indirection through some URL.
> Another thought here:
> We could provide a level of dereference for authorized controllers in
> the device’s MUD file, in the form of a URL list that would look
> something like:
> { [
> “controller” : “controller-name"
> “mud-urls” : [ some mud urls of valid controllers here ]
> “include” : “https://levelofindirection.example.com” that points to a
file that contains a JSON serialization of this grouping
> }
yes, this is exactly what I was thinking about.
Would "mud-urls" / "include" be mutually exclusive?
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
