Re: [OPSAWG] putting quarantined IoT devices behind a captive portal
{my appologies for still getting captive-portal vs captive-portals@ wrong}
John Romkey wrote:
>> Eliot Lear 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.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] putting quarantined IoT devices behind a captive portal
Juergen Schoenwaelder 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 , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] putting quarantined IoT devices behind a captive portal
Eliot Lear wrote: > It’s the following part that I’m thinking about: >> 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. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] putting quarantined IoT devices behind a captive portal
Michael,
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
(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).
/js
On Tue, Jul 09, 2019 at 02:38:58PM -0400, Michael Richardson wrote:
>
> Eliot Lear 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
> >> 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 , Sandelman Software Works
> >> -= IPv6 IoT consulting =-
> >>
> >>
> >>
> >>
> >>
>
>
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103
Re: [OPSAWG] putting quarantined IoT devices behind a captive portal
It’s the following part that I’m thinking about: > On 9 Jul 2019, at 20:38, Michael Richardson 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 >>> 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 , Sandelman Software Works >>> -= IPv6 IoT consulting =- >>> >>> >>> >>> >>> > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > signature.asc Description: Message signed with OpenPGP ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] putting quarantined IoT devices behind a captive portal
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)? Eliot > On 9 Jul 2019, at 16:41, Michael Richardson 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 , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > signature.asc Description: Message signed with OpenPGP ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] putting quarantined IoT devices behind a captive portal
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 , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
