Michael, would an ICMP "administratively prohibited" not be a sufficient signal? Sure, things can be made much more complex, but I doubt that devices will try to actively investigate why they can't communicate (and implement additional protocols for this) if all they can do at the end is to change the color of an led or simply shut-off (i.e., stop assuming its a temporary network issue and reduce/stop probing effort).
/js On Tue, Jul 09, 2019 at 02:38:58PM -0400, Michael Richardson wrote: > > 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 =- > > > > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
