Subject: Re: [Captive-portals] [OPSAWG] putting quarantined IoT devices behind a captive portal

From: Michael Richardson <[email-masked]>
Date: Tue, 09 Jul 2019 20:53:00 -0400

Juergen Schoenwaelder <[email-masked]> wrote:
    > 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

Probably good enough.  Some wanted a more specific signal.

It's intended to just be a signal to go ask the captive portal API
if the device is captive.

    > (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).

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 09 Jul 2019 21:05:01 -0400

Montgomery, Douglas (Fed) <[email-masked]> wrote:
    > Most of the devices I think of as actual IoT devices have no direct
    > UI/shell.  Your only interaction with them after initial
    > “install/configure” is through their cloud web service interface.

That's true for many devices, but not all.
Even light bulbs have output interfaces :-)

    > Having said that I think your model is fine.

Good.

    > I would suggest detecting device reboot would be one signal to clear
    > quarantine state.  Since MUD “misbehavior” is mostly instantaneously
    > detectable (1 packet), I am not that concerned that the device might
    > reboot for others reasons and still be infected.

Device reboot probably needs an attestation to be believed.

    > One might keep a counter and a time stamp of quarantine clears and if
    > you a device had N MUD violations after quarantine clears in X time,
    > lock it down in quarantine or completely take it off line.

Reasonable, but in the space of quality of implementation, I think.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 09 Jul 2019 21:15:56 -0400

{my appologies for still getting captive-portal vs captive-portals@ wrong}

John Romkey <[email-masked]> wrote:
    >> Eliot Lear <[email-masked]> wrote:
    >>
    >>>> 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.
    >>
    >> Yes, so a full attack on the IoT device would do what you describe.
    >> A partial attack might miss messing this.  A reboot might clear out the
    >> malware, or might mitigate it enough (such as going to boot firmware) that
    >> would permit new firmware to be loaded.
    >>
    >> Yes, getting completely out of the quarantine would require either
    >> attestation or human intervention.  But, if the device now has good firmware,
    >> it would be able to send the "please unquarantine me" signal.

    > I believe strongly that the only safe thing you can do with a device
    > that’s been in any way compromised is completely isolate it.It
    > shouldn’t be able to send an “unquarantine” signal. You shouldn’t even
    > try to talk to it.

That's a reasonable view.
The question is: what next?
                   draft-richardson-shg-un-quarantine-00
tries to discuss this.

    > Let the firewall which is implementing MUD notify the user about the
    > problem. Let the device’s app or cloud services notify the user that
    > the device is offline. Possibly in a later evolution of MUD the
    > firewall might have a way to notify the device’s cloud service, but I
    > wouldn’t hamstring the initial version of MUD with an attempt to do
    > that.

I fully expect any notifications out should be done by the firewall.
There are two issues I'm trying to address:
  1) there will be false positives from use of MUD.  Manufacturers will
     screw up, DNS mappings will be updated out of sync with firmware, etc.
     If it is too painful to diagnose and fix, then MUD will get disabled by
     operators (ISPs, who will get the call), or by end users.

  2) not every user of a device will get the notifications.
     So devices with displays (think: thermostats, refridgerators, SIP phones,
     TV sets, etc.) whether they have real malware on them, or false
     positives should be able to indicate that they are offline.
     This matters a lot if you are trying to dial 911 on a broken phone,
     and you aren't the person with the app that gets the notifications
     from the firewall.

Putting them behind the captive-portal API when quarantined lets them get
exactly the kind of information they want.  It also helps them when they
turned on where there really is a captive-portal.