Re: [Mud] [OPSAWG] putting quarantined IoT devices behind a captive portal

[Eliot Lear <[e-mail]>]

It’s the following part that I’m thinking about:

> On 9 Jul 2019, at 20:38, Michael Richardson <[e-mail]> 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 <[e-mail]>
>>> 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 <[e-mail]>, Sandelman Software Works
>>> -= IPv6 IoT consulting =-
>>> 
>>> 
>>> 
>>> 
>>> 
> 
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
>