[Last-Call] Dnsdir last call review of draft-ietf-opsawg-mud-iot-dns-considerations-12

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Reviewer: Nicolai Leymann
Review result: Ready with Issues

Hi,

I was assigned as the dnsdir reviewer for
draft-ietf-opsawg-mud-iot-dns-considerations.

The draft is on BCP track and details concerns related to the use of IP
addresses and DNS names by IoT devices specifically when using MUD 
(Manufacturer Usage Description) and makes proposals how DNS can be used in the
context of MUD files.

There were already several reviews in the past and a fair amount of discussion
on the mailing list. As far as I can see most of the comments made by the
reviewers and on the mailing list have been addressed in the latest version of
the draft.

The draft has a clear structure, but needs some "language polishing" (also see
nits below) and there are a few minor issues which should be fixed.

Major issues:
none

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 communication
  is being used. Protocols such as DoH or DoT provide encryption,

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 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?

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
  resolver provided by an ISP (sitting in network of ISP and being used by end
  devices in home/local networks)? Is the assumption that the public resolvers
  will be used in addition to resolvers provided by the network?

Nits:
Section 3.1:
        - "Attempts to map IP address to names …" -> "attempts to map IP
        addresses to names …" - "the mapping are …" -> "the mappings are …"
Section 4.1:
        - "avoid a IP address literal" -> "avoid an IP address literal"
Section 5:
        - "For some users and classes of device" -> "For some users and classes
        of devices"

Regards

Nic


-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux