[OPSAWG] Review comments on draft-ietf-opsawg-mud-iot-dns-considerations-10

[Mahesh Jethanandani <[e-mail]>]

Hi Authors,

Here are my review comments on the above draft. They are divided between Overall, Major, Minor and Nit comments. Rob’s comments might have covered some of them, in which case feel free to ignore.

Overall:

This document needs a grammar review, preferably by somebody whose task is to edit documents. Also, the abstract refers to use of both IP address and DNS, but the Introduction talks DNS, but makes no reference to use of IP address till Section 3. Shouldn’t the Introduction section expand on the Abstract? 

It is not clear from the Abstract or from the Introduction, the problem that is being solved. Is it devices trying to access a resource in the Internet, or external parties trying to (maliciously) access or modify the MUD file? Reading RFC 8520 and this document, it appears to be the former, but it would help to clarify.

Major:

> At the MUD policy enforcement point -- the firewall -- there is a problem. The firewall has only access to the layer-3 headers of the packet. This includes the source and destination IP address, and if not encrypted by IPsec, the destination UDP or TCP port number present in the transport header. The DNS name is not present!

There are several assertions in this paragraph that could do with some clarity, and the clarity requested above might help. Again, is this in the context of traffic originating inside the device private network, or traffic originating from outside the device network? My understanding of firewalls is that the default policy for a device inside a private network is to allow access any resources in the network, and drop any traffic originating from the outside world. If this is for traffic originating from inside the device network, a temporary hole is punched in the firewall to allow the return traffic to pass through. Therefore, is the ACL for traffic originating outside the device network, or is for traffic originating inside the device network?

Minor:

Section 3. If we are comparing, should there be a Section titled “Strategies to map IP addresses”?

> The second section of this document details how common manufacturer anti-patterns get in the way of this mapping.

Definition of “anti-patterns” needs to come on first use, not later in the document.

> 	• it can not be done fast enough,


What is the definition of fast? How often do these lookups happen to make it a significant delay? And how does it compare to getting the data that one is fetching from the Internet?

> 	• it reveals usage patterns of the devices,

How is this an issue, as any effort to do a lookup or get data is going to show usage? And how is it known what the kind of device is doing the lookup. 

Nits:

- In general lot of small paragraphs, with one of two sentences per paragraph. Can they be consolidated?

- Use of acronyms Do53, DoQ, DoT or DoH. These are not common acronyms. The definitions for some of them, e.g., Do53 come much later in the document. Please define in a Terminology Section or somewhere before first use.

> IoT Devices SHOULD prefer doing DNS to with the DHCP provided DNS servers.


Grammar?

> The ADD WG has written [I-D.ietf-add-dnr] and [I-D.ietf-add-ddr] to provided.

Same here.


Mahesh Jethanandani
[e-mail]