Thank you for the review and kind words.
Nicolai Leymann via Datatracker <noreply@xxxxxxxx> wrote:
> Minor issues: Section 3.1.2: - "This does not require access to all
> on-path data, just to the DNS requests to the bottom level of the DNS
> tree."
NL> Data of DNS requests is only visible if a non encrypted
NL> communication is being used. Protocols such as DoH or DoT provide
NL> encryption,
Well.
1. recursive to authoritative requests are *not yet* ubiquitously encrypted.
(we can root for RFC9539, but...)
2. unless the in-addr.arpa zone is part of a bigger entity (Amazon EC2...),
then even just traffic analysis might show which reverse zone is being
looked up.
So I'm not sure I know what to do with your comment.
> Section 3.2: - I think the assumption is correct that there is a good
> chance that in typical home network CPEs, MUD controller and recursive
> resolver are running on the same deviced (the CPE). ○ NL: I might be
> worthwhile to mention that not all IoT devices necessarily use the DNS
> server provided by the network (e.g., they may default to one of the
> large open resolvers).
Section 6.5 explicitely recommends that they use the local resolver.
I've added, in section 3.2:
} If the IoT device did not use the same recursive servers as the MUD
} controller, then geofencing and/or truncated round-robin results could return
} a different, and non-overlapping set of addresses.
> Section 3.2: - "Properly designed recursive servers should cache data
> for at least some number of minutes, up to some number of days, while
> the underlying DNS data can change at a higher frequency, providing
> different answers to different queries!" ○ NL: Not sure if I got
> this. Can you be a bit more clear how "number of minutes/number of
> days" is related to TTLs used in DNS?
Some operators change their DNS answers based upon load, geography, and some
of them do it at a rate faster than the TTL on the data. That's usually
because the other answers aren't wrong, just not optimal.
Also, many recursive servers cache things for some minimum TTL, often 30s.
Given this, what text do you suggest I fix?
> Section 6.1: - "Finally, the list of public resolvers that might be
> contacted MUST be listed in the MUD file as destinations that are to be
> permitted! This should include the port numbers (i.e., 53, 853 for DoT,
> 443 for DoH) that will be used as well."
nl> What is the difference between a public resolver (e.g. 8.8.8.8) and a
nl> resolver provided by an ISP (sitting in network of ISP and being used
nl> by end devices in home/local networks)? Is the assumption that the
nl> public resolvers will be used in addition to resolvers provided by the network?
when an IoT device that uses the DHCP provided local IP addresses ("192.168.1.1",
fe80::1, etc.), it is a reasonable assumption that the MUD controller will
permit access to those IPs by default.
(Further , since the list of local resolvers can't be predicted, they can't
be put into the MUD file)
An IoT device that expects to be able to reach 8.8.8.8 will need to list
access to that IP address in it's MUD file. Whether or not it actually uses
that address in a particular installation or not is a different thing.
> Nits: Section 3.1: - "Attempts to map IP address to names …" ->
> "attempts to map IP addresses to names …"
check.
> - "the mapping are …" -> "the mappings are …"
check.
> Section 4.1: - "avoid a IP address literal" -> "avoid
> an IP address literal"
check
> Section 5: - "For some users and classes of
> device" -> "For some users and classes of devices"
check.
https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-mud-iot-dns-considerations/pull/14/files
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] mcr@xxxxxxxxxxxx http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
Attachment:
signature.asc
Description: PGP signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
