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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 24 September 2020 14:46 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 4D01D3A0D47; Thu, 24 Sep 2020 07:46:40 -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 ZyovgcZZVUll; Thu, 24 Sep 2020 07:46:38 -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 BF0EE3A0A02; Thu, 24 Sep 2020 07:46:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 86BF9389B4; Thu, 24 Sep 2020 10:25:13 -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 fx8mn9JC-vU5; Thu, 24 Sep 2020 10:25:13 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A767C389B3; Thu, 24 Sep 2020 10:25:12 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 675D1824; Thu, 24 Sep 2020 10:46:36 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Eliot Lear <lear@cisco.com>, opsawg <opsawg@ietf.org>, "mud\@ietf.org" <mud@ietf.org>
In-Reply-To: <C614A7E9-EF1C-4A8E-BD5A-A17C074F3E09@cisco.com>
References: <160082461405.2339.249127609152770744@ietfa.amsl.com> <f61a62eba99f4e17a96d222e384f4c8a@huawei.com> <16821.1600885661@localhost> <C614A7E9-EF1C-4A8E-BD5A-A17C074F3E09@cisco.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:46:36 -0400
Message-ID: <6718.1600958796@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/HT47c818VSQtoYxYwyztcU5LIW0>
Subject: Re: [OPSAWG] 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:46:40 -0000

Eliot Lear <lear@cisco.com> wrote:
    >> On 23 Sep 2020, at 20:27, Michael Richardson <mcr+ietf@sandelman.ca> 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.
    >> If it does this DNS lookup on a regular basis (updating the MUD ACLs
    >> implemented in the forwarding plane), then the cache stays warm, and the
    >> rules are accurate.
    >>
    >> This is how our implementation worked.

    > Either this, or there should be a relationship between the resolver and
    > the AP/switch/firewall/CPE in which appropriate query responses are
    > shared. That might be the better long term approach.

So you are imagining some channel from the recursive DNS resolver(s) which
basically just stream all name->IP pairs being cached.
An MQTT channel or encrypted multicast or CoAP Observe.

The policy enforcement point(s) would then be in charge of updating the ACLs
that were installed with names.
One could even hash the names into some number of channels if the update rate
was otherwise too busy.

    > What is key- in
    > order for protection to work, the infrastructure needs to know (1) what
    > names are authorized and (b) their associated addresses.  As important,
    > its understanding must be the same as that of the device that makes the
    > query.

Yes.  The common understanding of the mapping is key.

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