Subject: [Mud] new ways to get MUD files

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Jun 2019 12:53:14 -0400

I've been thinking about the Echo/Home/Mycroft systems of smart speakers, and
how they learn new things via "skills".   This makes it very difficult to
write MUD for them, since they can expand their abilities.
Yet, given the complexity of the devices, they are probably more risks
associated with compromises of such devices.  Mycroft I is ubuntu running on
an RPI.

It seems to me that each skill ought to come with a MUD file.
There are a number of issues:
  1) how does the MUD extension for the new skill get communicated to the
     firewall?

  2) how do we know the new description is legitimate, and not part of the
     attacker's "profile"?

  3) how do we identify which skill a communication is associated with?

  4) how do we engage with these vendors?

My IPv6 take is that each skill should have a different IPv6 address.
This could trivially be done by putting each skill into a container.

If you go that way, then it could work in IPv4 with DHCP+MUD-url within
each skill, but 256 IPs might not be enough for some people, which is why
IPv6 makes it so much easier and obvious.

(*Linux* containers with name spaces, don't have to be split off everything,
just doing the network namespace is enough.  The rest of the system can
be unified)

5) can we communicate MUD URLs without DHCPv6?

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

---

From: "M. Ranganathan" <[email-masked]>
Date: Fri, 7 Jun 2019 13:47:41 -0400

Hello Michael,

Do these new skills result in changes in communication patterns (I don't
know how this works and hence I ask)?

If there were a way to dynamically invalidate an existing MUD file and
register a new one with the mud controller dynamically, would that address
this use case? This could be accomplished as follows:

- Device violates its MUD profile
- Mud Manager gets informed of it.
- Mud Manager contacts manufacturer web site with a log of the events that
lead up to the violation.
- Mud Manager fetches a new profile if appropriate and installs it.

This would require standardizing the interaction and logging / event
notification format to send to the manufacturer so the manufacturer has
enough information to make this decision. Perhaps a subject for discussion.

On Fri, Jun 7, 2019 at 12:53 PM Michael Richardson <[email-masked]>
wrote:

> Mud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mud
>

-- 
M. Ranganathan

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Jun 2019 16:15:11 -0400

> know how this works and hence I ask)?

yes, if you add the "Phillips Hue" skill, then the device can talk to your
light bulbs.

    > - Mud Manager fetches a new profile if appropriate and installs it.

No, it wouldn't because the either new file would not be signed, or you'd
need to N! MUD files for N skills.  And anyone can write a skill, btw.

    > enough information to make this decision. Perhaps a subject for discussion.

I agree that all of these are important, and I want to work on them!
I just don't think that it helps for the smart-speaker.

In case I didn't share my RIPE IoT non-presentation, it is here:
  https://www.youtube.com/watch?v=GOmHx8jpaCM

A different setup, but similar results, would be for a Zwave or Bluetooth
gateway.  As you add new devices (on Zwave, not IP), then the set of
allowable transactions might change.  That's probably far more constrained
than the skills problem, but it still seems like an issue.