[Cacao] playbooks for ending-quarantines of residential IoT devices
Michael Richardson <mcr+ietf@sandelman.ca> Sun, 31 March 2019 01:16 UTC
Return-Path: <mcr@sandelman.ca>
X-Original-To: cacao@ietfa.amsl.com
Delivered-To: cacao@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A02120046 for <cacao@ietfa.amsl.com>; Sat, 30 Mar 2019 18:16:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 9RSG-Mnd69Fy for <cacao@ietfa.amsl.com>; Sat, 30 Mar 2019 18:16:50 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C5A312002E for <cacao@ietf.org>; Sat, 30 Mar 2019 18:16:50 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [209.171.88.16]) by relay.sandelman.ca (Postfix) with ESMTPS id 7A1A01F45B for <cacao@ietf.org>; Sun, 31 Mar 2019 01:16:48 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id C636423BF; Sun, 31 Mar 2019 03:16:52 +0200 (CEST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: cacao@ietf.org
X-Attribution: mcr
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Sat, 30 Mar 2019 21:16:52 -0400
Message-ID: <11776.1553995012@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cacao/LXA7SFg8Dkf5KYfM1Y2ymrfmi0k>
Subject: [Cacao] playbooks for ending-quarantines of residential IoT devices
X-BeenThere: cacao@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Collaborative Automated Course of Action Operations <cacao.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cacao>, <mailto:cacao-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cacao/>
List-Post: <mailto:cacao@ietf.org>
List-Help: <mailto:cacao-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cacao>, <mailto:cacao-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 31 Mar 2019 01:16:52 -0000
I came to the CACOA BOF because I think going to BOFs is a good way to find out if the work is relevant to me. I didn't think it was going to be... until... In the SecureHomeGateway (SHG) work at CIRALabs with MUD-based firewalling, we came across a proceedural problem: once we have identified a device as contravening the policy, and we quarantee it, then what? I know now that what I'm lacking is a playbook that can be executed typical residential user (which for sexist and agist reasons seems to always be someone's grandmother). Feedback that the Canadian Multistakeholder effort https://iotsecurity2018.ca/ got was that ISPs suspected that they were going to be on the hook to take the support calls. The SHG effort is partially about helping ISPs defend against being responsible for finding all the attack vectors. Helping ISPs redirect the support calls seemed like a good thing. (Redirect to where...? Still TBD) I wrote https://datatracker.ietf.org/doc/draft-richardson-shg-un-quarantine/, with the idea of bringing this forward in the RIPE IoT WG. I like writing in Markdown, and so it's on the IETF DT because RIPE has no equivalent. It's clear to me now that I'm writing a playbook! My playbook is clearly not in scope for CACOA since CACOA is about playbook technology, not playbooks themselves. Still part of my original goal in the document was to identify the parts that could be automated either through existing or developing protocols (INCH/MILE and DOTS are big on that list), or perhaps through other not-yet-developed protocols for things that clearly could be automated. I would welcome unicast feedback on how to make my document into a proper playbook. A question to the CACOA BOF is whether doing gap analysis is in scope. My feeling is that it is not, that it would attempt to boil oceans. Yet, if CACAO wants to be able to describe and sign operations, it behoves it to know what kind of things need to be done, with enough detail that we can describe the inputs to those operations. So specifically, I'm thinking that we need to have a some kind of parametric interface to the signed snippets, rather like SQL ?-parameters. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
- [Cacao] playbooks for ending-quarantines of resid… Michael Richardson
- Re: [Cacao] playbooks for ending-quarantines of r… Joseph Salowey
- Re: [Cacao] playbooks for ending-quarantines of r… Bret Jordan
- Re: [Cacao] playbooks for ending-quarantines of r… Michael Richardson
- Re: [Cacao] playbooks for ending-quarantines of r… Michael Richardson
- Re: [Cacao] playbooks for ending-quarantines of r… Jason Keirstead
- Re: [Cacao] playbooks for ending-quarantines of r… Michael Richardson
- Re: [Cacao] playbooks for ending-quarantines of r… Bret Jordan