Subject: Re: [Mud] [Iotops] Fwd: New Version Notification for draft-morais-iotops-inxu-00.txt

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Nov 2021 04:42:57 -0500

Thank you for your interesting draft. I've CC'ed [email-masked] as well.
{My first dyslexia induced thought is that INXU is close to NIXU, which some
of us know as former Int-Area AD Pekka Nikkander's company... }

There is some overlap here with DOTS.
I'm not an expert on DOTS, so I can't say exactly, but I'm sure that the
whole ISP talks to CPE model is in there.   DOTS is more about offloading the
traffic from the CPE device to the ISP... but according to what criteria, and
this is where the MTD might help.

Minor:
There are some terms that you've used which might be translations which are
uncommon in english: "short team" and also "TCP connection starter"
I think you mean "small team", but I'm uncertain if there is a more subtle
meaning.
I think that "TCP connection starter" probably means "TCP initiator"
(the end that sends the TCP SYN).

I really like your draft.  From what I can tell, your MTD isn't an extension
to MUD, but rather an parallel object which looks very much like a MUD file,
but is provided by an ISP or security team to a CPE to help it deal with an
active attack.

I wrote a document,
https://datatracker.ietf.org/doc/draft-richardson-shg-un-quarantine/ that was
about how a compromised device went back into order.  It turned into a RIPE
presentation at the IoT WG: I hoping that some of the ISPs would tell me what
they are doing for communication among themselves.
  http://www.sandelman.ca/SSW/talks/ripe-iot-unquarantine2019/

ROLIE, SCAPv2, TAXI, STIIX were mentioned from some of the
government/enterprise people, but apparently nobody was doing any of that as yet.

Your work seems to overlap a bit with some of these.

In the above deck, there is an auxiliar slide 51, where you see a "swifter API"
which is essentially your MTD and MTD server.  The SHG project (now defunct, alas)
never implemented that part.

Sávyo Morais <[email-masked]> wrote:
    > This is a draft we are proposing to append a security functionality to
    > MUD (RFC 8520) with a vulnerability management system for IoT networks
    > with a short security experts team.  Hope you will appreciate this, and
    > please let us know about any suggestions, comments or corrections in
    > the document.

    > https://www.ietf.org/archive/id/draft-morais-iotops-inxu-00.html

    > Abstract: This document proposes the Intra-Network eXposure analyzer
    > Utility (INXU) as a vulnerability management solution for IoT networks.
    > The goal of INXU is to extend the functions of the RFC 8520 and support
    > a Security Experts Team on protecting multiple heterogeneous IoT
    > networks, even when there is a few or none private information of the
    > networks.

    >    INXU identifies and analyzes the capability of an IoT device being
    > exploited by an well known malicious activity.  We also propose the
    > Malicious Traffic Description (MTD), a data-model to describe traffic
    > related to malicious activities.

---

From: Sávyo Morais <[email-masked]>
Date: Tue, 23 Nov 2021 11:22:34 -0300

Hi Michael, thanks for your helpful comments.

> of us know as former Int-Area AD Pekka Nikkander's company... }

This was not planned hahahaha, but it can be changed in future draft
updates.
A Fun fact about INXU name is that it makes reference to a wasp that is
common in my region.

> this is where the MTD might help.

I would say they are complementary from what I could see in the DOTS
Requirements (RFC 8612),

INXU is more about managing the risks around well known vulnerabilities,
covering manufacturer's lack of bug fixes, and supporting the devices life
after its end-of-life.

It also fights DDoS, but more by breaking the botnet's gears than by
blocking the outgoing DDoS traffic.
Maybe in this case I could change the Simple Example section.

> (the end that sends the TCP SYN).

A native speaker suggestion always helps :D
I will update both in the text.

> but is provided by an ISP or security team to a CPE to help it deal with
an

Agree with you in the point of extension/parallel, I just did not find a
good way to say that as you did.
Gotta update it.

Regarding the second point, I just need to stress that INXU does not
include the intrusion detection element,
it just looks at the network and says "okay, someone can exploit this, so
please prevent bad things from happening".

> about how a compromised device went back into order.

I can see INXU supporting a kind of partial quarantine in this context.
Also maybe the state update from device-of-interest to suspect.

> It turned into a RIPE

And how was their feedback?
I can also try to do something similar in LACNIC/LACNOG.

> government/enterprise people, but apparently nobody was doing any of that
as yet.

I'll take a look at this, but I guess nobody implemented it due to
potential usability implications.

At least this is my main concern on improving INXU to avoid getting stuck
at home
because someone can scan my door lock.

> never implemented that part.

I have implemented an INXU Module (the module analyzes threats) prototype,
maybe it can be helpful just in case SHG rises from the ashes like a
phoenix.

It is just a draft code running the core of the threat analysis,
but we can go further and implement it into the OpenWRT.