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

[Michael Richardson <[e-mail]>]

Thank you for your interesting draft. I've CC'ed [e-mail] 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 <[e-mail]> 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.