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

"M. Ranganathan" <> Mon, 24 June 2019 16:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6915A1204C3; Mon, 24 Jun 2019 09:03:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id abg1qjBq7vAN; Mon, 24 Jun 2019 09:02:59 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8EF86120369; Mon, 24 Jun 2019 09:02:59 -0700 (PDT)
Received: by with SMTP id s7so97000iob.11; Mon, 24 Jun 2019 09:02:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pTBFoAzsKnuwma825Y6VqljnQr+CSFXhqX8v/IR+QGc=; b=BoambRudgFfYhTOdaOftZq3ClhuzXC5NvLsq5zlaErAFE0DoHsE0kaMeKDegEJQU5s /Oksez+yAv957nMNgsDeIV6IvLVktl/GAckF2UfShb/Sz4LjU0H4Ae+tlOzzSE0CbL1z 46ohDWmd7MruMYPumr8MO2zNPAn/6ptFvw0xd8+3hF7QJ6bKou2Ep5fTJpdKcIgwpEmU YP16QlhV1O892yMJEIIAqADOUaIlgiVES7Uob3RINInmeJZEbDJwKlgGYF9EhfGCUlei WDt9Ulbs2z+otF5I9dro28uhepuAg5AmtWHioRyKZSlWR352IOubT2yp2Hca3w2za1lz HKzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pTBFoAzsKnuwma825Y6VqljnQr+CSFXhqX8v/IR+QGc=; b=HG4Epl0g+zeokcKTE1JvZC6vDnRVd80AFQcUoUUP8TZm/NNm99lMLriQQSPDTum175 7zUg7sG9TzFkMYc6WBUWQZgydCcqBRB7wifu1TEgvG2I/6/83IzVbBgYgXA5vizIJYBn S7pqw1sQaaZKDFAErrKezF8VJ81mQ56dPVT875Qo7zsRKHi+9xnDVe8ZEl3uY0o6rYdf NvAFW3ldwJ0h55z05qT5j7p4Wcq2/wxT16ja8UmtyfciOcHc7wFt5CihiWIpMGAtzXwh c+xHhwM3RJVFDpq4aIw9oLOONM+ijw3YOmn9/nEumWHwd+2Kj27QCGdtusN1SrUOD9bn zp0Q==
X-Gm-Message-State: APjAAAWxvnt+yB591jGN/Yf6o8uC4EzQap++JqjCZFc5FDczRc4fbGBB ezAajgK5n08wUI3meBbQzc4Sud7HxGd6EO9DrDY=
X-Google-Smtp-Source: APXvYqx+VNJAS8cxxQQMysTBt3ccxvSayWqx/JKFv5MVbQ4RuWaWu35sSyEq6b0Y6bCrXEP3QDCldMpguOHZfneLqAI=
X-Received: by 2002:a05:6602:2252:: with SMTP id o18mr3476907ioo.63.1561392178520; Mon, 24 Jun 2019 09:02:58 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: "M. Ranganathan" <>
Date: Mon, 24 Jun 2019 12:02:21 -0400
Message-ID: <>
To: Eliot Lear <>
Content-Type: multipart/alternative; boundary="00000000000027e8e3058c13f2f3"
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: Mon, 24 Jun 2019 16:03:03 -0000

Hi Eliot,

On Mon, Jun 24, 2019 at 5:48 AM Eliot Lear <> wrote:

> 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.  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.

Regardless of whether the app directly calls the MUD manager or the Join
registrar calls the MUD manager, an interface to it would need to be
defined so that the MUD manager can be notified.

A RESTful interface should work fine. Of course the RESTful API should be
secured and based on certificates/HTTPs but that problem has been solved so
does not need to be re-defined here. Of greater concern is that it is
exposed outside the NW infrastructure. However, it does not HAVE to be
exposed -- the same interface can work in either case (i.e. the Join
registrar can use it or the controller  application can use it, with the
recommendation that it SHOULD not be exposed).

As you rightly point out, discovery protocols are dime a dozen so pick a
simple one. Can DNS (SRV record) be defined/used to locate the MUD
manager?  Perhaps it can be sent back in the DHCP response in case the
service needs to be exposed to the application (just thinking out loud).

> 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.

Sounds good.

Regards, Ranga

> Thoughts?
> Eliot

M. Ranganathan