Re: [Mud] I-D Action: draft-richardson-opsawg-mud-iot-dns-considerations-03.txt

"Panwei (William)" <william.panwei@huawei.com> Wed, 23 September 2020 09:02 UTC

Return-Path: <william.panwei@huawei.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 96F6B3A0E95; Wed, 23 Sep 2020 02:02:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 37x-zjMwzSjq; Wed, 23 Sep 2020 02:02:06 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D283B3A0E93; Wed, 23 Sep 2020 02:02:05 -0700 (PDT)
Received: from lhreml704-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id B6FA76D8116B9DD7F8F0; Wed, 23 Sep 2020 10:02:03 +0100 (IST)
Received: from nkgeml708-chm.china.huawei.com (10.98.57.160) by lhreml704-chm.china.huawei.com (10.201.108.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Wed, 23 Sep 2020 10:01:56 +0100
Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml708-chm.china.huawei.com (10.98.57.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 23 Sep 2020 17:01:54 +0800
Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1913.007; Wed, 23 Sep 2020 17:01:54 +0800
From: "Panwei (William)" <william.panwei@huawei.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
CC: opsawg <opsawg@ietf.org>, "mud@ietf.org" <mud@ietf.org>
Thread-Topic: I-D Action: draft-richardson-opsawg-mud-iot-dns-considerations-03.txt
Thread-Index: AQHWkUkqmycj0obc10qWfbjonlTmQal14YfQ
Date: Wed, 23 Sep 2020 09:01:54 +0000
Message-ID: <f61a62eba99f4e17a96d222e384f4c8a@huawei.com>
References: <160082461405.2339.249127609152770744@ietfa.amsl.com>
In-Reply-To: <160082461405.2339.249127609152770744@ietfa.amsl.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.99.125]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mud/fXW-9oun9Uyj4N3d7abP5EAE6VA>
Subject: Re: [Mud] I-D Action: draft-richardson-opsawg-mud-iot-dns-considerations-03.txt
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: Wed, 23 Sep 2020 09:02:08 -0000

Hi Michael,

This is an very useful and essential draft, I think. The DNS resolving issue may be an important obstacle for deploying MUD solution successfully.

   The simplest successful strategy for translating names is for a MUD
   controller to take is to do a DNS lookup on the name (a forward
   lookup), and then use the resulting IP addresses to populate the
   physical ACLs.
This strategy is simple, but I doubt it can't be called 'successful' as it won't work all the time. You already listed some failure scenarios.

Beyond the considerations in the draft, another method I imagine is to deploy a DNS proxy (but I don't know whether it's practical).
In the residential scenario, the CPE device is usually the MUD controller and the policy enforcement point, and it can also act as a DNS proxy. When the IoT device sends a DNS query it will send to the CPE. And CPE can first filter the unexpected DNS query by comparing the DNS names with the ones defined in the MUD file, then CPE will query the actual DNS server. When the CPE gets the answers from the actual DNS server, it can respond to the IoT devices with the answers and generate the corresponding ACLs as it knows the IP addresses now.
In the enterprise scenario, the MUD controller, the policy enforcement point, and the DNS proxy may be three different devices. The MUD controller gets the MUD file of the IoT device and dispatch the file to the DNS proxy. When the IoT device sends the DNS query to the DNS proxy, the DNS proxy can filter the DNS query as well and then get the answers by querying the real DNS server. After that, the DNS proxy will tell the IP addresses of the DNS names to the MUD controller, and the MUD controller can generate the ACLs and configure the policy enforcement point.
I'm not an DNS expert, and this is a little thought, please don't mind if it's useless.

Regards & Thanks!
Wei Pan

> -----Original Message-----
> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf
> Of internet-drafts@ietf.org
> Sent: Wednesday, September 23, 2020 9:30 AM
> To: i-d-announce@ietf.org
> Subject: I-D Action:
> draft-richardson-opsawg-mud-iot-dns-considerations-03.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
>         Title           : Operational Considerations for use of DNS in IoT
> devices
>         Author          : Michael Richardson
> 	Filename        :
> draft-richardson-opsawg-mud-iot-dns-considerations-03.txt
> 	Pages           : 13
> 	Date            : 2020-09-22
> 
> Abstract:
>    This document details concerns about how Internet of Things devices
>    use IP addresses and DNS names.  The issue becomes acute as network
>    operators begin deploying RFC8520 Manufacturer Usage Description
>    (MUD) definitions to control device access.
> 
>    This document explains the problem through a series of examples of
>    what can go wrong, and then provides some advice on how a device
>    manufacturer can best make deal with these issues.  The
>    recommendations have an impact upon device and network protocol
>    design.
> 
>    {RFC-EDITOR, please remove.  Markdown and issue tracker for this
>    document is at https://github.com/mcr/iot-mud-dns-considerations.git
>    }
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-richardson-opsawg-mud-iot-dns-con
> siderations/
> 
> There is also a HTML versions available at:
> https://www.ietf.org/id/draft-richardson-opsawg-mud-iot-dns-considerati
> ons-03.html
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-richardson-opsawg-mud-iot-dns-co
> nsiderations-03
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt