Dave Thaler via Datatracker <noreply@xxxxxxxx> 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@xxxxxxxxxxxx http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
Attachment:
signature.asc
Description: PGP signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
