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

[[e-mail]]

Thanks Michael for working on this.  See answers below.

> -----Original Message-----
> From: Michael Richardson <[e-mail]>
> Sent: Wednesday, March 27, 2024 7:35 AM
> To: Dave Thaler <[e-mail]>
> Cc: [e-mail]; [e-mail]; Eric Vyncke <[e-mail]>;
> [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: [Iot-directorate] Iotdir telechat review of draft-ietf-opsawg-mud-
> iot-dns-considerations-12
> 
> 
> Dave Thaler via Datatracker <[e-mail]> 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?

I'd probably suggest just clarifying 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?

Yeah, I'd probably explicitly say it's 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.

Here I'd probably say that having an enforcement point that has to make
DNS queries periodically, instead of directly using the DNS cache in the recursive
resolver used by the IoT devices, is NOT RECOMMENDED as it causes non-deterministic
connectivity failures.

Dave