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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 24 September 2020 14:43 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 0E3CB3A0CB4; Thu, 24 Sep 2020 07:43:39 -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=[BAYES_00=-1.9, SPF_HELO_NONE=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 ADa6RziQFxgg; Thu, 24 Sep 2020 07:43:36 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2BAE3A0D47; Thu, 24 Sep 2020 07:43:35 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 30C8F389BC; Thu, 24 Sep 2020 10:22:01 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rPCrjnzXm9sr; Thu, 24 Sep 2020 10:21:59 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C5BAC389B4; Thu, 24 Sep 2020 10:21:58 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 85145824; Thu, 24 Sep 2020 10:43:22 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Panwei \(William\)" <william.panwei@huawei.com>, opsawg <opsawg@ietf.org>, "mud\@ietf.org" <mud@ietf.org>
In-Reply-To: <fc5c7df524a54c2fb4033222feee8277@huawei.com>
References: <160082461405.2339.249127609152770744@ietfa.amsl.com> <f61a62eba99f4e17a96d222e384f4c8a@huawei.com> <16821.1600885661@localhost> <fc5c7df524a54c2fb4033222feee8277@huawei.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Thu, 24 Sep 2020 10:43:22 -0400
Message-ID: <6015.1600958602@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/qEg-7wyMLI7lA0TFTBkIA7Iup6U>
Subject: Re: [OPSAWG] [Mud] I-D Action: draft-richardson-opsawg-mud-iot-dns-considerations-03.txt
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: Thu, 24 Sep 2020 14:43:39 -0000

Panwei (William) <william.panwei@huawei.com> wrote:
    >> Yes, the CPE could look at the DNS queries the device is using, and then
    >> cache them.   Or, when it loads the MUD file, it could do a DNS lookup on
    >> all the names, and cache them.  Then, when the device asks, it is already
    >> cached, and one can be sure that a known IP/name combination is
    >> returned.

    > I think the 'cache' here means a pre-query. But the cached IP/name may
    > be incorrect if the real DNS server changes the answer.

That's why an extra layer of proxy is not helpful: it's already present.
No additional middle boxes are needed.

A recursive DNS server caches answers and, in a sense proxies, the question.
It pays attention to the provided TTL, and expires the data when it happens.

The MUD controller needs to know the TTL of all things it looks up, so that
it can look them up again before the TTL expires.
The operator of the service can't update their servers faster than the TTL
anyway (because clients can cache the result), so there won't be any
inconsistency.

A DNS TTL of 0 is permitted however, and either this document needs to recommend
against doing that, or provide some guidance.  I'm not sure what the right
answer yet.

    > What I suggest is no pre-queries. The IoT device sends a DNS query to
    > the DNS proxy, and the DNS proxy queries the real DNS server. So the
    > DNS proxy can 1) filter the illegal DNS queries which are not defined
    > in the MUD file, and 2) know the DNS answer exactly with the IoT
    > device.

I see.
This depends upon the IoT query always travelling via the same path to the
same recursive DNS server.  That's why you've put this proxy in place.
I think that this just introduces an additional single point of failure, when
DNS has already provided redundancy.  That is, it makes DNS less reliable.

Doing the queries when installing the ACLs leverages the resilience rather
than reduces it.

Perhaps, however, the MUD controller should perform the query to all
recursive DNS servers and should merge the results if they are not
identical.

    >> If you can generate the ACL on demand fast enough, it can work.
    >> Many IoT devices, if DNS seems slow, will switch to 8.8.8.8.
    >> Google Chromecast for instance, always sends to both local and 8.8.8.8 from
    >> what I've read, and uses which ever is faster.

    > The CPE can block the DNS query to 8.8.8.8 and force the IoT device to wait.

It could do that.

    >> > 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.
    >>
    >> Sure, that's essentially correct.
    >> The DNS proxy is just the local recursive resolver.
    >> What counts is that the MUD controller and the IoT device use the same
    >> recursive resolver, and see the same cache.

    > Yes.
    > Also, I assume the IoT device won't do DNS lookup frequently, so
    > updating the cache each time when the IoT device sends the DNS query
    > can be acceptable.

I agree that this would reduce the DNS lookup frequency.

In the end, either strategy can work, as long as the IoT device can be
convinced to always do DNS queries to a place that the MUD controller knows
about.

Updating the ACLs based upon DNS queries means that there has to be some new
active entity in the DNS lookup path, and this may be much harder to deploy.
For home gateways, it's all degenerate, so both methods are probably
equivalent.  For enteprises, it is not.
DNS recursive services are something which enterprise operators tend to be
reluctant to mess with, as it often have profound effects on the desktop user
experience.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide