[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Captive-portals] putting quarantined IoT devices behind a captive portal (fwd) Michael Richardson: putting quarantined IoT devices behind a captive portal

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

Attachment: signature.asc
Description: PGP signature


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


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

Attachment: signature.asc
Description: PGP signature


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

Attachment: signature.asc
Description: PGP signature