Re: [OPSAWG] The future of MUD work

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 01 August 2019 20:45 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 0710112022B; Thu, 1 Aug 2019 13:45:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 cZdYSwDBkmIR; Thu, 1 Aug 2019 13:45:54 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90CEA1201BB; Thu, 1 Aug 2019 13:45:54 -0700 (PDT)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 9C8C9380BE; Thu, 1 Aug 2019 16:45:24 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5FF7D8EF; Thu, 1 Aug 2019 16:45:52 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "opsawg@ietf.org" <opsawg@ietf.org>, mud@ietf.org, "ops-ads@ietf.org" <ops-ads@ietf.org>
In-Reply-To: <CAFpG3gebHt37JY6+C6DfpRgV++J239EF0zNnm_oTPOWTDHha5g@mail.gmail.com>
References: <D9AF7D6E-7434-4AE4-A2A5-26CD52C2FE20@cisco.com> <849DED7F-6701-4B26-9645-0B076A224C05@cisco.com> <DC608C90-ADBE-4D31-A226-D441F784D5E4@cisco.com> <CAFpG3gebHt37JY6+C6DfpRgV++J239EF0zNnm_oTPOWTDHha5g@mail.gmail.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Thu, 01 Aug 2019 16:45:52 -0400
Message-ID: <6514.1564692352@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/p8szgSF7WCTfq-CE_aJsBR89iqc>
Subject: Re: [OPSAWG] The future of MUD work
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: Thu, 01 Aug 2019 20:45:57 -0000

This is my list of MUD work.  This is what I'm already active in, or which I
expect to start documents soon.  I have not included documents that others
are writing!

1) title: Manufacturer Usuage Description for quarantined access to firmware
   docname: draft-richardson-shg-mud-quarantined-access-00

2) title: A standard process to quarantine and restore IoT Devices
   docname: draft-richardson-shg-un-quarantine-01
   NOTE: I expect this document to go through RIPE IoT WG.
   I expect this document to provide a GAP ANALYSIS

3) title: MUD processing and extensions for Secure Home Gateway Project
   docname: draft-richardson-opsawg-securehomegateway-mud-00
   Informational document, may not need to be published.

4) Operational considerations for using DNS names and IP literals in IoT devices
   (planned. Not sure how to fit MUD into the title yet, but this is driven
   my the constrained that MUD needs)
      -> will need to reference draft-reddy-dprive-bootstrap-dns-server
         which we hope to get into DPRIVE WG soon.
      -> but otherwise, it's a BCP that will emphasis certain things
         that BEHAVE probably started.

5) (planned) CAPPORT extensions for signaling quarantine status to IoT
devices

6) (planned) A profile of IPFIX to carry anonymized telemetry from
   MUD controllers to Network Operators.
   [there was also discussion about sending it to manufacturers]
   [this grows out of {2}]


==== Other NON-MUD related IoT work that I see/have started ====

7) draft-ietf-6tisch-dtsecurity-zero-touch could be without a WG if 6tisch shuts
   down very soon.

8) (planned) BRSKI adaptions for use with Cloud Registrars
   [may instead be a profile of RFC8572]
   [this grows out of ACME-integration discussion, btw]

9) Extensions to BRSKI to carry device/firmware attestion artifacts(claims)

{clearly, I can't do all of these things alone}

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [




--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-