[OPSAWG] 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: 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 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/opsawg/hyIgDeIroAbdk10rHgYk8yXoAkI>
Subject: [OPSAWG] putting quarantined IoT devices behind a captive portal (fwd) Michael Richardson: putting quarantined IoT devices behind a captive portal
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: 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 =-