It’s the following part that I’m thinking about: > On 9 Jul 2019, at 20:38, Michael Richardson <[email protected]> wrote: > > 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. (%) >
You are suggesting that a device self-remediate. Some devices may be able to eventually do that, but I have my doubts. Were I a hacker, I would have the device pretend to do just that. And so this ties somewhat to RATS. I think a MUD extension might be able to help in as much as one could imagine a “remediation” recommendation. Eliot > 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 =- > > >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
