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

Eliot Lear <lear@cisco.com> Tue, 09 July 2019 14:54 UTC

Return-Path: <lear@cisco.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 B6BFD120165; Tue, 9 Jul 2019 07:54:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 KbrG76NsrjAW; Tue, 9 Jul 2019 07:54:08 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DCE612016A; Tue, 9 Jul 2019 07:54:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1819; q=dns/txt; s=iport; t=1562684048; x=1563893648; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=pX7SE1Yy28cTJo69wsR84zkvGex97mjQdAogoJWaVKE=; b=WAqqMNKchzkEtnQhEXCEDnStnHlUUtlDvPmktR4lTMO1RYtmOboq1JW7 Vsl/mMOQ2X42YuHPB/Nu/Q2CF853A+RjCy2zK6kyfa1ZUGS91C6pnigcR iobJf/Bc9bWEbdqThrq8p9Xigh7+zplkszigPsSiBel+iEZHqTUJ9wYlB 0=;
X-Files: signature.asc : 195
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AWAACXqSRd/xbLJq1mGgEBAQEBAgEBAQEHAgEBAQGBVgIBAQEBCwGCFmpSIBIohByIe4tzmm8CBwEBAQkDAQEvAQGBS4J1AoJmNwYOAQMBAQQBAQIBBW2FSIVKAQEBAQIBI1YFCwsYKgICVwYTgyIBgXsPq3OBMoVHhF0QgTQBgVCKJYF/gTgfgkw+h04ygiYElGaVbAmCGYIfgQyEbYttG4IslVShZIMKAgQGBQIVgWYigVgzGggbFWUBgkE+kEk9AzCQBAEB
X-IronPort-AV: E=Sophos;i="5.63,470,1557187200"; d="asc'?scan'208";a="14118064"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Jul 2019 14:54:05 +0000
Received: from dhcp-10-61-105-202.cisco.com (dhcp-10-61-105-202.cisco.com [10.61.105.202]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x69Es56w016592 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 Jul 2019 14:54:05 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <7534958E-E1A6-470D-B4BB-6B88CD27B54C@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_6DD4917D-FC86-4217-A788-C0367EA1BB1C"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 09 Jul 2019 16:54:04 +0200
In-Reply-To: <4486.1562683318@localhost>
Cc: "opsawg@ietf.org" <opsawg@ietf.org>, "mud@ietf.org" <mud@ietf.org>, capport@ietf.org
To: Michael Richardson <mcr+ietf@sandelman.ca>
References: <B8F9A780D330094D99AF023C5877DABAA49CD8C1@nkgeml513-mbx.china.huawei.com> <CAFpG3gc4ijy+xH7O_9EzpzwcROu3XcTA4xpSAH9P+oyhWQzMyg@mail.gmail.com> <4486.1562683318@localhost>
X-Mailer: Apple Mail (2.3445.104.11)
X-Outbound-SMTP-Client: 10.61.105.202, dhcp-10-61-105-202.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/mud/c-8yTyMR2b7JnsP6NNAjhhww_gI>
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 14:54:11 -0000

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 <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 =-
> 
> 
> 
> 
>