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 =-
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 =-
Description: PGP signature
--- End Message ---
-- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
