Re: [OPSAWG] Declaring something to be a controller in MUD

Qin Wu <> Tue, 02 July 2019 01:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0045F12018D; Mon, 1 Jul 2019 18:44:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JpPeIl00wdA3; Mon, 1 Jul 2019 18:44:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 54D4A12018B; Mon, 1 Jul 2019 18:44:51 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 22FCA158CD8675AA82B9; Tue, 2 Jul 2019 02:44:49 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 2 Jul 2019 02:44:48 +0100
Received: from ([]) by ([]) with mapi id 14.03.0415.000; Tue, 2 Jul 2019 09:42:21 +0800
From: Qin Wu <>
To: Eliot Lear <>
CC: "" <>, "" <>
Thread-Topic: [OPSAWG] Declaring something to be a controller in MUD
Thread-Index: AdUwdNms2CQ7NqnHSFy07TtU1rh0VQ==
Date: Tue, 2 Jul 2019 01:42:20 +0000
Message-ID: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAA49BD98Ankgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [OPSAWG] Declaring something to be a controller in MUD
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Jul 2019 01:44:55 -0000

Look like your solution requires controller device and the light bulb discover each other, so that IoT devices can discover each other in in an autonomic network,
It is not clear how is controller device URL correlated with light bulb URL through RESTFUL interface and ietf-mud-controller-candidate module and ietf-mud module?
Advertise controller device URL to all light bulbs, and then light bulb select appropriate controller device URL and correlate its URL with controller device URL.

Controller device select a set of light bulb it can control and manager and maintain the binding between controller device URL and light bulb URL.
How to revoke the binding between controller device URL and light bulb URL when light bulb select other controller device or be turned off?

发件人: Eliot Lear []
发送时间: 2019年7月1日 18:26
收件人: Qin Wu <>
主题: Re: [OPSAWG] Declaring something to be a controller in MUD

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.


On 1 Jul 2019, at 10:23, Qin Wu <<>> wrote:

发件人: Eliot Lear []
发送时间: 2019年7月1日 15:52
收件人: Qin Wu <<>>
主题: Re: [OPSAWG] Declaring something to be a controller in MUD

On 1 Jul 2019, at 09:20, Qin Wu <<>> wrote:

发件人: OPSAWG [] 代表 Eliot Lear
发送时间: 2019年6月24日 17:48
主题: [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 is a controller, either for MUD URL or a class  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.


 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.