[Mud] putting quarantined IoT devices behind a captive portal (fwd) Michael Richardson: putting quarantined IoT devices behind a captive portal
Michael Richardson <mcr+ietf@sandelman.ca> Tue, 09 July 2019 18:41 UTC
Return-Path: <mcr+ietf@sandelman.ca>
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 7F18B120A5B; Tue, 9 Jul 2019 11:41:37 -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 ZFG6u4iTe67u; Tue, 9 Jul 2019 11:41:34 -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 EA5C0120A51; Tue, 9 Jul 2019 11:41:23 -0700 (PDT)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 887973808A; Tue, 9 Jul 2019 14:39:20 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E44DC5D0; Tue, 9 Jul 2019 14:41:22 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: captive-portals@ietf.org, opsawg@ietf.org, mud@ietf.org
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: Tue, 09 Jul 2019 14:41:22 -0400
Message-ID: <27897.1562697682@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mud/g3u66GDEi4CZCUrN1x_Lz3rPaoM>
Subject: [Mud] putting quarantined IoT devices behind a captive portal (fwd) Michael Richardson: putting quarantined IoT devices behind a captive portal
X-BeenThere: mud@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of Manufacturer Ussage Descriptions <mud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mud>, <mailto:mud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mud/>
List-Post: <mailto:mud@ietf.org>
List-Help: <mailto:mud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mud>, <mailto:mud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jul 2019 18:41:38 -0000
Again, a WG whose ML is not the WG name, and there is no alias. ARGH. Here are some emails that didn't get to captive-portals@ietf.org. Sorry for the duplication for others.
--- Begin Message ---Between editing drafts yesterday, I got to thinking about CAPPORT. I have been working on what to do when an IoT device violates it's MUD profile. There are a bunch of issues around this. Yesterday, it occured to me that when such a device is quarantined (I really think it should be "quaranteed", but that's not a word) that the capport controls and APIs should be available to the device to learn what went on. This is not new, I think that this as been the approach of most enterprise NEA systems upon encountering "infection". This has, I assume, involved forced HTTP proxies to inform human. But, if we have APIs, we can inform device as well. Is this on anyone's radar? -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =---- End Message ---
--- Begin Message ---Eliot Lear <lear@cisco.com> wrote: > I’m not quite certain how it would work. Can you show a flow that will > work for an IoT device (e.g., headless and no display)? Device gets quarantined, and the MUD-controller moves it into an isolated "VLAN". I put air/scare quotes around VLAN, because it's a "MAC-address VLAN", not an 802.1Q thing. It's really just a layer-2 ACL. {We have no way to force the mishaving device into tagging it's packets, nor can we force it onto some other ESSID. We can't do a "port-based" VLAN, because wifi has no ports, and we don't really know how many unmanaged switches might be on the port anyway. One might map this onto a IEEE 802.1Q VLAN across a backbone} Instead of just dropping all traffic for a device in this category, all traffic (other than excepted traffic if you implement https://datatracker.ietf.org/doc/draft-richardson-shg-mud-quarantined-access/) would go into a captive portal system. Such a system would, according to https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/ receive a message when it initiates connections which are not allowed. (While the capport WG contemplated an ICMP unreachable message with a URI in it at one point, that is not the current design) Actually, I have no idea from reviewing the documentation what the appropriate "you might be captive" ICMP is now.. THERE IS ONE RIGHT? Once the IoT device gets such a message, it can use the API described at: https://datatracker.ietf.org/doc/draft-ietf-capport-api/ to retrieve a JSON object telling it that it is captive. At which point, it can flash a LED, or attempt a firmware upgrade, or maybe just reboot if a timer goes off. (%) This requires that the IoT device get the captive portal API end point, which https://datatracker.ietf.org/doc/draft-ietf-capport-rfc7710bis/ can deliver via DHCPv4/v6 or RA. >> On 9 Jul 2019, at 16:41, Michael Richardson <mcr+ietf@sandelman.ca> >> wrote: >> >> Signed PGP part >> >> Between editing drafts yesterday, I got to thinking about CAPPORT. I >> have been working on what to do when an IoT device violates it's MUD >> profile. There are a bunch of issues around this. >> >> Yesterday, it occured to me that when such a device is quarantined (I >> really think it should be "quaranteed", but that's not a word) that >> the capport controls and APIs should be available to the device to >> learn what went on. >> >> This is not new, I think that this as been the approach of most >> enterprise NEA systems upon encountering "infection". This has, I >> assume, involved forced HTTP proxies to inform human. But, if we have >> APIs, we can inform device as well. >> >> Is this on anyone's radar? >> >> -- >> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> >> >> -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =---- End Message ---
-- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
- [Mud] putting quarantined IoT devices behind a ca… Michael Richardson
- Re: [Mud] [Captive-portals] putting quarantined I… Erik Kline
- Re: [Mud] [Captive-portals] putting quarantined I… Michael Richardson