Qin and others: Just to get the ball rolling, I’ve posted today draft-lear-opsawg-mud-controller-candidates-00.
I think this should help the discussion. Eliot > On 1 Jul 2019, at 10:23, Qin Wu <[email protected]> wrote: > > 发件人: Eliot Lear [mailto:[email protected] <mailto:[email protected]>] > 发送时间: 2019年7月1日 15:52 > 收件人: Qin Wu <[email protected] <mailto:[email protected]>> > 抄送: [email protected] <mailto:[email protected]>; [email protected] > <mailto:[email protected]> > 主题: Re: [OPSAWG] Declaring something to be a controller in MUD > > > > > On 1 Jul 2019, at 09:20, Qin Wu <[email protected] > <mailto:[email protected]>> wrote: > > 发件人: OPSAWG [mailto:[email protected] <mailto:[email protected]>] > 代表 Eliot Lear > 发送时间: 2019年6月24日 17:48 > 收件人: [email protected] <mailto:[email protected]>; [email protected] > <mailto:[email protected]> > 主题: [OPSAWG] Declaring something to be a controller in MUD > > Hi everyone, > > A few of us are just trying to put out an initial draft that addresses one > gap in MUD (there are several). In a MUD file one can say that one wants to > access a controller in two ways: either "my-controller” meaning a controller > that services devices of a particular MUD URL or a “controller” class that > services devices based on a particular class name of controller. > > 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. > > [Qin]: Since MUD in RFC8520 has already specify DNS extension and DHCP > extension, why not configure MUD manager with controller’s declaration? So > the RESTFUL interface can be defined between NMS and controller, if my > understanding is correct. > I believe this is network initiated solution, you might have client initiated > solution, but probably more complicated than network initiated solution. > > Can you say a few more words? I’m not sure I’m quite following you. > [Qin]: What I am suggesting is NMS preconfigures the MUD manager with > controller’s declaration information, during DHCP process or DNS process, the > controller’s declaration can be returned > To the router or switch between the thing and MUD manager or return to the > thing, the router or the thing can access controller through controller > delclartion. > > If the MUD manager also needs to be advertised to the thing, DHCP Discovery > or DNS process can be leveraged. In this case, NMS needs to preconfigure DHCP > server with MUD manager information. > > Eliot > > > That at least provides a hint to the administrator that this particular > device is capable of serving in a particular role. > > To make that declaration, the device must- > Form the declaration; > Find the MUD manager; and > Send it. > > Forming the declaration is easy: we can make this a YANG grouping and then > place it in various spots. > > Finding the MUD manager depends on one question: > Was the device built to be a controller or is it a general purpose device > that has an app that is intended to be a controller? > > If the device was built to be a controller, we can simply cram the > declaration into that devices own MUD file as an extension. If the device is > a general purpose computer, things get a bit more interesting. In this case > we have two choices: > > Either create a MUD file that points somewhere internally - this doesn’t seem > very plug and play. > Make the declaration directly to the MUD manager. > > I’m going to focus on the latter for the moment. It is easy enough to create > a RESTful interface for this purpose, but it requires a mechanism to > discovered the MUD manager, which up until now has been an internal part of > the network infrastructure. > > Let me call this out plainly: letting the app itself directly call the MUD > manager requires that the MUD manager itself become exposed to the user > infrastructure, which is a change. > > 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. > > 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? > > Eliot >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
