Subject: [OPSAWG] putting quarantined IoT devices behind a captive portal (fwd) Michael Richardson: putting quarantined IoT devices behind a captive portal

From: Michael Richardson <[email-masked]>
Date: Tue, 09 Jul 2019 14:41:22 -0400

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 [email-masked].
Sorry for the duplication for others.

Subject: putting quarantined IoT devices behind a captive portal
From: Michael Richardson <[email-masked]>
To: "opsawg\@ietf.org" <[email-masked]>, "mud\@ietf.org" <[email-masked]>, [email-masked]
Date: Tue, 09 Jul 2019 10:41:58 -0400

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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

Subject: Re: [OPSAWG] putting quarantined IoT devices behind a captive portal
From: Michael Richardson <[email-masked]>
To: Eliot Lear <[email-masked]>
Cc: "opsawg\@ietf.org" <[email-masked]>, "mud\@ietf.org" <[email-masked]>, [email-masked]
Date: Tue, 09 Jul 2019 14:38:58 -0400

Eliot Lear <[email-masked]> 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 <[email-masked]>
    >> 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 <[email-masked]>, Sandelman Software Works
    >> -= IPv6 IoT consulting =-
    >>
    >>
    >>
    >>
    >>

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Erik Kline <[email-masked]>
Date: Sat, 20 Jul 2019 23:33:44 -0400

Most discussion has, co-chair hat off, be circling around some minimal
working API mechanism to get things started.

That said, one could easily imagine, for example, something as simple as an
additional API boolean key,

    "quarantined": true|false,

Perhaps once there's some experience with 7710bis+API implementation...

On Tue, 9 Jul 2019 at 14:41, Michael Richardson <[email-masked]>
wrote:

> ---------- Forwarded message ----------
> To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>,
> [email-masked]
> Cc:
> Bcc:
> ---------- Forwarded message ----------
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>,
> [email-masked]
> Bcc:
> I
> (I
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Jul 2019 20:03:49 -0400

> That said, one could easily imagine, for example, something as simple
    > as an additional API boolean key,

    > "quarantined": true|false,

I think that I want to implement exactly this then.

This means providing the API info in the DHCPv4 to all devices, but
for many devices, even though there is no restriction at all. 

A concern that was recently raised is attackers that might attempt to
impersonate other devices (same L2/L3 address), and do things to trigger
quarantine.  Once you train the users to unquarantine without thinking...

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [