Subject: Re: [OPSAWG] The future of MUD work

From: tirumal reddy <[email-masked]>
Date: Thu, 1 Aug 2019 20:15:27 +0530

A new WG to focus on MUD sounds like a good idea. Several vendors and ISPs
offer security services to protect home networks, protecting IoT devices in
home networks is one of the key challenges, and MUD can help secure IoT
devices in both Enterprise and home networks and the security solutions in
both these networks are quite different.

Cheers,
-Tiru

On Wed, 31 Jul 2019 at 14:15, Eliot Lear <[email-masked]> wrote:

> On the other hand, it shouldn’t just be me.  It’d be a very small working
> group ;-) If others are interested, they should speak up.
>
> On 30 Jul 2019, at 11:09, Eliot Lear <[email-masked]> wrote:
>
> Signed PGP part
> Hi Joe,
>
> On 29 Jul 2019, at 23:44, Joe Clarke (jclarke) <[email-masked]> wrote:
>
> OpsAWG members and our Ops ADs, it was discussed in opsawg at IETF 105
> that with the amount of MUD work being proposed (and discussions happening
> outside of opsawg) that perhaps MUD should evolve into its own WG.  Some
> cons to this approached were discussed (maybe it would be too heavy-weight
> with a charter, milestones, etc.).  However, I wanted to take this
> conversation to the list so we can close on it publicly.
>
> Speaking as WG co-chair, I am happy to continue to support the MUD work in
> opsawg, but I want to make sure the WG feels compelled to work on it; and I
> want to make sure the full community that is interested in MUD can follow
> and discuss items here.  That said, it was mentioned in 105 that perhaps a
> bigger “on-boarding” set of work would be better served in its own WG.  I
> think if the scope of MUD grows beyond the definition and its extensions
> (as we’ve been seeing the work progress thus far) it might be better served
> in its own WG space.
>
> Thoughts?
>
>
> I think it is probably time for at least one WG to spring from OPSAWG.  We
> didn’t really complete the agenda at the IETF, and a good reason of that
> was MUD.  There are at least four active drafts on that one subject, one of
> which we didn’t really talk about (bw-profile).  For me it’s a matter of
> what can reasonably be coded, tested, and be useful for manufacturers.  In
> as much as we can bring a bit more focus to manufacturers by offering them
> more of a venue for discussion, the additional WG would be welcome.  On the
> other hand, if we find that we’re not making progress, or if we progress
> extensions quickly, we can close the WG and continue the mailing list, and
> move back to OPSAWG.  I don’t see a MUD working group as a long term
> activity (famous last words), but targeted more at producing the necessary
> for broader adoption and then going out of business.
>
> Eliot
>
>
> Joe
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>
>
>
>
>
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 01 Aug 2019 16:45:52 -0400

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   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Warren Kumari <[email-masked]>
Date: Thu, 1 Aug 2019 18:09:24 -0400

On Mon, Jul 29, 2019 at 5:44 PM Joe Clarke (jclarke) <[email-masked]> wrote:
>
> OpsAWG members and our Ops ADs, it was discussed in opsawg at IETF 105 that with the amount of MUD work being proposed (and discussions happening outside of opsawg) that perhaps MUD should evolve into its own WG.  Some cons to this approached were discussed (maybe it would be too heavy-weight with a charter, milestones, etc.).  However, I wanted to take this conversation to the list so we can close on it publicly.

I *personally* believe that a WG focused on MUD makes sense - I think
that there are enough people interested in the topic, and enough work
to make it worthwhile - this will allow us to corral the work into a
single place and allow people interested in MUD to focus on that.
Forming a short lived WG *should not* be a large undertaking -  Yes,
it does require some process wonkery with charters and such, but we
should be able to use the existing work as proof that there is
interest, etc.
If it turns out this is not enough work to justify an entire meeting
slot, we can have a joint OpsAWG / MUD meeting (which I'll agree is
only a marginal change from the current situation :-) ). If, on the
other hand, there is sufficient work for a slot, it will free up time
in OpsAWG and allow OpsAWG to work on other stuff.

Note that these are my personal views - the MUD WG, if it were to be
created, would presumably be on the Management side of Ops & Mgmt, and
so Ignas will have to approve / make the decision.
W

>
> Speaking as WG co-chair, I am happy to continue to support the MUD work in opsawg, but I want to make sure the WG feels compelled to work on it; and I want to make sure the full community that is interested in MUD can follow and discuss items here.  That said, it was mentioned in 105 that perhaps a bigger “on-boarding” set of work would be better served in its own WG.  I think if the scope of MUD grows beyond the definition and its extensions (as we’ve been seeing the work progress thus far) it might be better served in its own WG space.
>
> Thoughts?
>
> Joe

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Fri, 2 Aug 2019 21:16:15 +0000

> On Aug 1, 2019, at 18:09, Warren Kumari <[email-masked]> wrote:
> 

Thanks, Warren.  Presented work aside, there is also a mud@ list, and Michael has posted some work in progress from him that would likely fit.  It could very well be that opsawg would become a MUD WG unless that work is spun out.

> so Ignas will have to approve / make the decision.

This makes sense given what has already been ratified as well as the very strong tie to YANG in a lot of the current WIP.

Joe