[OPSAWG] Declaring something to be a controller in MUD

Eliot Lear <lear@cisco.com> Mon, 24 June 2019 09:48 UTC

Return-Path: <lear@cisco.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 422EF12013A; Mon, 24 Jun 2019 02:48:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WaHe5FTt2DPK; Mon, 24 Jun 2019 02:48:33 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 215A3120033; Mon, 24 Jun 2019 02:48:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7756; q=dns/txt; s=iport; t=1561369712; x=1562579312; h=from:mime-version:subject:message-id:date:cc:to; bh=NQ4Kod0mJ1nykm9I2TrznMRBxJ80VrOxcUrzd8QT+uQ=; b=Cyge7XiM/i5h7hsftVUunpUohULtVjcDUe0q0DN64ZG9Onztx771Lfzh fTOKl3iQPsCRnMtkTmYJbic4umJcccVCYMSx4AB6ovqsFsWmCgOJQUIeH 1HBLgqqkWPtrMTIGUGLPOjE1RImuYe9PZnP8/sNPSvNwXEJK2qztDw5I8 Q=;
X-Files: signature.asc : 195
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BXAADYmxBd/xbLJq1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZ4MBUQEgEiGEHYh7nm+HfQIHAQEBCQMBAR8QAQGEQIMMOBM?= =?us-ascii?q?BAwEBBAEBAgEFbYo3DIV0UQVdAmCDNAGCCgijJoExihwQgTSBUYokgX+BOB+?= =?us-ascii?q?CHoNChHgygiYEi3iHbluVSAmCFgOCG4EJgyaNFRuDE4oFii+NJoZZVoF1glG?= =?us-ascii?q?IBoMIAgQGBQIVgWchgVgzGggbFWUBgkIINYIKg2mKVT0DkGABAQ?=
X-IronPort-AV: E=Sophos;i="5.63,411,1557187200"; d="asc'?scan'208,217";a="13528813"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jun 2019 09:48:30 +0000
Received: from [10.61.230.12] ([10.61.230.12]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x5O9mT5k027185 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 24 Jun 2019 09:48:29 GMT
From: Eliot Lear <lear@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_75954778-D2D0-4E16-AEA7-02E72DB2FF46"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-Id: <1FDE5A58-569B-47FD-8C24-435D78F8A3B2@cisco.com>
Date: Mon, 24 Jun 2019 11:48:28 +0200
To: opsawg@ietf.org, mud@ietf.org
X-Mailer: Apple Mail (2.3445.104.11)
X-Outbound-SMTP-Client: 10.61.230.12, [10.61.230.12]
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/N21M3Gv2ByZjvMcg5Ra0xKw4fTM>
Subject: [OPSAWG] Declaring something to be a controller in MUD
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jun 2019 09:48:35 -0000

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