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 =-
- [OPSAWG] The future of MUD work Joe Clarke (jclarke)
- Re: [OPSAWG] The future of MUD work Michael Richardson
- Re: [OPSAWG] The future of MUD work Eliot Lear
- Re: [OPSAWG] The future of MUD work Eliot Lear
- Re: [OPSAWG] [Mud] The future of MUD work Ted Lemon
- Re: [OPSAWG] The future of MUD work tom petch
- Re: [OPSAWG] The future of MUD work tirumal reddy
- Re: [OPSAWG] The future of MUD work Michael Richardson
- Re: [OPSAWG] The future of MUD work Warren Kumari
- Re: [OPSAWG] The future of MUD work Joe Clarke (jclarke)