Re: [OPSAWG] [Iot-directorate] Iotdir telechat review of draft-ietf-opsawg-mud-iot-dns-considerations-12

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 27 March 2024 14:35 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 A2979C169424; Wed, 27 Mar 2024 07:35:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5_jACyFUclzS; Wed, 27 Mar 2024 07:35:12 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00:e000:2bb::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83FF6C16940A; Wed, 27 Mar 2024 07:35:10 -0700 (PDT)
Received: from dyas.sandelman.ca (60-240-91-174.static.tpgi.com.au [60.240.91.174]) by relay.sandelman.ca (Postfix) with ESMTPS id C49DE1F448; Wed, 27 Mar 2024 14:35:08 +0000 (UTC)
Authentication-Results: relay.sandelman.ca; dkim=pass (2048-bit key; secure) header.d=sandelman.ca header.i=@sandelman.ca header.b="BEz0PKgS"; dkim-atps=neutral
Received: by dyas.sandelman.ca (Postfix, from userid 1000) id 75A8BA191C; Thu, 28 Mar 2024 01:35:02 +1100 (AEDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sandelman.ca; s=dyas; t=1711550102; bh=28LelM9Ip0DfzRc8wlqGLZ/gvF1ZHrSVXlpI2yCiuck=; h=From:To:cc:Subject:In-reply-to:References:Date:From; b=BEz0PKgSKJbxdpju99P9zJBGvBqv87QimSAV3gPyKzxbEthWhbTmhUne+DTS80HPv b/4mivxqs4D14F/ahikRZc5V9U90TKagNdbf4R7Ap9yfPt3cUyL83Q/9wGo2eNhD/x Sj2fCOgsIXRkvNYCmUiHb7HkCRsKq5tqNNyTOk1ShTu32i/AXxssp49CiBb44GNl9Z 9ODTT5BJZ1xawkc277zjQ6pr9560Vj8SauwfIwt+tlK2PctU5H+wg97C+rZuTm5A/M FgTTQ/CxurHzQ6ujNDR9FelmINYNqAKlf3cz5NPPUTIgGfSdZDS34wrFjQJdc6ILvN Uobyx85BXQm6A==
Received: from dyas (localhost [127.0.0.1]) by dyas.sandelman.ca (Postfix) with ESMTP id 73999A1918; Thu, 28 Mar 2024 01:35:02 +1100 (AEDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Dave Thaler <dave.thaler.ietf@gmail.com>
cc: iot-directorate@ietf.org, mud@ietf.org, Eric Vyncke <evyncke@cisco.com>, draft-ietf-opsawg-mud-iot-dns-considerations.all@ietf.org, last-call@ietf.org, opsawg@ietf.org
In-reply-to: <170966862434.44439.11464149628011549154@ietfa.amsl.com>
References: <170966862434.44439.11464149628011549154@ietfa.amsl.com>
Comments: In-reply-to Dave Thaler via Datatracker <noreply@ietf.org> message dated "Tue, 05 Mar 2024 11:57:04 -0800."
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Thu, 28 Mar 2024 01:35:02 +1100
Message-ID: <518697.1711550102@dyas>
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/OrItKzGdRAP61odqI5BY08LmQr0>
Subject: Re: [OPSAWG] [Iot-directorate] Iotdir telechat review of draft-ietf-opsawg-mud-iot-dns-considerations-12
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 27 Mar 2024 14:35:16 -0000

Dave Thaler via Datatracker <noreply@ietf.org> wrote:
    > Section 3.2 (A successful strategy):
    >> This situation does not result in failures as long as all possible A/
    >> AAAA records are returned.  The MUD controller and the device get a
    >> matching set, and the ACLs that are set up cover all possibilities.

    > This paragraph, and various others in the draft, make a potentially false
    > assumption that the IoT device does a DNS query.

okay, so that's a good point.
Recommendation 0: use DNS?
Or maybe just clarify that the scope is only for devices that use DNS?

    > RFC 8520 section 8.1 states:
    >> 8.1 src-dnsname The argument corresponds to a domain name of a source as
    > specified by inet:host. > A number of means may be used to resolve hosts. What
    > is important is that such resolutions be consistent > with ACLs that are
    > required by Things to properly operate.“

    > As far as I can tell, MUD has no such requirement that the device use DNS to
    > resolve domain names.  Specifically, above says "A number of means may be used
    > to resolve hosts."  DNS is only one such means.

yes.
If the device has hard-coded IP addresses in the firmware (it has happened
many times, I think. There was an NTP situation a decade ago...) then that's
okay, just hard-code the same IP address into the MUD file.

If the device uses some other elaborate protocol, then I agree, it's a
problem.    I'm not sure what I should say about that, other than scope it
out of scope?

    >> A MUD controller that is aware of which recursive DNS server the IoT
    >> device will use can instead query that server on a periodic basis.

    > This is not as good as the MUD controller _being_ the recursive DNS server
    > the IoT device uses, where the ACL in the enforcement point can be updated
    > at the same time as the DNS cache is updated, when the IoT device does a
    > DNS query.  If there is a time delay between the DNS cache being updated
    > and the ACL being updated, one can get lack of connectivity since the DNS
    > cache can contain a new IP address that the enforcement point won't learn
    > about until the next time it gets around to querying DNS. I would expect
    > that connectivity failures would be NOT RECOMMENDED.

Yes. having the MUD controller be the recursive DNS server is how this whole
document got started.  We implemented exactly that for the SHG project at CIRA.ca.
Then we discussed failure situations, and enterprise situations, and 8.8.8.8 usage.

Paul Vixie has a few rants about trying to get various devices in his home to
use the (DHCP) provided DNS servers, and how often they'd wander off and use
8.8.8.8 even when the local one was working perfectly fine... and the number
of devices that fail when 8.8.8.8 is blocked.  I think he also tried
impersonating 8.8.8.8, which works fine for Do53, but ought to fail for all
secured versions, and how many devices just continued working, because they
didn't actually check the certificate.  I don't know how/if to include any of this.

    > Section 3.2 alludes to this issue when it says:

    >> Where the solution is more complex is when the MUD controller is
    >> located elsewhere in an Enterprise, or remotely in a cloud such as
    >> when a Software Defined Network (SDN) is used to manage the ACLs.
    >> The DNS servers for a particular device may not be known to the MUD
    >> controller, nor the MUD controller be even permitted to make
    >> recursive queries to that server if it is known.  In this case,
    >> additional installation specific mechanisms are probably needed to
    >> get the right view of the DNS.

    > Given the resulting connecting failures I point out, it would probably
    > be good to say such use is NOT RECOMMENDED.  But right now I think the
    > draft is remiss in not evening point out that connectivity failures
    > can easily result.

okay. I will think on how to address this.
I'll also stop here, and continue tomorrow.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*