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

[Sávyo Morais <[e-mail]>]

Hi Michael, thanks for your helpful comments.
Please find some notes inline below:

> {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... }


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.

>
> 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.


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.

> 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).

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

> 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.

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".

> 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.


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
> presentation at the IoT WG: I hoping that some of the ISPs would tell me
what
> they are doing for communication among themselves.


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

> ROLIE, SCAPv2, TAXI, STIIX were mentioned from some of the
> 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.

>
> 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.


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.