On Tue, Jul 9, 2019 at 4:13 PM M. Ranganathan <[email protected]> wrote:
> The current draft https://datatracker.ietf.org/doc/draft-ietf-capport-api/ > Wrong reference, I meant https://datatracker.ietf.org/doc/draft-richardson-shg-mud-quarantined-access/ (sorry for extra email load). Assumes that the "quarantined device" can access a subset of the ACE's > allowed to the "unquarantined" device. > However, I can think of a scenario where this does not have to be the > case. I'd propose to generalize this. > > i.e. There are two sets of ACL's - one for normal operation and one for > quarantined access. (i.e. quarantine access is not necessarily a subset of > regular access). > > Use case: > > Under normal circumstances, the device does not need SSH access (port 22 > is not open). However, if the device is misbehaving some external agent (or > human maybe) logs in and investigates the issue. The fix could involve > copying new firmware. > > Does this make sense? > > Another thing that is missing currently is how to "clear" the quarantine > state at the enforcement point. This would need an API defintion of we want > to make that portable. > > Regards, > > Ranga > > > On Tue, Jul 9, 2019 at 2:39 PM Michael Richardson <[email protected]> > 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 =- >> >> >> >> -- >> Mud mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/mud >> > > > -- > M. Ranganathan > > -- M. Ranganathan
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
