From nobody Tue Nov 23 01:43:19 2021 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64003A05E2; Tue, 23 Nov 2021 01:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FL8ibQGIvcs4; Tue, 23 Nov 2021 01:43:08 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E52153A05AA; Tue, 23 Nov 2021 01:43:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id DEEEB1806E; Tue, 23 Nov 2021 04:45:50 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JThDbQmFKBje; Tue, 23 Nov 2021 04:45:45 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DF99A18016; Tue, 23 Nov 2021 04:45:44 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1637660744; bh=NMJPq0g+fphs2xGjICkN6QctT2sjyvq1O8sH69kY/VU=; h=To:Subject:In-reply-to:References:From:cc:Date:From; b=YNPYuRzCaHJP14FDGIIT0pud92l0cE1p7m6UEDfv3HbExBaC2EJvwGUx8F1kw7fN9 duYIssEFGO67tIInNobSCN8OC3rwObT3l76GW2fEB127CvK9pk3WPqSbC/jHA5q7iB jUk3hP/zJJyKL1kHEtp1skpBLQGnLk3B4xe4p4i8P0h9cb3usfraHFHFjXYTIZNVpt CMzxUDhgixZDj7JsJe0pGDgCu/FxuVoFhCVVptc0oUEKDaYp5aYxQO8fYqvQRfWGf5 VLefzPjMkBlsaeqIP6dLfGfdJYUPHpDOCLeIENJK6QIatd5UZvsHN6Q83KNQZOnFnM 5PHbPSqZIGIvw== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 979E9128B; Tue, 23 Nov 2021 04:42:57 -0500 (EST) To: =?us-ascii?Q?=3D=3FUTF-8=3FQ=3FS=3DC3=3DA1vyo=5FMorais=3F=3D?= , iotops@ietf.org, mud@ietf.org In-reply-to: References: <163759345909.25982.6148538891904763496@ietfa.amsl.com> Comments: In-reply-to =?us-ascii?Q?=3D=3FUTF-8=3FQ=3FS=3DC3=3DA1vyo=5FMora?= =?us-ascii?Q?is=3F=3D?= message dated "Mon, 22 Nov 2021 12:14:45 -0300." X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3 From: Michael Richardson cc: iot-wg@ripe.net X-Attribution: mcr X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Mud] [Iotops] Fwd: New Version Notification for draft-morais-iotops-inxu-00.txt X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2021 09:43:14 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thank you for your interesting draft. I've CC'ed mud@ietf.org 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 t= he traffic from the CPE device to the ISP... but according to what criteria, a= nd 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 w= as 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 wh= at 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 a= s 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=C3=A1vyo Morais 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, a= nd > 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 network= s. > The goal of INXU is to extend the functions of the RFC 8520 and suppo= rt > 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. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmGct6EACgkQgItw+93Q 3WV+4QgAuxf0j1XhuB/Qfy6LuoUAI86QRqox+BlFysdiUfWM3FOKUHo32iMNk4AB Srlfk6/FL9F3+7BW578YZRAGuIAHS9m/aB1LXrfLaRPXt214a7cgbYHXtwhYCvLM QwthPL/C7VcEv4QuWaMsIFjZPkZRP4ef/lF/4NJ7oIiBDMOvYrrxLSmYpbrl6b3R 1Fm5hD+OtKnQgKnHeTduamseRdsFGhwmluPD9SWbsnFjlPEVCDx8JX7y2qpRfaV1 4bdSeu7nLGVch4aXUJDS6i2Ah/ZqF9sJ1etYPNJb3KAj8xZZXzCe5G06RxAFlceE Q3IKiaD6yv0wKF9Ch12Vf5eT9O75fg== =ip9D -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 23 06:23:01 2021 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF26A3A0855; Tue, 23 Nov 2021 06:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlAnMcq1q-ub; Tue, 23 Nov 2021 06:22:49 -0800 (PST) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9F9F3A0851; Tue, 23 Nov 2021 06:22:48 -0800 (PST) Received: by mail-wm1-x336.google.com with SMTP id n33-20020a05600c502100b0032fb900951eso2410956wmr.4; Tue, 23 Nov 2021 06:22:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/qG++dPF6/cNCcYM1BGKnJk0oYPXbSr4WGd30YwypR8=; b=MAoUBUYn7WymcJaoVSzzypcpI3Zehx0yXJg1U/+gWGORe1oXJZO0eEmERD30OvzMTh LVrlqd8oCHJp8gR8dO6EZjN7yjV7f94/ksWP4H0Cw7WW9NpUzMCYn7DxKjrS99oTDfii UnCgLNWQKCVAjnEGXJsI3Qmd7Wt3JREw4u76b7ZsRdbhT2z/ibaDlSfgAcUFw1+a/+ds gZ77VFS2g9I673LQuqpsVzxJh33FbJa0hdTMTfL1pOP/j4/4h2v8oZ2RDbI6lgH6U2kZ XMwVOA1MpWK5NvZLA4/922eZk5VXjXfy4+SZnEUEfXCifAfCxHRhzFoC6wgjsl3w9UUA Sngw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/qG++dPF6/cNCcYM1BGKnJk0oYPXbSr4WGd30YwypR8=; b=h/D3evpz8s9SO2/7JHHuedDONwpgjsDMVeOJPTmTRIIyVf8p5JpQr7CsK3AkEaBki/ O71IEsU5C7DGw7uUamAx59BhYs6jKMKbOTUag4nFmcRQs1VYNjSF1nuGssPYFBsHV6Ly Um/6/y7oYDKNBTvWikHnohJALuy0xDCoWAInp4+YDHeRxquMGnYQRnIBmz4Hg99mkH7P aoInulwln6eeS3YKCPz+ffThA9T3S00f6JZZyYSDVMbH4owzB6GdrLvxBF5mlqYE5iNE 1WOFc1NRGu/8RMxKpjOMk2aiqwMIvsWjS/NZ78l7tUg8fMHz7aATDjnw1GN+xQySDj4m V3pA== X-Gm-Message-State: AOAM533FLl3DsoAuFBCBsmLYp7h/4rELYwXzTFWS60KEzMcdXKYgGM8m B5p91vsKY7YxdosdLLnWT80UNQ0bMfl0WbVkBGg= X-Google-Smtp-Source: ABdhPJw+S08/tmKX3Q4OA+z4xeN9MT9Zh/ouyXUCpqHqCszQp+wZ9lgNeVC22pi7LL6QGRk5Br2H5vgrdKDLbD0c09s= X-Received: by 2002:a05:600c:3541:: with SMTP id i1mr3850223wmq.124.1637677365948; Tue, 23 Nov 2021 06:22:45 -0800 (PST) MIME-Version: 1.0 References: <163759345909.25982.6148538891904763496@ietfa.amsl.com> <11174.1637660577@localhost> In-Reply-To: <11174.1637660577@localhost> From: =?UTF-8?Q?S=C3=A1vyo_Morais?= Date: Tue, 23 Nov 2021 11:22:34 -0300 Message-ID: To: Michael Richardson Cc: iotops@ietf.org, mud@ietf.org, iot-wg@ripe.net Content-Type: multipart/alternative; boundary="000000000000a7786b05d175798b" Archived-At: Subject: Re: [Mud] [Iotops] Fwd: New Version Notification for draft-morais-iotops-inxu-00.txt X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2021 14:22:54 -0000 --000000000000a7786b05d175798b Content-Type: text/plain; charset="UTF-8" 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. --000000000000a7786b05d175798b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Michael, thanks for your helpful comments.
Please fi= nd 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 abou= t INXU name is that it makes reference to a wasp that is common in my regio= n.
=C2=A0
>
> 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. =C2=A0 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 he= lp.


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

INXU is more about managing the ri= sks 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 b= locking the outgoing DDoS traffic.
Maybe in this case I could change the= Simple Example section.

> Minor:
> There are some terms th= at you've used which might be translations which are
> uncommon i= n english: "short team" and also "TCP connection starter&quo= t;
> I think you mean "small team", but I'm uncertain i= f there is a more subtle
> meaning.
> I think that "TCP co= nnection starter" probably means "TCP initiator"
> (th= e end that sends the TCP SYN).

A native speaker suggestion always he= lps :D
I will update both in the text.

> I really like your dr= aft.=C2=A0 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,<= br>> 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 exten= sion/parallel, I just did not find a good way to say that as you did.
G= otta 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-r= ichardson-shg-un-quarantine/ that was
> about how a compromised d= evice went back into order.


I can see INXU supporting a kind of = partial quarantine in this context.
Also maybe the state update from dev= ice-of-interest to suspect.
=C2=A0
> It turned into a RIPE
>= presentation at the IoT WG: I hoping that some of the ISPs would tell me w= hat
> they are doing for communication among themselves.


A= nd how was their feedback?
I can also try to do something similar in LAC= NIC/LACNOG.

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


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

At l= east this is my main concern on improving INXU to avoid getting stuck at ho= me
because someone can scan my door lock.
=C2=A0
>
> In t= he above deck, there is an auxiliar slide 51, where you see a "swifter= API"
> which is essentially your MTD and MTD server.=C2=A0 The = SHG project (now defunct, alas)
> never implemented that part.

I have implemented an INXU Module (the module analyzes threats) protot= ype,
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 an= alysis,
but we can go further and implement it into the OpenWRT.
--000000000000a7786b05d175798b--