Again, a WG whose ML is not the WG name, and there is no alias. ARGH.
Here are some emails that didn't get to [email protected].
Sorry for the duplication for others.
---------- Forwarded message ----------
From: Michael Richardson <[email protected]>
To: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, [email protected]
Cc:
Bcc:
Date: Tue, 09 Jul 2019 10:41:58 -0400
Subject: 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 <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
---------- Forwarded message ----------
From: Michael Richardson <[email protected]>
To: Eliot Lear <[email protected]>
Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, [email protected]
Bcc:
Date: Tue, 09 Jul 2019 14:38:58 -0400
Subject: Re: [OPSAWG] putting quarantined IoT devices behind a captive portal
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 =-
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
_______________________________________________
Captive-portals mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/captive-portals