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

"Montgomery, Douglas (Fed)" <dougm@nist.gov> Tue, 09 July 2019 20:33 UTC

Return-Path: <dougm@nist.gov>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B151A120025; Tue, 9 Jul 2019 13:33:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMSAoLOgvq8Z; Tue, 9 Jul 2019 13:33:29 -0700 (PDT)
Received: from GCC01-DM2-obe.outbound.protection.outlook.com (mail-eopbgr840112.outbound.protection.outlook.com [40.107.84.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41F47120024; Tue, 9 Jul 2019 13:33:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4ig92cIQ/7U5BpDIU02odRbICnBMLI2eLH2213MB8s0=; b=KNARROfZa78xmisbY0tCBwhKcspkfjJVs3n3saqcEX3sPPyb5AcIG6fhWpqsOfZeLWLnyX+g+a+9S0K/nHRcxr9eDJtNtfSFTdDxnu3WC3LLT+9RhgTJwd2Bz0qvql+Iz37EAK8balpXRxoom0W3BfQaPhHarAIB+t0lP28EJ+Y=
Received: from BN7PR09MB2596.namprd09.prod.outlook.com (52.135.255.12) by BN7PR09MB2849.namprd09.prod.outlook.com (52.135.243.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.20; Tue, 9 Jul 2019 20:33:26 +0000
Received: from BN7PR09MB2596.namprd09.prod.outlook.com ([fe80::a073:b2d8:358d:ab15]) by BN7PR09MB2596.namprd09.prod.outlook.com ([fe80::a073:b2d8:358d:ab15%7]) with mapi id 15.20.2008.014; Tue, 9 Jul 2019 20:33:26 +0000
From: "Montgomery, Douglas (Fed)" <dougm@nist.gov>
To: "M. Ranganathan" <mranga@gmail.com>, Michael Richardson <mcr+ietf@sandelman.ca>
CC: "opsawg@ietf.org" <opsawg@ietf.org>, "mud@ietf.org" <mud@ietf.org>, Eliot Lear <lear@cisco.com>, "capport@ietf.org" <capport@ietf.org>
Thread-Topic: [Mud] [OPSAWG] putting quarantined IoT devices behind a captive portal
Thread-Index: AQHVNmYv+E60kSQqYEK6zQx8mYoeGKbCnlYAgAAaTQD//8KfgA==
Date: Tue, 09 Jul 2019 20:33:26 +0000
Message-ID: <420BE1C3-BA84-4306-BD72-B7CE9905B659@nist.gov>
References: <B8F9A780D330094D99AF023C5877DABAA49CD8C1@nkgeml513-mbx.china.huawei.com> <CAFpG3gc4ijy+xH7O_9EzpzwcROu3XcTA4xpSAH9P+oyhWQzMyg@mail.gmail.com> <4486.1562683318@localhost> <7534958E-E1A6-470D-B4BB-6B88CD27B54C@cisco.com> <27334.1562697538@localhost> <CAHiu4JNjPwFu=4OEX8_HuFf+Pcgmg=fCkqd2gzki35=Qu7wM=A@mail.gmail.com>
In-Reply-To: <CAHiu4JNjPwFu=4OEX8_HuFf+Pcgmg=fCkqd2gzki35=Qu7wM=A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1c.0.190703
authentication-results: spf=none (sender IP is ) smtp.mailfrom=dougm@nist.gov;
x-originating-ip: [2610:20:6222:140:9d21:29d9:8e52:24c8]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5c6de76b-c50e-4cf6-f239-08d704acb246
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:BN7PR09MB2849;
x-ms-traffictypediagnostic: BN7PR09MB2849:
x-ms-exchange-purlcount: 7
x-microsoft-antispam-prvs: <BN7PR09MB28496BE4FB7FB0ACD772267ADEF10@BN7PR09MB2849.namprd09.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6790;
x-forefront-prvs: 0093C80C01
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(136003)(39860400002)(366004)(376002)(396003)(189003)(199004)(51444003)(6246003)(186003)(81156014)(6436002)(6306002)(54896002)(236005)(86362001)(6486002)(6512007)(4326008)(53936002)(6506007)(53546011)(2906002)(81166006)(102836004)(68736007)(76176011)(446003)(11346002)(2616005)(476003)(486006)(316002)(229853002)(110136005)(8936002)(54906003)(99286004)(58126008)(25786009)(76116006)(7736002)(256004)(14444005)(606006)(14454004)(5660300002)(478600001)(36756003)(33656002)(6116002)(64756008)(8676002)(66556008)(66476007)(46003)(66446008)(66946007)(966005)(71190400001)(71200400001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN7PR09MB2849; H:BN7PR09MB2596.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: XLBIa/IFxfcAg2N4awS8kQRjXAoVFwZd8GuccDHUj7bIvrfh5vscf8fib5KKY0jHb9v8Sq5hrRapX3nfUlIbzeem14Vi5r+zKs7DZ8TvGawNXVv6bXSbN6BlcuEne8Y+q2HP4416BBrxIZF/y5dIuFz8h1Yvl+AhRABaNqU1VHWucKJHpOhwL2/N5DdKKVmxUVA1/v71bcwAFw3OusAziS6FtnZqdGVauZA5sR0p+qjZeVVahWA5WgSWWUkZh4yLhU3HExNUMERj1jmYFmM1QSwv1sk5Z/KvTGREd+/pD5wUD0PwRu9gw3qnXRS+1SyyMdE9oBgJwG/TJUjuoiUDoBvsOIbW8fDn7hL/DWXmwC7Hfit6anELYlLYIAeMmdxTAnqncSqeqJ9vbOce6rMS9dawCoar9dR7QHbnRaZ8FI4=
Content-Type: multipart/alternative; boundary="_000_420BE1C3BA844306BD72B7CE9905B659nistgov_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-Network-Message-Id: 5c6de76b-c50e-4cf6-f239-08d704acb246
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2019 20:33:26.6035 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: dougm@nist.gov
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR09MB2849
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/ZtgOEQFEz02oDUpWf7i8Ypzy3Ag>
Subject: Re: [OPSAWG] [Mud] putting quarantined IoT devices behind a captive portal
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jul 2019 20:33:34 -0000

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.  Having said that I think your model is fine.

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.

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.

dougm

--
DougM at NIST


From: "IETF-MUD LIST:" <mud-bounces@ietf.org> on behalf of Mudumbai Ranganathan <mranga@gmail.com>
Date: Tuesday, July 9, 2019 at 4:13 PM
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: "opsawg@ietf.org" <opsawg@ietf.org>, "mud@ietf.org" <mud@ietf.org>, Eliot Lear <lear@cisco.com>, "capport@ietf.org" <capport@ietf.org>
Subject: Re: [Mud] [OPSAWG] putting quarantined IoT devices behind a captive portal

The current draft https://datatracker.ietf.org/doc/draft-ietf-capport-api/<https://datatracker.ietf..org/doc/draft-ietf-capport-api/>
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 <mcr+ietf@sandelman.ca<mailto:mcr%2Bietf@sandelman.ca>> wrote:

Eliot Lear <lear@cisco.com<mailto:lear@cisco.com>> 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/<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-richardson-shg-mud-quarantined-access%2F&data=02%7C01%7Cdougm%40nist.gov%7Ca08eabd297e242cbe7fb08d704a9f772%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636983000363419649&sdata=t5GQKZst%2BCezofO4a7vGekkILbIkf%2FSWmG5vfcX9Ao4%3D&reserved=0>)
would go into a captive portal system.

Such a system would, according to
https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-capport-architecture%2F&data=02%7C01%7Cdougm%40nist.gov%7Ca08eabd297e242cbe7fb08d704a9f772%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636983000363429646&sdata=%2FYsk7daSV5qv%2B%2B5gS7YDyH%2BhlwDZhkdbrYij9RQn8GA%3D&reserved=0>
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/<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-capport-api%2F&data=02%7C01%7Cdougm%40nist.gov%7Ca08eabd297e242cbe7fb08d704a9f772%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636983000363429646&sdata=Na%2FWWVybCuYWxOYILb%2BOlL99q1bZNz0qopbhVWggqI4%3D&reserved=0>
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/<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-capport-rfc7710bis%2F&data=02%7C01%7Cdougm%40nist.gov%7Ca08eabd297e242cbe7fb08d704a9f772%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636983000363439631&sdata=Nafuv7GJEwFuQeA5GxByWPU8aJGd5Dxunv%2FbOyqsFjA%3D&reserved=0> can deliver
via DHCPv4/v6 or RA.


    >> On 9 Jul 2019, at 16:41, Michael Richardson <mcr+ietf@sandelman..ca<mailto:mcr%2Bietf@sandelman.ca>>
    >> 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 <mcr+IETF@sandelman.ca<mailto:mcr%2BIETF@sandelman.ca>>, Sandelman Software Works
    >> -= IPv6 IoT consulting =-
    >>
    >>
    >>
    >>
    >>


--
Michael Richardson <mcr+IETF@sandelman.ca<mailto:mcr%2BIETF@sandelman.ca>>, Sandelman Software Works
 -= IPv6 IoT consulting =-



--
Mud mailing list
Mud@ietf.org<mailto:Mud@ietf.org>
https://www.ietf.org/mailman/listinfo/mud<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmud&data=02%7C01%7Cdougm%40nist.gov%7Ca08eabd297e242cbe7fb08d704a9f772%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636983000363439631&sdata=jfX9DMHG9ccfEW92JCQWhPO1FAXKFGf2o4L1M3lTlJY%3D&reserved=0>


--
M. Ranganathan