Re: [Mud] [OPSAWG] putting quarantined IoT devices behind a captive portal
"M. Ranganathan" <mranga@gmail.com> Tue, 09 July 2019 20:17 UTC
Return-Path: <mranga@gmail.com>
X-Original-To: mud@ietfa.amsl.com
Delivered-To: mud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 821E912007A; Tue, 9 Jul 2019 13:17:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Level:
X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 097UFWMFz6mP; Tue, 9 Jul 2019 13:17:16 -0700 (PDT)
Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3016812006D; Tue, 9 Jul 2019 13:17:16 -0700 (PDT)
Received: by mail-io1-xd2f.google.com with SMTP id m24so36486571ioo.2; Tue, 09 Jul 2019 13:17:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ndbP5W7bl6Bhdiads/fWhSSSVWrzXxM5wWavxX1razI=; b=lteGNO0psZktOloQM6WpfaXa8Edgy/nx4jSTTYlFHcNoblASM+vVk7s4HvtDdj1zIO h+5ujcqKZjWADiajAco65nCKRIxfAxlZZzJr4yAdtrzirJd4T0r/KcTk5o+mUn549njN pZ9wWz5hfqT44U7zEmYkb9AAZIVyQZHvUKaC2ExRUfgJYCPDnDXXyk/p3cJ4yKUzAX7w QjjT3Q+odwobfgkaNpHw3xUhdUv5jscY7BkL1rBSujkzvX6tPcKiJkleloTj3cWhNzSc 71VS9wQq6/ccxUTEdo0VblROhMlZslj7V4dshqFskQg0Eg+Rd27G2GIzSq9mUkzlk/kb zx0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ndbP5W7bl6Bhdiads/fWhSSSVWrzXxM5wWavxX1razI=; b=mWGBkPcnhOCzmXr9Oz9QvmNmNvcAM1HdMz2h4JnlyAyfbwW0N642Q22sCGsnmSxL9g oIfLBORjE3UWiiIU3jgAVOEbcMYcjQw1J+I57keZY1tZI508XrHwE5kpIpDcWJO6q0I9 RSUZg48CfXpB2BS3CmYK3jODsZbqWrbHpnFH5B1T6Q0tEM0A6Vw1Ovo/y02l/MQptAFj Q7vAc+jRVxat9lgYEfkVVDHDIJ2IlSRRGErpx5C4xSKSkGdD3kYDVcseKjXW1iru9zFZ sPDQt42KAKYUk8JTiqRmH8h6ste+ARR4i7Y318B8sjB98GW2drTm5IGDHRluKToF7NBi CmYg==
X-Gm-Message-State: APjAAAXYDaVQnErBbP9YTv3bFvaAe2BHTeUYjKtx3KyUzryhrR5D8XD6 T51AKelsZ7QpxaJwgOnin+4u67ZaoxS8Gq9zCwtG7oHWXME=
X-Google-Smtp-Source: APXvYqxWts1wA9VPzp8smFra9D0UOK+z1L0l7TNwP/O+dRzFwJAcE2j9KsSLwF/A58oavk/MqtqWgUVgxyoA9V+K9U0=
X-Received: by 2002:a5d:9448:: with SMTP id x8mr28851064ior.102.1562703435320; Tue, 09 Jul 2019 13:17:15 -0700 (PDT)
MIME-Version: 1.0
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>
From: "M. Ranganathan" <mranga@gmail.com>
Date: Tue, 09 Jul 2019 16:16:39 -0400
Message-ID: <CAHiu4JPA8cmoJfyQ-xFMOX3TU7+x+j6EAeVx_WmeT7C-3zssdw@mail.gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Eliot Lear <lear@cisco.com>, "opsawg@ietf.org" <opsawg@ietf.org>, "mud@ietf.org" <mud@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000026dcba058d453f0e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mud/cjHrvVBB6XT34EEERMSY1pbiRaE>
Subject: Re: [Mud] [OPSAWG] putting quarantined IoT devices behind a captive portal
X-BeenThere: mud@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of Manufacturer Ussage Descriptions <mud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mud>, <mailto:mud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mud/>
List-Post: <mailto:mud@ietf.org>
List-Help: <mailto:mud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mud>, <mailto:mud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jul 2019 20:17:19 -0000
On Tue, Jul 9, 2019 at 4:13 PM M. Ranganathan <mranga@gmail.com> 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 <mcr+ietf@sandelman.ca> > wrote: > >> >> Eliot Lear <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/ >> ) >> 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 <mcr+ietf@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>, Sandelman Software >> Works >> >> -= IPv6 IoT consulting =- >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> >> -- >> Mud mailing list >> Mud@ietf.org >> https://www.ietf.org/mailman/listinfo/mud >> > > > -- > M. Ranganathan > > -- M. Ranganathan
- [Mud] Fwd: New Version Notification for draft-red… tirumal reddy
- Re: [Mud] New Version Notification for draft-redd… Eliot Lear
- Re: [Mud] [OPSAWG] Fwd: New Version Notification … Qin Wu
- Re: [Mud] New Version Notification for draft-redd… tirumal reddy
- Re: [Mud] [OPSAWG] Fwd: New Version Notification … tirumal reddy
- [Mud] putting quarantined IoT devices behind a ca… Michael Richardson
- Re: [Mud] [OPSAWG] putting quarantined IoT device… Eliot Lear
- Re: [Mud] [OPSAWG] putting quarantined IoT device… Michael Richardson
- Re: [Mud] [OPSAWG] putting quarantined IoT device… Eliot Lear
- Re: [Mud] [OPSAWG] putting quarantined IoT device… M. Ranganathan
- Re: [Mud] [OPSAWG] putting quarantined IoT device… M. Ranganathan
- Re: [Mud] [OPSAWG] putting quarantined IoT device… Montgomery, Douglas (Fed)
- Re: [Mud] [OPSAWG] putting quarantined IoT device… Michael Richardson
- Re: [Mud] [OPSAWG] putting quarantined IoT device… Michael Richardson
- Re: [Mud] [OPSAWG] putting quarantined IoT device… Michael Richardson
- Re: [Mud] [OPSAWG] putting quarantined IoT device… Michael Richardson
- Re: [Mud] [OPSAWG] putting quarantined IoT device… Eliot Lear
- Re: [Mud] [OPSAWG] putting quarantined IoT device… Juergen Schoenwaelder
- Re: [Mud] [OPSAWG] putting quarantined IoT device… John Romkey