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

["M. Ranganathan" <[e-mail]>]

On Tue, Jul 9, 2019 at 4:13 PM M. Ranganathan <[e-mail]> wrote:

> The current draft https://datatracker.ietf.org/doc/draft-ietf-capport-api/
>


Wrong reference, I meant


https://datatracker.ietf.org/doc/draft-richardson-shg-mud-quarantined-access/

(sorry for extra email load).

Assumes that the "quarantined device" can access a subset of the ACE's
> allowed to the "unquarantined" device.
> However, I can think of a scenario where this does not have to be the
> case. I'd propose to generalize this.
>
> i.e. There are two sets of ACL's - one for normal operation and one for
> quarantined access. (i.e. quarantine access is not necessarily a subset of
> regular access).
>
> Use case:
>
> Under normal circumstances, the device does not need SSH access (port 22
> is not open). However, if the device is misbehaving some external agent (or
> human maybe) logs in and investigates the issue.  The fix could involve
> copying new firmware.
>
> Does this make sense?
>
> Another thing that is missing currently is how to "clear" the quarantine
> state at the enforcement point. This would need an API defintion of we want
> to make that portable.
>
> Regards,
>
> Ranga
>
>
> On Tue, Jul 9, 2019 at 2:39 PM Michael Richardson <[e-mail]>
> wrote:
>
>>
>> Eliot Lear <[e-mail]> 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 <[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 =-
>>
>>
>>
>> --
>> Mud mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mud
>>
>
>
> --
> M. Ranganathan
>
>

-- 
M. Ranganathan