[OPSAWG] extending/amending IPFIX for MUD unquarantine work

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 01 August 2019 21:12 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95048120128; Thu, 1 Aug 2019 14:12:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 QUi88-mxjbtt; Thu, 1 Aug 2019 14:12:05 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 271031200F7; Thu, 1 Aug 2019 14:12:04 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E57A23818D; Thu, 1 Aug 2019 17:11:35 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9EE9680; Thu, 1 Aug 2019 17:12:03 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: iot-wg@ripe.net, opsawg@ietf.org
cc: mud@ietf.org
In-Reply-To: <CAFpG3gfWDMctjTRta7sqhRo8Prp1M+riTHAS69HAHE8EN3i0RA@mail.gmail.com>
References: <12332.1564605651@localhost> <CAFpG3gfWDMctjTRta7sqhRo8Prp1M+riTHAS69HAHE8EN3i0RA@mail.gmail.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
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<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Thu, 01 Aug 2019 17:12:03 -0400
Message-ID: <12418.1564693923@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/8woOk29jqhUjDE1Nv2mGLx5Nh5A>
Subject: [OPSAWG] extending/amending IPFIX for MUD unquarantine work
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Aug 2019 21:12:08 -0000

I want to introduce the IETF OPSAWG to some MUD related work that I started
in the spring.  After some discussion about an appropriate place for this
work, I realized that this is primarily aimed at Operators, and I primarily
want feedback from those who want to do this.
I also realized in March that was I was building a playbook, and that the
IETF CACAO (BOF) work might want to use some of this as requirements, but
that BOF didn't continue.

So the plan is to do this mostly in the RIPE IoT-WG, with the document
providing recommendations (BCP), and also gap analysis feedback to many
places, including the IETF.

The talk I was going to do at RIPE78 did not happen due to a short agenda.
I had done a screencast; it got cut off 94% through due to a full /var/tmp,
but I decided that was good enough.  The slides and video are below.
My thanks to Kathleen Moriarty who walked me through some of the
ROLIE/STIIX/MISP stuff that I know very little about.

The first step of the Secure Home Gateway/MUD-Controller to ISP/operator link
is when an IoT device violates it's MUD profile.  My document contemplates
two stages of pergatory on the assumption that MUD ACLs will initially be
not that reliable, and what we do not want to do is to train end users to
click through warnings.

This requires some kind of "three strikes" and you are out kind of system,
and to make that work, well, to continue the Baseball analogy, we need an
umpire.  The ISP/network-operator will need to do that, and that means that
they need to get data on what is going wrong.  Which devices are doing what,
and how often, and this needs to be in enough detail to corelate across
customers.  And the data needs to be pseudo-nonymized and expunged against
the eventual database breach or LEA action.

IPFIX seems to be the right protocol for this.  Tiru says they already use it.
It will need some significant extra security/management layer to provide for
automatic enrollment.

Also needed is some kind of feedback to the MUD controller as to how
significant this event currently is, and whether futher quarantine is
waranted or whether to expect an updated MUD file.   It has been suggested
that this part of the first step is a place for DOTS.

The document is in your nearest Internet Draft archive as:
    draft-richardson-shg-un-quarantine-00

and the github is at:
     https://github.com/CIRALabs/shg-un-quarantine

including the slides in fodp and pdf format (with the animations expanded) in
the "presentations" folder.

The screencast/video is at:
   http://junk.sandelman.ca/junk/unquarantine-RIPE-talk.ogv
   https://youtu.be/GOmHx8jpaCM



--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-